Permalink 404’s & Response is not a valid JSON response

I first came across this WordPress cum Apache2 Permalink 404 problem back in 2018 and described a fix here. Unfortunately I had forgotten all about it and even though the damn fix was sitting right there in front of me I had to re-endure all the grief and suffering again. However during this grief and suffering I came across another nasty little feature that seem associated with the new Block editor. (previously I was using the classic editor) Namely after changing the permalink I got “Updating failed. The response is not a valid JSON response.” whenever I tried changing a post.

I previously wrote up a fix for the 404 problem when you change permalink style here. While it is much the same as this it is here, it is four years old and pre-dates the Block editor. But it may be worth a look along with this in case it somehow explains thing differently and more usefully for you.

This problem (in total) probably only applies to situations where you are using your own Apache2 server. But it may apply in part if you’ve not got the .htaccess file properly configured on some hosted webspace. I would imaging that if you are using a hosting service then it would be highly unlikely you would need the bit below about a2enmod.

I must add that this problem (2nd time ) almost beat me to death. It appeared to be intractable. But that was only because I had failed to configure Apache properly. (or read my own f**king notes!). I didn’t think (until now) that the two issues in Permalink 404’s & Response is not a valid JSON response” were related. But I think they are. Either that or I fluked a fix to both.

Here’s What Happened

Basically I installed WordPress with no issues. I built a child theme, again with no issues. I could build pages and posts using both the Gutenberg and the Classic editor. BUT I could only use the “plain” default URL settings for both posts and pages. If I changed it under settings→permalinks to something a bit more useful I’d end up with a 404 not found.

In the Gutenberg editor I also noticed that I often (always?) got a red bar with the following error message in it..

“Updating failed. The response is not a valid JSON response.”

So if you are a getting this then maybe it is tied up with this permalink problem. Obviously before I started using the Block editor and before I fixed the permalink problem I didn’t get it. After I fixed the permalink problem in apache2 then the JSON invalid response issue I was getting in the Block Editor disappeared too.

So, What was I getting with the unconfigured Apache?

I changed the permalink setting away from the default. Then in the editor the new URL for the post/page looked correct. But it just did not work. It always returned 404 Not Found.

Here’s what I did to solve this (for me) They were not done in this order but I think that this is the best order to do them in. It may also be that not all these steps are needed.

Here’s the Fix

1. In etc/apache2/apache2.conf: change AllowAll=none to AllowAll=All. I did this for all four settings but I think that only the one related to /var/www is necessary. You change all 4 to get it working back out the ones you don’t need by trial and error. I’m pretty sure you only need /var/www

Doing this enables the .htaccess file (more in a minute). Without doing this .htaccess file is simply not read.

2. Turn on mod_rewrite

sudo a2enmod rewrite

(this was the missing bit that killed me for two days. This MUST be done if it’s your own server)

3. Ensure the .htaccess file exists and holds the following code (or similar. In my previous post I used a slightly different incantation but never mind – the standard wordpress version is fine)

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteRule .* – [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

RewriteBase /

RewriteRule ^index\.php$ – [L]

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]

</IfModule>

I gather it is possible to completely dispense with the htaccess file and simply do everything in apache2.conf. But most people only host a site to develop it and then upload it to a host provider where use of a htaccess file is not optional. So you might as well do it in your prototype code too.

Make sure you htaccess file is writable by www-data as well as the owner.

Restart apache2 after the mods. with sudo service apache2 restart

(or whatever other incantation you like)

That’s it.

Hopefully the permlinks should now work and those hideous Permalink 404’s & Response is not a valid JSON response messages will be history too.

Lost Root Password to Mysql and Phpmyadmin

Yes. I committed the cardinal sin. I lost my root password to mysql and phpmyadmin. Consequently I could not log in as root in order to change the permissions for a user. Of course I hadn’t noticed I had lost the damn thing because normally I never-ever log in as root to anything.

It was only when I need to fiddle about with other users when I typed in what I thought it was – only to find my memory was crap. Of course, I had written it down somewhere safe. I always do. The problem was (crap memory again) I couldn’t find where.

