GuildWiki:Software and technical issues/Bugs

Please make note of any bugs you encounter in the wiki here. Click edit and follow the directions in the text area that appears.

Can't find your bug? Maybe it has been Resolved.

Fatal Error
Page: Charlatan's Armor Problem: Fatal error: Allowed memory size of 12582912 bytes exhausted (tried to allocate 2048 bytes) in /usr/home/guildwiki/public_html/includes/Image.php on line 1071.

Submitted By: PanSola = 24.7.179.183 22:42, 4 April 2006 (CDT) who still can't login.


 * Fixed, the images were causing problems, so I took the images out of the page. We'll need to get new images uploaded, but at least the page works now.  --Rainith 01:11, 5 April 2006 (CDT)

GuildWiki is the target of spambot zombies
Page: Many (see recent history)

Problem: A spamminion master has been using his army of zombies to spam his urls everywhere.

Submitted By: 05:22, 28 March 2006 (CST)

Possible Fix: SpamBlacklist


 * I've gotten SBL to install on my test mediawiki installation without too much trouble. 05:22, 28 March 2006 (CST)


 * An easier way to take care of the problem is to disallow anonymous edits. -- James Sumners 22:12, 28 March 2006 (CST)


 * You think that will really help? A load of them post by name. 22:30, 28 March 2006 (CST)


 * Hmm, I hadn't really been keeping up with the spam posted here so I didn't realize they were using accounts. -- James Sumners 00:40, 29 March 2006 (CST)
 * I would estimate that at least 95% of the spam and vandalism is posted from anonymous IPs. Just look at Special:Log/block to see a list of users that have been banned for varying amounts of time. --161.88.255.140 01:03, 29 March 2006 (CST)
 * Of course, if you did require a logged in account, that could just make the spam harder to police. Currently, you can look at the Special:Recentchanges and give special attention to anon postings.  Requiring logged in accounts just requires the spammer to write a script to automatically walk through the set-up screens for creating accounts.  Spam continues, but the likely candidates for extra scrutiny are harder to spot. --161.88.255.140 01:15, 29 March 2006 (CST)
 * Oh yeh, every IP edit I see is a potential spam edit, yay for paranoia! 01:49, 29 March 2006 (CST)
 * Sadly, that is how I react to IP posts. I certainly don't consider all IP posters to be spammers, actually very few IPS posters are spammers, but most spammers are IP posters (and yes, I see the irony in my using an IP address) --161.88.255.140 07:11, 29 March 2006 (CST)


 * I disagree with IP-based blocking on principle. It makes the baby Wikisus cry. Filter the spam, not the potential spammer. 01:07, 29 March 2006 (CST)


 * I agree with Stabber, just look at the flow of Spammer. Has it ceased? Has it decreased? Has all the blocking actually made Skuld feel any safer? :) I don't know what that SBL thing does (and no Stabber I didn't click on the link), but I imagine it basically reviews submitted edits to prevent the Spam edits from taking place, regardless of IPs. --Karlos 07:02, 29 March 2006 (CST)


 * Bump! SpamBlacklist is an utterly trivial 90% solution to spam links. F G 22:42, 6 April 2006 (CDT)
 * Looks like it is included in MediaWiki 1.6. Now if only we could get an upgrade... -- James Sumners 00:18, 7 April 2006 (CDT)

Timezone display problem
Page: All pages

Problem: The times inserted by the server appear to be UTC+8 (Hong Kong, Singapore, etc.) times, but they are flagged as "CST", which I assume is "Central Standard Time". Either the server should be made aware of its own timezone, or it should print timezones as "UTC+8".

Comments: I'm researching the fix at the moment. Will update this comment when I figure it out.

Submitted By: 04:22, 10 March 2006 (CST)


 * This seems to be a server misconfiguration rather than a mediawiki bug. How hard would it be to configure ntpdate or something on the server to sync the correct time with various global atomic clocks? FreeBSD documentation for this in case you need it. 09:01, 14 March 2006 (CST)


 * Bumping this issue. It's really annoying since MediaWiki ignores user settings that try to go more than -12 hours, and I think California is 21 hours behind Hong Kong. -SolaPan 20:10, 6 April 2006 (CDT)

