You’d think after over a decade of troubleshooting WordPress permission issues that I’d have learned my lesson by now.
I’ve been diagnosing site performance issues with my garden blog (the Site Health tool was complaining). One of the issues that constantly kept coming up was a REST API error that reported cURL timeout issues. This usually manifested itself in agonizingly slow page load times. I went through the plugin/theme deactivation dance to hone in on the culprit: Fast Secure plugins that had been defunct for several years but still useful for buffering brute force attempts. I finally decided to move on to a different ReCaptcha solution and retire Fast Secure. Oddly enough, my primary site had the identical plugins installed but never encountered the same issues.
Moving on, I noticed that the Media Library thumbnails never displayed and that I had issues uploading/adding new media (cannot create directory). Now ordinarily my main media storage is in an S3 bucket, but I sometimes might need to make local posts unique to the garden theme of the site.
I spent hours and days researching this issue, thinking it had to be some kind of ownership issue. I kept flipping user and group ownership on files and directories, only to break ownership of other WordPress files and directories. I poured over logs looking for some indication of access errors.
Ultimately, I just had to reset all the file and directory permissions in my WordPress wp-content folder to get things working again:
$sudo find /path/to/website/wp-content -type f -exec chmod 644 {} \;
$sudo find /path/to/website/wp-content -type d -exec chmod 755 {} \;
Then I reset ownership of wp-content to my wp-user:
$sudo chown wp-user:wp-user -R wp-content/
Then finally, to make sure media uploads and thumbnails worked again:
$sudo chown www-data:www-data -R wp-content/uploads/
Of course while I was resetting file/directory permissions, it was worth reading the updated Permissions topic over at WordPress codex. Turns out I could have a functional site even with wp-config.php set to 440/400.
Last issue that drove me a little crazy. View Details on the Plugin page always resulted in an error: refused to connect. I was so sure that my restrictive firewall settings needed to open an IP block to the WordPress plugin repository. But it turned out to be an SSL issue. Because the details page was in an iFrame, an SSL setting needed to be set to permit this. In my case, I change this setting in the appropriate ssl parameter .conf file:
Header always set X-Frame-Options sameorigin
Then restarted Apache for settings to take effect. Now…does this toggling the option make my site less secure? I’m assuming that if the request came directly from localhost that the traffic should be permitted. I just have to ensure my servers are sufficiently secure against being hacked, a lesson I learned earlier this year, and a story for another day.