I always obfuscate saved passwords – just in case some nasty person raids my desk and steals my documents. So it is probably staring me in the face. On the plus side I suppose it shows my obfuscation works pretty well. Hey Ho.

Check Your Mysql Version

Here’s what I did to reset the lost root password to mysql and phpmyadmin. This worked for me. I’m running mysql ver 8.0.30 Check this with:
mysql -V
Mine come back with this.
mysql Ver 8.0.30-0ubuntu0.20.04.2 for Linux on x86_64 ((Ubuntu))
This may not be compatible with all other versions but I expect it should be with this or later versions.


This method (after trying and failing with many others) is based largely around this post on devanswers.co. So major Hat Tip to them. There are a few extra steps here mainly surrounding clean up before actually changing the password. But if you are running mysql 5 you would probably be better off at devanswers as they deal with that earlier version as well as mysql 8. But you may still want to do the mysql killing and clean up as described here.


If, like me you got to this point after many failed attempts to fix this we need to check what sort of dismal state we are in.

We need to kill mysql. Make absolutely sure it really is dead. It’s worth checking that you haven’t got multiple versions running. This may (especially) happen if you’ve been faffing around with other failed attempts to crack in to mysql (like I had).

Cleanup: Kill all Mysqls

sudo ps -A | grep mysql – if this shows you one or more mysql or mysqld processes running then….
sudo pkill mysql
sudo pkill mysqld
sudo ps -A | grep mysql
– make sure this time nothing comes back.


Now we have to make sure the following directory (and associated user) exists. It may well not.

If you try and push ahead without having this directory properly set you will get something like this:
chalkie@chalkies-box:~$ mysql -u root mysql
ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)
[1]+ Exit 1 sudo mysqld –skip-grant-tables

If you already have this error message START AGAIN. Go back and check ALL instances of mysql are dead THEN create the directory as below.


ls -l /var/run/mysqld
If it is not there and the owner is not mysqld:mysqld then…
sudo mkdir /var/run/mysqld
sudo chown mysql /var/run/mysqld

check it again with
ls -l /var/run/mysqld


Now restart mysql in safe mode like so..
sudo mysqld_safe –skip-grant-tables&
You’ll get something like this back..
[1] 100757
chalkie@chalkies-box:/var/run$ 2022-08-21T12:57:00.853461Z mysqld_safe Logging to ‘/var/log/mysql/error.log’.
2022-08-21T12:57:00.907704Z mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql


now we can login as root like so…
sudo mysql –user=root mysql

You now should be logged in as root the prompt should now be mysql>


Now you are logged in as Root

From here you can now do all sorts of damage. Or even change the lost password for root as so..

First remove the old password with this…(notice the trailing semi colons and ignore the mysql> prompt)
mysql>UPDATE mysql.user SET authentication_string=null WHERE User=’root’;

mysql>flush-privileges;

mysql>ALTER USER ‘root’@’localhost’ IDENTIFIED WITH mysql_native_password BY ‘a-new-pw-i-promise-never-to-forget’;
mysql>flush-privileges;

And that’s it. Log out and kill the safe mode mysql process

mysql>exit;
sudo killall -u mysql


Now restart it:
sudo /etc/init.d/mysql start
CHECK the new password for root works by logging into mysql and/or phpmyadmin with it!!!

I hope that helps. My other Ubuntu style fixes are listed HERE

Wordfence XSS Cross Scripting Error for Admin: Fix

I had had an annoying problem where I’d log into one of my WordPress sites, then attempt to change the side bar and remove (say) a block of code that pulls in an iframe from another site (i.e. Twitter or Amazon or whatever) I got blocked by my security Wordfence plugin with a XSS cross scripting error. The actual site works fine it is just the admin cannot change anything. I first fixed this back in 2020, then forgot about it. I then changed my admin URL (i.e. broadband provider) and it re-appeared. Now as a penance I’m writing it up.

A potentially Unsafe Operation Screenshot. XSS cross scripting error.
Each blocked widget entry gets one of these
Wordfence Blocked Attacks email snippet listing multiple XSS cross scripting errors
Yes. I tried several times! And it blocked each and every one of them

