Integrating GPT‑4 into MediaWiki: A Step‑by‑Step Guide

Large language models can turn a MediaWiki installation into an editing assistant: summarize discuss pages, draft wikitext, suggest categories or answer questions grounded in wiki content. But the integration pattern matters more than the model: if the API key or the conversation can be manipulated by wiki users, the feature becomes a cost hole and a content-integrity risk. This guide covers a safe, server-side integration approach, the operational guardrails, and the real projects worth knowing about.

Design constraints first

• The API key stays on the server. Never ship the key to the browser — a client-side integration lets any visitor burn your quota and possibly exfiltrate prompts
• The wiki's content rules apply. Generated text becomes wiki content: it must be reviewable, attributable and removable like any edit
• Costs scale with usage. An assistant that any logged-in user can call is a metered service; decide the budget and enforce it server-side

Architecture

The minimal safe shape: an extension exposes a special page or API module; the PHP code calls the model provider server-side; the response is returned for review, not auto-published. A skeleton for the API module:

// Get the secret from configuration, never from the client
$apiKey = $config->get( 'MyLlmApiKey' );

$body = [
    'model'    => 'gpt-4o',
    'messages' => [
        [ 'role' => 'system', 'content' => 'You convert plain English into wikitext. Be concise.' ],
        [ 'role' => 'user', 'content' => $userPrompt ],
    ],
    'max_tokens' => 1000,
];

$res = $http->post(
    'https://api.openai.com/v1/chat/completions',
    [
        'headers' => [
            'Authorization' => 'Bearer ' . $apiKey,
            'Content-Type'  => 'application/json',
        ],
        'body' => json_encode( $body ),
    ]
);

Use MediaWiki's HTTP service (HttpRequestFactory injected via service wiring) rather than raw curl, and store the key with the rest of the configuration (LocalSettings.php or a secret file outside the document root). Add a simple rate limit via MediaWiki's $wgRateLimits-style per-user throttling in your module.

Grounding the model in wiki content

LLMs without context hallucinate; with context they are useful. The dependable pattern is to fetch real page content first and include it in the prompt:

1. Accept a page title from the user
2. Load the page text server-side (e.g. WikiPage::getContent or the REST page/html endpoint)
3. Constrain the prompt to that content — "summarize the attached page", "rewrite this section in simpler language"
4. Optionally run a search (Special:Search API) to assemble a small context corpus before asking

This turns the assistant from a general text model into a wiki-aware tool, and keeps the wiki as the source of truth.

Guardrails

• Moderation — pass user prompts through the provider's moderation endpoint or add server-side filters; a wiki assistant is a public prompt-injection surface, and page content used as context can be adversarial
• Attribution — mark generated content clearly (e.g. a template like {{Generated by AI}} or a change tag) so reviewers and readers know what they are looking at
• Licensing — model output is not necessarily wiki-license compatible out of the box; check the provider's terms and your wiki's content license before auto-accepting longer outputs
• Cost caps — per-user quotas, max tokens per request, and a hard monthly ceiling at the provider account level

Existing projects and alternatives

Before building your own, look at what the ecosystem already ships (all experimental-grade as of 2026):

• WikiRAG — retrieval-augmented generation against wiki content
• Wanda (Wikimedia Deutschland) — an experimental assistant UI prototyping Wikipedia-integrated chat
• Client-side helpers such as AutoLlmsTxt serve machine-readable content to AI tools — a complement, not a replacement

None of these are stable production software yet; plan for your own thin, reviewable integration with the architecture above. Keep the scope small — one special page, one API call, clear output — and the feature will be maintainable where grander designs rot. The extension development manual is the reference for the surrounding plumbing (service wiring, API modules, i18n).