# Start a new discussion

## Not signed in

Want to take part in these discussions? Sign in if you have an account, or apply for one below

## Site Tag Cloud

Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.

• CommentRowNumber1.
• CommentAuthorTobyBartels
• CommentTimeJan 13th 2010

These have stopped working. Examples are Sch/S and adjunction/zigzagepsilon. Change / to %2F in the URI makes no difference. I get

Internal Error

An application error occurred while processing your request.

Note that the adjunction/zigzagepsilon is included in adjunction, and that works fine; everything renderes correctly. Similarly, relative point of view redirects to Sch/S, and the redirection works fine, even though the page itself doesn't come up. But we cannot open the pages for editing.

• CommentRowNumber2.
• CommentAuthorTobyBartels
• CommentTimeJan 13th 2010

Actually, the inclusion of adjunction/zigzagepsilon and its friends into adjunction stopped working when I deleted the cache of adjunction (which broke some iTeX).

This affects only a few pages, but it looks pretty serious for them.

• CommentRowNumber3.
• CommentAuthorAndrew Stacey
• CommentTimeJan 13th 2010

Okay, this is the same problem that did for SEAR+epsilon. At some point, the URL is getting decoded one step further than thought. I don't think it's anything to do with the character encoding, in particular. If you change / to %252F then it does work. This gets decoded to %2F which then goes through the system cleanly. So adjunction%252Fzigzagepsilon should work fine. But without that extra encoding, the / is getting interpreted as a path separator and confusing the poor dear.

So, we can add the extra layer of escapes or choose a different character to denote subpages. *significant pause while I refrain from saying "I told you so"*. I vote for the latter.

However, after my experience with SEAR+epsilon, we shouldn't rename these pages from within Instiki but rather directly on the database.

The full list of pages with forward slashes in their names is:

+---------------------------------------------------------------------+ | name | +---------------------------------------------------------------------+ | oriental/Delta2 | | oriental/Delta3 | | oriental/Delta4 | | monoidal category/pentagon | | monoidal category/pentagonator | | induced representation/adjoint | | generalized smooth space/relationships | | comma object/2cell | | comma category/2cell | | associahedron/K4 | | adjunction/zigzageta > history | | adjunction/zigzagepsilon | | adjunction/zigzageta | | pentagon decagon hexagon identity/pentagon heights | | Toby Bartels, from http://en[dot]wikipedia[dot]org/wiki/File | | pentagon decagon hexagon identity/pythagorean identity | | pentagon decagon hexagon identity/regular pentagon | | Sch/S | | pentagon decagon hexagon identity/golden ratio identity | | pentagon decagon hexagon identity/irregular icosahedron | | pentagon decagon hexagon identity/golden triangle | | pentagon decagon hexagon identity/golden ratio | | pentagon decagon hexagon identity/icosahedron | | pentagon decagon hexagon identity/duads | | pentagon decagon hexagon identity/Euclid | | pentagon decagon hexagon identity/icosahedron triangles | | pentagon decagon hexagon identity/skinny duads | | pentagon decagon hexagon identity/square duads | | pentagon decagon hexagon identity/golden ratio identity pythagorean | | pentagon decagon hexagon identity/pythagorean icosahedron | | pentagon decagon hexagon identity/pentagon width | | pentagon decagon hexagon identity/icosahedron pentagon | +---------------------------------------------------------------------+

