MediaWiki Development Services

SolidWiki is a specialist MediaWiki development team. We build, customise, and maintain MediaWiki-based wikis for organisations that want a structured, searchable, self-hosted knowledge base on a proven open-source platform - without the ongoing per-seat licensing costs of commercial alternatives.

This page describes the services we provide, how each engagement works in practice, and what to expect when working with us. If you have a question that isn't answered here, reach out directly through solidwiki.com.

What We Do

SolidWiki Services at a Glance
Service	What It Covers
Wiki Setup and Configuration	Full LAMP stack provisioning, MediaWiki installation, HTTPS, short URLs, and production hardening
Custom Skin and Branding	Brand-matched wiki skin built to your visual identity guidelines, responsive and accessible
Extension Installation and Configuration	Selection, installation, testing, and configuration of extensions suited to your wiki's requirements
Content Migration	Structured migration of existing content from Confluence, SharePoint, WordPress, DokuWiki, or other platforms
Security Hardening	File permissions, access control, HTTPS enforcement, two-factor authentication, anti-spam configuration
Performance Optimisation	Caching configuration (OPcache, APCu, Memcached), database tuning, job queue management
Ongoing Maintenance and Support	Core and extension updates, security patching, backups, and technical support

MediaWiki Setup and Server Configuration

A properly configured MediaWiki installation requires more than running the web installer. The setup decisions made at the start - URL structure, database configuration, file permissions, caching - directly affect security, performance, and how manageable the wiki is over time.

We handle every stage of the technical setup:

Linux server provisioning (Ubuntu Server LTS or equivalent)
PHP configuration with all required extensions
MariaDB or MySQL database setup with a dedicated wiki user and restricted privileges
MediaWiki installation and initial configuration via LocalSettings.php
Short URL configuration (clean /wiki/Page_Name URLs rather than query-string URLs)
HTTPS setup with a valid TLS certificate and HTTP-to-HTTPS redirect
File upload directory configuration with PHP execution disabled in the uploads path
Sitemap generation and robots.txt configuration for appropriate search engine indexing
Post-installation security hardening including file permissions and installer directory removal

The result is a wiki that is ready for real use from day one - not a default installation that requires further remediation before it is safe to put in production.

For technical background on the setup process, see "How to Install MediaWiki on Ubuntu Server".

Custom Skin and Branding

An out-of-the-box MediaWiki installation looks like every other unmodified MediaWiki site. For most organisations, a wiki that visually belongs to the brand - with the organisation's logo, colour scheme, typography, and navigation structure - produces meaningfully better editor adoption than a generic installation.

We build custom MediaWiki skins from the ground up using MediaWiki's SkinMustache base class and the ResourceLoader asset delivery system. Custom skin development covers:

Responsive layout matched to your brand guidelines
Logo, favicon, and colour scheme integration
Custom navigation structure - sidebar, top navigation, or combined
Typography configuration matching your organisation's typeface choices
Print-optimised stylesheet so pages produce clean printed output
WCAG 2.1 AA accessibility compliance including sufficient colour contrast and keyboard navigation

A custom skin is delivered as a standalone, versionable package that can be updated independently of MediaWiki core and extensions, keeping upgrade paths clean.

Extension Installation and Configuration

MediaWiki's extension ecosystem covers most functional requirements organisations have - visual editing, structured data, citations, notifications, authentication, search, and more - without requiring custom development. The challenge is selecting extensions that are actively maintained, compatible with the current core version, and configured correctly for the specific wiki.

We handle the full extension integration process:

Assessment of requirements and selection of appropriate extensions from MediaWiki's official directory
Compatibility verification against the current core and PHP version before installation
Installation and configuration, including all relevant LocalSettings.php settings
Testing in a staging environment before deployment to production
Documentation of installed extensions and their configuration for ongoing reference

Common extensions we configure for business and institutional wikis include:

Common Extensions for Business Wiki Deployments
Extension	Purpose
VisualEditor	WYSIWYG editing interface for non-technical editors, using the bundled PHP Parsoid library. See "VisualEditor Setup Guide".
Cite	Footnote and inline citation management with a rendered references section
WikiSEO	Per-page meta title, description, and Open Graph data for search engine optimisation
OATHAuth	Two-factor authentication via TOTP authenticator apps and hardware security keys
ConfirmEdit	CAPTCHA framework for account creation and link-adding to reduce spam
AbuseFilter	Rule-based automated detection and blocking of abusive editing patterns
CirrusSearch	Full-text search powered by Elasticsearch with relevance ranking
LDAPProvider and PluggableAuth	Enterprise single sign-on integration with Active Directory, Okta, Microsoft Entra ID, and other identity providers
CategoryTree	Hierarchical category navigation via an expandable tree interface
Echo	User notification system for page changes, mentions, and system alerts

