CmdrKeene

Hey thank you for your interest, I must have forgotten to post back because I did get it added to my top header area, the magnifying glass will show at the top of https://cmdrkeene.com on mobile now for me, so I’m happy.

Conversion tracking was working for me using Sitekit before the new GA4 property (and apparently still is in the UA property). Is this related to this discussion and GA4 will sometime in the future start picking up my woo checkout conversions as the UA one does?

I don’t know why but if I upload media from wordpress.com and let it synchronize to the site (jetpack rpc I guess), it doesn’t crash the server although it takes like 3 full minutes for a 1mb png picture. Looking on my server’s actual FTP in the uploads directory I see the file pop in in about 12 different sizes. I wonder if that work is what’s causing the issue.

I’m sort of inclined to think it’s the later case at the moment. I connected by SSH and from the top command and although 2GB seems low to me, the utilization is so low I assume this must be normal.

I want to try uploading media now and watch this. I don’t think I’ve ever seen a memory usage peak here but I have seen CPU usage climb high, especially (perhaps only) when trying to import media. Most public facing pages are heavily cached and don’t touch the server and traffic is really low anyway. Admin pages aren’t cached though and I see CPU load average climb over 1.00 if I’m in admin changing products or things.

I have users on the site right now and I’d rather avoid taking the site offline for 5-10 minutes at a time at the moment. I will explore late tonight around midnight (about 12 hours from now) and see what I can learn or if repairing tables in phpmyadmin helps.

All my other wordpress sites have always been on really basic shared hosting, this is the only one I’ve ever had such real direct server access to beyond the bare basic cPanel things. And I realize that’s way out of scope of “WordPress” but I do worry this thing isn’t configured right or something. Although this site was just as buggy before Bluehost migrated us to VPS (which for all I know, the “migration” was just granting us this WHM access and didn’t involve moving the site at all, it’s been a black box to me).

You can probably guess that bluehost has been of absolutely zero help whatsoever.

Discovered the Cloudflare “Bot Blocker” was causing my issue.

Thanks, I appreciate that knowledge. I know in some cases these look like obvious probing (sometimes even from humans), but it appears a great volume of these are coming from MSN/Bing bot trying to crawl nonsense pages and URL paths that don’t exist and never existed.

That’s totally separate issue that has nothing to do with WF itself though.

Bing seems to think it’s seeing a 302 when it hits the URL (WF firewall shows a 503) and when I test the URL in a browser I see my 404 page (and testing with a header checking site does indeed show a 404 header is returned) so I don’t know why the bing bot keeps trying it hit it anyway. But that’s definitely not a WF problem so I’ll take the problem to bing.

I believe I’m having the same problem with my site that uses WooCommerce ShipStation + Wordfence.

Thanks for the reply but that is unfortunately not the cause. The password reset emails are correctly being generated by the server and sent, they just don’t arrive to gmail accounts. They arrive to all other email service recipients.

Darn, I was really hoping I could customize my child-theme created by it to modify the template and just move that snippet elsewhere. Thanks anyway.

I use Cloudflare for DNS and from what I can tell their cache controls are default to only applying to resources. There’s a descriptor on the page that says “Note: By default, Cloudflare does not cache HTML content. You can create a Page Rule to cache static HTML content.”

Since I have no such rules, am I understanding correctly that I’m OK to keep WP Super Cache enabled right now? Is there a way to definitively check that I’m not causing any problems?

As far as I can tell there’s no additional way for me to “disable” cloudflare other than pointing my nameservers directly to my host instead of to CF, but if there’s another option I should check to make sure CF isn’t going to cause issues, please let me know.

Awesome, thanks! It’s the little things sometimes that make a big difference.

Thanks much. I posted it over in the “Storefront theme” forum at Support ? Theme: Storefront ? White Font on White Background in Block Editor

@joyously you are spot on, I didn’t even know themes put styles into the editor. But after making a tweak to the homepage font color in the theme customizer panel to a darker gray text, I came back to /admin and found it changed the color of paragraphs in the editor to be the same gray color 7c7c7c. I guess it’s rare for the Storefront theme that WooCommerce recommends to have a dark background used and I’m the first to notice or at least report this.

I’m guessing at this point the only way to fix it is to split it into a child theme and go fix the CSS in the child so it doesn’t apply to the admin editor.

What indicates that? It does it for all the block types I use like paragraph or list. I thought those were standard parts of this new editor. What’s it called again Gutenberg maybe. I can’t remember