This one is a little weird. I had inherited a web site; I do some volunteer service, and the original web site was done in FrontPage 98. People who used the web site knew the URL to a particular file on that web site: the meetings directory.
Later, a member showed me an app that was super useful; but the best way to implement it was as a WordPress plugin. I guess I’m learning WordPress now (not that I was a fan of FrontPage 98: good riddance).
After the conversion, the members that knew the URL to the meeting directory complained that their bookmarks were broken. Fair enough, I had broken them. I got a redirector plugin, and created a 301 redirect from the known URL to the new location.
But there was a problem with the new location: my default WordPress URL scheme for the uploads folder includes putting year and month in the URL. So an upload today would be in ./uploads/2023/04/
What’s going to happen next month, when there is a new meetings directory file? It isn’t going in the April folder, I can assure you. Am I going to have to update the redirect every single month?
I’ve been doing computers for 40 years. Having to update the redirect every single month is stupid. Why can’t I just move the file to the root of the uploads directory?
Well … turns out WordPress needs to have a database entry for every file. I can move the file, but that orphans that entry in the database.
Even if I do move it, how does the old office manager update it? A regular old Media Library upload will upload the new file to a dated folder, and now we’ve got two files with the same name but different locations and URLs.
I had to find a plugin that does media file replace (in-place), but that wasn’t too hard. I use Enable Media Replace by ShortPixel. It was pretty easy to train the old office manager to follow the steps: click on the file in the Media Library, find the Replace button, and follow the directions on screen.
That was six years ago. This morning, the new office manager deleted the file. She had the presence of mind to recognize that something was wrong; but not enough to halt before doing damage. The new meeting directory file now has the wrong name and the wrong URL.
I kind of hate WordPress for the permissions trouble. What looked to be simple with the WordPress CLI (command line interface), wp media import did not work. ./wordpress/bin/wp would only ever get Permission denied. I should probably mention that the “user” I’m logged in as is not the same user as who runs the web site and has access to all the files.
Here are the steps I had to take to repair the damage. I got to figure them out; hopefully you will find them useful. And if the file gets damaged again, I’ll have these instructions for a quick repair.
- ssh into the server and find the uploaded file. In this case it will be in
./uploads/2023/04/ - rename the file to the old file name.
- move the file from
./wordpress/htdocs/wp-content/uploads/2023/04/to./wordpress/htdocs/wp-content/uploads/ - Delete the file in the WordPress Media Library (web page). WordPress will still show you the file, because it isn’t looking at the file, it’s looking at it’s database entries about the file. It looks like the file is there, but it’s a phantom. Delete it.
- Back to the server command line prompt: change the file system permisssions to be way too permisive.
./wordpress/bin/wp media import ./wordpress/htdocs/wp-content/uploads/file.pdf --path=./wordpress/htdocs/ --skip-copy- change the file system permisssions back. ASAP.
- When you look at the WordPress Media Library (web page), you will see your file again – but this time it has a non-time-stamped URL. Huzzah! Paste that link into whatever page needs to serve it up. In my case, since I moved the new file to where the old file was, the links were still good.
How to give way too many permissions (this is terrible):
sudo chmod -R 777 /path/to/folder/wordpress
How to fix the permissions:
find ./wordpress -type d -print0 | sudo xargs -0 chmod 755
find ./wordpress -type f -print0 | sudo xargs -0 chmod 644