What shall we rename them to? (Assuming everyone's okay with the renaming, that is)

• CommentRowNumber4.
• CommentAuthorTobyBartels
• CommentTimeJan 13th 2010
• (edited Jan 13th 2010)

We've been using > (with spaces) pretty heavily for subpages. So oriental/Delta4oriental > Delta4 etc. That includes adjunction/zigzageta > historyadjunction > zigzageta > history. Toby Bartels, from http://en[dot]wikipedia[dot]org/wiki/File exists only to catch a link from a page history (an experiment that I will not repeat), so there's no point in having it at any other name. Finally, I would move Sch/S to relative scheme, although Zoran might have an opinion about that one.

The downside of >, as you have probably noticed by now, is that you can't link to such a page directly from the Forum. (But maybe you can fix that.)

• CommentRowNumber5.
• CommentAuthorMike Shulman
• CommentTimeJan 13th 2010

Wouldn't it be better to fix the bug that causes one too many layers of encoding/decoding?

• CommentRowNumber6.
• CommentAuthorTobyBartels
• CommentTimeJan 13th 2010

@ Mike #5

That's what Jacques wants to do.

In the meantime, I have copied Sch/S to relative scheme so that it can actually be used (although links to Sch/S and the other redirect titles still will not work, but I have fixed some of these). This means that Sch/S should be moved to relative scheme > history (or to Sch/S > history if the bug is fixed). The others do not seem so important, especially since the inclusions will continue to work until the including page is edited.

• CommentRowNumber7.
• CommentAuthorTobyBartels
• CommentTimeJan 13th 2010

I also spun off relative point of view, so now every link will work that isn't directly to either Sch/S or S-Sch; and all of the links in the Lab either work or are in context with a link that works.

• CommentRowNumber8.
• CommentAuthorAndrew Stacey
• CommentTimeJan 13th 2010

Jacques is looking in to this, but it's not yet clear where the bug lies. Evidence currently points to passenger which is the program that sits between the web server and instiki, so not really under Jacques' control. So in the meantime, we can rename the pages to make them usable again.

I should be able to fix the fact that >s don't work here without too much problem.

So, shall I rename?

• CommentRowNumber9.
• CommentAuthorTobyBartels
• CommentTimeJan 13th 2010

Just to give a clear proposal for disucssion: Shall Andrew rename the pages listed in #3 as follows:

?

OK with me.

• CommentRowNumber10.
• CommentAuthorMike Shulman
• CommentTimeJan 14th 2010

Sure.

• CommentRowNumber11.
• CommentAuthorAndrew Stacey
• CommentTimeJan 14th 2010

Okay, that's done. Just to record it somewhere, the syntax was:

UPDATE pages SET name=REPLACE(name,'/',' > ') WHERE (name RLIKE '/' && id != '2286');

(The significance of the 2286 is that that is the 'Toby Bartels, from http...' page; I did the 'Sch/S' change first which then removed it from the set that matched the forward slash.)

• CommentRowNumber12.
• CommentAuthorAndrew Stacey
• CommentTimeJan 14th 2010

I've also put in a patch for the '>' symbols in links. Something was encoding them before the Wikilinks plugin got to them.

The medium-term fix will be to integrate all the formatting plugins in to one since problems like this come from several things acting one after the other and each doing something stupid that the next doesn't like.

(The long-term fix is to port this forum to ruby so that we can use exactly the same formatter as on the nLab and stop worrying about these issues)

• CommentRowNumber13.
• CommentAuthorAndrew Stacey
• CommentTimeJan 14th 2010

(Of course, now we have to go through correcting all the pages that include/link to those pages. Bleugh.)

• CommentRowNumber14.
• CommentAuthorAndrew Stacey
• CommentTimeJan 14th 2010

Right, I think I've fixed them all.

Incidentally, when fixing the adjunction includes I noticed that the "only put ascii into iTeX" rule was being broken: the included SVGs had non-ASCII unicode characters in and that was causing iTeX to complain. I replaced them by the numerical entity codes (that seemed to be the only option here).

• CommentRowNumber15.
• CommentAuthorTobyBartels
• CommentTimeJan 14th 2010

Looks good!

A few minor problems remain:

1. Just for the record, Toby Bartels, from http://en[dot]wikipedia[dot]org/wiki/File still does not work properly, but since it is only linked internally by page histories (twice, and never again), there is no point in fixing it until the underlying bug in Instiki (or Passenger, I guess) is resolved. (Incidentally, this page was supposed to be redirected to Toby Bartels, but the brackets that I put in to fix the inability to use . prevented this. Not to mention that it got cut off and so would have served no purpose anyway.)
2. Andrew moved Sch/S to scheme > history, but it should have gone to relative scheme > history; I've fixed this and tidied up the page.
3. I removed some cache files so that, when the underlying bug is resolved (or when the URIs are fixed by hand), links to oriental/Delta4 etc will properly resolve.
4. There are no redirects from oriental/Delta4 etc to oriental > Delta4 etc.

I'm thinking that it is not worth the trouble to create redirects as in point 4. Thanks to Andrew's list in #3, I could do it, and maybe someday I will, but not now unless somebody thinks that it's important. So even after the underlying bug is fixed, oriental/Delta4 etc will come up empty.

• CommentRowNumber16.
• CommentAuthorAndrew Stacey
• CommentTimeJan 14th 2010

We shouldn't need the redirects. There are no pages within Instiki that point to the pages with the slashes - I tracked them all down by searching the database directly. Given the nature of these pages, there shouldn't be any external links to them either (except maybe from here). I guess there are links in the history, but I don't think that keeping redirects just so that historical pages stay exactly the same is a good precedent to set, ditto with links from here. We could always put a note in the FAQ if we're worried.

But maybe I'm missing something ...

• CommentRowNumber17.
• CommentAuthorTobyBartels
• CommentTimeJan 14th 2010

Actually, the redirects would not keep the historical pages the same, since you can't include across a redirect. So the only reason for them is to catch links from outside the Lab, including the Forum and the Café. Ideally, I would say, do it; but links from the Forum (if indeed there are any) are so rare, and links from anywhere else are so unlikely, that I don't think it's worth it.

It's also possible that the redirects would behave screwily, since the redirection command would be included by another page, and the wrong page might get it (especially after it's edited). I haven't tested this.