Today I got an issue in WordPress. When I try to create a new page and uploading a new image in the WordPress admin section, I try to find out the solution, but I didn't get it... So after sanding an hour I got a solution...
Error
"Publishing failed. Error message: The response is not a valid JSON response."
Go to settings>permalinks. Select "Post name" and save.
Try updating your posts/pages. If it doesnot work, try selecting another option in the settings>permalinks.
Right now, you can use the Classic Editor plugin for fixing this issue.
The answer for the error is the editor I didn't know, but there is a new editor issue. If you are getting the same issue, then please use the below plugin. For fixing these issues, I'm doing R&D on this issue. If I get an exit solution, then will I make an update soon...
I had the same problem on a local dev environment and found the issue was due to rewrite permissions. Make sure your .htaccess file has the proper permission.
sudo chmod 755 .htaccess
After permissions are set, save your permalink settings. If the problem still exists, make sure mod_rewrite is enabled. The following will work for apache2 on Ubuntu.
sudo a2enmod rewrite
sudo systemctl apache2 restart
If still not working, your apache config is probably too strict. The following should do the trick for apache2 on Ubuntu. Edit /etc/apache2/apache2.conf and look for the root directory block. It's normally the one with /var/www like below. You will probably see AllowOverride None. Just change it to All like below for your local, but you probably want to do some research and be more secure on a production server.
<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>
After the change is made do another restart on apache and all should be good.
sudo systemctl apache2 restart
Changing the permalink settings as mentioned previously fixed the problem for me. If you keep "Post name" as the permalink setting, then the .htaccess file needs to be writable by wordpress.
Alternatively the below can be pasted at the bottom of .htaccess file. Mod_rewrite changes are executed from the bottom of the file first.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
Maybe you have a security issue with mixed content (HTTP and https URLs).
Step-1
1. 1. Check your Wordpress URL. Go to Settings -> permalink then click plain and save a page. then remove error
Step-2
Check your Wordpress URL. Go to Settings -> General
Change Wordpress Adress and Site Adress to https://
This solved the problem for me
Navigate to Settings > Permalinks. Select the permalink structure to Post name and save. Now try saving your post/page.
Here I have shared the screen-shot for your reference.
The problem should have been resolved.
Once your issue is resolved then you can select an old option in Permalinks if you want.
Note: If you have already selected Post Name then you need to select other option for reset permalink.
Go to /etc/nginx/sites-available/
open default file --> sudo vi default or sudo nano default
Add Below line to the location:
Add the comment :
#try_files $uri $uri/ =404;
Add this line : try_files $uri $uri/ /index.php?$args;
See the screenshot below described with red line :
I just installed classic editor plugin and it sorted out the “The response is not a valid JSON response” problem.
I had the same "not a valid JSON response" error when trying to publish my content. WordPress seems to do a JSON post when publishing a new post/page so I checked the network tab in my Developer Tools. If you check the "response" tab for this JSON call you might see some more details about this invalid JSON response.
In my case (yours might be different) some deprecated debug message was outputted before the actual JSON data and messed up the response. After fixing the deprecated message publishing worked again.
<br />
<b>Deprecated</b>: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in <b>Unknown</b> on line <b>0</b><br />
<br />
<b>Warning</b>: Cannot modify header information - headers already sent in <b>Unknown</b> on line <b>0</b><br />
{__NORMAL_JSON_DATA_HERE__}
Now, here there are two server blocks, first one is running on port 80.
for second server block there is a port 443 where you should implement the below code.
server{
#ssl configuration
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
# try_files $uri $uri/ =404; // comment this block
try_files $uri $uri/ /index.php$is_args$args;
}
}
Now exit and restart nginx server.
~$ sudo service nginx restart
you are done. enjoy.
In My case, it was a Firewall issue. A ModSecurity firewall rule was triggered for the website. I contacted the hosting provider (NameCheap), they identified the issue and then whitelisted the triggered rule on the server. Then the problem was resolved.
Looks like this still has not been fixed.
A workaround that worked for me (posting in case it works for someone else too) - in my case I was using an HTML block which was causing the issue. What I did was to add a Paragraph block > Edit as HTML. It resolved the issue for now. It's a shame that WP didn't look into it yet, seems like it's been happening for a while.
I had this same error and the cause in my case was a shortcode used in the page and the function that defined the shortcode was using 'echo' to output the data rather than using 'return'
I'd been getting the same error message when adding and/or updating pages, in addition to various other random errors. I was getting the errors on both my local development server and my webhost. When changing to one of the default themes (e.g. twenty nineteen), the errors would go away. For me, the problem turned out to be in my page template files. I'd noticed that when choosing a template for a newly created page, I'd have multiple choices with the same name.
I have several page template files (e.g. about-page.php, contact-page.php, services-page.php, etc.). When creating these files, since most of these pages were similar, I would just copy/paste from an existing file to make a new xxxx-page.php file. However, in some of those copied files (not all), I'd forgotten to modify the 'Template Name' (at the top of the file).
After I'd gone through and made sure all of my template files had unique names, the JSON error went away. All of my other errors disappeared as well. I'm using Wordpress 5.4.
My issue was .htaccess related. I got the hint from LucasBr's comment about a ".htaccess configuration problem". Since I had copied the site to my local dev environment. I needed to update the custom mod_rewrite settings to match my setup.
The important lines were:
RewriteBase /
and
RewriteRule . /index.php [L]
They had previously been set to access a sub-directory site.
I have some echo in some of my custom plugins, so this was also causing this issue.
I had the persisting issues. Before I could find the solution, I replaced PHP 8, as this was custom PHP Installation.
But nothing worked.
The solution was found during Drupal Installation.
Enable Opcache(only for Drupal though)
Allow Mod rewrite, Allow all(in my httpd.ini file there were three occurrences of Mod Rewrite,
And they were changed to None to All again none all this was small letter, and final one None to All
Restart httpd with httpd -k restart (CMD as Administrator)
This resolved.
I encountered the same kind of problem for a different reason with one of my client and never saw it as a potential solution.
If you enabled a W.A.F (like cloudflare or similar), one of the side effects can be this error, so be sure to disable to disable you waf if none of the other solutions are working.
If you use mod security 3 with Wordpress, you might get this message:
Publishing failed. The response is not a valid JSON response.
To remove it, you would need to add this rule to your exclusions file called
REQUEST-900-EXCLUSION-RULES-BEFORE-CRS
as follows:
# Remove Publishing failed. The response is not a valid JSON response.
SecRule REQUEST_HEADERS:Host "example.com" \
"id:1025,\
phase:2,\
pass,\
nolog,\
chain"
SecRule REQUEST_URI "#beginsWith /wp-json/wp/v2" \
" ctl:ruleRemoveById=933210,ctl:ruleRemoveById=949110"
You might need to change the rule id and change example.com to your domain name. After that, do this:
sudo nginx -t
if no problems were detected, restart nginx:
sudo service nginx restart
sudo systemctl restart nginx
This is a permalinks error.
Do these steps to fix it (depending upon the cause in your scenario) as explained here: https://wordpress786.com/updating-failed-error-message-the-response-is-not-a-valid-json-response/ :
go to settings > permalinks and save them once again
if you're on nginx, go to site nginx conf file and make sure that it contains the rules for wordpress permalinks (usual nginx configurationn for wordpress, ask me if confused)
restart nginx if you make any edits to conf file
If you face issue on image upload follow this: https://navinrao.com/the-response-is-not-a-valid-json-response/
I was getting this issue while updating normal text too.
The issue I face was due to having javascript:void(0) keyword inside my link () .
Please be sure if your content has keyword containing javascript
before updating.
<i class="fa fa-linkedin" aria-hidden="true"></i>
After I remove javascript:void(0) ; it works fine.
Have a nice time :)
Try removing any redirects to the WordPress site including subdomains.
I have installed silverstripe 4 into the /var/www/html folder in apache.
However, when I go to the url, I have to use "localhost/public/index.php" in order to obtain the main page. I thought I was to be able to just go to "localhost" to find the defaut page. What am I to do if I want to have a main page without people having to specify "/public/" before it?
Thanks.
Normally, your localhost website can be resolved without adding /public/ if the following 2 things are configured correctly.
Enable Apache mod_rewrite
Having .htaccess rewrite config in /var/www/html
Troubleshooting
Check if you got the right .htaccess in /var/www/html. Basically, this Apache config file will forward all the requests to /public/ folder.
If .htaccess is fine, make sure your mod_rewrite is enabled in your Apache. Check this link.
I am in the process of migrating my site to Wordpress from IIS.
I have run into an issue:
I have URL's that are a mix of upper and lower case that reference images. These URL's are getting a 404 because the case of the URL does not match the case of the file location.
For example, in my article I have a URL:
https://aaa.bbb.com/wp-content/migrate/ABC/abc.png
The file this is referencing is: /var/www/aaa/wp-content/migrate/abc/abc.png
When I change the URL to the same case as the file, it works, however how can I make it ignore the case of the folder on disk?
I tired the mod_speling module by putting this into /etc/apache2/apache2.conf but this just does not work for me. Also tried putting this into .htaccess in the root of my web directory but that made no difference.
<IfModule mod_speling.c>
CheckSpelling On
CheckCaseOnly On
</IfModule>
I have read various threads on here but I'm completely stuck.
I managed to find a work around to this.
I ended up writing a rewrite rule in the VirtualHost file to rewrite everything to lowercase apart from anything within the directory of assets imported from Windows.
Chrome workspaces: let's say I map local CSS files to those served by my local http server. Everything works great and I can modify the files in-browser and upon page refresh my changes persist.
We happen to fingerprint our assets so that they are referenced via urls like styles.css?longuniquehash. Great practice - this way we can use aggressive caching and be sure the most recent assets will be used by the client.
However, this backfires a little with workspaces as the mappings get lost whenever the url is updated. In a nutshell: we map styles.css?123 to the local resource, we change it and on page refresh it comes back as styles.css?234 which has to be mapped again.
We're using cassette, but the problem can be reproduced on any setup with fingerprinting. Is there a setting or a workaround I'm missing?
According to Chromium, the support for mapping URLs with query params (i.e. style.css?123) was only partial up until Chrome 49 - where it was removed completely.
If you can't manually remove the params from your code, a temporary workaround is to remove the ?123 param from the stylesheet reference in the Chrome inspector once the page has loaded. Then your workspace mapping and auto-refreshing should work fine until you load the page again.
You can star and follow this issue here: bugs.chromium.org
I assume you do not develop on your live server (and if you do please stop and develop on your local machine or at least on a test server) so you activate the "cache buster" only on your live environment. We always have a quick way of checking the environment we are running on all our projects so just check before appending the "?123" query.
I you do not what to solve this in code you can also add this in your htacces (if you are using apache)
SetEnvIf Host 'local.domain.com' runenv=local
RewriteCond %{ENV:runenv} ^local$
RewriteCond %{REQUEST_URI} .*\.css
RewriteCond %{QUERY_STRING} !^$
RewriteRule ^(.*)$ /$1? [R=301,L]