Forum:Move - bug reports

This is basically a thread to collect all the little issues you've noticed so we can either fix them ourselves or pass them on to Curse. If anything's off, no matter how minor, please post it here :)

I'm starting off with the list of issues the admins have compiled/been working to fix so far.

Current list
List of unresolved & partially resolved issues. For resolved issues, see /resolved.

(S) = can be fixed by us (C) = needs to be fixed by Curse

Page content

 * all reported issues resolved

CSS & skin

 * (C) Validation errors:
 * #global-wrapper is unclosed (missing  ).

JavaScript

 * all reported issues resolved

Misc

 * Email:
 * (C) Confirmation emails are not being sent.
 * Images
 * (C) Some .gif images are corrupt and not displaying full color range
 * (C) Broken images in Special:UnusedFiles and Special:UncategorizedFiles require fixing

Current reports
For reports relating to resolved issues, see /resolved.

Unused images
Special:UnusedFiles still states more images than it shows as unwanted. Currently states there is 7, but only shows 6. User Avatar talk.png 20:57, 1 December 2011 (UTC)
 * Before I re-add this to the list, could we get some feedback whether Curse has tried any of my previous suggestions and if so, which ones? -- Porter21 (talk) 10:12, 2 December 2011 (UTC)


 * All these rebuild scripts have been run. Ausir 13:27, 2 December 2011 (UTC)


 * Ok, then I'll look into what else might be causing this. -- Porter21 (talk) 16:06, 2 December 2011 (UTC)


 * "/maintenance/checkImages.php" and "/maintenance/cleanupImages.php" would be my last suggestions for finding out/fixing what's wrong, otherwise I'm out of ideas for now. -- Porter21 (talk) 16:46, 2 December 2011 (UTC)


 * On a sidenote, running "/maintenance/rebuildFileCache.php" probably wouldn't hurt either, it might fix the issues with certain GIFs/PNGs. -- Porter21 (talk) 17:12, 2 December 2011 (UTC)

Good news: After the upgrade, Special:UnusedFiles and Special:UncategorizedFiles now show the broken files (rather than only including them in the counts), so we can finally fix it. -- Porter21 (talk) 19:23, 8 March 2012 (UTC)


 * Seems like there are a couple we can't get rid of because they have invalid file names? -- Porter21 (talk) 16:52, 19 March 2012 (UTC)


 * $wgIllegalFileChars needs to be adjusted to allow both " and / so they are no longer invalid file names. Preferable to the default value of restricting only : from the file name, just in case there are other files that contain illegal characters that crop up in the future. User avatar tag.gifUser Avatar talk.png 01:31, 20 March 2012 (UTC)


 * Are you sure about that one? It's a bit confusing, but to my understanding it works like this:
 * $wgLegalTitleChars defines which non-alphanumeric characters can be used in page titles (including file names).
 * $wgIllegalFileChars contains a subset of $wgLegalTitleChars which are disallowed for file names specifically.
 * So I don't think you can allow  and   for file names by altering $wgIllegalFileChars; you'd have to alter $wgLegalTitleChars. Since that is potentially dangerous, I'd rather avoid it if we can. I've suggested to Ausir to run  ; hopefully it'll find the files with unparseable file names and rename them.
 * Still wonder how those files ended up in the database in the first place. -- Porter21 (talk) 11:02, 20 March 2012 (UTC)


 * From what I am reading here - mw:Manual:$wgIllegalFileChars and mw:Manual:$wgLegalTitleChars, those 2 settings should work in the same manner as black/white lists. So changing either should have the same result. The reason I mention $wgIllegalFileChars, is because it affects only files names and not all page names. That aside, if cleanupImages.php does fix the issue for the remaining images, what happens when we come across other images that contain such characters in the future. Are these setting going to prevent us from renaming, deleting etc. such files. I only ask as I have yet to look for a valid image with these attributes to check if it may chase issues down the line. User avatar tag.gifUser Avatar talk.png 12:58, 20 March 2012 (UTC)


 * Well, I think we agree that those settings are a sort of blacklist/whitelist setup, but I guess our interpretations of priority/order differ ;) I think $wgIllegalFileChars can only be used to blacklist characters which were previously whitelisted by $wgLegalTitleChars, but it can't be used to whitelist characters. That aside, the main issue I see is that both  and   are not valid characters for use in file names in any OS that I know, so there's a good reason these are not allowed for the name of the "physical" files; I'm pretty sure the server won't like files with such names being uploaded.


 * As for the script, if it does fix the issue for the current "problem" images it'll also fix it for any other images which are currently in the database. In my opinion, the handful of problematic images which are currently in the database were likely created by the script used to harvest the images during the move (since, as we've noticed, the software prevents uploads with illegal names like that). Once we get rid of the ones currently in the database, I don't think we'll have any such problems in the future. -- Porter21 (talk) 13:19, 20 March 2012 (UTC)

