Post/Author/DateTime	Post
#1 kilpatds Jan 02, 2010 23:16:32	original post So, in the charop group's wiki, I've got my Avenger's guide.  I've used '/' to give the pages a bit of a namespace. Avenger/PP                  Paragon paths Avenger/ED                  Epic Destinies Avenger/Feats              Feats overview Avenger/Feats/Heroic I think you get the idea.  At the top of each page, I've got a ToC section with links to the other pages. Originally, I had to make all the links relative.  For example, in the Avenger/Feats section, internal wiki links automatically prepended "Avenger", basically.  So the link to the Epic Destinies page was just Now, if I'm editing a page, the wiki links appear to be relative to the charop wiki.  So the ED page would be Except that if I go back to the page days later, the links now point to charop/Avenger/Avenger/ED (Avenger gets repeated).  If I edit them, it goes back to needing the prefix. (No, I'm not insane.  Making a null edit "fixes" a page with links that have extra "Avenger" components.  As does making a change (breaking the links), and then rolling it back.  No, I do not know the time frame required for the pages to break themselves.  I suspect a backwards compatibility hack that's using rolling time, not absolute time) So, um, Which is it?  Kindly advise.
#2 Zireael Jan 03, 2010 3:49:50	Not to mention the fact I can't still find anything in the wikis that's not in the latest additions section. Maybe someone would tell me how to do it?
#3 whitebaron Jan 03, 2010 8:13:03	it seems like they keep changing the format every now and then, and sometimes with an update they even revert it back to some old form. what still works (and always worked for me): *[./Eberron:Amor_Fati/Locations Locations] (included in community.wizards.com/realadventures/wik... ) so: just use a rather absolute path, even though it makes absolutely no sense. btw, his kind of behaviour seems only to crash "top-level" entries.. as if some mysterious update script would go through those entries...
#4 kilpatds Jan 04, 2010 8:23:18	*[./Eberron:Amor_Fati/Locations Locations] Tried that on my equipment page  (Look at the weapons's link).  Didn't work.  The page is broken again as of this post. I edited that last night (10pm by the history), so it broke overnight.  The "cron job screwing up my pages" theory could be valid.
#5 whitebaron Jan 04, 2010 9:09:06	there's some interesting stuff going on. compare community.wizards.com/charop/wiki/Avenge... to community.wizards.com/charop/wiki/Avenge... technically (uri-standard), this should be the same page. practially, it does things differently. note that the edit page also uses that strange form of a link, and thus your preview also only works with community.wizards.com/charop/wiki/Avenge... If you just handled it a bit more flat, you'd not have that Problem btw... With just one tier, it works.. Avenger -Equipment -Weapons -Armor - etc. This strange feature of the webserver/page is also the reason why it works in preview and when you look at it from the generated link afterwards, but does not a bit later - Because your link is inherently wrong, and the wiki does some other strange things with those "virtual" directories you are creating. ./ should be .../Avenger/ , but since it handles the / part wrong, it sees Avenger%2FEquipment instead. the path for that is .../wiki/, thus you need the Avenger again for previewing. When you look at "the real thing" later, it's broken... because this !"$%& up implementation only changes / to %2F for the editing pages. TLDR - my advice: shoot the previewing part, and get rid of the extra /Avenger/. Make sure when you check the page after, that the preview/edit mode has not messed up your url to include %2F instead of /. Everything will be fine then.
#6 kilpatds Jan 04, 2010 9:18:21	./ should be .../Avenger/ , but since it handles the / part wrong, it sees Avenger%2FEquipment instead. the path for that is .../wiki/, thus you need the Avenger again for previewing. When you look at "the real thing" later, it's broken... because this !"$%& up implementation only changes / to %2F for the editing pages. TLDR - my advice: shoot the previewing part, and get rid of the extra /Avenger/. Make sure when you check the page after, that the preview/edit mode has not messed up your url to include %2F instead of /. Everything will be fine then. My current hope: I'll point out bugs and they will fix them.  We'll see how that works. Your mental model has the wiki generating actual files in a directory structure?  My mental model (assuming java UI-in-front-of-DB application) has it all being a DB row.  I didn't expect "./" to work at all, so I guess that is evidence for the directory structure implementation (er, OUCH!  Don't Do That!  It makes scaling the application linearly across multiple servers much harder.  You can't easily go to a "multiple servers connect to multiple DB slaves, primary DB scaled for write work" model, you can't put your servers in multiple datacenters without having rsync problems, etc, etc) If I don't have the Avenger/ part, then the link is broken (goes to charop/wiki/Weapons, not charop/wiki/Avenger/Weapons).  Until the update happens, when Avenger gets stuck in there and it works again. I'm not doing anything with %2F.  And I'm not using preview either.  Edit, submit, check. If I do have it, then the update doubles up the Avenger part, which breaks the link.  But (the infurating part) is that the official text of the wiki page doesn't change.  Just the generated output.  So a third possibility is that the bug is a difference in behavior between the "generate static output" script and the "generate dynamic output" methods.
#7 kilpatds Jan 04, 2010 9:23:14	there's some interesting stuff going on. compare community.wizards.com/charop/wiki/Avenge... to community.wizards.com/charop/wiki/Avenge... technically (uri-standard), this should be the same page. practially, it does things differently. *headslam*.  Yep, that does seem to be most of the issue.  So, don't look at the links post/save.  Edit the URL to have real slashes, and check there. Dear new forum maintainer people: Fix This, kthx.
#8 WotC_Michelle Jan 04, 2010 17:30:12	Thanks for the detailed steps. I've reported this and will post back when I have an update.
#9 whitebaron Jan 04, 2010 18:30:33	btw: I do not think that it is stored in directories. the main concern is what the browser does with those uris. since wizards url-escapes the slash sometimes, and the browser quite properly does not see it as directory as a slash is a valid character ... well you can figure from there.
#10 kilpatds Jan 04, 2010 20:06:43	It sure works like it's a directory path.  Using "/Full/Path" does ... something else.  ( seems to point to community.wizards.com/Path.  Not wiki/Path, just /Path.) So seems to work.  Excuse me, I'll continue banging my head in the corner.
#11 whitebaron Jan 05, 2010 5:50:29	the reason it works like it is that your browser does interpret it as such - even though there is no directory on the server. / have distinctive role in uris, but they need not be handled the same on the server. that's the basis of url-rewriting, to make it a lot easier on search-engines to index your page. btw: community.wizards.com/go/post/reply/7588... this url, used to reply to this thread is not really proper. it works because url rewriting changes a lot of that, but usually get-parameters come after a ?. Also, by using Get-Params combined with url-rewriting, you invalidate EVERYTHING that this was meant to accomplish. You should go and tell those incompetent onesite PHP programmers that they should really reconsider their jobs.
#12 kilpatds Jan 21, 2010 16:08:31	So I had moved to absolute links That no longer works.  There's some redirection going on to the %2F version, but it doesn't always happen so I can't just use the %2F version of the link. How am I supposed to work with this?  All absolute links, all the time?  Come on! (What I'd like to see: reliably works inside a wiki space. reliably works for a hierarchal page.)
#13 kilpatds Jan 22, 2010 14:51:15	Bump?  Am I really the only person trying to use nested namespaces in the wiki?
#14 kilpatds Jan 25, 2010 9:25:36	New brokenness: links to +foo+.  Whitespace used to be trimmed, and that's clearly the correct answer here, rather than URI encoding the spare whitespace. Ya'll should try and get a refund for this wiki system... Edit: All other brokenness mentioned in this thread remains.  So this is just getting worse.
#15 whitebaron Jan 25, 2010 14:49:55	my previously working wiki links are now broken too. good job! community.wizards.com/realadventures/wik... try going to locations and then just pick any... but wotc probably does not care about usability, just about it being there... else this system should have never gone online in the first place...
#16 WotC_Michelle Jan 25, 2010 15:06:15	We are working on the latest two bug reports for linking - will let you know when we have an update.
#17 kilpatds Jan 25, 2010 15:16:03	Thanks for working on this ... but right now the wiki is missing critical basic wiki functionality.  I would consider these bugs to be of blocker severity.  They are not at the data-loss level of severity, but are basically at the "edit doesn't work" level, because they prevent basic functionality (cross wiki links) from working. (When I first reported it, it wasn't a blocker because there was a workaround.  The "fixes" that have gone in have broken the workarounds.  So now it's a blocker) Edit: see below.  Found a sane workaround, and thus the priority is now back to minor.
#18 kilpatds Jan 27, 2010 10:27:11	Found a workaround...  single brackets, pseudo-absolute path. [Avenger/Feats Feats] works perfectly, both in / mode and in %2F mode.
#19 WotC_Michelle Jan 27, 2010 11:52:22	Great -  in general, linking should be working like Mediawiki, with single brackets for internal links and double brackets for external links. I will be posting more detailed documentation about linking once we are done with testing variations. Found a workaround...  single brackets, pseudo-absolute path. [Avenger/Feats Feats] works perfectly, both in / mode and in %2F mode.
#20 kilpatds Jan 27, 2010 11:54:32	Great -  in general, linking should be working like Mediawiki, with single brackets for internal links and double brackets for external links. I will be posting more detailed documentation about linking once we are done with testing variations. Er, actually it's set up the other way around.  single brackets are external, and double are internal.  The internal links are having anchoring issues based on / vs. %2F navigation...
#21 WotC_Michelle Jan 27, 2010 12:08:18	Great -  in general, linking should be working like Mediawiki, with single brackets for internal links and double brackets for external links. I will be posting more detailed documentation about linking once we are done with testing variations. Er, actually it's set up the other way around.  single brackets are external, and double are internal.  The internal links are having anchoring issues based on / vs. %2F navigation... How are you defining internal vs. external?
#22 kilpatds Jan 27, 2010 12:15:16	I can't verify it now, but when I started editing, the Link button used , and the globe+link button used []. (Now both use []). Internal: points to other pages in the wiki.  .  www.mediawiki.org/wiki/Help:Links  What they call internal links. External: points to pages on other sites.  Traditionally start "http://". [http://foo foo] I'd assume that external links get transformed into <a href="[before whitespace]>text">after whitespace&gtl/a> I'd assume that internal links get a bit more processing done on them.. or certainly could have more processing done on them (make sure the page exists, format the link differently if it does not)
#23 WotC_Michelle Jan 27, 2010 12:15:46	Great -  in general, linking should be working like Mediawiki, with single brackets for internal links and double brackets for external links. I will be posting more detailed documentation about linking once we are done with testing variations. Er, actually it's set up the other way around.  single brackets are external, and double are internal.  The internal links are having anchoring issues based on / vs. %2F navigation... How are you defining internal vs. external? Disregard - I had them transposed when I typed it. Don't worry, the developers don't :D I will post back again when I have more.
#24 WotC_Michelle Apr 16, 2010 15:28:04	We are rolling out some changes to the parser next week that will correct the way linking is done to make it consistent with mediawiki linking (as intended). We will be running a couple of scripts to correct existing links, but may still have some broken links that will need to be corrected manually. Take a look at the details and give feedback here.