This post was most recently updated on August 16th, 2021.4 min read.
This article explains one possible fix to a situation, where your pictures in WordPress fail to show up. In this particular case, uploading, editing and even selecting pictures for your articles works – just displaying them doesn’t work. Alternatively, programmatic access might fail as well: in my case ShortPixel reported an error “There was an error and your request was not processed: Could not download file (404 Not Found)”. This was peculiar, as I was pretty sure I had just uploaded the files and they were in fact visible in gallery…
But I’m going ahead of myself. What was the issue again, and how did it surface?
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.
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 – or at least all revent ones – 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.
Let’s dive in with the steps to fix this – all accompanied by some sweet 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 30, I don’t know what you might be using – does TikTok have FTP? 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 folders, 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.
So, to recap:
Short answer to that is, that both the year and month folders should have 755, and above I’m showing you how to make sure this is the case using FileZilla (although the same principle applies to other FTP clients as well).
They should be 644, and above I’m showing you how to make sure this is the case using FileZilla (although the same principle applies to other FTP clients as well).
Beats me, but at least the fix is easy! Just be prepared to see this happen on an almost yearly basis – it’s happened twice for me in the last ~6 years.
With that – you should be good! Try it out and see how it goes :)
- System.Text.Json.JsonPropertyName not working for CosmosDb in .NET Core/5? - October 19, 2021
- Errors loading an assembly that’s using Microsoft Graph API - October 12, 2021
- ILogger binding suddely failing for Azure Functions – what to do? - October 5, 2021