Oh, WordPress just keeps on giving! 😂 So it’s another year, and it’s time for some Y2k20-issues! I was too young to fix any Y2K-issues myself, so I guess it’s just fitting something breaks now.
This article explains one possible fix to a situation, where your pictures in WordPress fail to show up.
So this was a fairly random WordPress-issue I encountered. It goes something like this: Suddenly each and every uploaded picture on your WordPress site fails to display. It’s available and editable in your WordPress Media Library, and can be added to posts, it just won’t show.
At least in edit mode, it’ll look something like this:
In your Media Library, all of the thumbnails will be broken. Somewhat like below:
And taking a look in the browser console (that browser is Brave, in case you’re wondering!), you’ll see something like below:
So, the browser is encountering 404 errors for each picture. But they ARE in fact available in the library – and the error code is actually misleading.
I quickly ruled out a one-time glitch, cache issues, CDN issues and security plug-ins interfering – but none of those turned out to be the cause. But firing up an FTP client and taking a look at the files on the server actually shed some light on the cause!
Truthfully, I don’t know if the issue was really related to the year changing, but it WAS related to a new folder being created on the server’s uploads -folder without proper permissions!
Okay, so you might guess this already – but now it’s time to go ahead and fix the permissions on the new folder(s). This isn’t that tough – just compare the permissions on the folders that do work with the ones that don’t.
So, a short walkthrough first, and then a better description coming in with some screenshots!
Time needed: 10 minutes.
How to fix permission issues for your WordPress Media Library?
- Open your FTP Client
- Browse to wp-content > uploads
- First, verify that a media file that works has the same permissions I’m describing below.
- Set your folder permissions to be 755
Just select “recursively for folders” or whatever it is in your client.
- Set your file permissions to be 644
Just select “recursively for items” or whatever it is in your client.
Okay – so that’s the quick version. Now with the screenshots!
Just fire up your FTP client and browse to the following directory:
your_WordPress_folder > wp-content > uploads
This should look something like this:
(Replace the year and month numbers in the following piece with whatever’s relevant at the time you’re reading this)
For the functional folder, your permissions should look something like this:
And for the files inside, it should be something like this:
Checking the permissions for the new folder – 2020 in my case – revealed that it was in fact 750 instead of 755: it was missing the “read” and “execute” permissions for 2020 folder! This issue was also replicated for the month folder below.
Similarly, checking the files inside the folder revealed that instead of 644, they were 640, i.e. missing the “read” permission that’s definitely required to, well, read the files.
At this point, it’s pretty easy to see the issue. If the files are not available publicly, simply including them with <img> -tag (like WordPress does) will just not work.
And the fix should be somewhat clear as well – apply the proper permissions (755 for folders and 644 for files) to the new files on the server!
With a client such as FileZilla, this is usually fairly straightforward, as you can select something like “Recurse into subdirectories” and select whether you want to apply the change to files or directories or both. Kinda like below:
This’ll probably look somewhat like this in your FTP client:
When it’s all done, browse back to your site, hit refresh a couple of times and you should have the pictures up.
With that – you should be good! Try it out and see how it goes :)
Latest posts by Antti K. Koskela (see all)
- Office 365 video migration to Office Stream imminent – Get Ready! - February 5, 2020
- How to use TWRP to flash an Android device that refuses to boot to TWRP? - January 29, 2020
- Azure Functions host quits with “The system cannot find the file specified” - January 22, 2020