The Problem:
When I tried and change anything using Appearance → Customise in WordPress dashboard the item I want to change gets blocked with this “Potentially Unsafe operation” on the left:

Later I receive my Wordfence email outlining Wordfence activity and I get this sort of thing in the “Recently Blocked Attacks” section.

The IP address (blanked out in the “Blocked Attacks” image) is my own. Wonderful though the Wordfence plugin is (and it really IS wonderful!) it is blocking me from changing anything! Which is rather sub-optimal, although I can still post.

The fix is simple – when you know where it is in the Wordfence plugin.

Select the Wordfence top level menu item in the WordPress Dashboard. Then select the “Live Traffic” Tab. You will see a list of blocked activities. Identify the one that has your IP address on it and then click on the “eye” on the far right of the summary line.

Traffic Logging Snippet. Blocked Admin for XSS cross scripting error
Notice the “eye” on the far right under the “View” column

After you have clicked the “eye”, you then get this.

Expanded Traffic logging snippet detailing XSS cross scripting error
Here’s the expanded entry. You need to get to here then you can whitelist your own URL

Select the “ADD PARAM TO FIREWALL ALLOW LIST” Then you are done! Your false Wordfence XSS Cross Scripting Error should go away.

You can now check that this has been implemented (and also exactly who is allowed to bypass the firewall) by clicking on the “All Options sub-menu item in the Wordfence menu in the WordPress dashboard.

In the “Rules” section make sure “whitelist” is on. (It should be) Then go down to “AllowListedURLs” and expand it. Here you should see your newly whitelisted URL. You can turn it (and any other ones) on and off from this menu too. I did not need to log out/in for changing enable/disble to work but you may need to.

Anyway hope that helps.

Locked in Maintenance Mode? Getting a WordPress Site Back Up.

WordPress is a complex beast and occasionally an update (automatic or otherwise) will fail to take the site out of maintenance mode after it completes. Most people never actually see their site in maintenance mode. It’ll look something like this below though you may not have the fancy image – just a battleship grey background.

Continue reading

My Domain Property Wouldn’t Verify in Google Webmasters. Here’s Why.

Google Webmasters (and it’s Google Search Console ) provides you with a Domain property verification string to allows you to get the full search data going to your site. The Domain Property shows all the search data for your site in one place rather than (say) separate data for https and http access. It is worth using.

Continue reading

WordPress: Adding Google Analytics Without a Plugin

There are many Google Analytics plugins for WordPress. Most also give you some form of display of this data in the wp-admin area. But you also get the endless plugin promotions trying to get you buy the enhanced version. While I don’t mind (that much) people trying to sell their wares (especially when I’m using a free version) sometimes it just grates.

So if rather than using a plugin you would like to just code and forget it, you can simply add a function into a file in the site child theme. Then you can check it works and forget about it. That’s what I do.

Continue reading

Backing up a One.com WordPress site

It is a good idea to always keep a recent local WordPress back up copy of your one.com hosted website. One.com is one of the more reliable hosting companies and they offer a backup facility for customers. But even so, if you have a recent local copy of your website safely stored on your hard drive there is no question about your ability to restore your site should the worst happen.

Continue reading

Creating a local Backup of a Hostpapa WordPress site

Here’s my personal notes (with an intro) on creating a local backup of a Hostpapa wordpress site. Maybe they’ll be useful to you too.

It is a good idea to always keep a recent local back up copy of your Hostpapa website. You can use Hostpapa’s remote backup facility for convenience as well, but if you have a recent local copy sitting there on your hard drive you know exactly where you stand.

Continue reading

Local WordPress Install: Posts return 404?

If you have just set up (say) a local Apache2 server and have a local wordpress install so you can debug your website locally you may find (like I did) that while the main webpage comes up fine, when you click through to anywhere else on the site it returns a 404 Not Found error. Even though you know the page/post is there and it shows up OK in the wp-admin section.

For me it turned out that I had not enabled an important plugin on Apache2 to allow permalinks to work. The missing module is called mod_rewrite. It is simple to fix.

Continue reading