Talk: Eyes/Proposals

Proposed configuration tweaks

Enabling user CSS and javascript

This feature is off by default in MediaWiki installations, and it doesn't appear to be active here. (I'll verify this conclusively when I can do so.)

The advantage isn't just in letting knowledgeable users tweak the wiki to their personal tastes or styles while not affecting other users, it's the fact that it lets users test CSS and Javascript without affecting other users. It also is pretty much the only way a regular user can perform the tests without the help of an admin. — Eyes 18:00, 22 July 2011 (UTC)

Enabling search suggest

MediaWiki has a built in feature on the search box that provides a list of article titles that start with the text you've already typed into the search box, but it's off by default for some reason. — Eyes 18:00, 22 July 2011 (UTC)

Shutting off the default prefixed category sort option

The problem with this comes up with articles outside of mainspace. When you add templates to a category without providing a sort key, they are all placed under T because MediaWiki includes the namespace when sorting them, so Template:Missioninfo and Template:Talkheader end up under T in categories unless you specifically provide a sort key, i.e. [[Category:General wiki templates|Missioninfo]] to get it put under M.

By shutting this option off, MediaWiki automatically drops the namespace when sorting items in categories, and Template:MissionInfo automatically gets put under M. (This change will only get applied retroactively if Curse runs a script to update the links, though.)

Note that in future versions of MediaWiki, this is now off by default and the option is being deprecated, so by disabling it now and refreshing the links, we'll be ahead of the curve. — Eyes 18:00, 22 July 2011 (UTC)

Proposals to install extensions

DynamicPageList

This is a powerful extension that gives us the ability to create custom-formatted lists that are automatically generated by querying the wiki with a parser function. While it has some weaknesses (it can even pull information from pages, but not in a very efficient way), it is a very powerful tool that gets used to automate a lot of routine tasks or simplify any large-scale editing tasks by giving you a way to automatically find what pages you need to edit.

The point is that it's such a versatile extension that it can be hard to come up with specific examples. One simple example would be for the admins to have a list on a single page of all pages in one of the deletion categories while still being able to see which category it's in, removing the need to check each one individually.

Another example of DPL being used can be seen on GuildWiki's main page. Just below the "Welcome to Guildwiki" part, DPL is being used to automatically bring the current login announcements from the Guild Wars login announcements page. Changing that page will also update the main page automatically--nice for getting frequently changed on a page you don't want to leave unprotected.

