We've released Chameleon 6.0.0.

Chameleon is a popular Bootstrap-based skin that gives you a customizable, mobile-friendly, and responsive layout.

Highlights:

• Upgraded from Bootstrap 4 to Bootstrap 5.3, obtained via Extension:Bootstrap 6. All Bootstrap 5 classes and utilities are available in wikitext and templates.
• Bootstrap 5 exposes its colors and many other values as CSS custom properties, so a lot of what used to need an SCSS recompile can now be done from `MediaWiki:Chameleon.css` with plain CSS.
• The bundled Font Awesome icon set moved from version 5 to 6.

Requirements went up: Chameleon 6 needs MediaWiki 1.43 or later, PHP 8.1 or later, and Extension:Bootstrap 6 or later.

Since Bootstrap 5 renames and removes a number of Bootstrap 4 classes and utilities, plan for some migration work if you use Bootstrap classes in wikitext, templates, or custom stylesheets, or if you customize the SCSS variables. The migration guide covers the class renames, the SCSS changes, and the Font Awesome update: https://github.com/ProfessionalWiki/chameleon/blob/master/docs/migration.md

The companion BootstrapComponents extension has also released version 6 with Bootstrap 5 support, so you can move both at the same time.

You can try Chameleon 6 and BootstrapComponents 6 together on our demo wiki: https://bootstrap.pro.wiki

Release announcement: https://professional.wiki/en/news/chameleon-6-0-0-released

Feedback and bug reports are welcome. Issue tracker: https://github.com/ProfessionalWiki/chameleon/issues

We've released Semantic MediaWiki 7.2.0.

Highlights:

* A `+display` option for `{{#set:}}`: store and show a value in one call, without a separate inline annotation. Example: `{{#set:Has population=812,405|+display}}`

* A new `{{#property_link:}}` parser function for linking to a property page from running text, replacing the `[[Foo::@@@]]` trick. This resolves a feature request open since 2016.

* Six security fixes: five XSS issues in `Special:Ask` and `Special:SearchByProperty`, and an open redirect in `Special:URIResolver`. We recommend upgrading.

* PostgreSQL support works again (it was broken since 7.0.0), plus PHP 8.5 compatibility fixes and a memory fix for long-running maintenance scripts on large wikis.

It is a minor release: compatible with MediaWiki 1.43 up to 1.46 and PHP 8.1 up to 8.5, no breaking changes, and no need to run update.php. If you set `$smwgEntityCollation` to a `uca-*` value, run `updateEntityCollation.php` once after upgrading.

Professional Wiki created the two new parser function features for a public-sector customer. We thank them for funding this SMW work!

Find details and upgrade instructions at https://professional.wiki/en/news/semantic-mediawiki-7-2-0-released

Feedback and bug reports are welcome. Issue tracker: https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues

So I’m pretty ruthless with trying to eliminate spammers on my wiki with a giant email-blacklist page.

To kill the existing users, I had been doing something along the lines of:

UPDATE `wiki_user` SET user_password='', user_email='', user_token='' WHERE user_email like '%bjork.wtf';

but it’s a bit of a pain to build this query and run it in myphpadmin and I’ve started instead just doing a search on wiki_users for, e.g., LIKE '%bjork.wtf' and then selecting all results, and deleting their user records outright. Is there any reason to prefer the manual SQL above to the delete approach that I’ve started doing?

We've released Native Markdown, a new open-source MediaWiki extension that provides a deeply integrated Markdown content model.

In contrast to some earlier Markdown extensions, the entire page is stored as Markdown rather than embedding Markdown within wikitext via a tag or similar.

All of these work on Markdown pages:

• Wiki links with the semantics you know: `[[Page]]` gives blue or red links tracked in WhatLinksHere, `[[Category:X]]` assigns the category, `[[File:X.png|thumb|Caption]]` embeds a framed image
• Templates, parser functions, and magic words, expanded through MediaWiki's own parser (dependency tracking and the same output sanitization as wikitext); wiki admins can turn this off for a pure Markdown wiki
• Table of contents, redirects, page moves, diffs, history, and full-text search that indexes the rendered content rather than the raw markup
• CommonMark plus GitHub Flavored Markdown with footnotes; YAML front matter stored as page metadata