Content Migration to MediaWiki

Moving an existing body of knowledge into MediaWiki - from Confluence, SharePoint, WordPress, DokuWiki, or any other platform - is rarely a simple import. Each platform stores content in a different format, and the structural differences between source and target require deliberate transformation rather than a direct transfer.

We manage the full migration process across four stages:

Content extraction. We export existing content from the source platform via API, database export, or structured export tools - preserving page text, metadata, file attachments, and where possible, the original authorship information.

Content transformation. Source content is converted into valid MediaWiki wikitext. This includes reformatting tables, converting inline formatting, restructuring headings, transforming internal links, and mapping source content types to appropriate MediaWiki namespaces. Conversion is done programmatically where volume permits and reviewed manually for complex or high-priority pages.

File and image migration. Uploaded files - images, PDFs, Office documents, and other media - are migrated to the wiki's File namespace with correct file metadata and updated in-page references.

Import and validation. Converted content is imported via MediaWiki's XML import system. Post-import validation checks for broken wikitext, missing files, malformed templates, and orphaned pages before the migration is considered complete.

We also handle URL redirect mapping so that links pointing to the old platform continue to resolve correctly after migration, preserving any established search engine indexing and avoiding broken links in existing documentation.

For an overview of the technical migration process, see "MediaWiki Database Maintenance Guide".

Security Hardening

A MediaWiki installation that has been set up but not hardened is a partially finished deployment. Several configuration steps that are not applied automatically by the installer are significant from a security perspective.

Our security hardening service covers the specific steps documented in MediaWiki's own security manual, applied to your installation:

File permission configuration: wiki directory owned by a non-web-server user, images directory correctly owned by the web server, LocalSettings.php set to not be world-readable
Removal of the installer directory after setup
HTTPS enforcement with HTTP Strict Transport Security headers
Canonical URL configuration to prevent credential interception on non-HTTPS requests
Database user privilege restriction to only the operations MediaWiki requires
Database bind address configured to reject external connections
Script execution disabled in the file upload directory
$wgSecretKey and $wgUpgradeKey set to strong, unique random values
Access control configuration: anonymous read and edit restrictions where required
OATHAuth two-factor authentication enabled for administrator accounts
Anti-spam extension stack: ConfirmEdit, AbuseFilter, SpamBlacklist, TitleBlacklist
PHP security settings verified: display_errors, expose_php, session.use_trans_sid

For the full technical reference, see "MediaWiki Security Hardening Guide".

Performance Optimisation

Most MediaWiki performance problems are caching configuration problems, not hardware problems. A correctly configured installation handles significantly more traffic than a default installation on the same server, without any change to the underlying infrastructure.

Our performance optimisation service applies the configuration recommended in MediaWiki's official performance tuning documentation:

PHP OPcache verification and tuning (bytecode caching)
APCu installation and configuration as the local object cache
Memcached or Redis installation and configuration for multi-server or high-traffic deployments
$wgMainCacheType and $wgParserCacheType configured appropriately for available server RAM
MariaDB InnoDB buffer pool sized to the actual data footprint of the installation
Job queue offloaded from web requests to a cron-based runner
ResourceLoader cache headers configured for appropriate browser-side caching
ImageMagick configured for image resizing in preference to the GD fallback

For wikis with substantial anonymous readership, we also configure Varnish or Nginx FastCGI caching to serve complete HTML responses to unauthenticated visitors without invoking PHP.

For the full technical reference, see "MediaWiki Performance Optimisation".

Ongoing Maintenance and Support

MediaWiki is actively developed software. New releases ship approximately every six months, with security patches issued more frequently. Extensions and skins require compatible updates. PHP versions reach end-of-life on a rolling schedule. An installation that is not actively maintained accumulates security risk and becomes progressively harder to upgrade.

Our maintenance service covers:

