BluehostSupport

Hey there! We dug into this and the key detail is that the 503s were tied specifically to direct hits to the /cart/ URL, not to your store’s actual working cart. In your case, /cart/ was not the live WooCommerce cart endpoint anymore (your active cart page was set to a different page in WooCommerce settings), but /cart/ was still being requested directly. Those direct requests were kicking off heavier PHP work than a normal page view and, on shared hosting, that can exhaust the available PHP workers and cause Apache to return a 503 because it can’t get a response back in time.

Once we removed a temporary test MU-plugin that was intercepting that path, the 503s stopped completely. After that, /cart/ correctly returns a 404, which confirms it is not a valid cart page on the site right now. Meanwhile, the cart continued to work normally when accessed through the site’s actual UI flow.

The permanent fix should be relatively simple: either point WooCommerce’s Cart page back to a page that lives at /cart/, or set a permanent redirect so any requests to /cart/ go to the real cart page you’re using now (the one currently assigned in WooCommerce settings). No server-side tuning is needed if the routing is corrected.

From what we can see on the install, the site is using Blockbase as the parent and Arbutus from WordPress.com as the child theme. So the Arbutus theme package you wanted is installed and active, which is good news. The issue now is more about what WordPress is being asked to show on the front end.

When you deleted the earlier pages and posts, WordPress was left with almost nothing to display. Themes do not bring their own demo content. On top of that, the site is still showing a “Coming Soon” style screen, which usually means a coming soon or maintenance mode is sitting in front of the theme.

First, in your dashboard go to Appearance, then Themes, and confirm that Arbutus is marked as the active theme. Then go to Pages, then Add New, create a simple test page with a title and one line of text, and publish it. After that, go to Settings, then Reading, set “Your homepage displays” to “A static page,” choose that test page as the homepage, and save the changes. That gives WordPress a specific page to render on the front.

Next, if visiting https://mleefoster.com
still shows a Coming Soon or placeholder screen, there is almost certainly a coming soon mode switched on. On many Bluehost installs this is controlled from the Bluehost section in the left side of the dashboard, often under Settings. Open that section, look for any toggle labeled Coming Soon or Maintenance, switch it off, then refresh your site in a private or incognito browser window so you are not looking at a cached version.

If those steps give you your test page on the front end, then the theme and content are working and you can start building out the rest of your pages and layout. If you are still seeing a phantom or blank page after trying this, it would help to know what you see under Settings, then Reading, and exactly which Arbutus theme and author are listed as active in Appearance, then Themes, so folks here can dig a bit deeper with you.

Most of us have had at least one “why is my homepage totally blank” moment, so you are definitely not alone here.”

• This reply was modified 5 months, 3 weeks ago by BluehostSupport.
• This reply was modified 5 months, 3 weeks ago by Steven Stern (sterndata).

Hi Jason, I’m glad support was able to help get you to this point. In reviewing the upstatemycanals account, the main site is loading fine currently. We do see a couple links that lead to dead pages on the new jptravel.store site, however they all direct to an outside URL (hotels-comparer.com/?marker=605882) that is not hosted on your account. You may want to update these links to working URLs. 

Aside from that, the jptravel.store website appears to be up and running without issue on the WordPress package you have moved it to with your original. Was there a particular issue you were struggling with aside from those few dead links?

Looks like what’s happening is the Virtue theme (you’re on 3.4.13) just isn’t built for newer PHP. The warnings in your log are from the theme’s image code, it’s trying to grab info from an image that doesn’t exist, and PHP 8.2+ is a lot stricter about throwing notices. Normally those warnings wouldn’t take a site down, but some hosts (Bluehost included) run PHP so that warnings spill out as errors, which can chew resources or break output. Jumping to PHP 8.3 won’t really fix it.

Virtue is a Kadence theme. Worth checking if they’ve got a more recent build or if they suggest one of their newer themes with a similar look. If you want to hang onto Virtue for now, a dev can patch the offending lines by adding a simple check so it doesn’t try to pull from a non-existent array. That stops the log spam.

