MediaWiki as a Wikidot replacement

Pages

Pages

✅

Being a wiki, MediaWiki supports pages complete with persistent records of revisions which can be recovered if needed. At a high level, these concepts are equivalent.

Sites

Wikis

✅

MediaWiki supports having multiple wikis with isolated permissions and pages. Sites are also permitted to have custom domains.

Localization

Localization

✅

MediaWiki is well-translated and has many localization options.

Users

Users

🔵

Users have some differences.

• In Wikidot, they are first-class objects, like accounts on most sites.

• A shared, global user table in MediaWiki can be used. Here, there is no notion of “local” accounts, and a user is the same everywhere. “Membership” or “atttaching” to a wiki does not exist. This is the closest analogue to how Wikidot treats users as first-class objects.

  • Wikimedia Foundation sites use a separated system, where users are second-class objects attached to sites, and connected together via the CentralAuth system. (That is, users do not even exist on a wiki at all until they are attached, i.e. created, on first visit to that site/) This was done for legacy reasons and should not be considered for a new site.

• Naming is different. MediaWiki allows essentially all unicode characters to be used in usernames.

• MediaWiki usernames are case-sensitive.

• MediaWiki requires all usernames start with a capital letter.

• It is possible to rename users with the Renameuser extension.

(See below “Slug normalization”)

Wikitext (syntax)

Wikitext

❌

MediaWiki has an entirely different syntax than Wikidot. Several transition steps will need to be taken, at minimum:

• Write a renderer for ftml which outputs MediaWiki wikitext.

• Write guide(s) which describes MediaWiki’s syntax, both high-level and in-depth, for an audience of those used to Wikidot syntax.

• Convert pages manually if they have parsing or conversion errors.

• Review templates to ensure they work properly.

• Review page links and backlinks to ensure they are in order. (For instance, external links toscp-wiki.wikidot.com will need to be changed to page links)

See also:

• Collapsible elements, which describes a possible means of having Wikidot collapsibles using existing MediaWiki constructs.

Custom parser

❌

Using ContentHandler, all namespaces (save MediaWiki:) could be configured to use a different parser system. By plugging in ftml, MediaWiki wikitext would not need to be used, and the above transition would not need to take place.

However there are some issues. Internationalization passes through MediaWiki wikitext, which would need to be converted, and outcomes like structured data and categories need to be implemented as part of the parser’s output. This will be a substantial effort, as the MediaWiki parser is tightly integrated into its code and will be difficult to work with.

See also:

• MassMessage, which uses a custom page type which wraps the MediaWiki parser.

Categories

Namespaces

✅

These concepts are essentially equivalent, however they are configured differently in MediaWiki.

Category read restrictions

Lockdown

🟡

Wikidot’s implementation has several issues, but it does permit categories to be configured such that their contents are not publicly visible. In MediaWiki, this is not native functionality, but the Lockdown extension is able to offer this concept, though with many of the same limitations as Wikidot, and these restrictions may not be respected or compatible with other extensions. (This is noted because any MediaWiki installation to replace Wikidot will doubtlessly need several extensions for compatibility).

Category write restrictions

Namespace settings

✅

MediaWiki has native support for restricting writes based on namespace and user role.

Tags

Categories

🔵

Pages can be placed into “categories”, which are essentially analogous to Wikidot tags. There are some differences however.

• Categories have their own pages, and can be given descriptions and other relevant information.

  • Category pages themselves can be placed in categories. This creates a category tree which can be used to represent information hierarchically.

• Because categories are wikitext, restricting their addition or removal can be controlled using edit filters.

Slug normalization

Title normalization

❌

Both Wikidot and MediaWiki normalize slugs, but do so in extremely different ways.

For Wikidot:

• The slug is restricted to ASCII only (the wikidot-normalize crate supports non-ASCII Unicode letters).

• The slug is casefolded.

• Any invalid characters are converted to dashes. Multiple, leading, and trailing dashes are removed.

For MediaWiki:

• The slug accepts essentially all Unicode characters, including punctuation.

• The slug is case-sensitive. Pages Apple and APPLE are different.

  • It is believed to be trivial for an extension to make titles wholly case-insensitive.

• The first character of the slug must be capitalized. Pages Apple and apple are identical, with the latter being redirected to the former.

  • This is problematic because the natural use of all-lowercase SCP designations, such as scp-1000, will result in an ugly title like “Scp-1000”.

  • This restriction also applies to namespaces and user names.

  • This can be disabled by setting $wgCapitalLinks to false, however this is uncommon.

• Slugs may contain spaces (converted to _). This is distinct from -, which can be used as its own character.

Alternate normalization systems are not really possible in the code, at least without extensive modifications to MediaWiki core. A system of automatically redirecting pages could be implemented, but may need to exist at the router level (i.e. in nginx before the request hits MediaWiki). A bot could also be employed to automatically add hundreds of redirects for all listed variations.

This is culturally relevant to the SCP Wiki, as the slot a page has is important. SCP articles are numbered, and it could be confusing if similarly-cased or punctuated articles could be created.

Slug / Title Distinction

DISPLAYTITLE

