MediaWiki installation quality

[dantman]

I was a core-developer and made a few extensions so substandard installs irk me a little and make me want to fix them...

Sooo... a few points that could be improved on individual niwa wiki.

• Zelda Wiki - Pretty decent install, though I'm not sure of the purpose of using Wikimedia's beta opt-in
• Metroid Wiki - install is out of date (major version behind, and not up to date with security releases within that major release) the path could also be fixed to use prettyurls
• Mario Wiki - one major version out of date
• Wars Wiki - path could be fixed
• WikiBound - definitely some path fixes when it gets a domain

Some of those are easy to fix on ones own, others I could try to help with.

[tacopill]

which paths will we need to fix?

[dantman]

which paths will we need to fix?

by paths, I mean the lack of pretty url configuration. ie: the wiki is using /index.php?title=Foo instead of /wiki/Foo or /Foo (though I dislike the latter).

Though Wars Wiki seems to be fine... either someone fixed it, or perhaps I was looking at another wiki?

Oh, hmmm... WiKirby is using an odd ~wikirbyi url for the long urls.

[tacopill]

which paths will we need to fix?

by paths, I mean the lack of pretty url configuration. ie: the wiki is using /index.php?title=Foo instead of /wiki/Foo or /Foo (though I dislike the latter).

do i need pretty URLs?

[dantman]

which paths will we need to fix?

by paths, I mean the lack of pretty url configuration. ie: the wiki is using /index.php?title=Foo instead of /wiki/Foo or /Foo (though I dislike the latter).

do i need pretty URLs?

Lyat Wiki already has them configured (though I never liked ambiguous root pretty urls).

[tacopill]

which paths will we need to fix?

by paths, I mean the lack of pretty url configuration. ie: the wiki is using /index.php?title=Foo instead of /wiki/Foo or /Foo (though I dislike the latter).

do i need pretty URLs?

Lyat Wiki already has them configured (though I never liked ambiguous root pretty urls).

doesn't answer my question though. And how is /w "ambiguous root"?

[dantman]

which paths will we need to fix?

by paths, I mean the lack of pretty url configuration. ie: the wiki is using /index.php?title=Foo instead of /wiki/Foo or /Foo (though I dislike the latter).

do i need pretty URLs?

Lyat Wiki already has them configured (though I never liked ambiguous root pretty urls).

doesn't answer my question though. And how is /w "ambiguous root"?

I did, Lyat Wiki already has pretty urls configured. If clicking on links to random articles doesn't bring you to a page with a /index.php?title= in them, then you have some sort of pretty url setup configured. Or are you talking about another wiki?

By "ambiguous root" I'm not talking about the root for your php files, I'm talking about the base path for your articles. I mean that http://starfoxwiki.org/Articlename rather than http://starfoxwiki.org/wiki/Articlename carries a form of ambiguity. This stems from the fact that the root root is shared by everything else, like your /w directory, standard paths for favicon.ico, robots.txt, apple-touch-icon.png, etc... it's ambiguous because if you define http://starfoxwiki.org/* as "*" is an article, then is http://starfoxwiki.org/robots.txt an article? is http://starfoxwiki.org/w/index.php the  [[w/index.php]] article? obviously not, but from a technical standpoint it's ambiguous. The normal way to deal with that of course is to differentiate by what is a file and what isn't, if /robots.txt exists then it gets served instead of an article. However as a technical result of that it actually means that when you visit /Star_Fox_64 the webserver actually does a system stat call on the filesystem (io, which is slow in some regards) checking to see if a file named "Star_Fox_64" exists in the DocumentRoot, which is a bit of a waste when urls like /wiki/Article unambiguously define an area as article space so the webserver never has to ask itself "is there a file sitting at that path" since /wiki/ is defined as a virtual path that never has files. (in short, I just don't like munging filespace and articlespace together)

[tacopill]

But my question is "do i need pretty URLs?"? Not, what wiki's are currently using them?

[dantman]

But my question is "do i need pretty URLs?"? Not, what wiki's are currently using them?

Well depends on what you define as need... You don't "need" to be able to customize the way your wiki looks... you don't "need" to let your users have their own user .css and .js... they're just extra features that any good quality wiki has setup. Why would you want your articles to show up as http://starfoxwiki.org/w/index.php?title=Falco_Lombardi inside your reader's address bar or Google when it's possible to have http://starfoxwiki.org/wiki/Falco_Lombardi or http://starfoxwiki.org/Falco_Lombardi ?
Though, I suppose besides making paths to articles on your wiki look all around better they also make it easier to setup a robots.txt that properly excludes dynamic content to avoid search engines pounding your wiki asking for things it will never index.

[tacopill]

Why would you want your articles to show up as http://starfoxwiki.org/w/index.php?title=Falco_Lombardi inside your reader's address bar or Google when it's possible to have http://starfoxwiki.org/wiki/Falco_Lombardi or http://starfoxwiki.org/Falco_Lombardi ?

Why wouldn't I want index.php to show up in the address bar?

I apologize if i am being annoying, but it seems i am not asking my question properly, as I am looking for Why i would want to use pretty URL's? if i don't need it, what are the aesthetic and practical qualities? If they aren't needed, what incentive is there for me to switch over to?

