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
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]
</IfModule>
# 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)
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!
