z00000mer

Stick a fork in this problem, because it’s DONE. ??

Ok, I found it.

It appears that a user-defined Apache Handler that I never defined that was named application/php-edge with a mime/file type of .php was in the cPanel. I hosed it out and now I can run any php version 5.6 and up that I choose without any problems.

This was a fun one, I gotta admit.

Thanks again to everyone that pitched in with help.

Ehhhh… LULZ, as the kids say.

I changed the PHP version via the cPanel MultiPHPManager to version 5.6 and everything on the site works. This is on a brand new WordPress 5.2 automatic script installation directly into the /public_html document root.

If I use the same tool to change the PHP version now to anything else, the WaterFox browser will not open the .php pages and instead tries to get another browser to do so.

At a point in the past I had Bluehost change the default domain on the account and doing so was supposed to only disaffect Weebly per this page:

https://my.bluehost.com/hosting/help/345

I had them change it back to the original domain today on a hunch and that hunch did not pan out, but at least I stumbled on as to how to get everything working.

Going to see if I can set up or find a php error log here on Bluehost and keep an eye on .htaccess changes when switching from one version of php to another one. I just wanted to let everyone here know that I shined a light in the php kitchen and the cockroaches all started running.

Thanks!

Copy that, autotutorial & thank you very much.

I got a clean restore of the site via vaultpress and I still cannot update or create pages/posts. Also cannot kill the CDN built into the $39 a year version of Jetpack still after full restore.

I have not, as of yet, set up a ssh account/keys and tried a hands-on WordPress install at bluehost.

If I completely remove Jetpack from the bluehost server, the REST API problem remains.

I’m going to just park the site on a Linode instance and let it twirl there and see if WordPress has a hankering for going belly-up before I resort to a static site or drag out Drupal or Grav.

If I run into anything tasty to report, I’ll swing by and let you kind folks know. Thanks again to ALL for your help.

-z

Yeah, Jetpack has a CDN and if I go to turn it off I get an error:

Error disabling site accelerator. JsonParseError

You can’t make this stuff up. Unbelievable.

I just now remembered that Jetpack ~might~ have a CDN. I’ll go get that fired up again and see if it does and if so how I can go about flushing it. I do not remember if it has a CDN or not and if I enabled it or not. WordPress is like running the gauntlet. LOL

Hi t-p,

Oh yeah, I went to their support chat and spent some time with them. They are nice folks but they were not able to come up with an answer. They were the people that suggested that I might be able to find an answer over here, so I made an account here to get the ball rolling.

Bluehost uses caches – at least on the shared server offering. This is done by means of “must-use” plug-ins named Endurance Browser Cache and Endurance Page Cache. I’m finding this in the .htaccess file:

#AddHandler application/x-httpd-ea-php70 .php
#<IfModule mod_expires.c>
# ExpiresActive On
# ExpiresByType image/jpg “access plus 1 year”
# ExpiresByType image/jpeg “access plus 1 year”
# ExpiresByType image/gif “access plus 1 year”
# ExpiresByType image/png “access plus 1 year”
# ExpiresByType text/css “access plus 1 month”
# ExpiresByType application/pdf “access plus 1 month”
# ExpiresByType text/javascript “access plus 1 month”
# ExpiresByType text/html “access plus 5 minutes”
# ExpiresByType image/x-icon “access plus 1 year”
# ExpiresDefault “access plus 6 hours”
#</IfModule>

<ifModule mod_headers.c>
#Header set X-Endurance-Cache-Level “0”
</ifModule>

I just commented it all out and set the .htaccess file permissions to 444 so they could not stomp on my browser cache after I cleared it.

They have a beta CDN but I do not have it enabled.

Hi Jan,

Copy that on the post edit time window. Thanks for the tip.

Both installs are looking to be the same and the file and folder permissions are looking good so far. I’m still flipping over rocks – pulling down config files and running them through BBEdit diff to see if anything pops up.

Thanks for pointing out your post edit and the fact that posts can be edited here. I’m a newbie here. ??

I have not yet solved it. I cannot use pretty permalinks in the installation directly within the public_html folder without seizing up the REST API.

If I wish to install WordPress into a sub-folder under public_html, then I’m in great shape. LOL.

The .htaccess files for both installs appear to be identical.

I’m going to flip over some more rocks and see if I can actually get to the bottom of this for real.

BTW, I went to bluehost support with this first. They sent me here.

You’re going to love this.

On the fresh WordPress 5.2 install directly in the public_html folder I get the REST API problem. I decided to go to permalinks and change the default after the install, which was “Month and name” and set it instead to “Plain” and the REST API problem goes away when I check Site Health. Thanks for mentioning permalinks.

I think that I’ll go take a gander at the .htaccess file and maybe the WordPress config to see if I can spot any obvious nonsense.

I should just stick to Bootstrap, but I need a search function for this site. ??

Thanks again.

Hi autotutorial,

I went ahead and pointed another domain at bluehost and set up a second WordPress instance with their install script and immediately after I checked the Site Health and the REST API was fine.

After that, I deleted my working site and performed a fresh WordPress 5.2 install using their built-in script and the REST API on that is reporting as not behaving correctly and still throwing the The REST API did not process the context query parameter correctly. notification.

To answer your question, yes, I use pretty permalinks on all WordPress installs. ??

I’m going to twirl around with this fresh bluehost default install that is misbehaving and see if I can figure out what is haywire. The second install inside a folder nested in public_html works great, but the install directly inside public_html is not good on the REST API.

Thanks for your help and guidance. I’ll keep you posted if I run into anything juicy here.

OK, I can see that this is going sideways, so instead of me pulling down my functioning website that I can use the Classic Editor plugin with, I think that I’ll first go install WordPress 5.2 fresh on that same Bluehost shared server and see if I get the same plate of spaghetti. If everything is peachy-keen then I will take your advice and rebuild the existing website.

BTW, the upgrade/update to 5.2 was handled automatically by Bluehost.

I sincerely appreciate your help and guidance and I’ll keep you in the loop as to what I encounter along the way on my end. Thanks again.

I should note that this displays when I am NOT in Troubleshooting mode. In Troubleshooting mode it says that everything is OK and shows a black checkmark, yet the problem saving pages and posts persists.