Selecting skins prevents login
Page: All on site

Problem: I was playing with my account preferences (timezone, etc) and saw the option for skins. I selected one to see what it looked like, and clicked "Save". Now the only way that I can access the site is by deleting the cookie for gw.gamewikis.org. Once I attempt to login again, the cookie is re-created, I am unable to access the site, and I receive the following error message: Fatal error: Cannot redeclare class skinmonobook in /usr/home/guildwiki/public_html/skins/MonoBook.php on line 25

Comments: While I knew to delete the cookies in order to regain access, how many users have done the same as me and did not know to delete the cookie? I realize that for the technical minded out there, it's hard to imagine anyone not knowing to do that; but there are a lot of people whose only thought when cookies are mentioned is wondering if they're penut-butter or chocolate chip. I can't help but wonder how many might be out there that lost access to the wiki due to this bug, and now are effectively blocked from even viewing it anymore. --161.88.255.140 00:45, 8 March 2006 (CST) (username: "161.88.x.x")

Submitted By: --161.88.255.140 06:45, 4 March 2006 (CST) (my username is: "161.88.x.x")


 * PanSola here. I just ran into the same problem, and can't log in to my account anymore...  If this bug isn't fixed I'd have to create a new account... -24.7.179.183 15:00, 17 March 2006 (CST)


 * I posted a note on both Gravewit's and Nunix's talk pages to try to get their attention about this. Unfortunately I don't know what else to do.  --Rainith 15:09, 17 March 2006 (CST)
 * EDIT - And I left him a PM on the GWG forums. --Rainith 15:15, 17 March 2006 (CST)

Red links for non-broken links
Page: toolbox (every page)

Problem: "Report A Bug" link is red, creating a false appearance that the link doesn't work, which kept me away from clicking it to report bug during the past however many months.

Submitted By: PanSola 11:24, 1 March 2006 (CST)

Notes: Ok, I know red makes things stand out. But because it's also the "broken link" color, I think a different color should be used to highlight it. -PanSola 11:25, 1 March 2006 (CST)


 * I have a similar comment about text in the Ch2 infobox. 11:50, 1 March 2006 (CST)

mdash
Have many of the mdashes turned to garble? I'm getting â€” in place of them. I have a feeling it happened with the server move. &mdash; Lunarbunny 13:44, 18 February 2006 (CST)
 * Special characters got $#(%*ed during the server move. I dunno how to fix them.  --Rainith 13:50, 18 February 2006 (CST)
 * See MediaWiki talk:Sectionlink. 05:20, 22 February 2006 (CST)
 * Actually it just involved deleting the page altogether. I just didn't know which page it was.  --Rainith 05:35, 22 February 2006 (CST)
 * Can you nuke the talk page as well as it serves no purpose any more? 05:50, 22 February 2006 (CST)
 * Done. --Rainith 06:06, 22 February 2006 (CST)
 * Woah, is this fixed now? I don't even know what I did. Gravewit 02:37, 23 February 2006 (CST)
 * I don't know what happened with the move to the new server, but MediaWiki default created a bunch of pages like MediaWiki:Sectionlink which caused the messed up characters to appear. It seems that the way to fix that is to delete those specific pages.
 * The full list of these pages is in Special:Allmessages. There are only one or two other rare messages that are still garbled up. Seems like the only way to catch 'em all is by a brute-force linear traversal. 04:37, 23 February 2006 (CST)

(Not so) Special pages
Page: Special:Specialpages

Problem: The Special pages page seems to be missing all the normal special pages. I see the Admin special pages, but none of the normal ones.

Comments: Someone else mentioned this somewhere, but I wanted to put in an official report.

Submitted By: Rainith 16:56, 12 February 2006 (CST)