Just because other wiki's do it isn't enough of a reason for me to do so.

[dantman]

Why would you want your articles to show up as http://starfoxwiki.org/w/index.php?title=Falco_Lombardi inside your reader's address bar or Google when it's possible to have http://starfoxwiki.org/wiki/Falco_Lombardi or http://starfoxwiki.org/Falco_Lombardi ?

Why wouldn't I want index.php to show up in the address bar?

I apologize if i am being annoying, but it seems i am not asking my question properly, as I am looking for Why i would want to use pretty URL's? if i don't need it, what are the aesthetic and practical qualities? If they aren't needed, what incentive is there for me to switch over to?

Just because other wiki's do it isn't enough of a reason for me to do so.

Have you ever went to Wikipedia and instead of using the search box, just jumped to your address bar and replaced the title of the article you're on with the title of the one you're looking for and just hopped over there? Besides that pretty urls are partly about making your urls nice and readable, /index.php?title=Article is filled with a bunch of technical cruft, and also mixes itself in with things like &action=edit pages which aren't meant to be touched by search engines, etc... if you'll take a look at wikipedia's /robots.txt you'll see that part of the pretty url functionality allows them to disallow search engines from looking at /w/ in general, this keeps search engines from requesting the edit page (the link is visible on every page so a search engine will undoubtedly try to look there) only to get a robots-noindex tag starring at them making the query useless. But beyond that it also tells search engines not to try looking at other things like search queries, histories, and other dynamic content pages that will have the search engine crawling through a huge dynamic mess looking at things it'll never index (and just waste the wiki bandwidth).
There's also the whole philosophy that urls are not a filesystem, file extensions like .php don't belong in them. And the SEO philosophy of having urls that mean something and have no reason to change for some technical reason like switching code language or switching to a host where you have to use .php5 instead of .php to make things work.

But plain and simple... /wiki/Article or /Article looks much better to someone reading your wiki than /index.php?title=Article

[Axiomist]

Speaking for WiKirby, I'm open to your suggested improvement. Adam and I never looked at url mods before WiKirby, and boy was there a lot of reading to do for it. Basically we just settled for what we had. Let me know how to proceed and thanks for bringing it  up!

[dantman]

Speaking for WiKirby, I'm open to your suggested improvement. Adam and I never looked at url mods before WiKirby, and boy was there a lot of reading to do for it. Basically we just settled for what we had. Let me know how to proceed and thanks for bringing it  up!

Ok, doing a double check over WiKirby. Pretty urls look to be configured fine. As for the http://wikirby.info/~wikirbyi/index.php?title=Kirby_Wiki&action=edit urls, it appears that http://wikirby.info/index.php?title=Kirby_Wiki&action=edit works fine...

It looks like to fix the WiKirby long urls all you need to do is tweak $wgScriptPath to not include the /~wikirbyi.

[Axiomist]

Alright! Sounds simple. It's a bad time tho, I'm just coming in from work and am due early in the morning, so I'll pass your message to Adam. Again, I appreciate your bringing this to light. Since Wars Wiki's staff is normally too busy to keep up with this forum, school, and their own wiki + forums, I usually pass messages to them. So if they need or even could do better with any of your suggestions, I'll let them know right away.

[Miles of SmashWiki]

I think SmashWiki's up-to-date. Correct?

[Jake]

I think SmashWiki's up-to-date. Correct?

Yes, it is.

I actually ran this test on all NIWA wikis a few weeks ago. I too am a fan of pretty URLs.

One thing dantman did not mention was that pretty URLs can sometimes have a positive effect on rankings in search engines. It's just easier for them to locate pages that *appear* to be static and not accessible only through URL variables. (index.php?title=Page_Name)

[Adam]

Speaking for WiKirby, I'm open to your suggested improvement. Adam and I never looked at url mods before WiKirby, and boy was there a lot of reading to do for it. Basically we just settled for what we had. Let me know how to proceed and thanks for bringing it  up!

Ok, doing a double check over WiKirby. Pretty urls look to be configured fine. As for the http://wikirby.info/~wikirbyi/index.php?title=Kirby_Wiki&action=edit urls, it appears that http://wikirby.info/index.php?title=Kirby_Wiki&action=edit works fine...

It looks like to fix the WiKirby long urls all you need to do is tweak $wgScriptPath to not include the /~wikirbyi.

Thanks for the help! I had some issues when we were first setting up, and the only way I could successfully install MediaWiki was using /~wikirbyi in the path. To be honest, I'd forgotten to ever go back and look into it again, since the normal URLs were working. 

[dantman]

I found out something new today.

Pre-1.17 (ie: every stable version of MediaWiki out so far) versions of MediaWiki have a bug when you use paths like /Article rather than /wiki/Article. Parts of the api are broken, namely anything that uses a &title= param. So api based watch/unwatch, api based editing, api based protection, deletion, etc... are broken in some cases.

[Greenpickle]

http://www.pikminwiki.com/api.php?action=parse&title=Nectar

Yay, fail.

[dantman]

http://www.pikminwiki.com/api.php?action=parse&title=Nectar

Yay, fail.

You got that fixed by the time I saw it?