You can add Native Markdown to existing wikis without breaking anything, since those pages remain wikitext. By default, new pages will be in Markdown (Talk, Template, and MediaWiki namespaces stay in wikitext), with configuration options that let you control how fully you switch, e.g., only in certain namespaces or for titles ending in `.md`.

Not yet supported: VisualEditor and section editing. `<ref>` in the Markdown body is not supported either; footnotes cover citations.

Native Markdown requires MediaWiki 1.43+ and PHP 8.1+, installs via Composer, and is free and open source (GPL 2.0 or later).

Release blog with demo video: https://professional.wiki/en/news/native-markdown-released

Source and issues: https://github.com/ProfessionalWiki/NativeMarkdown

Happy to answer questions. Feedback and bug reports are welcome.

How can I make the default be dark mode for users that aren't logged in, with vector 2022 skin?

I am creating a wiki on Miraheze and don't have access to LocalSettings.php.

On a vanilla mediawiki installation using the default skin, I've noticed that it doesn't acknowledge that my browser is set to dark mode until I log in. Is there a way to change that? And why does it behave this way?

I don’t know much about tech stuff so I’m really lost on what to do. I’m just trying to log in to my Promethease / snpedia account. I have been automatically blocked by mediawiki. I have an infinite block because of my ip address because “my ip address is listed as an open proxy in the DNSBL used by snpedia”

New MediaWiki versions have been published that fix an RCE (Remote Code Execution) vulnerability in the import mechanism. You should either update your wikis immediately or remove import and importupload rights from all users until you are able to patch.

Additionally, an RCE vulnerability was patched in the EasyTimeline extension and other security issues with AbuseFilter and SyntaxHighlight were patched.

For more details consult the wikitech-l post at https://lists.wikimedia.org/hyperkitty/list/[email protected]/thread/J52N2ONQO7GP3XR7UIEA5PI7SVZYTBJ7/

Hi everyone,

I am currently working on an open source wiki engine. To figure out what things I should focus on, I wanted to ask you guys your current feelings about mediawiki as a piece of software.

How do you feel about mediawiki? Is it easy or frustrating to use? What are the worst parts of working with mediawiki, or the best? Are there any features/QoL changes that mediawiki doesn't have that you would like to see implemented?

Any feedback is appreciated.

I’ve been hosting a site (rejectionwiki.com) at dreamhost for quite a while, but it seems like I’ve been getting steadily degrading service over the years to the point where the site is often unreachable. Does anybody have a hosting service they like? I get about 10K page views per month and would like to keep the cost under $8/month which is about what I get from the google ads that run on the site so I’m not losing money providing the service. The vast majority of users are based in the US.

I was looking around for an extention, that gives me a "MotD"-textblock on my mainpage of my littl' wiki. I found ALOT of huge extentions, with ALOT of feature. Fully overdozed, for my needs.

What im looking for is, to simply parse a line of text from a article (with many lines of text, one "MotD" per line") or an simple textfile, randomly and display it on my mainpage.

Is there an recommendation for that kinda feature? Im fully lost, with the insane amount of extentions, that are available ;-).

Thanks alot!

We've released Semantic MediaWiki 7, the biggest release in years, with a focus on performance and easier installation.

Highlights:

• Significantly faster: optimized queries and maintenance jobs, with order-of-magnitude gains on large wikis in some cases
• Easier to install: a plain `wfLoadExtension( 'SemanticMediaWiki' )` is now enough, with no more `enableSemantics()`
• Support for MediaWiki 1.45 and 1.46, and PHP 8.1 through 8.5
• 24 notable enhancements and 32 bug fixes

Most extensions to SMW already include support for SMW 7.

Special thanks go to alistair3149, who led this release, and to Paladox for keeping the continuous integration infrastructure running. We are also grateful to Brian Wolff, who surfaced numerous performance issues, and to Niklas Laxström and jaideraf for testing.

Find details and upgrade instructions at https://professional.wiki/en/news/semantic-mediawiki-7-released

