Support » Fixing WordPress » WSoD in different pages + debug not working

  • Resolved zrunner


    **WordPress version:** 5.2.2
    **OS used:** Debian 9
    **Php version:** 7.0.33-0+deb9u3
    **MySQL version:**
    **Aapache version:** 2.4.25

    I tried this morning to install WordPress on my vps (I use it for the first time), manually by downloading the .zip file. The configuration went well, the site seems to be working. But for reasons I don’t know, the theme preview (for menu customization) is completely white, and according to my browser console, an error “Load denied by X-Frame-Options:…&customize_theme=avira&customize_messenger_channel=preview-0_changeset_uuid=7e5ca4d…&customize_theme=avira&customize_messenger_channel=preview-0 does not permit framing” appears in red.

    In addition, the preview of the articles does not work any more, I only see the loading logo running in a loop, with two errors in the console (see

    I don’t know if it’s related, but I also noticed that the “More details” button on the plugin addition page only gave a white rectangle. If I want to see these details, I have to Right click > Open in a new tab… no matter what plugin it is.

    It should also be noted that in the configuration of the site, the WordPress web address is different from the site’s web address, respectively and The /var/www/html/minecon folder contains only the index.php file, copied from the wordpress folder as indicated in the documentation. Oh and I tried both with Firefox and Safari, up to date.

    Now, what I’ve been trying to do:

    • put a chown for the user “www-data” on the folder …/html and recursively. It fixed some errors, but not the ones I listed here.
    • access the .htaccess file… except that it doesn’t exist anywhere (with the ls -a cmd). I tried to create it myself in the folders …/html, …/html/wordpress and …/html/minecon, without success. And WordPress tells me that it can’t edit it, according to the permalinks page.
    • move the file wp-config.php from the wordpress folder to the minecon folder. WordPress immediately complained that it no longer existed, and nothing was working, so I cancelled.
    • set the parameters ‘WP_DEBUG’ and ‘WP_DEBUG_LOG’ to ‘true’ in the config file. It hasn’t changed anything, there’s still no log in the wordpress/wp-content folder.
    • install the php extensions that were missing according to the “site health” page. Other than the problem of cropping images, it didn’t fix anything.
    • uninstall the extensions and restore the default theme. I had no extension, and no matter what the theme, the problems remain
    • install the “Health Check & Troubleshooting” extension. I have more info in the “site health” section, but the debug mode doesn’t work, when I press the button it redirects me to the home without changing anything, and I can click as many times as I want without seeing anything.

    I think I have exhausted here the majority of the solutions I found on the internet and on the forum, and I lack ideas… without log files it is difficult to understand exactly where the error is.
    If I have left out any information, feel free to ask for it, I would be happy to give it to you.

    A big thank you to those who will take the time to help me, as some friends have already tried for a few hours…

Viewing 7 replies - 1 through 7 (of 7 total)
  • Moderator bcworkz


    Ensure www-data is the user PHP runs as. It’s set in the Apache configuration files somewhere, location is version dependent. Verify the chown was applied to all folders and files by some random spot checks. Be sure file permissions are 6xx and folders 7xx. Your user may no longer be able to create an .htaccess file, but WP/PHP should be able to. Changing permalink settings from plain to anything else should trigger a file creation if it does not exist.

    To eliminate possible theme and plugin conflicts, deactivate all plugins and switch to the twentynineteen theme. You can carefully restore your preferred setup when all the remaining errors are resolved.

    Even if no errors are shown with WP_DEBUG defined as true, any PHP errors should still be logged in the PHP error log, the one whose location is set in Apache configuration, which is generally not wp-content by default. If no errors are logged, php.ini may be misconfigured. Remember to restart Apache if you edit any server configuration files.



    Thank @bcworkz, I tried some things, here’s my work:

    The php user is indeed www-data (I checked it via <?php echo exec('whoami'); ?> in a php page).
    According to the stat command, the owner of the folders is www-data, in the name of the same group (name verified via the groups www-data command), and all rights are in 644 for files, 755 for folders. Besides, in which folder is this file supposed to be created? Because it always returns me an error of missing rights…

    For themes and plugins I said in my first message that I had disabled them all, with the default theme, so nothing on that side.

    I found the php.ini file, as well as the error section, but the line error_log = syslog was commented. I added one just below by specifying a path, then restarted apache2, and now the theme preview works again. But since the /var/log/apache2/error.log file was almost empty, I deleted my line in php.ini, restarted apache2, and everything still works. I assume it was the restart that fixed this problem.

    I went back to the “Site Health Status” page, and the REST API error is still present. More precisely “The requested URL /minecon/wp-json/wp/v2/types/post was not found on this server.”. By doing some tests I noticed that this url address was wrong, and that maybe that’s why the preview of the articles didn’t work (since the error is similar); the real address is /minecon/index.php/wp-json/wp/v2/types/post. But no idea how to fix it….

    Thanks again for your help, which has already helped me unlock one of the white screens!



    Edit: actually I cannot even publish or save any article, which is pretty annoying for a blog… Plus I noticed that the default wordpress post returns a 404 page when I try to access it from the home page. No idea why

    Moderator bcworkz


    If the error_log line in php.ini is commented out, the default Apache log location is used. That location is specified in Apache configuration somewhere. On my system the logs are in /var/log/apache2/ by default. Sounds like it’s the same as yours. If the WSoD is resolved, the error logs may not be very useful in resolving other issues.

    So my only success so far was getting you to restart Apache 😀 Progress I suppose.

    While WP will work in a basic way without an .htaccess file in the WP installation folder, the API will not work correctly. Assuming /minecon/ is your WP installation folder, /minecon/wp-json/wp/v2/types/post really is the correct path. Getting a URL not found error indicates a missing or incorrect .htaccess. Adding index.php to the path is what .htaccess is supposed to do.

    You need to have .htaccess in the WP installation folder. It should contain at least this (for non-multi-site WP):

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /minecon/
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /minecon/index.php [L]
    # END WordPress

    Create it it yourself with that content if you need to. Double check owner and permissions once it’s in place. If your WP installation is not in /minecon/, edit accordingly in two places and place in the actual installation folder.

    If /minecon/ is not the WP installation location, what is? And what do you wish to accomplish by copying index.php elsewhere? In any case, lets first setup WP conventionally as a subfolder install, assuming it’s not in /var/www/html/. If you need to, set the home and site URL settings for WP to point directly to the actual installation. Also keep the default theme and all plugins deactivated for now. We can add all these things back in later on once we are sure the basic installation is stable.



    To simplify the structure of my folders and return to a more classic state, I moved all my wordpress files to the /var/www/html/minecon folder, so that I only have one folder for the site. After modifying the index.php accordingly, I noticed that even the permalink generation, with the.htaccess, works again!

    I still had a problem of 404 for the api and articles, but modifying the permalinks on the ‘simple’ structure (?p=123) fixed these errors. From what I see, everything is working perfectly! I put the Avira theme back to test it, and I still have no error. I think that not having a custom url is a lesser evil, compared to not having a site at all 😀

    I would like to take this opportunity to ask one last question, is it really necessary to update php? I have version 7.0.33, and I see that version 7.2 is available, but I have no idea how to update it (probably a complete uninstall-reinstall?)

    In any case, a big thank you for your help, I was starting to despair of my case x)

    Moderator bcworkz


    I’m glad it worked out! Some of your described symptoms had me mystified. Fortunately they were apparently side effects. It’s still possible to have a custom URL, but the approach of moving index.php was clearly not the best way to do that 🙂 Since you have a VPS, I think the best way to have a custom URL is via a virtual host. You can add definition files that declare a server name (domain name) and the associated document root folder, which is usually /html/, but could be /html/minecon/ or any other subfolder. Domain requests then go directly to that folder. This is essentially how shared hosting works.

    The virtual host files are at /etc/apache2/sites-available/. There will be a default .conf file you can use as a guide for creating other host files. Create a symlink to your new host file in /etc/apache2/sites-enabled/. Restart the server for the new file to become active. Then update your WP settings to reflect the desired domain name.

    You don’t have to update PHP right now, 7.0.33 is perfectly serviceable. However, from what I hear, 7.2 comes with a noticeable improvement in performance. If code runs without any problems on 7.0, it should run fine on 7.2 as well. You don’t really need to uninstall the current version, just update from the Debian repository. The installer will get rid of dependencies no longer required.



    Thanks. I’ll keep these info somewhere, if I need it later. Now I just hope everything will go right!

Viewing 7 replies - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.