In the meantime, you can at least keep the site online by telling WordPress to log warnings instead of showing them. Drop this in wp-config.php:

define(‘WP_DEBUG’, true);
define(‘WP_DEBUG_LOG’, true);
define(‘WP_DEBUG_DISPLAY’, false);
@ini_set(‘display_errors’, 0);

That way the warnings still get written to the error log, but they won’t surface on the site and cause “downtime.

Hey Joe, you’re running into two separate, but related issues: WordPress and Jetpack are out of sync with the PHP version your account is using, and Recovery Mode emails are going to the site’s stored admin address, which may be old or blocked, so you’re not seeing them.

Here’s the quickest path to get back in and make edits. First, lower PHP temporarily so the site can load. In your Bluehost account manager open Advanced and use MultiPHP Manager to set the domain to PHP 7.4. This isn’t a long-term fix, just a safe bridge so the dashboard opens with older code. When you can log in again, update WordPress core to the latest, then update plugins and themes, then move PHP back up to 8.1 or 8.2. The error about __autoload points to older code on PHP 8, and the Jetpack_IXR_Client message points to an older Jetpack version on a newer PHP, so updates will resolve both once you’re back in.

If the dashboard still won’t load after changing PHP, disable Jetpack from the file side to break the error loop. In cPanel or the Bluehost File Manager go to wp-content/plugins and rename the jetpack folder to something like jetpack.off. If that doesn’t do it, temporarily rename the entire plugins folder to plugins.off, then reload the site to confirm it comes back. Once you’re in wp-admin, rename folders back and re-activate plugins one by one after they’re updated.

About the missing Recovery Mode email, WordPress sends that to the admin_email saved in the database, not necessarily the address you expect. If an old developer’s email is still in there, you won’t receive anything. After you can access wp-admin, go to Settings → General and confirm the Administration Email Address. If you can’t log in yet but need to change it, you can adjust the admin_email value in the wp_options table via phpMyAdmin. Also check your domain’s email routing or any external mail provider settings to be sure the mailbox exists and isn’t full; if delivery is flaky, add SMTP later with a plugin once the site is stable.

If you just need to reset a password to get moving, try wp-login.php?action=lostpassword with a mailbox you can access. If that still doesn’t arrive, it’s another sign the stored admin email is out of date or mail isn’t configured; the PHP switch and plugin rename steps above are the faster unlocks.

Once you’re back in and updated, bring PHP back to 8.1/8.2, re-enable Jetpack, and clear any persistent cron errors. If the Jetpack fatal error returns only when Jetpack is active, leave it off, update it to the latest, and reconnect it. If you see fresh fatal entries after all updates, copy the newest lines from the error log and we’ll help you pinpoint the exact call that’s failing.

If you’d like us to take a closer look at the account-side logs and PHP settings, we’re happy to help. Just reach out to our support team by phone or chat and they would be happy to assist!

The 429 Too Many Requests message appears when your site exceeds the PHP process limit of 25. Each plugin or script can start a process, and when the number is exceeded new requests are blocked.

For the SSL warning, confirm that your WordPress Address and Site Address in Settings > General both begin with https:// and enable Force HTTPS in your hosting control panel. This will make sure the certificate is applied consistently.

To help reduce the number of processes, review your active plugins and deactivate any that are not essential. Enabling caching will also help lower the load, and adding a CDN such as Cloudflare can reduce server strain.

After making these changes, test again and monitor your process count to see if it improves.

Yeah that error is exactly what it looks like. str_replace() expects a string but the plugin is sending it an array. That mismatch is what’s breaking the redirect to PayPal. It’s a PHP 8 issue but the plugin dev is right that updating should fix it since newer versions usually patch this kind of thing.

If you can’t find the plugin folder in File Manager, go into public_html, then open the folder for your site, then wp-content, then plugins. If you still don’t see it, skip the search bar and just navigate manually. Search in File Manager isn’t super reliable.

You’re doing the right thing holding off until registration calms down. Once it does, updating that plugin should sort this out cleanly.