🔵

In MediaWiki, a page’s slug is its title. In order to change the title a page has, the syntax {{DISPLAYTITLE:title}} can be used. Templates such as lowercase can be created to assist users in changing the title in standard ways.

URL compatibility

N/A

🔵

The web server can be configured to serve pages at / rather than at /wiki. For the more specific problem of slug normalization, see above.

Page locks

Page protection

✅

Pages can be given varying levels of protection to prevent vandalism or misuse.

• This system is publicly logged, unlike Wikidot which is entirely opaque and unaccountable.

• There are additional tiers of protection instead of a binary switch. The most interesting example is cascading protection, which applies recursively.

• It is possible to prevent a certain page slug from being created.

• With AuthorProtect, a new protection level is added, which restricts edits to the page creator only. A group permits users to apply this to their own created pages.

• With LockAuthor, all users cannot edit pages they did not create.

Anti-vandalism

N/A

✅

MediaWiki is provably capable of handling very large sites while still enabling action against vandalism. Some tools (such as ClueBot or Twinkle) are third-party bots or tools, and not part of the core software itself.

Relevant extensions or features:

• AbuseFilter – Denying certain edits if they match particular regular expressions, and related logging.

• AntiSpoof – Avoid deceptively similar usernames.

Page rating

VoteNY, ArticleFeedbackv5, wikiHow Rating Extension

❌❓

There are a number of voting extensions, but they tend to be poorly maintained or simplistic. It is possible to replicate Wikidot’s vote environment, but further improvements will likely require a custom extension.

Start page

Main page

✅

A main page can be configured for a site.

Files

Files

🟡

Files are completely different concepts.

• In Wikidot, they are attached to a page, and only exist in that context. In MediaWiki, they are their own first-class object, and are essentially File: pages like any other page.

• MediaWiki files can be easily used from any page, unlike in Wikidot where non-local files require a full URL.

• Wikidot files are isolated per-page, so filenames do not have to be unique. A page apple can have an attachment image.png, and a different page banana can also have an attachment image.png. Some mechanism of ensuring files are well-named and isolated will need to be developed, either in policy or in code.

• Wikidot files are deleted when its parent page is. This is not native to the platform but could be implemented using a bot.

Redirects

Redirects

✅

MediaWiki natively supports redirects. They may only be linked to pages on the same wiki (can be configured).

Site search

Search (Cirrus)

✅

MediaWiki search is functional, and there are many ways to customize it and make it significantly more useful than in Wikidot.

Modules

Special pages (1, 2)

🔵

These two notions are mostly similar, but in details they are very different. However most of the use cases in Wikidot are covered relatively well by MediaWiki. Particular modules may also be mentioned separately.

Components / Includes

Templates

🟡

MediaWiki has native support for templates, which are a fair bit more extensible than Wikidot’s. However, like with the syntax, these are designed very differently and will require effort to convert and document the changes, as well as cultural changes.

ListPages (offset pages)

Subpages

🔵

If subpages are enabled in the main namespace, then adding /1, /2, etc to the main page could be used as a replacement for offsets.

ListPages (other uses)

DynamicPageList, DynamicPageList3, DynamicPageListEngine

🟡

These are three viable extensions which could replace the use case of the ListPages module (for the intended use of listing pages), however they have not been thoroughly evaluated, and there may be Wikidot features within ListPages that are not supported by any of these extensions, or have issues.

Author pages / art pages

User pages

🟡

User pages are a clear analogue to author pages, however there are some differences:

• They must be in the User: namespace.

• They are linked to as if they were the user’s profile. This means that restrictions or user page creation based on authorship is culturally problematic.

  • Especially so since User talk: pages will need to be created, and people may simply customize those instead.

Art pages and other related media can simply exist as subpages within their User: space.

Forums

WikiForum, SocialProfile, DPLforum, DiscussionTools, LiquidThreads, PostComment, Comments

❓

There are a few extensions to consider when trying to create a forum system on MediaWiki:

• WikiForum adds a forum special page, with categories and the like similar to Wikidot. If SocialProfile is installed, its avatars will also be displayed.

• SocialProfile is a package containing several aspects means of socialization, including DMs (see below). If the other offerings it have are acceptable, it could be viable.

• DPLforum adds a Forum: namespace, where forums are a implemented as structured wikitext. It can be seen as a cross between talk pages and a full forum system.

• DiscussionTools adds a series of utilities to make editing talk pages easier, such as being able to click “reply” next to a current comment. In beta.

• LiquidThreads was a Wikimedia Foundation initiative, but it is no longer maintained. It provides forum post-like encapsulation over talk pages.

• PostComment is a wikiHow extension which has been archived.

• Comments allows people to add comments to a page when <comments /> is added to it.

Alternatively, forums could be deployed entirely separately from MediaWiki, and standalone forum software used instead. For instance phpBB or XenForo (not free).

Talk pages (namespace)

❌

If we ignore extensions, then MediaWiki does not have a meaningful forum replacement, and instead uses a system of talk pages, pages associated to others (similar to the “discussion” link on Wikidot pages), which users can write in to hold conversations.

