Wikit Problems

On this page: Things that don't work as expected in this Wikit implementation

Please report Wikit problems to the google bug tracker!!! edit

LV 2007 July 31

PLEASE!!! Remember to submit ALL wikit bugs at http://code.google.com/p/wikitcl/issues/list

so that problems can be tracked.

AMG: What's the current preferred method of reporting wiki problems?

Historical list of wikit problems edit

wikignomes note: I've spun a new page off for the older comments on this page that are no longer relevant. However, I could use help from wikignomes in checking to see if the reports remaining here are still relevant. If so, it might be worthwhile to report unique ones to the wikit bug database...

From the "Wiki gripes" page - http://wiki.tcl.tk/18

Purpose: a place to list weird side effects, surprises, and ... gripes, with regards to the concept of Wiki Wiki webs, or Wiki in short. Related pages: Comments on the Tcl'ers Wiki, Suggestions for Wikit, and Wikit Problems.

JC: Some of the comments below ought to be moved to the above (new) ones, I think

The concept of Wiki is fascinating. Here's a list of thing which may need some improvement, please feel free to add notes:

URL recognition is tricky, "(URL)" links to "URL)", for example.
It's yet another formatting convention (albeit a very simple one) - the basic requirement being that it must display well as HTML, and on Tk. A secondary goal is to make it reasonably obvious and readable as plain text.

AK: Ok, I found the main references to the pages mentioned above, in Jean-Claude Wipplers page, but I think it illustrates a general problem. A Wiki usually grows in unpredecented ways, and very unstructured, thus easily causing the "lost in (hyper)space" syndrome: Where am I, where were I, how do I find X. I believe that at least one (trusted) user, in case of complex Wiki's some more, should try to "moderate" an area. Hm. ... I am not thinking of moderation in the sense of "pre-edit approval", it is more like gardening. First a spurt(?) of growth, then the moderator/gardener starts weeding (removing OT-post), structures the contents into something more coherent, afterward the next cycle of growth and weeding begins. These phases may overlap, of course.

1999 Mar 9, AK: I thought to say "yes", but then I noticed that the search facility cuts the returned result at 50 entries, just like the recent page. So I have to say "Not quite". A sitemap tells us what we have, in a clear manner. Using a search facility however is more like being blind and probing, we don't know about the possible contents of the site, what we can search for.

1999 Mar 9

DGP: What I miss most is a Table of Contents/Index/Site Map. Since The Tcler's Wiki is promoted as the entry point, there ought to be available on that page, or on a page linked by that page, some way to find all the pages there are. I thought the New Pages page might be it, but it seems not. I first entered the Wiki on package management, following AK's link in c.l.t. I don't think I could have ever found that starting from The Tcler's Wiki.

1999 Mar 9, AK, Remark: My link in c.l.t. used a feature of this wiki, the auto-search. If the url given to the cgi does not match the various standard formats (nn.html, nn@, nn!, ..., nn a number) it will start a search for possibly matching pages. A single word must be used, but capitalization can be used to mark inner components. The search will automatically add * between them before starting the search (LaVi => La*Vi for example).

1999 Mar 9, AK: The recent changes

page is a quite good approximation of a sitemap, but currently had the problem that some huge content (Books, Tcl-URL!) was added to the wiki in the last days, overflowing the limit of 50 entries quite drastically. Many of the useful other pages were ousted because of this. Setting the limit to 100 entries could.

BSA 23-Mar-1999: Q: Why do we have to edit in yet another special format, What is wrong with just using html? (other than complexity for new users). NB I am new to the wiki experience and haven't read the FAQ if indeed there is a link to it here.

AK, Mar 24, 1999: IMHO you already gave the answer: complexity for new users. A wiki tries to encourage readers to start writing too. A (simple) formatting language which is mainly text with interspersed commands should fare better in this regard than something like HTML, where it is quite easy to get lost in heaps of markup with interspersed fragments of text.

It's up to the people writing the Wiki to make sure that new users can find their way around. On Ward Cunningham's wiki this is done by a writing pages to welcome new users and roadmap pages for major topics.

DGP, 1999 April 20: It's really annoying that you can't italicize more than once per line. Also, how does one include a literal "[" in their text ( I guess I just did. ) without triggering another page marker. It's awkward trying to document Tcl usage with these quirks.

