Category talk:Pages with broken file links

A page gets listed here and you can't fathom why?

Whatever the cause, assuming the page does not actually contain broken links, there's an easy solution: edit the listed page and immediately save it without changing anything. Its history won't change, you won't be credited the edit, but the page will get de-listed. Aldyron (Contributions • Message) 11:05, November 15, 2014 (EST)

• If the page is listed here, then the wiki software has determined there is a broken file link. If you can't figure out which one or why, let me know and I'll dig in deeper. ShoeMaker (Contributions • Message) 13:25, November 15, 2014 (EST)

I may have not been crystal clear in my first post. I'll try again.

Sometimes, you find out a certain page is listed in Category:Pages with broken file links, but you double-check the page and you can't find any broken file links.

For example, it happens to me in a repeatable way when I edit or create a page and save it with a picture link that is intentionally broken in order to then click on its redlink to upload the corresponding actual picture file. Before the upload, the page is of course listed in Category:Pages with broken file links, and both category listings at the bottom of the page say (since my preferences are thus set) the page belongs to this hidden category.

Now, after the upload, I'd expect the page not to be listed in Category:Pages with broken file links any more, but it's not so. That's odd. What's odder is that now only one of the category listings at the bottom of the page say the page belongs to this hidden category.

At this point, I'm inclined to think this behavior is caused either by a bug in the MediaWiki software or by some unforeseen interaction between installed extensions.

Now goto my first post... :-D→ Aldyron (Contributions • Message) 09:03, November 16, 2014 (EST)

Forgot one thing. A few minutes ago I've uploaded the mugshot for Zombie Pirate. As I write this, that page is listed in Category:Pages with broken file links. I will leave it that way so that someone else can verify (or not) my results. Please, whoever does so, write your findings here for reference, thank you. Aldyron (Contributions • Message) 09:13, November 16, 2014 (EST)

• I know What you are saying. Let me see if I can give some pointers on solving how entries show up in this category.
  1. Recent uploads used on pages before the job queue adds the file to the database.

     If you save a new page with an image that hasn't been uploaded, or is being uploaded at the same time, or was just recently updated before the page was made, then the page will likely show up in this category, but will eventually go away on its own once the job queue gets around to updating the categories on the page.

     To correct the issue yourself immediately (as job queues have been known to take months) you need to preform null edits on both the image then the page, you will need to go to the page where the image is, ie File:Example.png where Example.png is the new image. Click "Edit", "⇓ Scroll down to edit box ⇓", and then the "Save page" button. Then, you will need to preform a null edit on the page where the image is used (the page that is in this category) by navigating to the page, clicking "Edit", "⇓ Scroll down to edit box ⇓", and then the "Save page" button.

  2. Use of really old images that were "transwikied" from enterwiki. When we migrated all the images from enterwiki a few years back, the images made it over, but none of the corresponding pages in the database for the files made it over, so the server doesn't "know" they are all here. When this happens, the software displays the file which is where it is suppose to be, but since it doesn't see the file in the database, the page lands here. There are a couple ways to fix this so that the page will no longer be in this category. The best way to do it is to download the image to your local machine, get an administrator to "delete" the image from the server and then re-upload the image using the software's upload page to the same location. Once you do this, preform a null edit on the image and the page in the category and it should go away. Complications have been known to arise in this process and it has been known to not take. In those cases, your best bet is to contact Xevo or myself.

  So, it's not a bug in the software itself. The first example (the one that applies to your comment) is a just a matter of a little patience (and the reason in only shows up in one of two category sections is because one of them is populated by the core software itself, which relies on the job queue to update it, and the other is an extension we use to prettify the category structure. Some interesting reading on the topic can be found at mw:Manual:Job queue — mw:Manual:Purge#Null edits The second was created by human error in the heat of the moment and will take a large scale effort on my part to completely correct the issue (it's also part the reason we can't move files to other page names without downloading the image, deleting the old page name, and re-uploading to a new page name). ShoeMaker (Contributions • Message) 15:10, November 16, 2014 (EST)