There has been discussion, query/complaint made in several locations on this wiki concerning problems with misalignment of certain pages. As one user described it "the page is all squished up". The "Community Portal" is one example of a page where this problem has occurred. For those of you who haven't encountered this, the problem is transitory. If you open the page as if to edit it, the problem goes away. It eventually returns, though I don't know how long that takes.
I also do not know what's causing it. However, the problem is not unique to this wiki, as it has been reported on other wiki as well---for example "Zelda". I presume that there's some sort of coding problem that is triggering this---it could be some particular combination of code needed to create (for example) display boxes, tables, etc. However, the common denominator seems to be related to page size and/or complexity. I tend to see this on larger pages, but I don't think the Community Portal is particular large, so there must be something else involved.
I've tried to get some help on this at Live help, but go only a limited response there (Yup, looks like a problem, but no suggestions). Also tried on Wikia Help forum, and perhaps additional thoughts will come from that source. I will attempt to reogranize some pages where the problem is known to occur, perhaps breaking them into small pages to see if that helps. It will be a slow process since the problem goes away immediately once you edit a page---only to return later. Hence, its a matter of trying something, then waiting to see if the problem goes away permanently. Bill 13:18, 23 June 2007 (UTC)
- Good work, Bill. Robin Patterson 02:27, 24 June 2007 (UTC)
Some further developments: apparently the problem is being seen in a number of wiki's. GreenReaper has indicated that he believes the problem is related to the use of "div's" AND TOC, and that the issue cropped up after the recent upgrade. So things that used to work, now create this problem. I think we can work around this, but until Wikia addresses the problem, we can expect to see this periodically. In the meantime, when I see the problem, I'm attempting to isolate the offending code, and do something different as a work around. I made some adjustments last night in the Community Portal, and on the Help page, and the problem seems to have gone away this morning. If someone encounters the problem elsewhere, let me know and I'll see if I can do anything for it. Bill 15:23, 24 June 2007 (UTC)
Continueing on with the saga.... GreenReaper posted the following re workarounds:
- "Workaround: Purge page cache (add ?action=purge to URL) with a user that does not have in-page editing (anonymous users do not count for this, and you may well have noticed the problem after an anonymous user edited the page). The problem seems to be caused by wikiwyg stuff inserted into the cached version of the article. I've dropped an email to the developers and they are investigating. --GreenReaper(talk) 05:24, 25 June 2007 (UTC)"
So, looks like this has been elevated to an appropriate level. My experience with past errors of a MediaWiki nature is that there will be a fix---when the next upgrade occurs. So that may be sometime away. In the meantime, workarounds are in order. GreenReaper suggested one---I think what he's suggesting is to add the phrase "?action=purge" at the end of the url, and reload. I don't know if that can be done automatically, or if you have to add it manually each time it comes up. If it has to be done manually, opening and closing the page (ie, pretending to open it for editing, and closeing) is probably a simpler expedient. For long term purposes, trying to isolate the offending codeing (__TOC__ ) embedded in a div seems to be at least one of the culprits) is probably a better bet, though you may loose something in layout---better to loose something than to present people with a mess to look at.
The pages I've fiddled with seem to remain "fixed"...but since this is a delayed reaction problem, its hard to say if anything has really changed. One clue in GreenReaper's comment is that the problem may be triggered only by anonymous users---GreenReaper thought that it might occur with an anonymous edit, but perhaps its just a page access by an anonymous that's doing the deed. That would make sense, given the unpredictability of the problem--perhaps that's because we only see it when the random anonymous user accesses the page. While we can ban anonymous edits (if we want), banning anonymous page accesses a) doesn't seem practical and b) perhaps not possible. Bill 12:57, 25 June 2007 (UTC)