JC: On normal lines (not bullet lists and such), you can italicize by starting a new line, since formatting codes are recognized per line, even though they end up concatenated into one, see WOBBLE for an example. Brackets can be escaped by doubling them. Like [ and ]. I've added a note in the Formatting Rules page, thanks.

BG, 2000 Jan 2: I found that good old buggy Netscape would crash consistently once the single textarea post data grew enough. I had to crank up good old WebTk [1] to get the form to post.

RS, 2000-03-15: I'd like to be able to include Unicode entitities like in a Wiki page, but the ampersands get escaped, even with one or two backslashes in front. 2000-03-21: A more general thought, prompted by PSE: Why not allow embedded HTML which will pass through unchanged? This will allow Unicodes or other entities, embedded images, etc. Could look something like

This is normal WikiML

 <HTML><h2>Chinese Header </h2></HTML>
 ----
 And now we're back to WikiML again.

and everything between <HTML> and </HTML> would be copied as-is.

DKF, 2000-03-21: The problem is two-fold. Firstly, this Wiki is designed to be accessed by routes other than over the web (apparently) and these do not necessarily understand how to render HTML fully. Secondly, embedding arbitrary HTML allows some really nasty tricks with tables, frames, javascript (think of the damage you can do with onLoad), etc. Prohibiting these forces people to concentrate on real content with relatively little pain. And how do you handle the use of Unicode escapes when the browser says it cannot handle such stuff? Passing off Unicode in such situations is downright rude...

RS, 2000-03-21: Well.. we have kind of a class society where some browsers (getting more) can display Unicodes, and other can't (and show a question mark instead - also depends on the fonts you have, etc.). I see the point against arbitrary HTML, but &entities; (;-) can't do much more harm than being rendered as a "?", so I still advocate allowing them.