Core version upgrades, including running the database schema update script after each upgrade
Extension and skin updates, verified for compatibility with the current core version before deployment
PHP version upgrades as older versions reach end-of-life
Security release monitoring via the mediawiki-announce mailing list and prompt application of patches
Database maintenance: periodic export verification, index health, and buffer pool configuration review
Backup management: scheduled automated database dumps and file system backups, with transfer to off-site storage
Monthly maintenance reporting covering what was updated and the current state of the installation

Maintenance is available as a recurring plan or as individual engagements for installations that need specific work rather than ongoing coverage.

For the technical background on database maintenance, see "MediaWiki Database Maintenance Guide".

How We Work

We keep the engagement process straightforward.

Initial conversation. When you contact us, we ask a few questions to understand where you are starting from - a new deployment, an existing wiki that needs work, a migration from another platform, or something else. We explain what the work actually involves before anything is agreed.

Proposal and scope. We provide a written summary of what we will do, how long it will take, and what it will cost. We do not begin work before scope and cost are agreed in writing.

Delivery and handover. We deliver work in stages where the project permits, so you can review progress rather than waiting for a single final delivery. When the project is complete, we provide documentation of what has been installed and configured, and we make sure your team can navigate the wiki confidently before we close out.

Ongoing availability. After a project is complete, we remain available for follow-up questions, additional work, or a maintenance arrangement if ongoing support is needed.

We work with clients nationally and internationally, communicating clearly across time zones.

Why MediaWiki

MediaWiki is the platform we specialise in because it is the right tool for a specific and common organisational need: a large, structured, collaboratively maintained knowledge base where data ownership, long-term sustainability, and the absence of per-seat licensing costs are priorities.

It is not the right tool for everything. Organisations that primarily need a marketing website, a document management system, or a platform tightly integrated with a specific vendor ecosystem may be better served by other tools. We say this directly because choosing the wrong platform creates problems that only compound over time, and we would rather have that conversation upfront than deliver a setup that does not actually fit the need.

For the full assessment of when MediaWiki is and is not the right choice, see "What Is MediaWiki?" and "Best Wiki Software for Businesses".

Frequently Asked Questions

How do I start a project with SolidWiki?

The simplest first step is reaching out through solidwiki.com with a short description of what you are trying to build or fix. We will ask a few questions to understand your situation properly before giving you an honest assessment of scope, timeline, and next steps. There is no obligation involved in the initial conversation.

Do you only work with large organisations?

No. We work with organisations of all sizes - small teams building their first internal wiki, growing businesses that have outgrown informal documentation, universities and institutions managing structured reference content, and large enterprises deploying knowledge bases at scale. The scope of work adjusts to the project, not to the size of the client.

Can you take over maintenance of an existing wiki that was set up by someone else?

Yes. This is one of the most common situations we are brought in for. We assess the current installation - version, extensions, configuration, security state - and bring it to a properly maintained state before transitioning to ongoing maintenance. If the installation has drifted significantly behind current releases, we will be upfront about what the catch-up work involves before beginning.

How long does a new wiki deployment take?

A basic setup - server configuration, MediaWiki installation, HTTPS, short URLs, and production hardening - typically takes one to two days. A full project including custom branding, extension configuration, and content migration usually takes between two and eight weeks, depending on the complexity of the design requirements and the volume of content being migrated. We provide a realistic timeline estimate at the proposal stage.

What happens if we need to move to a different platform in the future?

MediaWiki stores all content in a standard relational database and supports XML export via its built-in import/export tools. Your content is not locked into a proprietary format. We can also assist with migration away from MediaWiki if your needs change, using the same migration approach we apply in the reverse direction.

Do you offer training for our editors and administrators?

Yes, as part of a project or as a standalone service. Editor training covers VisualEditor, basic wikitext conventions, page creation, and category management. Administrator training covers LocalSettings.php configuration, user management, permissions, extension maintenance, and backup procedures. Training is delivered as written documentation, recorded walkthroughs, or live sessions depending on preference.

Can MediaWiki be set up as a private wiki with no public access?

Yes. MediaWiki can be configured to require login before any content is accessible, with read and edit permissions controlled at user group and namespace level. See "MediaWiki Security Hardening Guide" for the relevant configuration details, or contact us to discuss the access control requirements for your specific deployment.

Is MediaWiki suitable for a wiki with thousands of editors?

Yes. MediaWiki scales to large editor populations without software licensing cost implications, since there are no per-seat fees. The same codebase runs Wikipedia and has been deployed in government and institutional contexts with many thousands of registered users. Infrastructure requirements grow with traffic and editor volume rather than with account count.

External Links