Messages

21

Kirby / Re: Kirby's Epic Yarn

« on: November 10, 2010, 11:04:43 AM »

He cannot inhale or jump.

Well, little correction... He can jump, he can slow his falls (though he turns into a parachute instead of puffing up)... he just can't inhale enemies, puff out air as an attack, or puff up to jump multiple times in mid-air (since he's thread).

Instead he uses his thread abilities to destroy enemies in a much simpler more plain way than before (though, transformations make up for that). The one real biggest difference (besides being able to slam down without turning into rock kirby, which reminds me more of SSB than old Kirby games) is IMHO it's much, much, much harder to even get injured and die in the game..... really, does this game actually let the enemies kill you? I sure never got damaged besides perhaps in a boss battle...

22

NIWA Discussion / Two questions?

« on: November 10, 2010, 10:54:19 AM »

Two questions here...

Firstly, is there any wiki here that was interested in Monaco? I know it had faults, and it was a Wikia skin, but there were some good ideas in it (iconified tabs do make it easier to use, hover menu navigation, etc...). So, were there any wiki's here or anyone who missed Monaco when the wiki went independent?

Why? I was 1/3 the way through porting Wikia's Monaco skin to be a generic skin installable on any MediaWiki installation, was wondering if anyone actually wanted me to complete it so it could be used.

And lastly, if someone offered MediaWiki hosting, do you think there are any wiki in the network that would want to take them up on it?

By hosting, I mean actual hosting, not Wikia style WikiFarming, hosting as in the kind of hosting relationship any NIWA wiki already has with the company who hosts their webspace... except instead of offering Shared, Dedicated, VPS, or Cloud hosting, it being dedicated MediaWiki hosting, with someone who knows the software managing it on a level including the features that let MediaWiki run on a network of servers that can handle a high load of readers.

23

NIWA Discussion / Re: MediaWiki installation quality

« on: November 09, 2010, 01:25:17 AM »

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.

24

NIWA Discussion / Re: MediaWiki installation quality

« on: November 08, 2010, 08:50:44 PM »

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

25

NIWA Discussion / Re: MediaWiki installation quality

« on: November 08, 2010, 08:12:21 PM »

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.

26

NIWA Discussion / Re: MediaWiki installation quality

« on: November 08, 2010, 07:55:07 PM »

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)

27

NIWA Discussion / Re: MediaWiki installation quality

« on: November 08, 2010, 07:43:00 PM »

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).

28

NIWA Discussion / Re: MediaWiki installation quality

« on: November 08, 2010, 06:12:09 PM »

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.

29

Wiki References / Re: MediaWiki Designers' Helpdesk

« on: November 08, 2010, 06:11:29 PM »

Exactly. I pay about $100 a year to host wikis (in 2 year intervals). If renting a webhost is not an option for you, maybe ask around and see if anyone is interested in offering free services to wikis?

Okay, thanks, I'll see what I can do to start up my first wiki.

What's the topic?

Sorry, but what's what topic? This thread? Currently: It's informing Darkgriffin of what options there are out their for hosting a wiki.

No, what's the topic of the wiki he's trying to start up?

30

Wiki References / Re: The Wiki Help Desk V2: Mash That Edit Button!

« on: November 08, 2010, 02:08:59 PM »

...I know why.
border-style and border-width are deprecated. Use

Code: [Select]

border: (width) (style) (color);

border-style and border-width are NOT deprecated. border-width, border-style, border-color are shorthands for the border-{edge}-{type} properties, border-{edge} is a shorthand for border-{edge}-{width,style,color}, and border: is a full shorthand in the same format as border-{edge} which affects all four edges.

There is no color specified by those border rules though. Also the reason for use of border-width appears to be so that only specific edges will have the border.

The issue is probably that "!width=35; style="border-style: solid; border-width: 0 1px 1px 0"| Str" is not exactly valid. attributes don't have ; in them, that looks like a bad attempt at trying to do width=35 (html/wikitext), and width: 35px; at the same time mixing up html and css syntax. "! style="width: 35px; border-style: solid; border-width: 0 1px 1px 0; border-color: black;" |" as for shortening, I recommend trying to make use of the wiki's Common.css

--
Tch, the page list is hard to see in these forums.

31

Wiki References / Re: MediaWiki Designers' Helpdesk

« on: November 08, 2010, 01:55:06 PM »

Exactly. I pay about $100 a year to host wikis (in 2 year intervals). If renting a webhost is not an option for you, maybe ask around and see if anyone is interested in offering free services to wikis?

Okay, thanks, I'll see what I can do to start up my first wiki.

What's the topic?

32

The Lounge / Re: Medabots Wiki - We need help!

« on: November 08, 2010, 12:51:30 PM »

As far as I know, the full wiki dump limits the changelog...

Either way we should use this as a chance to review articles and fix them to our new policies.

No, there ARE two dumps (current, and full) the full dump contains the entire history of every article on the wiki (excepting deleted content that you don't see anyways). In fact it's less limited than Special:Export is. Special:Export can sometimes not give you the full history if you try to export too many revisions at once (it was either 100 or 500, either way if a pages history is too long, or you export multiple pages that have a number of revisions that sum up to more than the limit it may trim out history).

33

The Lounge / Re: Medabots Wiki - We need help!

« on: November 08, 2010, 05:27:08 AM »

Pikmin Wiki, Transformers Wiki, and some others left huge notices saying not to edit there, to go to the new site and edit. I'd delete the best articles, one every three weeks, label it as spam/irrelevant content in the deletion summary, "Welcome" new users with a link to the new site, and mix in (some) regular spam deletion, just to prevent the wiki from being adopted.

also, keep in mind, if you delete too many, too fast, Wikia may notice.

Okay. So a moving plan would be:

1.- Use http://medabots.wikia.com/index.php?title=Special:Export&history=1&action=submit&pages=ARTICLE_NAME and http://es.medabots.wikia.com/index.php?title=Special:Export&history=1&action=submit&pages=ARTICLE_NAME to export articles. How often should we do this?
...
Am I missing anything here?

I should probably point out Wikia has full wiki dumps, they're linked from Special:Statistics on the wiki. You can import the whole wiki (no images, logs, or users though) in one go, you may need to use the maintenance script though if you can, Special:Import is a little limited in what it can import over a http post.

34

NIWA Discussion / MediaWiki installation quality

« on: November 08, 2010, 05:08:58 AM »

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.