JC, same day: Yes, richer content (and how about images?) sounds attractive. It's true that Wikit runs as both CGI-generating-HTML and as local Tk app. Both of these wil probably handle extended character sets quite well nowadays (I still use an 8.0 Tclkit for this web site, but I have an 8.3-based one ready to go). Also, Richard Hipp's TkHTML widget is up to an amazing level of functionality, so HTML in local mode is becoming a more realistic option (I'll need to check the Mac side). But what kept me from making all sorts of changes, is that the current setup works well from a more modest goal and "if it ain't broke don't fix it" (whether it is broken or lacking new features is debatable). I find the current wiki markup pleasant to use as is. So here's my next excuse (hey, I have loads of 'em): Tclkit and the scripted document mechanism are both undergoing major changes. The new Tclkit uses Matt Newman's Virtual File System (VFS) approach, which is a fascinating way to hide differences between file systems and databases. So I've been sort of holding back (for months now), before going into Wikit again and changing things. To prove that these excuses are not completely lame: Tclkit 8.3 has become viable about a week ago, and I've started switching to it in a commercial project only two days ago. So there is measurable progress. Not that it's enough to make a difference for the issues raised here yet... :o(

If someone wants to work on some of this, let me know. It would make a good excuse for me to bring Wikit to the new setup, and it'll be much easier to modify and try out things, because with VFS you could run Wikit either as a scripted document or from a regular directory with a set of scripts.

Bryan Oakley, 2000-05-15: I wish that multiple references to the same external document would have the same number in []'s. For example, the following two references both point to the same location, but appear as distinct numbers: [2] [3].

Woo! First comment on my Wiki from comp.lang.tcl (with my reply at top):

 Not my fault, Jean-Claude Wippler is no more responsible than I
 am. Maybe somewhat less so!  That's one of his distributed pages.

 Glenn Jackman wrote:
 > In comp.lang.tcl, you wrote:
 > > I have posted the details of my (highly satisfying) experience
 > ...
 > > http://wiki.tcl.tk/17
 >
 > Pretty cool.
 >
 > I found a bad link on the (uneditable) Help page:
 > http://inferno.slug.org/cgi-bin/wiki/3
 >
 >     See http://wikit.tcl.tk/IncrTcl for more details.
 >
 > Should of course be http://wiki.tcl.tk/IncrTcl
 >                            ^^^^^
 >

male - June 24th, 2004:

Since the revisions of wiki pages are accessible, I ask myself often why pages are listed in the Recent Changes, even if nothing has changed!

What's about changing this, to have really a "Recent Changes" page!

escargo - It seems like have a "Recent Changes" page with an automatically generated link to the diff between the most recent two versions would be good, so you can choose to focus on the change (desired behavior) or on the whole page (current behavior).

Remember that the current revisions support is, as far as I am aware, only relevant for changes made the previous day basically. Also note that if someone makes a bogus change to a page, and someone else comes along and repairs the damage, the page won't appear to have changed, but will in fact have changed.

male - June 24th, 2004:

A bogus change is no change and should not appear on the "Recent Change" page!

A try to save a page without changes, don't have to succeed! The wiki should take this as a cancelled edit! To act like this, there is no need of a CVS and the nightly revision mechanism!

I don't understand why this tcler's wiki has such revision mechanism, where you have to wait a day to see what had changed! Our (usemod) wiki, we use as team in the company, supports an external diff to allow revisions inspection.

The times when we had to decide, which wiki should be used, the usemod wiki (written in perl) was chosen, because of the markup language containing tables, nested (un)ordered lists, (ordered) headings, this diff capability and a users recognition via cookie admin!

30sep04 jcw

I've also just changed the SearchResults proc to ignore pages with exactly 1 char on them. I usually (pseudo-)delete pages by storing just a single space in them. From now on, these pages will no longer show up in a search. They do show up in the Recent Changes

because otherwise no-one would see it when an entire page is cleared this way.

escargo 22 Jul 2005 - The following paragraph illustrates a problem. The bold text spans too many words:

If you click on the taskbar icon for the two apps the iconnames show but the iconnames don't update! Even more amusing is that the iconnames appear in tooltips when you roll over the iconnames with the updated values that are not shown in the iconnames.

For some reason, the closing triple quotation marks are not closing the first set, and the embolden treatment is continuing.

Another problem that I found; consecutive links get combined and only a malformed link gets coded:

An bad example of including a link that will be numbered [4][5] followed by another one.

An good example of including a link that will be numbered [6] [7] followed by another one.

There are really two links in the markup, but only one gets displayed.

Lars H: The first problem can often be worked around by not putting the entire paragraph on a single line, but I suspect you already know that.

The linking problem is another effect of Wikit's "free-text links first, bracketed links later" processing which IMO in very Murphy (whenever it can get it wrong, it will). See my comments dated 2004-11-27 above for details.

MG I've just looked at the code for Wiki (assuming I downloaded the right thing), and it looks like the problem is in format.tcl (the 'render' proc):

        while {
            [regsub -all {'''([^']+?)'''} $text "\0\1b+\0\\1\0\1b-\0" text] ||
            [regsub -all {''([^']+?)''}   $text "\0\1i+\0\\1\0\1i-\0" text]
        } {}

        # And then the remaining ones. This also captures the hilites
        # where the highlighted text contains single apostrophes.

        regsub -all {'''(.+?)'''} $text "\0\1b+\0\\1\0\1b-\0" text
        regsub -all {''(.+?)''}   $text "\0\1i+\0\\1\0\1i-\0" text

Those first two regsub commands (inside the while loop) aren't needed, by the looks of it, and seem to be what's breaking it. Though I've only looked at it briefly - there could be something earlier that requires those.

And I think the link problem comes from this line (also in the render proc of format.tcl):

  set pre  {\[([^\]]*)]}  ; # page references ; # compat

Which should, I think, be

  set pre  {\[([^\]]*?)]}  ; # page references ; # compat

to make it non-greedy. None of that's tested, or even looked at too heavily - just some quick glances while I had a few minutes free - but I think it's right.

escargo 25 Jul 2005 - Is Google supposed to be indexing the "Differences" pages? Or is somebody retrieving them and making them available inappropriately? (See http://matsuri.site.ne.jp/neko/neko.cgi?KEYCODE=&URL=http://mini.net/tclrevs/3011-2

for an example.)

escargo 17 Aug 2005 - The following line does not format as a tagged list item, despite conforming to the formatting rules statement: "To create a tagged list, use: three spaces, item tag, ":", three spaces, item text"

::math::sum: calculate arithmetic sum of two or more arguments

I suppose the problem relates to all those extra colons.

escargo 17 Oct 2005 - I wanted to use a definition list to reformat the Consio page a bit, but this problem still exists; is there any workaround that allows the namespace separators ("::") to be rendered without causing the definition list formatting to fail?

HZe - 19 Nov 2005

Only a small issue: when I use my PocketPC/WLAN to read this Wikit (by the way: it's really good displayed on a small device like this), I cannot use the Search page. It uses <isindex> for the search phrase and the Internet Explorer on my PocketPC doesn't show this tag at all. Would it be possible to just change this into an <input> element?

An alternative is to type the search in the URL: http://mini.net/tcl/2?holger*

Lars H, 14 Dec 2005: Page 8932 [8] has a title that seems to have been malencoded (Onze règles, rather than Onze régles). Is this a Wikit bug or user error? (The latter seems a bit unlikely, as page titles shouldn't suffer from the same saving-in-unaware-browser bug as the page contents do.)

BH 8th March 2007: There seems to have been a problem (maybe with a particular user, maybe with Wikit itself) that causes paragraphs on some pages to be shown within a

 if 0 { ...
 }

block. The problematic changes appear to be from 2005 or thereabouts.

CJL believes that to be deliberate, if a little odd when first encountered. It allows source code (outside the blocks) and descriptive Wiki formatted text (inside the blocks) to be interleaved such that you can copy the whole lot to your clipboard in one go and have some valid Tcl to paste into a wish console (or other). It may also have something to do with wish-reaper.

LV BH, can you give me a specific example, so I can take a look at the page?

CJL - http://wiki.tcl.tk/12241

In the case of that page (and many others like that) the creator of the page did that intentionally. What it allows is documentation to be included within the Tcl script that will have its text parsed for wiki formatting (URLs, hyper links, etc.)

CJL : Isn't that the reason I gave, just described from the other end?

KJN 2007-07-22: search for 'http' gives a link styled as [1] that is off-Wiki.

KJN 2007-07-22: saving an edited page takes a long time ...

... 26 seconds for the previous edit, forever for the one before that (I cancelled it and saved again). It seems to be slower than with the old wikit. I'm on DSL, and this is not a busy time (0042 UTC).

Seems to be a problem.

rgf 2007-07-23: Sometime last week the wikit style seemed to change ... like it no longer has a style sheet. Whenever I check pages they now come up without coloring/highlighting (recent changes, etc.) I'm using an older Mozilla browser (1.7.3) on Redhat linux. Am I the only one experiencing this?

DKF: It's probably a consequence of the fact that there are now two style sheets in use, one which gives the main page style and the other which gives the styling of the buttons. Looks like older Moz doesn't like the incantation used to do that (style sheet loading is a black art...)

rgf 2007-07-30: The wikit style sheet issue seems to be back - I've lost text and color highlighting. Its not just the older browser ... I tried Mozilla 5.0 and didn't see the normal styles either. 2007-07-31 ... and today its working again. Thanks!

LES on September 24, 2007: I can't read The Tclers' Wiki with my Blackberry 8300 (aka Curve) browser. I can access http://wiki.tcl.tk

, http://wiki.tcl.tk/0

and http://wiki.tcl.tk/4

, but at least 9 out every 10 pages I try won't load. The Blackberry browser says: The item you selected cannot be displayed. Do you wish to save the item? Yes No If I choose Yes, it prompts for a folder, but I didn't really save anything to see what ever gets saved. If I choose No, it says: Unsupported media type: x-text/wiki.

Incidentally, I can receive e-mail in this Blackberry, but the Rivet-dev mailing list digests won't open either. The mail reader says: Unsupported media type in header. Those are the only messages I have been unable to read in 24 days using the Blackberry.

MHo 2007-10-24: Just a few annotations regarding the new format:

if the new menu is turned off, the left border is to small (or zero), so the chars on the page browser page are sticking right on the left edge of the monitor ... ;-)
Is there a chance to make the edit window as large as before?
the default font sizes are bigger than before. But if I do a Ctrl-Minus in my SeaMonkey to switch to a smaller font, the font-size of the new menu on the left side becomes much too small...

stevel Thanks Matthias. Please log any such suggestions using the link at the top of this page so that they can be tracked. Any resolution might take time, there's been a *lot* of work go into getting the Wiki to this stage, so all concerned (Colin, Jos, myself) need to get back to real life for a while.

EKB I've found that I can't view the wiki on my Palm T|X using its built-in browser, Blazer. Apparently it has to have a .html or .htm extension to be happy (and I couldn't find an option to say, "assume an html extension if none is present"). Is there a reason these pages don't have an html extension? They seem to be plain ol' HTML. Thanks.

jdc You can add .html to page numbers. Internal refs are always without .html so you will have to add .html often.

EKB Thanks for that information. Unfortunately, that won't work for me. The Palm browser doesn't give the URL (without .html) in the address bar, where I could edit it. Instead, it pops up an error message saying that it doesn't have a reader for the specified content, then offers to either save the content (where presumably I could view it as plain text) or cancel. Would it be possible to add a feature on the server/wikit side that would add ".html" to pages without extensions for stupid browsers like Blazer that can't figure out a page's content aside from its extension? Thanks.

CMcC EKB, I've thought about this and my current thinking is: although the changes to help you would be minimal, so would the changes to fix Blazer's foolishness. Unless we can discover that the Wiki is delivering non-standard text to you, and fix that, I am loathe to add four bytes to every page just to work around what appears to be Blazer's authors' idiocy. Have you gone back to them to ask them about their specific dysfunction? What have they said?

EKB I haven't asked the Blazer folk. I'll ask them first. After all, this isn't the only site this will be an issue. I was just sad not to get to see the wiki when I was out and about with my Palm!

2007 December:

CMcC Found a problem with wikit when the disk fills up - the resulting errors are caught and modifications to the wiki db are silently not flushed to disk. The next time the wiki is restarted, all the changes are simply lost. This has now been mitigated by catching commit errors and forcing the wikit into read-only mode - at least then edits won't be lost, and someone can investigate the cause.

KJN Is it possible to avoid filling the disk? E.g. install larger drives, or run a cron job to transfer old logs to a machine with plenty of disk space, or mail you when the disk is nearly full, etc.

LV Problem no way to anticipate all the possible points of failure. So the first place to hit is where Colin mentions - find the places where errors may occur, catch the errors, and make certain that things are not lost and that people can't make new changes until things are fixed.

I want to publically thank Colin for his tireless efforts to keep the Wiki running. He took over this summer from JCW after technical problems this past spring arose, creating a multi-month downtime for the wiki. Having the wiki back up and running is such a joy, and I really appreciate the time, money, and energy that Colin invests in the software, hardware, and community.

KJN I too am very grateful to Colin for getting the Wiki back online, keeping it running, and improving it. The Wiki enhances the experience of every Tcler. The software appears to be reliable again, but problem of filling the disk has cropped up more than once. Larry, you are right that Colin has tackled the correct issue first.

Modern disks can give us hundreds of gigabytes of free space, and therefore plenty of warning before the disk is full. If a disk upgrade would help to solve the problem (and also make the sysadmin's life easier in other ways), I would be glad to contribute to the cost, and I am sure other users of the Wiki would also wish to help.

2008 April

NEM: Not sure if this is the correct page. The current stylesheet /wikit.css sets the colour for all A links, whether visited or not, to be the same colour, making it hard for me to see what I've already looked at. It looks like this is supposed to be commented out but is done using // which is not a valid comment marker for CSS (only /* */ works, IIRC). At least on Safari this causes all links to be rendered identically regardless of status.

2008 November LES: What is wrong with the third column of the Recent Changes

page? I thought it could be something in my browser, but it isn't. [9]

jdc 21-nov-2008 The timestamp of the last edit was replaced by a barchart indicating the recent activity of the page.

adavis 21-Nov-2008: I found the old arrangement with the "delta" button, which displayed the whole page with the most recent edit highlighted, to be much more useful. Am I alone in this?

DKF: You can still get the delta by going to the page and looking at the top of the screen. I'm not sure whether the delta is better or worse though; it depends on whether the page is “hot” or not. Maybe it would be nice to have both on the front page...

adavis 21-Nov-2008: Thanks - I hadn't noticed that. I do like the idea of putting this back on the front page though.

LV Nov 21, 2008: What would people think if the difference and highlighting ignored differences that were just white space changes? The reason I ask is that it seems to me that one or more web browsers seem to change tabs to spaces or vice versa (or maybe it is deleting trailing white space), seemingly at random spots. So someone who makes one little change at the bottom or top of the page can cause a "ripple" of changed lines which really are just white space differences.

LES I agree with ignoring whitespaces. But that new "recent activity" display is awful. It really looks like something that the browser cannot display, like an unusual character set or something.

Hmm - if you mean the "Edit summary" page, maybe there is some kind of disconnect with your browser. Because on my computer, the Recent Changes page looks like this:

 Wikit Problems ▲ LES@201.68.242.81

with a grey block at the end indicating that changes have occurred, and in the Edit summary page, I see:

LES@201.68.242.81, Fri Nov 21 09:55:21 EST 2008, #chars: 202, #lines: 1 
LES I agree with ignoring whitespaces. But that new "recent activity" display is awful. It really looks like something that the browser cannot display, like an unusual character set or something.

with your comment's background in green (because it was an addition to the page).

I don't see any unusual character set issue.

Remember, submit bug reports (and include screen shots in cases like this) at http://code.google.com/p/wikitcl/issues/list

so that maintainers can look into the issue.

LES No, I just mean the third column in the Recent Changes

page. That grey block is misleading. If you look at the browsershots page I referred to [10], you will see that most browsers render what looks like a grey ribbon, but at least one [11] displays a series of squares. That's what my browser shows and looks similar to a character set issue IMO. Even if rendered correctly, the grey ribbon is very cryptic or misleading. What in the world is a grey ribbon supposed to mean? Where else has that convention ever been used? Any newcomer is likely to be scratching their head about it, or more likely to just dismiss it as some odd CSS flaw. There has to be a better way to indicate "activity" or at least something that actually looks like a gauge.

CMcC I see that Firefox 2.0.0.16 and Dillo 0.8.6 render it incorrectly, but not too ugly for use. I'm prepared to cop that hit. The grey ribbon is supposed to be as unobtrusive as possible, and I think it succeeds at that. Perhaps we could add a title attribute to explain its function, but I don't put that at a high priority.

LV When I use lynx, I see 1 or more '*' characters at the end of the lines. I would guess that if someone figures out a better character based representation that invokes the sense of the quantity/size of changes that have occurred on the page, and proposes it via the issues/list url mentioned above, it would be given some consideration.

I suspect the change was in response to requests for some way to distinguish a change in a page because comments or discussion was going on as opposed to small editorial changes, url fixes, etc. The bar at the end of the line seems, to me, to get "longer" as more changes occur on a page.

CMcC yes, it's supposed to be an inverse measure of the gnomic flux in the vicinity of that page, in decibels, as an analogue of effective change on a page.

AMG: Spaces and tabs get hella munged in the editor. [12] Update: It's fixed now. Yay!

CMcC 15Mar09

LES on 2009-08-24: Is it just me, or wikit works fine right until I edit and try to save a page? I press the "Save your changes" button and the submission takes from 5 to 10 minutes to go through. Meanwhile, the whole site is inaccessible. It's not my computer. I have a remote account, can't check the wiki from there either when it is down. I suspect there is something broken in the "Save" mechanism.

CMcC I shall test this. In my test, the response time was less than 10 seconds. Not saying it's not possible for the wiki to be unresponsive, but I can't repro. Do you observe this lag always/often/occasionally?

stevel I've also tested this and can't reproduce. Could you try clearing your cache and trying again. Also, please note the comment at the top of this page re logging bugs in the bug tracker - thanks.

LES Steve, look at the paragraphs on this page, the comments seem to be posted in descending chronological order. Each page has its own order, I tried to follow what seemed to be in effect on this one. Colin, I spent quite some time on the chat room yesterday and several people reported severe sluggishness, including DKF. I'm just adding this "Save your changes" problem because that really seems to be happening in my case. I've been oberving that for two days, it always happens when I edit a page.

BTW, maybe someone with direct access to the wikit.gz file could run it through sed and replace all occurrences of http://www.tcl.tk/man/tcl[0-9.]+/ with http://www.tcl.tk/man/tcl/. That would be easier for wikignoming and cleaner on the Recent Changes page. Just an idea.

CliC Anyone else notice that this Wiki's left-side menu bar recently appears below the page text on Linux Firefox 3.6.13, as opposed to beside it? It's fine in Chromium, and on Firefox in Windows. May be a Firefox bug. If anyone else responds affirmatively, I'll file a report with the bug tracker as advised above.

jdc This has been reported before, but I could not fix it yet.

wiki jumps the shark

Category Wikit

Category Tcler's Wiki