It does have one weakness... it's okay for getting a relatively large chunk of information from one page to another and it's great for getting a list of pages based on information about pages (what categories they're in, what templates they use, their titles, contributors, etc), but inefficient at querying information from the page because it has to do full-text search to do that. This the same reason it isn't a great choice if you wanted to pull information from a infobox (say Template:Missioninfo on any mission page.) into a table on a listing page (say List of missions). — Eyes 18:00, 22 July 2011 (UTC)

I forgot to note that with this extension, there is currently a security concern that it could be used to run arbitrary code. Curse has still installed this extension on other wikis, but with an option that only allows DPL queries to run on protected pages. This effectively means admins end up having to approve all uses of DPL. (Note, however, that we can still protect pages so that only registered users can edit them and that's still enough to allow the query to run. That still puts admins in the role of approving the initial use of DPL on a page, but then allowing regular users to change it on that page later.) — Eyes 05:08, 24 July 2011 (UTC)

Semantic MediaWiki

The weakness of DynamicPageList in being able to query small bits of information from pages is why this extension is worth having even with DPL. With this extension, we define "properties", or little bits of data about the subject matter of a page. For something like missions that use a common template, it can be done simply by adding the needed code to that template.

After that, if we want to make something List of missions update itself automatically, we just replace the tables there with SMW queries, and let updates to the information in any mission's infobox update the list page automatically. SMW does so more efficiently because its creates its own tables in the database and avoids doing full-text searches to get the data. (That work is done on saving the change, not when automatically updating the listing page. This nicely splits up the work into manageable chunks.)

Because it relies on properties, it requires more initial work to get the advantages out of it. In the long run, though, it can save a lot of routine work by automating many listing pages and giving editors more time to document the game by spending less time maintaining navigation pages. — Eyes 18:00, 22 July 2011 (UTC)

Feedback

That seems all quite reasonable. I hope this goes well with Curse. I explicitly asked them to get ftp access to the wiki installation, but no luck there. So you will have to discuss every point with our contact there and make them understand the wisdom of these changes. Let's wait a bit for others to comment on these points, before we move forward, but I for one would give this a go.

Regards, --RachelGarrett 23:07, 23 July 2011 (UTC)

We won't get FTP access. I know that much. Curse uses a source control system for all of its wikis, and they have extended access to that for some admins in the past. I've already requested that access, but I'm sure I won't get a response until at least Monday. (So that's the absolute earliest I could pursue these proposals, anyway.)

If they grant my request, it will mean I can make changes in the repository, but Curse has to push any changes I make to the live site. (It's handy having contact with an admin that already has this access for another wiki. I'm already half-configured on my end.) — Eyes 07:15, 24 July 2011 (UTC)

More Proposed Extensions

General extensions

• CategoryTree: Seen category pages where subcategories have a little [+] next to them letting you see sub-subcategories? That's what this is.
• News: Lets us create news feeds from the Recent Changes list, providing various ways to filter the results and format how it appears. Doesn't have to be just RSS/Atom feeds, but can display its result on wiki pages too.
• CategoryWatch: Improves the watchlist so that watching a category notifies you when pages are added or removed from the category, rather than just getting notified when the text on the category page changes.
• User Merge and Delete: Controlled by admins, this is exactly what it says on the tin. Gives users a way to rename themselves, or more accurately, gives admins a way to rename them (usually at their request). Not a particularly important extension, but could be useful.
• CreateBox and InputBox: Recommended because of the feature allowing these to preload text on a new page. Want a way to get the mission formatting automatically onto a new mission page? Create a little CreateBox somewhere that preloads that text when used. (Maybe a good use of our currently unused community portal page [other than redirecting to the talk page, that is].)
• Widgets: Think of these as a special kind of template that allows you to do things like pull in an RSS feed from an external site, pull in a Twitter timeline, etc. Widgets are editable/installable only by admins, but usable by all users. The extension only gives us the ability to bring in these widgets to the Widget: namespace; it doesn't bring in by itself, so support for the extension doesn't necessarily you support a particular type of widget, i.e. being against social networking widgets doesn't necessarily mean you're against installing the extension as that's a separate issue.
• DismissableSiteNotice: What it says on the tin. You can the site notices that admins can put on every page. It remembers you've hidden it from page-to-page once you've done so.
• Gadgets: Lets admins offer Javascript tools for customizing the wiki while making them completely optional. Provided Gadgets are activated through a new tab added to your user preferences.
• WinFilenameFix: Written by an admin on GuildWiki, this deals with the filename issues present in being on a Windows server (which we are). Basically, say you have a file called "Charge!".png for a page called "Charge!" (assume an infobox template requires the file have the same name as the page). Quotes aren't allowed in Windows filenames, though. This lets you upload the file as -Charge!-.png but still link to it as [[File:"Charge!".png]].

Extensions for fighting spam and vandalism

Basically, we just want these just in case. It's better to have them and not use them rather than get hit with a spambot attack and not have them ready to go. (Some Curse wikis were extensively attacked a few weeks, and I'm surprised theu didn't already add these extensions to our wiki. On this one, I'll go ahead if even only admins approve.)

• AbuseFilter: Like the idea of heuristics in anti-virus software, this lets us automatically reject edits that look like spam or vandalism in some way. While it certainly requires care in its usage, it's still good to have on hand. (We can confer with other Curse wikis on good filters to have, which will help us to prevent blocking legitimate edits.)
• AntiSpoof: Required by Abusefilter, so there's that. By itself, it's mean to restrict usernames to avoid problematic cases.
• CheckUser: Lets admins check IP address of users, which has obvious benefits in spam/vandal fighting.
• Nuke: Gives admins a special page to quickly delete many pages. Useful for cleanup after a spambot attack.
• AntiBot: Same kind of thing as AbuseFilter, but in AbuseFilter, we write our own filters. This lets us tie into actively maintained lists.
• ConfirmEdit: Lets us use CAPTCHAs. Not as important here because we don't allow anonymous edits, but a CAPTCHA for user registration is still worthwhile. Also has a setting that enables a CAPTCHA after a failed login attempt to resist automated password guessing attempts.
• SpamBlacklist: Lets us block specific external links. Useful in fighting spammer attacks by automatically blocking any edits containing links we blacklist.
• Title Blacklist: What it says on the tin. Prevents the creation of pages with titles we blacklist. Useful after deleting a page a spammer creates to prevent any other spammers from doing so again. — Eyes 09:07, 24 July 2011 (UTC)