New features

With the new {{#property_search_link:}} parser function, you can link to the list of all pages that have a given property value. For example, on a music wiki, an album page can link to all albums by the same band with {{#property_search_link:Has artist|Pink Floyd|More albums by Pink Floyd}}. See the documentation for more examples.

You can now rebuild the full-text search index in chunks, which helps on hosts that stop long-running scripts. Run rebuildFulltextSearchTable.php with -n to set the chunk size, -s to start or resume at a given subject ID, and --max-time to stop starting new chunks after that many seconds. With --use-job, the rebuild runs through the job queue instead.

Security fixes

This release fixes three security advisories, all rated medium: cross-site scripting issues in Special:Ask and Special:Browse, and a missing authorization check in the smwtask API module.

Both cross-site scripting issues also affect older versions, one as far back as SMW 2.5. Only the latest major version gets security fixes, so if your wiki runs SMW 6 or older, you need to upgrade to SMW 7 to get them.

Some of the fixes tighten input handling, so requests that previously succeeded may now be rejected. Special:Ask also now serves file exports and raw results fetched through its request_type parameter as plain text instead of HTML.

Fewer database queries and bug fixes

SMW caches data such as a property's type and a page's display title. Since 7.0.0, every read of such a value went to that cache, which meant a database query each time wherever the cache lives in the database, as it does by default in maintenance scripts. SMW now keeps the values it just read in memory, so repeated reads skip the query. In our test with 400 pages and a filled cache, rebuildData made 31.2k SELECT queries instead of 48.0k.

This query fix is one of 19 bug fixes in the release. Others restore Page Schemas editing, broken since 7.0.0, and the listwidget format of Semantic Result Formats, broken since 7.3.1. URL values containing a space now link to that URL, rather than to one with an underscore in place of the space.

Credits

This release was led by our own Alistair Kim. We thank the security researchers who reported these issues responsibly, and everyone who contributed.

Semantic MediaWiki is free and community-driven. Please consider donating to Semantic MediaWiki to support its continued development.

Upgrading

You can upgrade from SMW 7.3 without running update.php.

If your wiki uses properties of type URL or Annotation URI, run php maintenance/run.php SemanticMediaWiki:rebuildData after upgrading. Until then, queries on values containing a space may return wrong results. A URL ending in Foo bar and one ending in Foo_bar are now different values, so a query for one no longer finds the other.

If you upgrade from SMW 7.2 or older, the steps in our Semantic MediaWiki 7.3 post apply too. Coming from SMW 6 or older, they include running update.php and upgrading to MediaWiki 1.43 or later. See the release notes for the exact commands and every change.

Professional Semantic MediaWiki Services

At Professional Wiki, we provide Semantic MediaWiki services, including SMW hosting, SMW software development, SMW consulting, and MediaWiki upgrades. If you would rather not upgrade your wiki yourself, we can do it for you.

Request a wiki with Semantic MediaWiki and it is typically ready within 2 business days.

NeoWiki at a glance

At its core, NeoWiki lets you edit versioned structured data via forms. The forms are based on schemas, which you also create and edit via user-friendly UIs. You can query your data through graph databases. For example, you can list every active project a person leads, with its partners.

Subjects are your records, such as a person, a company, or a project. Each subject follows one schema.

Schemas define the shape of your data: property names, types, constraints, and defaults. Think of a Person schema, a Company schema, or a Project schema. Property types include text, numbers, dates, URLs, choice lists, text with a language tag, and relations to other subjects. The NeoWiki glossary explains these and other terms.

Forms let editors fill in typed fields with autocompletion and validation. If a related subject or schema doesn't exist yet, you create it on the spot, without leaving the form.

A page can hold several subjects. The Rijksmuseum page on our demo wiki carries the museum as its main subject, shown in an infobox. It also carries each year's attendance, with its visitor count and source, as a subject of its own. You edit those inside the museum's form. If you prefer one page per record, switch the wiki to subject-first mode.

Your wiki is the source of truth. Structured data is stored as JSON in a dedicated MediaWiki revision slot. Every change appears in the page history, with diffs and attribution. Approval flows work.

Standard query languages. NeoWiki projects your data into SPARQL 1.1 stores such as QLever, Oxigraph, and Fuseki, or into Neo4j for Cypher queries. You query from Lua modules or through the REST API.

Design principles

Usable without technical skills. You can view and edit your data and its schemas entirely through user-friendly interfaces, without ever seeing JSON, wikitext, or other technical plumbing. If you want to, you can still open the JSON and access your data through wikitext and Lua. The interface responds instantly as you work (reactive UI), one of many decisions that bring NeoWiki closer to tools like Notion and Airtable.

Your data stays yours. NeoWiki sends no telemetry and needs no third-party services. You can export your data as RDF, JSON, or MediaWiki XML, so you are not locked in.

Value over features. We focus on supporting the common use cases well rather than chasing every feature. In software, you often get over 90% of the value for less than 10% of the features. We explicitly do not aim for feature parity with existing solutions, be it those in the MediaWiki space or outside.

A solid foundation. Two things keep NeoWiki sustainable. The first is technical excellence: a well-thought-out architecture and automated tests. The second is simplicity: we build on popular existing tools such as QLever and Neo4j. This makes NeoWiki a solid foundation for continued innovation. The roadmap shows some of what can be built on top.

NeoWiki 0.1 Beta

From 0.1 on, every breaking change to stored data comes with a migration script or upgrade guide. It is still a beta, though: don't use it for a critical production system. Some capabilities you need might not be (fully) there yet (see the roadmap), and we're making changes rapidly.

The quickest way to play with NeoWiki is via the demo wiki at neowiki.dev. Before you can edit, create an account and confirm your email address.

You can install NeoWiki with Docker or add it to an existing MediaWiki (1.43 or later). The installation docs also cover the key settings.

Prefer not to run it yourself? We can host a pilot for you.

Recent progress

Much of what follows is new since our first public demo in March.

There is a new dashboard for your NeoWiki at Special:NeoWiki. Here you'll find recent changes to your data and links to other key overview pages, such as Special:Schemas and Special:Subjects, which list your schemas and subjects with controls to edit them.

You can now browse your data without having standard wiki content. Key components are the Special:Subjects list page, which supports search and filtering, and the Special:Subject page, which shows a single subject together with a list of referencing subjects (incoming links). For people with a Wikibase-like use case, such as an authority file or a controlled vocabulary, we've added subject-first mode, which makes your wiki data-centric instead of page-centric, so you can work without having to think about wiki pages.

You can now configure your NeoWiki via an on-wiki page. The configuration is stored in JSON, with changes visible and revertible in the page history. We also added a UI on top so you don't have to deal with the JSON directly. If you would rather not allow on-wiki configuration, you can turn it off in LocalSettings.php.

Schema import and export UIs. While you could already export and import schemas (and subjects, mappings, layouts, etc.) via the APIs and standard MediaWiki mechanisms, you can now also use a convenient export and import UI on Special:Schemas.

Configurable data display. NeoWiki's core gives you control over how values are rendered, for instance, via the precision attribute on number property definitions. We created an extensible view system that lets you choose whether to show a subject as an infobox, as a card, or in some other way. You can define layouts that specify which properties to show, override display attributes (e.g., numbers with a different precision), and customize the view (e.g., the border color of an infobox). While the foundations are there, some UIs are still missing and are on our roadmap.

Linked open data comes from ontology mappings, which project your own schemas onto a standard ontology in RDF exports and SPARQL stores. On the demo wiki, Pablo Picasso is an ordinary Person page. The mapping to the Europeana Data Model (EDM) exports him as an edm:Agent and his birthplace, Málaga, as an edm:Place. The CIDOC-CRM mapping models his birth as an event. One store can hold your native data and its EDM projection side by side, and a single query can combine both.

# Page "Pablo Picasso"
neo-subj:s2picasso2aaaa2 a edm:Agent;
    rdfs:label "Pablo Picasso";
    foaf:name "Pablo Picasso";
    skos:note "Spanish painter, sculptor, and printmaker who co-founded…"@en;
    rdaGr2:gender "Male";
    rdaGr2:dateOfBirth "1881-10-25"^^xsd:date;
    rdaGr2:placeOfBirth neo-subj:s2birthcity2aa2.

# Page "Málaga"
neo-subj:s2birthcity2aa2 a edm:Place;
    rdfs:label "Málaga".

NeoWiki started out with support for Neo4j, the world's most popular graph database, allowing you to run Cypher queries over your data. We then added a plugin system for graph stores and now support both Neo4j and SPARQL stores such as QLever, Virtuoso, and Oxigraph. You can run NeoWiki with any combination of those, or none. You can even run several instances of the same SPARQL store, each with its own graph projection, for example, one QLever instance for CIDOC-CRM and another for EDM.

Roadmap

Capabilities you can look forward to:

• Bulk import and other import tooling. Easy import from files, RDF, and Wikidata.
• Built-in query result visualizations. You can already create your own visualizations on top of the APIs, Lua, and wikitext, but we plan to add built-in ones, loosely inspired by SMW's "result formats", such as tables, maps, charts, and timelines.
• Advanced dates, such as those in the Extended Date/Time Format (EDTF), so you can record uncertain dates, ranges, partial dates like October 2026, and more. We'll build on the foundations we created for Wikibase EDTF.
• Images, other media files, and locations as property values.
• Additional multilingual support. You can already model multilingual values via the "Text with language" property type, which is similar to Wikibase's "Monolingual text" type. We'll likely also add multilingual support for some of these: property labels, choice list options, subject labels, and schema descriptions.
• Interface translations. Until then, NeoWiki's own interface is English only, while MediaWiki's interface and your content can be in any language.

Not planned yet, but possible on today's foundation:

• Editing values directly from query results. This capability has been requested over and over for about 20 years in SMW, and we can now finally realize it via NeoWiki's architecture.
• Using the data of an SMW or Wikibase in NeoWiki, making it accessible for queries and visualization. For Wikibases installed directly next to NeoWiki, we could even enable editing of the Wikibase items via NeoWiki's UIs, providing the form-based editing experience commonly requested by the community.
• Linking and querying data from external systems. Example: autocompletion on GeoNames locations.
• Faceted search, which allows you to filter and browse your data, building on top of our Wikibase Faceted Search work and experience.

We expect various complementary capabilities to be built on top of NeoWiki, for instance, via the ECHOLOT project:

• Ready-made schema+mapping bundles you import and subscribe to, such as a bundle for museums that want to model their data according to CIDOC-CRM and export EDM for Europeana.
• Reconciliation and enrichment via a dedicated web-based application and human-in-the-loop agentic workflows.

Excited about any of these or don't see your own top wishlist items? Let us know; we prioritize what is most needed.

NeoWiki and Semantic MediaWiki

Semantic MediaWiki (SMW) is the main inspiration behind NeoWiki.

We continue to maintain SMW, with six releases since June 2026, from the major Semantic MediaWiki 7.0.0 release to 7.3.1. The SMW project is in a better state than it was a few years ago. We also continue to provide managed SMW hosting and SMW software development.

NeoWiki does not aim for feature parity with SMW. If SMW serves your wiki well, keep using it.

As SMW maintainers, we've long wanted to improve usability and bring the software to the next level. Unfortunately, some things get in the way of achieving that vision on top of SMW. The project has accumulated quite a lot of technical debt, making it hard to make large changes. Additionally, it has accrued lots of capabilities and contains ancient architectural choices that prevent large changes without severely breaking existing use cases. After many years of feeling stuck, we bit the bullet and reimagined the SMW concept from the ground up, bringing us to NeoWiki.

With NeoWiki, we strive to reach broader adoption by appealing to users for whom SMW is too technical. We hope this brings new organizations to MediaWiki, which benefits everyone who builds on it, SMW users included.

You can run SMW and NeoWiki side by side on the same wiki. We do not yet have an integration between the two, but that might well happen, depending on demand.

If you do wish to migrate from SMW to NeoWiki, beware that there is no migration tool yet. Contact us for advice.

If you know SMW, the main concepts map like this. Your property pages and Page Forms definition become one schema, such as Person, which NeoWiki turns into a form. Properties belong to their schema rather than to the whole wiki. Subobjects become subjects on the same page. Instead of #ask, you write Cypher or SPARQL queries. Until the result visualizations on our roadmap arrive, you show query results through Lua.

We'll be creating a detailed comparison between SMW and NeoWiki in the near future, together with a guide to NeoWiki for those already familiar with SMW concepts.

NeoWiki and Wikibase

NeoWiki shares much of Wikibase's DNA. Both store structured data as JSON in page revisions, give every record a stable ID and a resolvable URI, and export RDF that you can query with SPARQL. In subject-first mode, subjects get their own pages in a dedicated namespace, just like Wikibase items.

NeoWiki fulfills many wishes we've seen from the Wikibase community. Some highlights:

• Form-based editing
• Built-in constraints, including the ability to reject edits that violate them
• In-wiki display for readers
• RDF in standard ontologies such as EDM and CIDOC-CRM, through mappings

Some places where we deliberately departed from how Wikibase does things:

• NeoWiki embraces standard wiki pages. They are great for showing your data to readers and combining it with text. Wikibase item pages can only hold data. In NeoWiki, pages can hold both data and text, like in SMW, but with the data stored in out-of-the-way JSON.
• IDs in NeoWiki are randomly generated, avoiding import problems. You can also mint them in bulk for larger imports, so you are not forced to create subjects before you can reference them.
• You define properties in schemas. Wikibase properties are global: any item can use any of them. A NeoWiki subject uses the properties its schema defines, and mappings tie those to shared ontology terms in RDF.
• Simpler data model: a property graph, where our subjects are the nodes and our relations are the edges. This gives you a simpler structure for qualification, which benefits from schemas and can be nested arbitrarily deep: go ahead and qualify those qualifiers if you so wish.

We continue to invest in the Wikibase community by maintaining our Wikibase extensions, providing managed Wikibase hosting, and innovating further.

If Wikibase serves you well, keep using it. Wikibase remains the better fit when you feed data into Wikidata, rely on its tool ecosystem, or federate across Wikibase instances.

You can run NeoWiki together with Wikibase on the same wiki. Similar to how Semantic Wikibase brings Wikibase data into SMW, we are exploring integrations that would make your Wikibase data available through NeoWiki. You could even edit it there. If you're interested in migrating from Wikibase or connecting it to NeoWiki, contact us.

NeoWiki and AI

We purposefully did not include AI in NeoWiki core, but it is simultaneously built with AI in mind, for those who want AI integration.

NeoWiki forms an excellent complement to AI systems, providing a versioned system of record that AIs can read, query, and edit. The page history provides a safety net and transparency. The comprehensive REST API and query endpoints give your AI what it needs, and you can use our MediaWiki MCP Server for smooth integration via its NeoWiki tools.

Who is behind NeoWiki

Our team at Professional Wiki builds NeoWiki: Morne Alberts, Alistair Kim, Karsten Hoffmeyer, and me, together with everyone who has contributed on GitHub. NeoWiki is open source under GPL-2.0-or-later.

NeoWiki is the foundation of ECHOLOT's core system. ECHOLOT (European Cultural Heritage Optimised Linked Open Tools) is an EU Horizon Europe project that runs through 2028, with 15 partners in 12 countries. It is led by TIB – Leibniz Information Centre for Science and Technology. We lead the work package that develops that core system.

Funded by the European Union

Hallo Welt!, the company behind BlueSpice, chose NeoWiki as the structured-data layer of BlueSpice Galaxy, its new knowledge management platform. It also funds the integration.

Thanks to our ECHOLOT partners, whose expertise in cultural heritage and linked data shaped this release, to Hallo Welt!, and to everyone who tested early versions: your input brought us to this exciting 0.1 release. Special thanks to Lozana Rossenova and George Bruseker for their myriad conceptual contributions. We also thank the SMW and Wikibase communities for laying the foundations, especially Markus Krötzsch and Denny Vrandečić.

Get involved

If you want to pilot NeoWiki in your organization, contact us. We already provide NeoWiki hosting.

I'm giving two talks at the MediaWiki Users and Developers Conference (MUDCon) in Ljubljana, also streamed on YouTube: "NeoWiki in Action" on November 11 and "Let AI Work With Your Wiki" on November 12. On November 13, Karsten Hoffmeyer is running a beginners' tutorial for NeoWiki.

We're moving fast. If you spot stale documentation, have capability wishes, or have feedback on what's already there, let us know in GitHub Discussions.

If you develop MediaWiki extensions, you can build on NeoWiki's extension points, for example, to add your own property types or views. We'll add more extension points based on demand.

Follow NeoWiki on Mastodon, Bluesky, and X, or sign up for email updates.

Security fixes

Together, the two releases fix 21 security advisories, eight of them rated high. Version 7.3.0 fixed a missing authorization check in the smwtask API module, through which anyone, without logging in, could read internal database statistics and reach maintenance operations meant for administrators. Version 7.3.1 resolves 20 more security advisories, among them twelve cross-site scripting issues across special pages, result formats, tooltips, and autocomplete, a cross-site request forgery in Special:SMWAdmin, a way for ordinary editors to protect pages indefinitely, and four denial-of-service issues. The details are in the published security advisories.

Nineteen of the 21 also affect SMW 5 and 6, and five go back as far as SMW 2.5. Security fixes only go into the latest major version, so if your wiki runs SMW 6 or older, upgrading to SMW 7.3.1 is the way to get them.

Some of the fixes tighten input handling, so requests that previously succeeded may now be rejected, and some HTML that used to render may now show as plain text. If something your wiki depends on stops working after the upgrade, please open an issue.

Also new in 7.3.0

Full-text search no longer ignores short words and stop words that carry a wildcard. A query such as [[Has text::~to* be]] used to search only for "be" and now also finds words starting with "to", so such queries can return more results than before.

The new $smwgConfigProfiles setting applies the configuration profiles that ship with SMW, such as db-primary-keys. See Upgrading if you enabled a profile following the 7.0.0 release notes.

The two releases also fix 12 bugs. Find every change in the release notes of 7.3.0 and 7.3.1.

Use Semantic MediaWiki with AI

You can connect Claude, ChatGPT, and other AI tools to your Semantic MediaWiki via our open source MCP server, and let them run queries or even edit on your behalf. Find out more in Use Semantic MediaWiki with AI.

Credits

These releases were led by our own Alistair Kim, who implemented the bulk of the security enhancements. We thank the security researchers who reported these issues responsibly, and everyone who contributed.

Semantic MediaWiki is free and community-driven. Please consider donating to Semantic MediaWiki to support its continued development.

Upgrading

From 7.3.0, upgrading to 7.3.1 needs no extra steps. From an earlier SMW 7 version, these steps may apply:

• If your wiki uses properties of type URL, Annotation URI, or Email, run the rebuildData maintenance script, since queries can otherwise miss some values stored by earlier versions.
• If you enabled a configuration profile with the require line recommended by the 7.0.0 release notes, that line had no effect. Replace it with $smwgConfigProfiles and run update.php, which the db-primary-keys, elastic-fileingest, and media profiles need. A wiki that loads a profile both ways does not start.
• If you upgrade from a version before 7.2.1 and use Elasticsearch or OpenSearch, run rebuildElasticIndex --only-update once to correct the sort order.
• If you upgrade from a version before 7.2.0 and set $smwgEntityCollation to a uca-* value, run updateEntityCollation.php once.

If your wiki runs SMW 6 or older, the upgrade crosses a major version and requires running update.php, among other steps. SMW 7 also requires MediaWiki 1.43 or later, so wikis on an older MediaWiki need to upgrade that as well. Our Semantic MediaWiki 7 release post and the 7.0.0 release notes describe that upgrade, and the list above applies too. Where those notes recommend a require line for a configuration profile, use $smwgConfigProfiles instead. Since 7.2.1, the database conversion that update.php runs for SMW 7 works in batches and resumes where an interrupted run stopped, which helps on large wikis.

See the upgrading sections of the release notes for the exact commands, and the Semantic MediaWiki 7.3.1 release page for an overview.

Professional Semantic MediaWiki Services

At Professional Wiki, we provide Semantic MediaWiki services, including SMW hosting, SMW software development, SMW consulting, and MediaWiki upgrades. If you would rather not upgrade your wiki yourself, we can do it for you.

Request a wiki with Semantic MediaWiki and it is typically ready within 2 business days.

Ask questions instead of writing SPARQL

Ask in your own words. For a single entity, the assistant searches for it and reads it. When a question needs a query, the assistant works out which properties it maps to, writes the SPARQL, runs it, and shows you the result, as it does in the demo for the oldest libraries in Belgium. You refine in the same conversation. Reading Wikidata needs no account. Your own Wikibase answers the same way, and SPARQL questions require it to have a query service.

Create and enrich items from what the assistant finds

The same conversation can write. Point the assistant at data it has just read, or at any other source it can reach, and describe in plain words what you want made of it. It finds the matching properties on your wiki, with their datatypes, and fits the values to them. A prompt like Create items in our wiki for these ten libraries: inception as an EDTF value, the Wikidata ID, and located in, creating the place items you need. is all the mapping instruction it gets.

That is the import in the demo, into our Wikibase EDTF demo wiki. The founding dates become EDTF values at Wikidata's own precision, a day for the Royal Library of Belgium and a century for St Bavo's Abbey. The Wikidata IDs become external identifiers. Where a property takes an item rather than text, the assistant creates the missing target items and links to them, which is how the libraries got their places. A second prompt then adds each library's official website: one sentence backfills a statement across the whole batch. Royal Library of Belgium (Q191) is the public result.

Keep control of what gets written

An assistant can match the wrong property or duplicate an item that already exists, so the writes have to stay reviewable, and they do. Every write is an ordinary wiki edit: it lands in Recent Changes and the item's history with an edit summary naming the tool behind it, the account's contributions list gathers a batch in one place, and each edit can be undone like any other. Review a batch before you trust the next one.

The server reaches your wiki as an account you configure, so the edits appear under that account and the assistant has exactly its rights. Without the edit right it cannot change anything. Ten items is a job for an assistant; thousands are a job for a script, which is faster and spends no model usage. What the assistant reads goes to your model provider, so treat a private wiki accordingly. Wikidata is a Wikibase too, so the writing tools work there with an account, but its bot policy governs batch edits, which is why the demo writes into a wiki of our own.

The Wikibase tools

• wikibase-search-entities finds items and properties by label or alias.
• wikibase-get-entity reads one entity's terms and statements, with the IDs it references resolved to labels.
• wikibase-query runs a SPARQL query against the wiki's query service.
• wikibase-edit-entity creates an entity or changes an existing one.
• wikibase-add-statement adds a single statement to an item.

The server reads the wiki's siteinfo, so these tools appear only on a Wikibase, and wikibase-query only where the wiki publishes a query service.

Getting started

The server runs beside your wiki and talks to its API; nothing is installed on the wiki itself. You run it yourself, or take it as an add-on to our managed hosting. Your AI tool and its model subscription are your own. The MediaWiki MCP Server page explains how to connect the two, and the extension packs documentation lists the tools for Wikibase and other extensions.

Wikibase and AI services

We provide Wikibase services, including hosting, development, and consulting, and help bring AI to your wiki. Get in touch if you want help connecting yours.

See also

• Use Semantic MediaWiki with AI, the same server against a Semantic MediaWiki wiki.
• Top Wikibase Extensions, our curated list of extensions that enhance a Wikibase, including Wikibase EDTF.
• Introducing NeoWiki and More at MUDCon, which includes a recorded demo of the MediaWiki MCP Server.

From Bootstrap 4 to Bootstrap 5

Bootstrap is the CSS framework that provides the grid, components, and utility classes Chameleon builds its layouts from, so this upgrade touches everything the skin renders. Chameleon 6 uses Bootstrap 5.3, which it gets through Extension:Bootstrap, the extension that bundles the framework for MediaWiki. All Bootstrap 5 classes and utilities are now available in your wikitext and templates.

Bootstrap 5 also 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 also moved from version 5 to version 6.

BootstrapComponents 6

Chameleon is not making the jump alone. Its companion extension BootstrapComponents, which lets you add Bootstrap components such as accordions, cards, carousels, and modals to wiki pages via parser functions and tags, has also released version 6 with Bootstrap 5 support. It builds on the same Extension:Bootstrap foundation, so if you run Chameleon and BootstrapComponents together, you can move both to Bootstrap 5 at the same time.

Upgrading

Chameleon 6 raises the minimum requirements: it needs MediaWiki 1.43 or later, PHP 8.1 or later, and Extension:Bootstrap 6 or later.

Because this is a major Bootstrap upgrade, plan for some migration work. Bootstrap 5 renames and removes a number of Bootstrap 4 classes and utilities. If you use Bootstrap classes in wikitext, templates, or custom stylesheets, or if you customize Chameleon's SCSS variables, you may need to update them. Our migration guide walks you through the class renames, the SCSS changes, and the Font Awesome update.

See it in action

Try Chameleon and BootstrapComponents together on our live demo wiki: bootstrap.pro.wiki.

Professional MediaWiki Services

At Professional Wiki, we provide MediaWiki theming and skin development, MediaWiki software development, and various MediaWiki services. Get in touch if you would like help with your Chameleon upgrade.

New parser features

The #set parser function gained a +display option, so you can store a value and show it in a single call without a separate inline annotation. For example, {{#set:Has population=812,405|+display}} stores the population and prints the stored value in place.

There is also a new {{#property_link:}} parser function for linking to a property page from within running text. It provides a dedicated syntax for what previously required the [[Foo::@@@]] annotation trick, resolving a feature request that had been open since 2016. For example, {{#property_link:Has population|population}} links to the property page under the label "population".

Both parser features provide a robust alternative to the "extended link syntax", which future versions of MediaWiki might drop support for. We (Professional Wiki) developed them for a public-sector customer and made them available to the entire community.

Security fixes

This release fixes six security advisories: five cross-site scripting issues in Special:Ask and Special:SearchByProperty, and an open redirect in Special:URIResolver. We recommend that everyone upgrades. The details are in the published security advisories.

Bug fixes

Version 7.2.0 also resolves a number of bugs. PostgreSQL support works again after being broken since 7.0.0, several PHP 8.5 compatibility problems are fixed, and long-running maintenance scripts no longer exhaust memory on large wikis. Find every change in the release notes.

Improvements from 7.1.0

If you missed it, Semantic MediaWiki 7.1.0, released on July 9, 2026, resolved each category- and property-hierarchy query in a single database query for a performance boost, alongside many stability fixes. Upgrading to 7.2.0 includes all of these changes as well.

Use Semantic MediaWiki with AI

You can connect Claude, ChatGPT, and other AI tools to your Semantic MediaWiki via our open source MCP server, and let them run queries or even edit on your behalf. Find out more in Use Semantic MediaWiki with AI.

Credits

This release was led by our own Alistair Kim. We thank everyone who contributed.

Semantic MediaWiki is free and community-driven. Please consider donating to Semantic MediaWiki to support its continued development.

Upgrading

Because 7.2.0 is a minor release, it does not require running update.php or any migration scripts, and it does not drop support for any MediaWiki version. We recommend that everyone running an older version of SMW upgrades. See the upgrading section of the release notes for the exact steps, and the Semantic MediaWiki 7.2.0 release page for an overview.

Professional Semantic MediaWiki Services

At Professional Wiki, we provide Semantic MediaWiki services, including SMW hosting, SMW software development, SMW consulting, and various MediaWiki services.

Request a wiki with Semantic MediaWiki and it is typically ready within 2 business days.

A real wiki page

A Markdown page renders like any other wiki page, and the MediaWiki features you rely on continue to work.

Wikitext link syntax works inside Markdown, with the semantics you know. [[Page]] gives you a blue or red link depending on whether the page exists, and the link is tracked in Special:WhatLinksHere. [[Category:X]] assigns a category, and [[File:Diagram.png|300px|alt=Text|Caption]] embeds an image.

Your shared templates keep working. Infoboxes, navboxes, and citation templates transclude with the usual {{...}} syntax, and a page re-renders whenever you edit a template it uses. Parser functions and magic words work too. Wiki admins can disable them in Markdown pages.

The Markdown flavor is CommonMark plus GitHub Flavored Markdown: tables, strikethrough, task lists, and autolinks, with footnotes on top. Tables are automatically styled as wikitables. YAML front matter is parsed, hidden from the rendered page, and stored as page metadata. Raw HTML is always escaped, so page content cannot inject scripts or other active HTML into your wiki.

You edit via the standard edit form. With the CodeEditor extension installed, you get Markdown syntax highlighting, and Show preview renders through the full pipeline. Diffs, history, undo, and page moves all work as expected.

Great for AI

For AI agents, the point is that the page source is plain Markdown and the wiki serves it unmodified. Fetching a page with action=raw returns the source exactly as it was saved, front matter and all. This is what an agent gets back from a documentation page on a wiki running Native Markdown:

---
version: 2.4.0
owner: Platform team
---

# Platform 2.4 release notes

This release focuses on deployment safety and documentation quality. Upgrade using the
[[Deployment Guide.md|deployment guide]].

## Upgrade checklist

- [x] Announce the maintenance window in #platform
- [x] Back up the database
- [ ] Run the search reindex job

The REST API reports the content model alongside the source, so an agent knows what kind of page it is working with, and action=parse returns the rendered HTML when an agent wants resolved links rather than the source. Writing works through the ordinary editing APIs, or more conveniently through the MediaWiki MCP Server, the tool that lets AI assistants read and edit your wiki. The agent hands over Markdown, and the wiki stores it verbatim. The round trip is lossless. An agent can fetch a page, edit it, and write it back without the content drifting through a wikitext translation. The same property makes Markdown pages a good fit for round-trips with git repositories.

Clean search results

Full-text search indexes the rendered prose of a Markdown page rather than the raw markup, so keyword lookups match what a reader sees. Search snippets are clean text instead of # and ** noise, and front matter stays out of the index.

Why we built it

Markdown support in MediaWiki has a long history of half measures. The furthest along is Extension:WikiMarkdown, which embeds Markdown blocks inside wikitext pages via a tag. Inside those blocks, there are no working wiki links, no category assignment, and no table of contents. It is also no longer maintained and does not work on current MediaWiki versions. Extension:Markdown is archived. We wanted the real thing: Markdown as a first-class content model, not a tag hack.

You might know our External Content extension, which embeds Markdown files from external sources such as GitHub into wikitext pages. The two are complementary. External Content brings outside Markdown into wikitext pages, while Native Markdown makes the wiki pages themselves Markdown.

What the first version does not do

We kept the first release focused on getting the content model itself right. Two MediaWiki editing conveniences are not there yet: there is no VisualEditor support, and no section editing.

If your editors rely on VisualEditor, wikitext remains the better model for those pages, and both models coexist on the same wiki, so you can choose per page. On the roadmap: mapping front matter to structured data such as Semantic MediaWiki properties, live preview and WYSIWYG editing, and import tooling for Obsidian vaults and git repositories.

Getting started

The first version of Native Markdown requires MediaWiki 1.43 or later and PHP 8.1 or later.

Once installed, new pages default to the Markdown content model everywhere (with some namespace-based exceptions). If you have any existing wikitext pages, they will continue to work as wikitext, and you have the option to switch them to the Markdown content model. The same applies in the other direction: if at any point you wish to switch from Markdown to wikitext, you can do so gradually.

If you would rather keep wikitext as the default, or offer Markdown only in specific namespaces, you can achieve this with a one-line configuration change. You can also let users decide via the optional .md suffix mechanism, which is disabled by default. When enabled, new pages whose title ends in .md default to Markdown, so the two models can mix freely even where wikitext is the default.

Installation instructions, configuration options, and the full documentation are on the Native Markdown extension page.

Get started quickly with Native Markdown via our managed MediaWiki hosting.

Open source

Native Markdown is free and open-source software developed by Professional Wiki, released under the GNU GPL v2 or later. We built it test-first: the Markdown pipeline is covered by a large automated test suite that also runs standalone without a MediaWiki installation, and continuous integration covers the supported MediaWiki and PHP versions. Contributions are welcome!

Professional services

Native Markdown is developed and maintained by Professional Wiki. We offer MediaWiki hosting, MediaWiki development, and help with bringing AI to your wiki. Get in touch if you want to use Markdown or AI agents together with your wiki.

See also

• Embedding External Content in MediaWiki, the announcement of our extension for embedding Markdown from GitHub and other sources.
• Installing MediaWiki Extensions with Composer, our guide to installing and upgrading extensions with Composer, the way Native Markdown is installed.
• Use Semantic MediaWiki with AI, on connecting AI assistants to your structured data via the MediaWiki MCP Server.

How it works

MCP, the Model Context Protocol, is the standard that lets AI tools like Claude and ChatGPT work with external systems and data.

The new SMW support adds two tools to the server. smw-list-properties lets the assistant discover which properties your wiki uses, together with ready-to-use templates for querying them. smw-query runs a Semantic MediaWiki #ask query and returns the results. Together, they let you explore your data by asking questions, instead of writing query syntax yourself. You describe what you are looking for, the assistant inspects your properties, writes the #ask query, and shows you the answer.

Suppose your wiki catalogs your team. You can ask something like "Which colleagues in the Berlin office speak French?" The assistant discovers the relevant properties, builds a query such as {{#ask: [[Office::Berlin]] [[Speaks::French]] }}, and returns the matching people. From there, you can refine the question, ask for a table that includes their roles, or have it count the results, all without touching wikitext.

The MCP server makes Semantic MediaWiki much more accessible by reducing the learning curve. To create and maintain your data model, you have to create property pages, templates, ask queries, and perhaps forms, all with their own syntax. Even if you know SMW, this is an involved task. Because the MCP server allows your AI to read and edit wiki pages, you can tell the AI what your data model is and instruct it to implement it in your wiki. Then it takes care of the nitty-gritty syntax details and other technical considerations.

The SMW tools only appear on wikis that have Semantic MediaWiki installed, so an assistant always sees the right tools for the wiki it is connected to. The server connects as a specific account, so the assistant only has the access that account has.

Getting started

The SMW tools are part of the extension packs in the MediaWiki MCP Server, which add extension-specific tools on top of the core page reading and editing. See the extension packs documentation for the full list, including support for Cargo and Bucket. The MediaWiki MCP Server page explains how to connect the server to your AI assistant.

Semantic MediaWiki and AI services

At Professional Wiki, we have deep expertise in both Semantic MediaWiki and AI. We maintain Semantic MediaWiki and provide Semantic MediaWiki services, including hosting, development, and consulting. We also help bring AI to your wiki, including our AI Assistant for MediaWiki and MediaWiki MCP Server integration. Get in touch to connect AI to your structured data.

See also

• Semantic MediaWiki 7 Released, the latest major release of the extension we maintain.
• Introducing NeoWiki and More at MUDCon, which includes a recorded demo of the MediaWiki MCP Server.
• MediaWiki Chatbot Extensions Compared, our overview of the AI chatbot options for MediaWiki.

Highlights

SMW is significantly faster. We optimized database queries and the maintenance jobs that keep your data up to date. The difference can be dramatic on large wikis. In one case, a sorted property query that took 30 seconds now returns in a few milliseconds, and browsing pages with thousands of properties is much quicker thanks to cursor-based pagination. Editing or deleting a widely-referenced category or property no longer forces a re-parse of every dependent page: a change affecting thousands of pages that once kept the job runner busy for hours now finishes in seconds. Pages with language-neutral content are also cached once instead of once per interface language, raising the parser cache hit rate. If you run a big SMW wiki, this release alone is reason to upgrade.

Support for MediaWiki 1.45 and 1.46. SMW now runs on everything from the MediaWiki 1.43 LTS through 1.46, and on PHP 8.1 through 8.5. For the details, see the compatibility matrix.

SMW is easier to install. Installation now follows standard MediaWiki conventions. A plain wfLoadExtension( 'SemanticMediaWiki' ) is all you need, with zero extra configuration. You no longer need the enableSemantics() call, administrators get the smw-admin right by default, and configuration now accepts plain strings instead of the old SMW_* PHP constants.

SMW is more maintainable. We replaced bundled third-party libraries with MediaWiki core services and modernized large parts of the codebase. This reduces the maintenance burden and makes future development faster and safer.

You can find the full list of changes in the SMW 7 release notes.

Companion extensions

Most companion extensions already support Semantic MediaWiki 7:

The extensions still marked in progress do not have a Semantic MediaWiki 7 release yet. We and the community are working on compatibility, and contributions are welcome. The changes for developers and extension authors in the release notes describe what needs updating.

Credits

Over 25 people contributed to Semantic MediaWiki over the past year. We would like to thank all contributors.

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.

Semantic MediaWiki is free and community-driven. Please consider donating to Semantic MediaWiki to support its continued development.

Upgrading

Semantic MediaWiki 7 is a major release, so it contains breaking changes. The changes most likely to affect site administrators are the raised minimum versions and the installation changes described below. For the full list, including changes that affect developers and extension authors, see the migration guide.

Unlike recent SMW releases, this upgrade does require a few extra steps:

• Run the update.php maintenance script. It converts the smw_hash column to a more compact binary format.
• Remove any enableSemantics() call. wfLoadExtension( 'SemanticMediaWiki' ) alone now loads SMW. If you used the domain argument to set a custom RDF base URI, set $smwgNamespace directly instead.
• If you customized the SMW namespace indexes via $smwgNamespaceIndex, replace it with explicit define() statements placed before wfLoadExtension(). See the migration guide for details.
• If you use the full-text search backend, run rebuildFulltextSearchTable.php to apply the new transliteration.

We recommend that everyone running older versions of SMW upgrades.

Get the new version via Composer:

• Step 1: Ensure the SMW version in composer.local.json is ^7.0.0
• Step 2: Run composer in your MediaWiki directory: composer update --no-dev --optimize-autoloader
• Step 3: Run the update.php maintenance script

Get the new version via Git:

This is only for those that have installed SMW via Git.

• Step 1: do a git pull in the SemanticMediaWiki directory
• Step 2: run composer update --no-dev --optimize-autoloader in the MediaWiki directory
• Step 3: run the update.php maintenance script

Query Semantic MediaWiki with AI

Semantic MediaWiki pairs naturally with AI assistants. Our MediaWiki MCP Server lets tools like Claude and ChatGPT work directly with your wiki using the Model Context Protocol, and it now includes dedicated SMW support. The smw-query tool runs #ask queries on your behalf, and smw-list-properties lets the assistant discover which properties exist and how to query them. Together they let you explore your structured data by asking questions in plain language.

Professional Semantic MediaWiki Services

At Professional Wiki, we provide Semantic MediaWiki services, including SMW hosting, SMW software development, SMW consulting, and various MediaWiki services.

Request a wiki with Semantic MediaWiki and it is typically ready within 2 business days.

Introducing NeoWiki (Spring 2026)

At the most recent MUDCon, I introduced NeoWiki, a new open-source MediaWiki extension for structured data. I co-presented with Bernhard Krabina from Knowledge Management Associates.

I have been maintaining Semantic MediaWiki for over 15 years and created large parts of Wikibase. Both are powerful, but they were designed in a different era. SMW is over 20 years old. Tools like Notion and Airtable have since set a usability standard that these older systems were never designed to match.

NeoWiki applies the lessons we have learned. You get radically better usability and sustainability, with a focus on the features that deliver the most value rather than feature parity. That means native schemas with types and constraints, form-based editing, multiple subjects per page, JSON storage in MediaWiki revision slots, and a standard graph database for queries.

NeoWiki is backed by ECHOLOT, an EU-funded cultural heritage consortium with 15 partners across 12 countries, and by Hallo Welt, the company behind BlueSpice. NeoWiki will power structured data in the next major version of BlueSpice. Professional Wiki is the product owner.

You can try NeoWiki at neowiki.dev and find the source on GitHub. The slides are available online.

Follow NeoWiki on Mastodon, Bluesky, or X. Or visit the NeoWiki page to sign up for updates.

MediaWiki MCP Server (Fall 2025)

At MUDCon Fall 2025 in Hannover, I presented our MediaWiki MCP Server in a 20-minute talk. MCP (Model Context Protocol) is a standard that lets AI assistants interact with external tools and data sources. With our MCP Server, your AI assistant can read, create, edit, and delete wiki pages directly.

In the demo I showed creating pages, building tables, and deleting pages. The MediaWiki MCP Server is open source and available on GitHub.

Wikibase Extensions (Fall 2025)

Also at MUDCon Fall 2025, I gave a 20-minute overview of the Wikibase extension ecosystem. If you use Wikibase, these 17 extensions can give you advanced search, data validation, local media support, date handling, and automated property values.

We have a detailed write-up in our blog post Enhance Your Wikibase With Extensions.