I first released Working with MediaWiki in 2012, and every few years since then I have released a new, updated version (one of the perks of self-publishing). The 2026 version just came out, with lots of updates, especially to the content about extensions, and a whole new chapter on wikis and AI. You can read the whole book online for free, or order a hard copy from Amazon, both from here:

https://workingwithmediawiki.com/

I hope you like it!

I have a mediawiki I run for a NWN module I'm developing. In it, I have a template, charbox, where I want to include an image in a table of character vitals, if an image is passed to the template.

It's available here if you wish to take a look: https://wiki.toud.pw/Template:Charbox

Read-only as we were getting hammered by LLM bots.

I'm failing to make the [[image]] only work if the image= is specified in the template.

Is this possible to do? If so, how can I accomplish this?

All right, so it would appear as though VisualEditor doesn't like the character "ム" being in any of the infobox parameters for some reason, giving me these errors when attempting to edit in VisualEditor, even though, as far as I know, ム is a perfectly acceptable character (and I am typing it directly from my keyboard instead of copy-pasting it). Can anyone help me figure out why that is? I just can't figure it out.

i went into the search console
submitted my base wiki link at wiki.mydomain
said redirect error
Whatever submitted a sitemap it found like 200 pages
i submitted wiki.domain/wiki/Main_Page and THAT worked and it says its on google but ive yet to see my site appear at all on google resutlts
granted it has only been a day, but my other sites appeared on google within less than a day.
i haave it behind nginx proxy manager

I don't want it to be stuck on localhost. So is there a FREE alternative? I downloaded XAMPP and MediaWiki for this.

Thanks.

Whilst trying to use this extension (TabberNeue), I found myself unable to relocate the first line, which is currently hidden beneath the header, in a similar manner as is found on this other wiki, which uses the same extension and format. I was wondering if anyone knows how to change this?

After the latest update to 1.45.1, the Font Awesome icons are missing from my buttons. For example, the button in the top-right corner no longer shows its icon. Or is it the skin that is missing information? "Pivot" version 7164acb.

https://www.grundskoleboken.se/wiki/Huvudsida

Is there a way to restore them?

EDIT

If someone else have this problem.

From 1.45, Pivot is extremely case sensitive. The folder with the skin must be named Pivot with capital P and in Local settings it must be:

wfLoadSkin( 'Pivot' ); and $wgDefaultSkin = 'pivot';

Otherwise, font awesome can't be found by Pivot.

I am finishing a migration of a MediaWiki installation to a new server before trying to update to the latest version. Everything seems to be working except for certain icons not showing, like the arrow for external links to other pages. In the following image, there's a gap where the icon should be.

However, the CSS for the link points at background-image: url(?2cd31); Normally, working icons are something like background-image: url(/w/load.php?modules=skins.vector.icons&image=expand&format=original&skin=vector-2022&version=kcn0q);

I poked around wikipedia.org, and it looks like an external link icon comes from a path related to the skin:

I disabled RewriteRules entirely to debug and cleared the page cache. I'm currently running:

• MediaWiki: 1.40.1
• PHP: 8.4.16
• ICU: 76.1
• MariaDB: 11.8.6
• Vector (skin): 1.0.0

I've seen some very old references to need to configure style paths, but I haven't found anyone posting a clear solution yet. My current entry point URLs are:

• Article path: /w/index.php/$1
• Script path: /w

Does anyone have ideas on how I can debug this further or what the right keywords are? It sounds like something related to the resource loader. Is loading of icons handled differently for skin and other (built-in?) icons? Thank you!

I just recently came across the wikimedia skins lab skins.wmcloud.org/

It doesn't show preview images and there's no live preview of the skin in use on an MW instance. This could be a valuable resource to not only MW sysadmins but also those who maintain wikis on hosts like Miraheze.

I've started rebuilding the skins lab primarily wanted the live preview system, but the cover/preview images are a nice touch https://skins.wikora.io
(Still a work in progress, the preview images are the ones on the mediawiki docs and skin variants don't link to the correct MW docs will fix with time)

Live MW preview instance is in 1.45.3