Messages

Joining and affiliating are two different things.  SEIWA would affiliate only.  DQ Wiki could join because it is now a Nintendo-only franchise.

Someone figured this out.

http://www.mwusers.com/forums/showthread.php?13956-RSS-feeds-do-not-showing-diffs-anymore&p=59545&viewfull=1#post59545

Wiki Name	Average Posts Per Week	Percentage	Change
Bulbapedia	4069.1	34.80%	-1.17%
Donkey Kong	18	0.15%	-37.72%
Fire Emblem	135.3	1.16%	+188.49%
Golden Sun	83.3	0.71%	+32.64%
Lylat Wiki	18	0.15%	+33.33%
Mario	3658	31.29%	+9.05%
Metroid	237.3	2.03%	+62.76%
Nintendo	39.2	0.34%	-15.15%
Nookipedia	126	1.08%	+30.03%
Pikmin	48.8	0.42%	+57.42%
Pikmin Fanon	76.1	0.65%	+33.74%
Smash Wiki	863.8	7.39%	+3.64%
Starfy	15.2	0.13%	-38.46%
Strategy Wiki	546.9	4.68%	+9.23%
Wars	6.1	0.05%	-37.76%
Wikibound	171	1.46%	-4.09%
WiKirby	56.2	0.48%	-28.13%
Zelda	1523.4	13.03%	-9.20%
Total	11691.7	100.00%	+3.43%
Date	11/28/2011

Edit: Made easier to read, added % of change from last update.  

Yeah, Google doesn't keep stats for feeds which are not followed by someone in Google Reader. So a little over a week ago I added all of the feeds and this is the result.  The values will obviously normalize the longer that the feeds are followed, but writing a script to do it manually would certainly be much more accurate.  

Edit: Also, you would need to make the script run multiple times daily.  The $wgFeedLimit is by default set to 50, so you would need to visit often to not miss updates.  Bulbapedia typically has over 500 a day.

Using Google Reader, here are some NIWA stats.  Note that these are taken from the recent changes feeds of each wiki and are bound to have differences, config settings, etc that skew the data.

Site	Changes per week	Percentage of total
Bulbapedia	4117.4	36.43%
Mario	3354.4	29.68%
Zelda	1677.7	14.84%
Smash Wiki	833.5	7.37%
Strategy	500.7	4.43%
WikiBound	178.3	1.58%
Metroid	145.8	1.29%
Nookipedia	96.9	0.86%
WiKirby	78.2	0.69%
Golden Sun	62.8	0.56%
Pikmin Fanon	56.9	0.50%
Fire Emblem	46.9	0.41%
Nintendo	46.2	0.41%
Pikipedia	31	0.27%
Donkey Kong	28.9	0.26%
Starfy	24.7	0.22%
Lylat	13.5	0.12%
Wars Wiki	9.8	0.09%
NIWA Total	11303.6	100.00%

Yeah I changed it back to clicks and it feels more normal.  The downside to using tabs in general is that the printable versions of articles do not show all of the information on the page.  Seems like I would need to modify the Mediawiki PHP code to do something special in that case. 

To answer your other question, the old Tabber extension did not allow spaces in the tab names.  Since converting over, I have not gone back and changed those pages to remove the spaces.  I would assume that jQuery would have no problem with it.

Excellent suggestions.  Yeah there are plenty of spots where jQuery can be used to make things more simple.  I put the tabs on mouse over, but really it is just an experiment to see if that would be better than requiring a click. 

VersionTabs definitely isn't a work of art, but I don't think there is anything potentially dangerous about it.

While I'm still waiting for any kind of response in the membership forum....

jQuery is included with Mediawiki 1.16 and newer.  In 1.17, you can load portions of the jQuery UI library on demand in your Common.js file as part of the ResourceLoader portions of Mediawiki. 

There are a lot of uses for jQuery within the wiki pages.  For example, a couple of the NIWA wikis use the Tabber extension (or at least include it).  However, jQuery has its own tabs you can use instead to save on performance. 

I've been experimenting with using the jQuery tabs and ways to include video content on wiki articles without it becoming too cluttered.

http://dragon-quest.org/wiki/Tantegel
http://dragon-quest.org/wiki/MediaWiki:Common.js

All,

I would like to go ahead and formally request that our wiki be considered for membership in NIWA.  I believe that we fulfill all of the requirements listed in the membership doc.  We have been independent for almost a year now and I feel that we have progressed to the point where an alliance would be beneficial.  The Dragon Quest community is small, but stable.  I feel that we could contribute positively to NIWA.

