Off Topic: Forum (& Wiki) glitches

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.

 

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.

 

If you log in using the url http://www.tetrisconcept.net you won't be logged in if you visit http://tetrisconcept.net , and vice versa.

 

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.

 

The fumen tags are broken. I have a link I've put into fumen.zui.jp and have seen it work, but then when I take the code (the m code, not v) and put it in the fumen tags, the resulting fumen is corrupt as all hell. What's up with that?

ex:http://fumen.zui.jp/?m105@DckzjbQpJ...prDeEFr4AAi/NKAEirSASYjrDG/BAAAwNFAHE98ARAAAA

becomes:

 

So I guessed Zircean's bug is fixed? Seems to be working for me.

Not forum related, but the Playing Forever page isn't laoding on the wiki.

http://www.tetrisconcept.net/wiki/Playing_forever

 

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.

 

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.

 

ST Stacking Setups page is also silently failing.

 

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.

 

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

 

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.

 

You are the man. Thanks.

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

 

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.

 

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.

 

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.

 

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.