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.
The question was edited 3 times and it now includes VPS and Centos tags, because i think there is something wrong with my VPS config file.
Ok, first, I've looked through all the questions asked here, and there is no answer to the issue I have.
The problem is that when I try to copy/paste and update or create WP post, I get this warning that says: "You don't have permission to access /wp-admin/post.php on this server."
The strangest thing is that when I copy/paste it mostly crashes only if there are some special format like Italic or any symbol, but not every like (). So if I paste text, it mostly crashes but not always.
Now, to make the things even stranger, I had a post that was doing just fine, I mean it used to appear fine on the blog. Then I've tried to create a contact page, I've published it and it didn't show on the blog. There was a message saying nothing found there on the link. Then I've started to click around and I've noticed my post that was doing right disappeared too. I mean it's still there, but when you click on read more it says nothing found.
I've turned off all the plugins I'm using (in fact only Fourteen Color) and have changed the theme, but with no result at all.
Any idea why does this happen?
I'm hosting it on a virtual server and there are running 2 sites more at the same Ip, but I don't think, this could be the problem.
Previously I was playing with SSL and I thought that might be the problem, but then I deleted the domain and have created anything from scratch and the issue persists.
Pd. When I try to publish a raw entered text from the keyboard I've no problems, but when I paste it, it usually crashes the post.
Edit: My .htaccess file is here:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Edit 2: It seems I can't post links too. When I try to post a link I get the same error.
Edit 3: I'm trying to locate the php log file, but it seems there's nothing there. So my thought is: what if the error have to do with wp trying to write the log but it can't get permission? I have the php logs enabled in the config so there should be at least one, but i can't find any. Does anyone can tell me, where I have to look for the logs. Now I'm looking on /var/log but there are no php log file.
Ok, I have to edit the answer, because despite everything worked fine, the problem appeared again. So, this time I dug deeper only to find out, that the problem were laying in my mod secure conf, so I had to set SecRuleEngine from On to DetectionOnly, and now the issue is gone.
Previously it was detecting every attempt to update the post like an XSS attack.
I had an issue like yours a few years ago and it drove me crazy, but I had to try out some solutions to finally find out the perfect one for me. Try one of these, they can't do no harm:
First: try to CHMOD your post.php to 774. Or even better, for the sake of your solution, chmod your wp-admin and wp-content folder to 777 and see if it works and then switch it back, so you will be able to pin point it.
Second: Add this part to the beggining of your .htaccess file:
<Files post.php>
Order Deny,Allow
Deny from all
Allow from all
</Files>
Instead of "all" in the "Allow from all" field you can just enter your IP.
Third: In my case, renaming this part
<IfModule mod_rewrite.c>
to this
<IfModule mod_rewrite.so>
helped, as I think this is a platform-specific, or configuration-specific issue, where Mac OS and Linux Apache installations are set up for .so AKA 'shared-object' modules. Looking for a .c module shouldn't break the conditional, I think that's a bug, but it's the issue.
Try any of these and I hope something will help you as it did to me.
I am sure there are many things not done yet to eliminate the technical frustrations that i am currently experiencing with Bitnami Wordpress Multisite 4.6-1 running on AWS. I am taking this opportunity to highlight the issue i am facing on stackoverflow community to get some help, learn, grow and most importantly be able to help as well. This is my first Question here and i am afraid that i am unable to post more 2 links here because i am not allowed to.
To Begin with, There seem to be Permissions Issues on Wordpress Multisite running on Aws EC2 which was setup and configured through Bitnami. Sadly documentation and Articles on Bitnami Wiki are not updated for the latest version of Wordpress Multisite and i am not comfortable using Bitnami Osx Application to manage Wordpress because i am not using Bitnami Cloud Hosting but AWS Ec2.
AWS EC2 Configuration Details:
Instance Type: T2 Micro
Elastic IP: Yes
Security Groups: Grants access to Bitnami WordPress
IAM User: 2 Users, Enabled with Following Policy.
1. AdministratorAccess
2. AmazonEC2ContainerServiceFullAccess
3. AmazonVPCFullAccess
Wordpress Network: Able to Install Themes & Plugins on Network and Problems are listed below.
Wordpress Site Running on Network: Able to Activate Network Plugins/ Themes. Able Import xml data on Site with minor issues as the Theme Installed on the network is Outdated.
Terminal: Able to establish SSH connection using pem key. browse, create files and delete any newly created files using bash commands however issue is with deleting unwanted Plugins / Theme by removing using same commands even through i did run chmod 777 multiple times to ensure read, write and execute is enabled but there is no Success.
Wordpress Issues:
Unable to Update Plugins through Dashboard weather Paid/Unpaid. Please check the screenshots.
Plugin Update - Failed.
Unable to Uninstall any outdated theme weather Active / Inactive on Sites. - Failed]2
Troubleshooting Steps 1:
Network Setup - Implemented through Terminal using VIM command :
1 - Added the following to wp-config.php file in /opt/bitnami/apps/wordpress/htdocs/ above the line reading /* That’s all, stop editing! Happy blogging.
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'ec2-x-x-x-x.compute-1.amazonaws.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1); */:
]
2- Added the following to .htaccess file in /opt/bitnami/apps/wordpress/htdocs/, replacing other WordPress rules:
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]
Result: NO Success.
Troubleshooting Steps 2:
SSH Connection to Instance : Succes
Create New Files: Yes
Delete Newly Files: Yes (using rm filename)
Delete Empty Dir: Yes (Using rmdir)
Delete Outdated Theme Dir: Permission Denied (rm: cannot remove 'startit': Is a directory)
Note: I did run CHMOD 777 at the beginning of SSH session again.
Result : NO Success.
Troubleshooting Step 3
FTP FileZilla: Connected through filezilla using PEM key.
Able to Upload new folders and files.
Unable to delete unwanted folders ;
Error: Permission Denied.
Result : NO Success.
Please know that i very new to all that i mentioned above and i am sure there are many troubleshooting steps that i have to follow. Your help will be highly appreciated.
I used a cloud server with BITNAMI, and just hated it. Not for me. Its a bare system. No cpanel, WHM, or anything exciting. Just an empty linux OS. We had spent a week getting it up. Finally decided to can it.
use command line:
What we did to fix the permission issues is CMD into your server as ROOT!
make sure you are root, if you are not root make sure you SUDO -SU.
File folders have to be "0755"
Files have to be "0644"
setting all files, and folders correctly made a world of difference.
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]
I've recently installed Wordpress and can't seem to get the website to display friendly URLs no matter what settings I use inside the Dashboard or in an .htaccess file. I've tried numerous versions of Wordpress and still can't achieve what I need, despite succeeding on hosts other than Concentric/XO, any idea why?
Update: I released a plugin that does all of this for you. However, you still need to follow the steps for the .htaccess file. Have a look here: http://wordpress.org/extend/plugins/permalink-fix-disable-canonical-redirects-pack/
Follow these steps before you attempt to install WordPress for the first time. If you have already installed it, start over.
To get Permalinks working you need to create a .htaccess file, WordPress can't do this automatically on this host. Here is what the basic .htaccess file should look like:
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
Make sure you create this file using an editor that allows for unix formatting (like PSPad, or VIM, Textmate, etc.), using notepad will give you a parsing error - it has something to do with invisible end of file characters(CLRF). Make sure the last rule has a hard return after it, it's required. .htaccess files are cached for up to 15 minutes so you may have to wait for it to kick in.
Next you'll need to edit your wp-settings.php file so open that up in your editor. Add the following code right above the closing ?> php tag:
if(isset($_REQUEST['q'])) {
$_SERVER['REQUEST_URI'] = "/" . $_REQUEST["q"];
}else{
if (empty($_SERVER['QUERY_STRING'])) {
$_SERVER['REQUEST_URI'] = $_SERVER['SCRIPT_NAME'];
} else {
$_SERVER['REQUEST_URI'] = $_SERVER['SCRIPT_NAME'] . "?" .
$_SERVER['QUERY_STRING'];
}
}
If someone can write that block of code more cleanly feel free, I'm not an expert PHP programmer.
Once that block of code is in place you can proceed to run the install.
Now that WordPress is installed you'll have to do one more thing before you can start blogging:
Create a new file called: disable-canonical-redirects.php and upload it to the wp-content/plugins directory.
Drop this block of code into that file:
<?php
/*
Plugin Name: Disable Canonical URL Redirection
Description: Disables the "Canonical URL Redirect" features of WordPress 2.3 and above.
Version: 1.0
Author: Mark Jaquith
Author URI: http://markjaquith.com/
*/
remove_filter('template_redirect', 'redirect_canonical');
?>
Now you need to enable that plugin, go to the Admin login page:
example.com/wp-login
Enable the plugin you created. That's it, you're on a horse.
Ask them whether they have mod_rewrite enabled.
To find out yourself, try adding a .htaccess file containing gibberish first:
sadölkasdfksdakföasldfg
if putting that onto the webspace, and then trying to access any page on it results in a 500 error, htaccess files get parsed.
Then try adding a "real" .htaccess file:
RewriteEngine On
if that works without a 500, then URL rewriting should be turned on.