In case anyone is ever curious or has a similar problem, here is how I solved our issues.  I'm not sure if they were bots or just human spammers, but they were creating new accounts, supplying an email address, and then verifying the email link.  That means that they were 'emailconfirmed' users, making it hard to limit their privileges without effecting other normal users. 

The issue was that these spammers were using "throw away" email addresses to register.  MediaWiki does not currently have any standard protection against this.  I was able to stop them by adding the following to LocalSettings.php.

Code Select Expand

$wgHooks['AbortNewAccount'][] = 'noMailinator';

function noMailinator( $user, $message ) {
if( preg_match( '/@(mailinator|binkmail|zippymail|devnullmail|mailinator2|bobmail|safetymail|tradermail|thisisnotmyrealemail|suremail|spamherelots|dispostable)/i', $user->getEmail() )) {
$message = 'One-time-use email services are forbidden on the Dragon Quest Wiki';
return false;
}
return true;
}

*crickets*

There has to be a simple solution to this.  For example, the DK wiki, Nookipedia, and Wikia all have diffs in their feeds.  However, Bulbapedia and others do not.  I guess I'll post the answer when I figure it out myself.

Recently we have had some problems with wiki spammers.  So far, I haven't been able to stop them altogether. 

The spammers create an account, then upload an image and create a page with spam that contains the image.  It's usually nothing vulgar, just random junk.  I tightened up the permissions and made more privileges required a confirmed email address.  However, I found that the spammers were using legit 'throw away' email addresses and confirming the accounts. 

They are most likely bots, but they most be somewhat complex to be giving an email address and then confirming it.  The IP addresses come from all over.  I've moved more privs into 'autoconfirmed' but I'm not sure how to stop them.   Any other wikis had problems?

Anyone know anything about configuring mediawiki feeds (RSS/Atom)? 

I think it would be useful to put more information in the recent changes feed.  Then you wouldn't have to go to the diff page to see what was changed.  However, it looks like I will have to dig into the mediawiki source since the only configuration is for feed types, etc.

Down for a week?  Yikes.

Well, I'm willing to let them give it a shot.  Online for Dragon Quest IX was really a big failure in the U.S.  I've been dying to play a DQ game with other fans for years.  I just would prefer that I didn't "have to". 

Really I wish it were just like DQIX's multiplayer, only it uses wifi instead of just the local DS wireless.

Hi PkNess, welcome to the NIWA forums.  Let me share some things that might be helpful to you.

The requirements for affiliation are listed here: http://www.niwanetwork.org/join.php.  Your site must meet them in order to be considered.  Right now your site does not meet many of these. 

However, the best thing  you can do is to start growing your wiki.  Learn about mediawiki and start making edits.  Try to build a community at your new site so that your site will grow.  Best of luck! 

Star Tropics, now that takes me back!  I remember I could beat chapter 2 of that game and then I could never get further hehe.

Hmmm, things like favorite Nintendo game tends to change over time.  Here is my chronological list.

Legend of Zelda
LoZ: Link to the Past
Super Mario 64
LoZ: Ocarina of Time
LoZ: Twilight Princess

Nice.  Thanks for posting that.  I didn't realize you could so easily do a look up.  All those scented soy candles must be slowing down the wiki hehe.  I've been messing with the profiler, which is pretty nice.  It tells the same story: most page loads are less than half a second, others can be 2-7 seconds.  

For those of you using static file caching for visitors, did you configure your mod_rewrite to go directly to the static pages?  It is described here:
http://www.mediawiki.org/wiki/Manual:$wgFileCacheDepth

I'm definitely considering a jump to Linode in the future.  All of the flexibility it offers is really appealing.  

Ok, things are getting a bit clearer now.  Yes, I've been reading the Mediawiki pages on performance tuning.  Too bad pretty much all of the options are not available at my current host.

This pretty much sums up hostgator's policy on PHP accelerators:
http://support.hostgator.com/articles/pre-sales-policies/is-it-possible-to-install-ioncube-php-accelerator-on-shared-server

I put all of my jobs queue on a cron a long time ago.  I enabled file caching, but that really only helps visitors to the site, not logged in users.  I turned on logging, but have yet to see any thing of significance.  I guess I could post the log file here.  I haven't tried using the mediawiki profiler either.

I seem to get only intermittent delays though.  Sometimes the pages load fast, sometimes really slow.  Hmmm.