I have been stuck on this for several days now. The theme customizer does not apply any change, and the problem seems to be different from everything I've seen on online forums (lucky me).

The page customize.php loads fine, no error whatsoever is thrown and the Preview Panel is displayed properly. I have checked the responses of the Ajax calls, using the developer tools of browsers. I have set Apache logging to debug level, I have also activated logging at the Wordpress level and increased logging at the PHP level, but no error message whatsoever is present in the logs. And the Ajax requests sent by customize.php all get a success response.

However, when trying to edit ANY theme, both the default ones, and downloaded ones, while the preview panel is properly loaded, and while the preview panel shows the fading animation indicating that the preview panel is being refreshed to display the changes as I am typing modifications, no change is actually shown on the preview panel. Even clicking on the Save/Publish button does not apply the changes. No change is applied on the live website either. And all modification entered on the left-side editor are lost upon refresh of the page.

However, articles, and content can be created without problem from other parts of the admin panel. Settings can be changed, themes and plugins can be installed, and all sorts of write operations can be done without problem.

I have checked that the URL of the wordpress website is the same than the url of the wordpress directory in Wordpress Settings, as suggested in forums. I have tried to switch back and forth between themes hoping that the issue would magically go away as suggested in forums. I have also tried disabling all plugins and have even reinstalled wordpress from scratch. But the issue is still there, and the most frustrating is that no error is thrown anywhere, it just fails silently, so I'm here trying to guess.

I have checked file system permissions but all files and folders are owned by the correct apache user. I thought that maybe requests were being silently "cleaned" by a filter, but mod_security is not installed anywhere in the pipeline.

Our setup is as follow, even though I do not think it should relevant: we have one front-end apache server acting as a reverse proxy for another Apache Instance running wordpress on a different virtual machine not directly exposed to the internet (for various security policy reasons). I will post the HTTPD configuration files in a minute.

On the front-end Apache (ie. the reverse-proxy, which is the SSL termination point. Just mentioning it for context since I am not sure where to look at, but there is no problem whatseover with SSL so normally this should be irrelevant)

<VirtualHost *:443>
 ServerName mywebsite.com
 ServerAlias www.mywebsite.com

 ProxyPass "/" ""
 ProxyPassReverse "/" ""
 ProxyPreserveHost On

 CustomLog /var/log/mywebsite.com-access.log combined
 ErrorLog /var/log/mywebsite.com-error.log

 SSLCertificateFile /path/to/certicate
 SSLCertificateKeyFile /path/to/private/key

<VirtualHost *:80>
 ServerName mywebsite.com
 ServerAlias www.mywebsite.com

Redirect / https://mywebsite.com/

On the Wordpress' Apache instance (ie. the backend)

<FilesMatch "\.php$">
    SetHandler application/x-httpd-php
<FilesMatch "\.phps$">
    SetHandler application/x-httpd-php-source

<VirtualHost *:80>
 ServerName mywebsite.com
 ServerAlias www.mywebsite.com
 DocumentRoot /usr/local/www/wordpress
 SetEnv HTTPS On
 LogLevel debug

<Directory /usr/local/www/wordpress>
      AllowOverride All
      Options -Indexes +FollowSymLinks
      Order Allow,Deny
      Allow from all
      # For Apache 2.4 add:
      Require all granted

<Location / >
 ExpiresActive On
 ExpiresDefault "now"

Any clue, pointer or idea would be greatly appreciated.


  • When trying to customize a default theme (such as Twenty Seventeen), I can see my edit appear for a few seconds on the preview panel but as soon as such the "ajax refreshing" of the preview panel completes, the change disappears. It looks the backend returns success but does not actually apply any change.
    – Samuel
    Commented Apr 14, 2019 at 6:19
  • Hum, this is quite a localized issue. Have you tried the same WordPress setup on a "normal" singular Apache environment with the same settings and plugins enabled? For example on your local machine? And is it working there? Or is it the same? Have you then tried to temporarily disable all plugins and custom code, and switched the theme? And JS console also indicates no problem, nothing? What happens when you add new terms to a category in the backend (I think that's Ajax as well), does that work as expected?
    – leymannx
    Commented Apr 14, 2019 at 19:16
  • @leymannx Thank you a lot for stopping by to help. The client advised that there is no such error on a local development environment. The problem is that it is nor clear at all what the difference between the environments is, since no error is thrown. This is complete guess work and there are quite a lot of parameters. What I may do that qi haven't done yet is try to run a php development configuration on the production server (however we didn't customize the php.ini but let's try, I'll report back)
    – Samuel
    Commented Apr 15, 2019 at 5:49
  • 1
    Wow, every works fine with a PHP development configuration. Let's dig into this angle then. I'll take the time to do an in-depth diff and will report back.
    – Samuel
    Commented Apr 15, 2019 at 6:23
  • 1
    @leymannx I have posted the answer, thank you so much, you really helped stimulate my thinking process. Thank your a lot for stopping by, this was very nice and helpful.
    – Samuel
    Commented Apr 15, 2019 at 7:28

1 Answer 1


So I finally have it. The problem came from the php.ini configuration option filter.default. The option was set to:

filter.default = full_special_chars
filter.default_flags = 0

As explained in the PHP documentation, this had the effect of sanitizing and stripping characters from all $_POST, $_GET, $_COOKIE, $_REQUEST and $_SERVER data, effectively beating me in the back in a very vicious way. I have commented out these lines to set them back to their default:

;filter.default = unsafe_raw
;filter.default_flags =

I hope this will help someone in the future as I do not wish this type of unproductive treasure hunt even to my worst enemy.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.