This post was most recently updated on December 7th, 2020.Reading Time: 4 minutes.
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: 15 minutes.
How to fix permission issues for your WordPress Media Library?
- Open your FTP Client
If you’re semi-old-school, you’re probably using FileZilla or something like that. If you’re under 40, I don’t know what you might be using – just fire it up.
- Browse to wp-content > uploads
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)
- First, verify that a media file that works has the same permissions I’m describing below.
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 -tag (like WordPress does) will just not work.
- Set your file permissions to be 644
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:
- Set your folder permissions to be 755
Again, just select “recursively for folders” or whatever it is in your client.
- Verify the fix
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 :)
- How to fix “System.IO.FileSystem: Could not find a part of the path \AppData\Local\AzureFunctionsTools\Releases\3.17.0\workers. Value cannot be null. (Parameter ‘provider’)” when running Azure Functions locally? - January 12, 2021
- How to nuke the Identity Cache in Visual Studio? - January 11, 2021
- Fixing unexpected Microsoft.AspNetCore package errors after a dependency update - January 6, 2021