WordPress File Permissions: Always Check and Reset

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.

oEmbeds Stopped Working: adapting to the new Instagram/Facebook API

What a mess. Just found out that WordPress no longer supports Facebook Instagram oEmbeds, which essentially breaks the format of single Instagram posts on my other sites.

Unfortunately using a plug-in such as Smash Balloon Social Photo Feeds is causing me some grief due to a reliance on Facebook’s API. Already Facebook, unknown to me, locked my account for suspicious activity. (I have a 30 day old account, to use on Messenger and one group.) Then when I finally resolved that issue, Smash Balloon still insists on setting up a Facebook business page to allow for unlimited tokens. So much for staying off Facebook.

Finally, once I took care of the token I just had to repost some of the Instagram posts that were affected; Smash Balloon took care of the rest.

On a side note can you believe WordPress is on version 5.x? It’s come a long way since I first started using it over a decade ago. Also PHP just released version 8, but I guess WordPress is not ready for it yet…so for now, my sites are/will be running 7.4.

I still have to troubleshoot site health issues with my garden blog. I thought hosting on Linode would improve my site’s performance. I’m not sure sharing a database on AWS with my main site is causing the problem. More on that later.

Oh and another inconvenience is using the WordPress app on my my phone. I have to turn off Google VPN to access my self-hosted WordPress sites. It’s becoming quite a chore to disable it while trying to write a post.