By MW in mediawiki — 29 Jun 2024

Streamlining Data Entry in MediaWiki with the Page Forms Extension

Why data entry in a wiki can feel like a hamster wheel

Ever opened a MediaWiki and thought, “There’s got to be a smoother way to get tables filled out?” You’re not alone. In many intranets the same page layouts pop up again and again—product sheets, incident reports, policy registries—yet the editors are stuck copy‑pasting wikitext, fiddling with brackets, and praying they didn’t miss a pipe. The result? Inconsistency, wasted time, and a backlog that looks like a line at the DMV.

Enter the Page Forms extension. It’s not magic, but it is a structured‑data lifeline that lets you freeze a template’s shape, hand users a friendly HTML form, and have the wiki fill in the blanks backstage. The next sections walk you through the mental gymnastics of planning your data, then the nuts‑and‑bolts of turning that plan into a form that actually works.

Step one: Sketch your data model before you code

Page Forms doesn’t read your mind; it reads the fields you declare. So before you touch a line of {{ markup, pause and ask yourself:

What kinds of pages will the wiki host? “Project”, “Ticket”, “Asset” are common categories.
Which properties belong on each page? Dates, usernames, status codes—list them out.
Are any of those properties repeatable? A ticket may have multiple “related tickets”.

Jot those questions down on a whiteboard or a sticky. In my last rollout for a research group, the list looked something like:

Project:
- Title (string)
- Lead (user)
- Start date (date)
- Funding amount (number)
- Tags (multiple string)

That “multiple string” bit is the clue that you’ll need a #array field later on.

Step two: Build the underlying template

Templates are the backbone. They turn raw form submissions into proper wiki pages. A minimal template for the “Project” example could look like this:


{{#if: {{{Title|}}}
 |'''{{{Title}}}'''
   Lead: [[User:{{{Lead|}}}]]
   Started: {{{Start date|}}}
   Funding: ${{{Funding amount|0}}}
   Tags: {{#arraymap:{{{Tags|}}}|,|{{{#1}}}}}
 |No data supplied.}}

Notice the {{#if}} guard at the top; it prevents an empty page from sprouting. Also, the #arraymap parser function is a handy shortcut for turning a pipe‑separated list into a comma‑joined string.

Step three: Define the form

Now the fun part: the #form tag. It tells MediaWiki to spit out a HTML form that mirrors the template’s fields. You can embed the form on any wiki page, or expose it via a URL using the #forminput parser function for a one‑liner link.


{{#form:
 |title=Create new Project
 |template=Project
 |fields=
   {{#field|Title|input type=text|label=Project title}}
   {{#field|Lead|input type=user|label=Project lead}}
   {{#field|Start date|input type=date|label=Kick‑off}}
   {{#field|Funding amount|input type=number|label=Budget}}
   {{#field|Tags|input type=textarea|label=Keywords (one per line)}}
 |new page title=Project:{{{Title}}}
}}

What’s happening? Each #field line maps a form input to a template variable. The “new page title” line tells the extension where to store the finished page. If you omit it, MediaWiki will ask the user for a name—a safety net, but usually you want to automate that.

Linking directly to a form: the #forminput shortcut

If you’re building a menu of quick‑entry links, the #forminput parser function is a neat one‑liner. Example:


{{#forminput:form=Create new Project|label=Add a project}}

That single line renders a button that pops up the same form you defined above. No need for an extra “Create Project” page just to host the form.

Fine‑tuning validation and user experience

Page Forms supports a handful of validation helpers:

#required – makes the field mandatory.
#exists – checks that a referenced page already exists.
#regex – runs a regular‑expression test against the input.

Here’s a snippet that forces a funding amount to be a positive integer:


{{#field|Funding amount|input type=number|label=Budget|default=0|validation=regex|regex=^[1-9]\d*$|validation error=Please enter a number greater than zero.}}

Notice the “validation error” flag: it shows a friendly message right in the form, avoiding the dreaded “Your edit was refused” pop‑up later on.

Querying the data you just collected

One of the biggest wins with Page Forms is that the same template fields become queryable via #ask or #show. Suppose you want a list of all projects started in 2023. A simple query page could contain:


{{#ask:
 [[Category:Project]]
 [[Start date::+2023-01-01..2023-12-31]]
 |?Title
 |?Lead
 |?Funding amount
 |format=ul
}}

Because the form populates the same properties that Semantic MediaWiki (SMW) indexes, you get a live report without writing any PHP.

Performance tips – don’t over‑index

Every extra field you turn into a property adds a line to SMW’s SPARQL store. For a wiki with thousands of tickets, that can slow down queries. A practical rule of thumb:

Only index fields you actually query against.
Group rarely‑used markup into a “metadata” template that stays hidden from SMW.
Run php maintenance/rebuildData.php after bulk imports to keep the store tidy.

Missing one of those steps once made our quarterly report take ten minutes instead of ten seconds. Not fun.

Common pitfalls and how to sidestep them

Below is a quick cheat sheet of things that bite newcomers:

Form and template name mismatch – The template= parameter must match the Template page name exactly, case‑sensitive.
Using reserved property names – Words like “Date” clash with SMW’s built‑in date parser; prefix with something unique, e.g., “Proj_date”.
Forgot to add the “Category” tag – Without it your new pages won’t appear in queries that filter by category.
Over‑relying on #array for large lists – For more than a dozen items, consider a separate sub‑page instead of a giant pipe‑separated string.

Real‑world example: a lightweight ticket tracker

At a midsize nonprofit we needed a simple way to log IT tickets without buying a SaaS product. Using Page Forms we rolled out the following:


{{#form:
 |title=New IT
 |template=Ticket
 |fields=
   {{#field|Ticket ID|input type=text|label=Ticket #|required}}
   {{#field|Reporter|input type=user|label=Reported by}}
   {{#field|Issue|input type=textarea|label=Problem description}}
   {{#field|Priority|input type=select|label=Priority|values=Low|Medium|High}}
   {{#field|Status|input type=select|label=Current status|values=Open|In progress|Resolved}}
 |new page title=Ticket:{{{Ticket ID}}}
}}

The accompanying Template “Ticket” included a [[Category:Ticket]] tag and a small table of the fields. After a week, the help desk manager could pull up a live list of all “Open” tickets with a single #ask query. No extra software, just a wiki that employees already knew how to edit.

Wrapping it up – the mindset shift

Think of Page Forms as a “bridge” not a “box”. It doesn’t replace a full‑blown database; it augments the collaborative nature of a wiki by giving non‑tech folks a guided way to enter structured information. When you pair it with Semantic MediaWiki you get a lightweight CMS that can power dashboards, catalogs, or even basic CRM functions.

If you’re still on the fence, ask yourself whether you’ve ever wished a wiki could stop “spilling” data across pages and start “collecting” it like a spreadsheet. The answer is almost always “yes”. The extension makes that wish achievable without a heavy server‑side rewrite.