This can work fine if the community is adapted to it, but for the SCP Wiki and its associated communities, this will be a massive cultural change.

Additionally, importing thousands of Wikidot forum posts and finding some way to represent them cleanly on talk pages will be a significant challenge.

An alternative to talk pages for the bulk of discussion is the use of some forum extension. These will need to be researched, but will doubtless present their own issues.

Forum moderation

Editing talk pages

❌

Moderating talk pages will prove challenging. Large, extant communities such as Wikipedia are already very familiar with the talk page system, and have an established culture surrounding it. Such structure will not exist for the SCP Foundation, and it will require an immediate, massive transition, which will prove disorienting.

There are several issues which affect talk pages, especially notable for a community which has a number of younger fans contributing lower-quality comments:

• Which user added a comment is not automatically added (when editing directly), instead it must be specified via signature (~~~~). Bots can be added to add missing signatures.

• Users are able to edit other people’s comments, and even delete them.

• Users may not be familiar with how to indent comments to reflect that they are replying to a particular topic.

User DMs

SocialProfile, User talk pages

🟡

With SocialProfile, a feature called UserBoard exists which can replicate this functionality. However the extension includes much more, and it is not clear how separable individual components are.

Aside from extensions, direct messages do not exist in MediaWiki. Notices are left to users by leaving a comment on their talk page. This will obviously require a cultural change.

Alternatively, the EmailUser special page could be used, but this would essentially permit exposing email addresses to users, which people may find objectionable on privacy grounds.

Moderator / Administrator

User groups

🔵

By default, MediaWiki has several user groups. Wikidot’s notion of the “moderator” and “administrator” map fairly well to MediaWiki’s “administrator” and “bureaucrat”, with the notable difference that admins are able to apply blocks (bans).

MediaWiki also allows customizing different groups which have special permissions. These can be further extended with extensions, which add new groups or add new capabilities to those groups.

Site membership and applications

User role and global editing settings

🔵

MediaWiki does not distinguish between “user who exists and is on a site” and “user who exists but is not on a site”, with the only way of having a “non-member” user is to block them.

To implement a “membership” flow, a site could be configured so that regular users cannot make any edits, and the “basic user” role is used instead. A user can be added to this group upon completion of some custom application flow, which will need to be researched and developed.

It is also possible to disable access by anonymous users, which requires that all users have a registered account.

Crom

API

✅

MediaWiki has a native API which can be used to interact with wikis in an automated way.

To avoid API write access abuse, the extensions ConfirmEdit (captcha) and AbuseFilter (customizable anti-spam) can be used.

Attribution

Structured data, templates, Cargo, SMW

🔵❓

It is possible to add attribution data via templates which apply structured data, using a flow such as Cargo → SMW.

Then a template such as {{author|Alice|Bob}} could be added, which would apply structured data that marks “Alice” and “Bob” as co-authors. More complicated systems could exist to help with the application of other kinds of attribution metadata.

This would not be a “native” feature, and a significant amount of work would be required to have it be available cleanly in all areas where this information is needed.

Some work would be needed (a template, or possibly a custom extension) to display authorial information in some standard location.

Narrative title

Structured data, templates, Cargo, SMW

🔵❓

Similar to attribution, the alternate or narrative title field could be added as structured data. Displaying it would likewise be similar to author attribution.

Theme pages

Unclear

❌

There is not a clear analogue.

CSS can be customized in a few ways:

• Users can customize their own experience with a CSS file in their userspace. This only applies to this particular user.

• Skins can be customized to have theme content. However this applies globally, not per-page, and is set at as a user preference.

• Because page titles are included in the CSS classes (for instance, <body class="... page-Main_Page ..."> for the main page), you could create a large “switch statement” in MediaWiki:Common.css which applies styling selectively based on page title.

• Gadgets could be used to load custom JS or CSS. These are customizable per-user, and are not very relevant to theme pages.

• It is possible to customize styling on a per-namespace basis. This is very similar to Wikidot’s native “theme” feature, and cannot be used for similar reasons.

• The closest analogue is the SkinPerPage extension, which would work, except it prevents user customization of CSS, which limits the usefulness and accessibility benefits of user-customized skin settings.

• TemplateStyles can style page content, but cannot make any changes to skin styling.

Of these, the TemplateStyles extension is the closest to how per-page styling is done, but it cannot alter the skin at all, which entails a cultural change due to a restriction of author creativity.

To allow skin styling to also be changed, but without bringing the restrictions of worsened accessibility or denying personal settings, a custom extension would need to be created.

Custom CSS

Extension:CSS

N/A

Allowing untrusted users to specify arbitrary CSS is a security flaw, and our setup on Wikidot works despite that. This is not a behavior we should bring to any new platform.

That said, the CSS extension is pretty much an identical match for Wikidot’s [[module CSS]] and is usable in that manner.

Sandbox / drafts

Draft: namespace, Push, Drafts

🟡❓

There are not good ways of copying pages from one site to another. English Wikipedia uses the Draft: namespace, and there are some extensions which can copy data to to other wikis. This will need to be evaluated more closely if we pursue a MediaWiki transition.