The other reason I mention $wgIllegalFileChars as the cause is the fact that while Cell for Dead "Void Creatures".jpg is disallowed, Cell for Dead "Void Creatures" is a valid title (also tested as a new page creation). Additionally, uploading Cell for Dead "Void Creatures".jpg displays the same symptoms as described in the MediaWiki manual, where by illegal characters are converted to.

But now you mention the import script that harvested the images, a new trail of though has occurred to me. Cell for Dead "Void Creatures".jpg exists over on Wikia as is. So why the page title is valid and the script created the page during the import, there was a conflict in creating the actual file itself due to this setting. This conflict has obviously created sync issues between the file actually existing and the file table list, I am assuming of course that the import script also amended the file table directly instead of the MW software. If that is the case there are a couple of scenarios that come to mind. Firstly, these are the only images that are affected with illegal characters and once resolved shouldn't be a issue in the future. The other scenario is that there are other file pages out there that exist without an actual image, essentially leaving use with missing images. Without knowing how the import script works in detail I can only hazard a guess, but logically to me it should be the first scenario, so once these files are fixed it should all be good. 14:25, 20 March 2012 (UTC)

Site map
May want to run maintenance/generateSitemap.php mw:Manual:generateSitemap.php, as I cant seem to find a sitemap for here, this would help a lot with SEO. While we are at it, might be an idea to get robot.txt done as well. User Avatar talk.png 01:44, 26 January 2012 (UTC)

Confirming emails
Seems trying to confirm an email is not sending out a confirmation email to validate the email address. 21:40, 27 March 2012 (UTC)


 * Confirmed - doesn't work for me either. Added it to the list. -- Porter21 (talk) 12:20, 28 March 2012 (UTC)
 * Hmm, it worked for me now. Looks like the issue is fixed. Ausir 23:12, 17 April 2012 (UTC)
 * Well, it's still not working for any of my email accounts (just to clarify, this is specifically about the email address authentication). -- Porter21 (talk) 00:14, 18 April 2012 (UTC)
 * Weird, I created an account with a new e-mail and it worked, I got a confirmation e-mail. Are you sure it's not landing in spam? Ausir 10:36, 18 April 2012 (UTC)


 * Confirmed, still not working for me either (checked spam etc.). User avatar tag.gifUser Avatar talk.png 11:03, 18 April 2012 (UTC)


 * I checked the spam folders multiple times and even tried an email account which doesn't have any spam protection. Maybe it works for new accounts but not for people who already had a validated email and try to change it? -- Porter21 (talk) 11:27, 18 April 2012 (UTC)

Links
Not really a bug, but just something that bugs me, might I suggest that $wgExternalLinkTarget be changed '_blank' in the settings.php 21:39, 4 April 2012 (UTC)


 * Hmm - I think changing this setting to "_blank" would result in internal links which are formatted as external links (such as the "view/discuss/edit" links of navboxes) being opened in a new window as well. Maybe a gadget would be better? It could differentiate between pseudo-external links and real external links, whereas that setting can't. Plus this seems like something people should be able to choose for themselves. -- Porter21 (talk) 08:48, 17 April 2012 (UTC)


 * I've added the gadget. -- Porter21 (talk) 07:03, 18 April 2012 (UTC)


 * Works great, although I would have preferred it to open both external and interwiki links in a new tab. User avatar tag.gifUser Avatar talk.png 19:32, 21 April 2012 (UTC)


 * It's supposed to do that (and it does for me). What's not working for you? -- Porter21 (talk) 10:46, 23 April 2012 (UTC)


 * Interwiki links where not opening in a new tab for me, but I just went to check again to confirm and it seems that they are now working for me. So it is all good at present. User avatar tag.gifUser Avatar talk.png 13:05, 23 April 2012 (UTC)