Notes:


 * I get this problem too - I cannot see ANY of the Special pages (not an admin). This just seems to be since we moved to the new server... Kidburla 22:52, 13 February 2006 (CST)
 * it was me and I can't remember where. still all blankety -_- 00:06, 20 February 2006 (CST)
 * They're back 04:44, 23 February 2006 (CST)
 * Still having a problem with them. Seems I can get them to show up by refreshing the page a few times.  --Rainith 04:50, 23 February 2006 (CST)
 * I get the same problem. For me it seems to depend on which page I am on when I click the link. Doesnt seem to make sense. --Xeeron 20:24, 23 February 2006 (CST)
 * For me the Special pages page is ALWAYS blank, ever since the problem started. -PanSola 11:21, 1 March 2006 (CST)

In the meantime I figured out what some of them are called, and put them under Specialpages. -PanSola 17:28, 2 March 2006 (CST)

Upload Bug
Page: Special:Upload

Problem: When uploading some files (usually with somewhat long file names (10+ characters)) I get this message: Could not copy file "/home/zeroliv/tmp/phpRAR4o6" to "/usr/home/0chroot/zeroliv/home/zeroliv/public_html/guildwars/images/0/06/BogSkaleBlighter.jpg".

Comments: Seems to happen every time I try to upload the file "BogSkaleBlighter.jpg" with another file that was having the same problem I managed to upload it by shortening the file name.

Submitted By: --Rainith 14:16, 16 October 2005 (EST)

Notes: I can not confirm that this has to do with file name length. This bug seems to happen randomly to me, with short and long file names alike. --Tetris L 01:32, 22 November 2005 (UTC)

Problem I've had the same problem, any solution?
 * See Software & Technical Issues/Bugs for a workaround.


 * This bug doesn't exist on other MediaWiki installations I have tested. My conjecture is that it is a permissions issue with certain subdirectories under images/. See also: Category talk:Upload errors. 09:30, 2 March 2006 (CST)

This is a long report: I decided to trawl through the Mediawiki source code to see what the bug was. First of all, I was able to duplicate the bug -- it has something to do with the  flag.

After lots of instrumentation and whatnot, it appears that the problem is with the  function and how it operates in safe_mode. The relevant function is  (and friends) in. If you instrument the various  calls there (or simply comment out the  ), then you will see that some   calls fail with a warning. The reason, according to the mkdir documentation is that in safe_mode it requires the parent of the  to be owned by (not merely writable by) the same user that the apache process itself runs as. A similar restriction exists for all the file munging operations.

Now, my suspicion is that the  directories for the gw.gamewikis.org root uses are not actually owned by the user the apache process runs as. On my Debian box, this is the  user. I dunno what FreeBSD uses -- probably. In this case, the fix is: chown -R nobody /path/to/wikiroot/images

This fixed the bug on my test wiki. There won't be additional security issues with this, as presumably these directories were already writeable by user. Can you try this and see if Image:DistractingShot.png (for eg.) is uploadable as Image:Distracting Shot.png now? 08:34, 14 March 2006 (CST)

Mis-floating Categories
Page: Previewing some pages.

Problem: Sometimes in preview, the bar showing the categories will float on top of the edit box for the article. Adjacent is an example.

Comments: This is reminicent of the old problem we had with the About Disclaimr bar. I am sorry, it does not appear consistently so I cannot pin one article where it always happens.

Submitted by: --Karlos 17:12, 1 November 2005 (EST)

Fatal Error
Page: <-web link 'cause I can't figure out how to link to an image's page w/o sticking the image itself in this page.

Problem: This is the message I get trying to go to that page: Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 3200 bytes) in /usr/home/guildwiki/public_html/includes/Image.php on line 1073

Comments: I'm guessing that this file someone uploaded it too big for MediaWiki, if so it should be deleted and the uploader should re-upload a smaller sized version.

Submitted by: --Rainith 23:04, 15 November 2005 (UTC)



Image does not display
Page: Image:Armor_courtly_f.jpg and Courtly Armor

Problem: The image does not appear at all in its own page and appears as a thin line in the armor page. Yet, the image is there on the server by virtue of this page: Image talk:Armor courtly f.jpg.

Comments: I can get the image to display on the Courtly Armor page, but not on the image's page itself. --Rainith 18:44, 17 November 2005 (UTC)

Submitted by: --Karlos 18:36, 17 November 2005 (UTC)

Paypal Bug
Page: Site support

