# Off Topic: Forum (& Wiki) glitches

Thread in 'Discussion' started by DeHackEd, 3 Jul 2009.

1. ### DeHackEdgreen Gm

Recently there were posts with damaged formatting. If you had bold text, it was missing. Same goes for:
• Lists (self-referencing gag)
• Underline
• Other exotic formatting

I think I've taken care of the last of it. If anyone catches any more historical posts in bad shape, please post and link to it.

This is the prime example of such a heavy post. It's fixed now, and here's hoping that's all of them.

Known problems: size tags are broken and not returning. The exact size is not saved and I'd just be guessing at the origanl sizes anyways.

2. ### tepplesLockjaw developer

Asterisks

I've found another glitch. At least in Firefox 3.5,
Code:
 elements are displayed full of asterisks. It makes a total mess of the [url=http://www.tetrisconcept.net/forum/showthread.html?t=11]LJ65 records[/url] topic, for one.

3. ### Muf

That's a known problem, and it it seems to be related to character sets. We have no idea why it only occurs in code tags, but a simple solution is to edit the post (which miraculously gets rid of the asterisks), copy the text to Notepad, paste it back into the browser edit field, and save the post. I've been doing this with all the records threads I've randomly come across.

I've found another glitch, the links in this post look strange:
http://tetrisconcept.net/forum/showpost.html?p=61&postcount=1

They're ()surrounded by double parentheses().

Last edited: 3 Jul 2009

5. ### Muf

Caithness: fixed.

6. ### nightmareci

The forum also ate up the hard tabs that were in my
Code:
code
tags; the only thread I used such special formatting was in Who likes Klax?, and I manually edited my posts to have the original formatting. Posts by tepples in that thread are still improperly formatted with asterisks and no hard tabs at this time.

9. ### Muf

Zircean: fixed.

10. ### nightmareci

I believe Playing forever doesn't work because it's so long that MediaWiki is overloaded with so much data. If you create a link to Playing forever's edit page, like this, then you can edit it, and remove some of the playfields and see that previewing the smaller page works. The old wiki actually gave an explicit "too much memory" error or similar when viewing this page, but the new wiki fails without any error reporting.

If you're desperate to try and view something, you could go into the edit history and select an older, smaller version of the page that works; the newest revision I could find that works, and the revision following it doesn't, is this one.

A proper solution to this problem of wiki pages being too large to view seems in order. One is to split up these big pages into a set of smaller pages, another is to introduce extensions that reduce the size of the pages but keep the same content in one page.

11. ### colour_thief

I'm very enthusiastically in favour of the latter solution. Even when the pages worked they were always really slow at generating the graphics. Seems a little strange for the same dozen tiny images over and over to cause so much trouble. There's got to be an elegant solution that we just never bothered to find when it was first set up.

12. ### Kitaru

ST Stacking Setups page is also silently failing.

13. ### DeHackEdgreen Gm

There's a new tag in the wiki designed to replace {{pfstart}}...{{pfend}}

Now you just use tags like this:
Code:
<playfield>
.T.......L
TTTIIIILLL
</playfield>

You may also use a space in place of a period.

All the same codes are recognized as pfstart/pfend, but they're MUCH faster to process and we may replace the images with something better as well.

In the meantime, ST Stacking Setups and Playing Forever have been modified to use the new style.

14. ### colour_thief

That's awesome. Can you explain where the speed difference came from? And are there any other low hanging optimizations?

15. ### Caithness

I don't know what it was like before the fix, but the fumen inserts look really funky in linux. The blocks are all really narrow, and squeezed to the left half of the playfield, with at least three hanging off invisibly.

16. ### Zircean

You are the man. Thanks.

*runs off to post this stuff in the TAP Death thread*

17. ### DeHackEdgreen Gm

The old code was basically doing a rewrite into more MediaWiki markup that required additional processing. For example, despite being completely useless every little image square was being rendered as a Wiki image link. If you clicked on it, you were taken to an information page about a 10x10 square.

<playfield> bypasses that and outputs raw HTML itself. I also cut out the useless links reducing HTML size a bit. ST Stacking Setup went from taking over 30 seconds (the limit, and hence never shows) to process to now taking about 7-8 seconds.

18. ### colour_thief

There's a harmless but annoying problem with fumens. Whenever they are on a page, the browser jumps straight to them. So instead of looking at the lastest post it's always the first fumen on the page.

To duplicate this bug, try replying (as opposed to quick replying) to this thread. Instead of focusing on the reply box, it'll focus on the first fumen in the post history below the reply box.

19. ### Rosti LFC

Does anyone else get it that when they use quick-reply, they end up being taken to an error screen?

Almost every time I use it I get taken back to my post saying I can't post more than once in seven seconds. It posts it once and then presumably tries to post it again, so I get an error due to the repeated post.

20. ### tepplesLockjaw developer

Use the Preview Button! Check those URLs!

I'm so used to hitting preview before posting that I usually hit "go advanced" or "more options" anyway even when I quick-reply.