Problem: Having to go GuildWiki-less recently, I went to donate via PayPal, however after choosing Canadian Dollars I get an error at the PayPal site of "Please enter an amount greater than zero." There's nowhere for me to enter an amount and clicking on "retry" yields the same result. Help? --User:Nietha

Comments: Originally posted on User Questions.

Submitted by: --Karlos 10:27, 21 November 2005 (UTC)

Upload Error
Page: Special:Upload

Problem: I try to upload Green.jpg and get Could not copy file "/var/tmp/php9TJmy9" to "/home/guildwiki/public_html/images/0/0e/Green.jpg".

Comments: Generally, there is a work around. Upload the image to a different name then change the page. Of course if the image is used frequently, that work-around is not so useful. --Karlos 12:41, 3 December 2005 (UTC)

It is usually as simple a fix as changing the capitalization of the extention to fix it. If you were trying to upload "Picture.jpg" change it to "Picture.JPG" It would be nice if we could add info about this to the Upload page. --Rainith 02:20, 4 December 2005 (UTC)

Submitted By: 83.67.39.175 06:44, 3 December 2005 (UTC) EDIT:

Undeletable Image
Page: Image:PlantFiber.png

Problem: When I try to delete this image I get this message: Could not delete file "/home/guildwiki/public_html/images/0/04/PlantFiber.png".

Comments: I think that Freyn has run into this problem before too with other images...
 * Yes, Ahiinrt, this has happened before. This is still around.  image:Image:Armor_frostbound_m.jpg (/home/guildwiki/public_html/images/0/04/Armor_frostbound_m.jpg) has the same problem.  --Fyren 19:40, 27 December 2005 (UTC)

Submitted By: --Rainith 03:27, 4 December 2005 (UTC)

Update: It's not solved but there's a workaround. If you run into any images that cannot be deleted, put a note on either User Talk:Gravewit or User Talk:Nunix; the images have to be removed from the database manually. Before the image-page itself can be deleted. --Nunix 00:32, 8 January 2006 (UTC)

Missing email reply
Problem: Created a new user account, entered an email address and followed link to confirm email address. Clicked on button which appeared and message claimed a confirmatory email had been sent. None actually received.

Submitted By: Rhess 07:45, 10 December 2005 (UTC)

Problem Continues: Same as above. Checked my profile, my email address is correct there. Is there a problem with the mail-bot?

Submitted By: Purple Recluse 17:45, 17 January 2006 (UTC)

Comments: Anyone else have this happen recently (since the server move)? Gravewit 02:40, 23 February 2006 (CST)


 * I changed my mail address a while ago but no confirm ever came through, that could be because I don't have access to skuld@@@simsational,,,co,,uk, my old address, =( 18:36, 20 March 2006 (CST)

Comments: Yes, the page will not send emails to any of my email accounts upon request. (By changing or activation.) --Nilles 01:52, 2 April 2006 (CST)

MediaWiki Version
Page: All pages.

Problem: The latest version of MediaWiki is 1.6.1. This version includes security updates. The version of MediaWiki that GuildWiki is running is 1.5.0.

Comments: I believe the software should be updated. Security fixes of any kind are important. Especially when one of the fixes is "Fix for remote code execution bug in 1.5 branch."

Submitted By: James Sumners 04:32, 10 March 2006 (CST)


 * Just a bump for this. 1.5.0 is vulnerable to a remote code execution flaw. What this basically means is that any attacker can if desired, run whatever they want in the context of the wiki user. This allows them to for example, delete the entire wiki, stick malicious code in there, delete all the admins, whatever they want. Even worse, it's possible to just use this vulnerability to stick their own code on the box, and use it as a zombie, spamming other sites much like this one is being spammed. Please upgrade! LordKestrel 01:48, 5 April 2006 (CDT)
 * Can you use this vunerability to upgrade the wiki? -SolaPan 10:50, 5 April 2006 (CDT)
 * Theoretically, yes. No way in hell would I ever do that though, it opens me up to far too much potential legal trouble. LordKestrel 15:02, 5 April 2006 (CDT)
 * There is now an even newer version available with even more security fixes. This should really be addressed. -- James Sumners 22:37, 6 April 2006 (CDT)