Ideas not yet built, practical and speculative alike.
Right now a new article always starts blank. Offer a starting-point picker when creating an article:
- Blank — today's behavior, an empty edit form.
- Generic (Wikipedia-style) — pre-fill the message body with a common
encyclopedia-article skeleton (e.g. an intro paragraph placeholder,
Overview,History,Referencessection headings) so new articles don't start from a truly empty box.
The template picker lives on the edit page itself (not the overview page's quick-create box, which still just takes you straight to a blank edit form and lets you pick there).
Templates are admin-configurable: admins can add new templates beyond the built-in "Blank" and "Generic" ones, via an ACP page.
Still needs deciding before implementation:
- What a template is allowed to contain (plain text with placeholders? BBCode? anything the message parser accepts?) and how that's authored in the ACP form.
- What sanitization that admin-authored template content needs before it's inserted into the edit form's message body — it's admin-authored rather than end-user input, but still ends up in content regular members see and can build on, so it shouldn't get a free pass on the same checks normal article content goes through.
The article_toc column has existed in the schema since early on, but
wiki/edit.php always inserts an empty string into it and nothing anywhere
reads it — it's scaffolded and abandoned. Finish it: auto-generate a TOC
from the article's heading structure and render it at the top of the
article (likely only worth showing past some minimum heading count, so
short articles don't get a token one-entry TOC).
A lightweight [[Article Title]]-style shortcut (MediaWiki's signature
syntax) instead of requiring a full [url=...] BBCode every time you want
to link one article to another. Would need a custom BBCode or a message-parse
step that resolves [[...]] to the right article URL, including handling
the "target article doesn't exist yet" case (MediaWiki renders those as a
distinct "red link" style).
The URL slug is fixed forever once an article is created — only the title
can change. There's no way to rename a page's URL while keeping its version
history attached; today that means manually recreating the article under a
new URL and losing the connection to its history. Needs a "move" action
(permission-gated, presumably u_wiki_set_redirect-adjacent or its own new
permission) that renames article_url across all of an article's versions
and optionally leaves a redirect stub at the old URL.
The existing notification type only fires for "pending approval" (aimed at moderators). Regular readers have no way to ask "notify me when this specific article changes" the way forum topic-watching works. Would need a second notification type plus a subscribe/unsubscribe action on the article view page.
Browsing is flat today — Popular/Latest/All/Sticky/Pending on the overview page, nothing that groups articles by topic. Would need a taxonomy (even a simple one-tag-per-article model to start) and a browse-by-category view.
Confirmed: wiki content is not in phpBB's board search at all. Checked
both ways — no search-related code anywhere in the extension, and live on
the test board, searching for a word that only exists in a live, approved
article's text ("trivial", from "Getting Started") returns zero matches.
wiki_article is a non-standard table outside phpBB's normal post/topic
search index, so this isn't surprising, but it does mean articles are
currently undiscoverable except by browsing the overview page or already
knowing the URL.
Two ways to close this, not mutually exclusive:
- Hook wiki content into phpBB's existing search backends, so it shows up in normal board search alongside posts.
- A dedicated wiki-scoped search page/box, simpler to build but a second, separate search UI for members to learn.
Every wiki page right now is built from phpBB's forum-listing template
patterns — forumbg, topiclist, the same row/list markup a subforum
index uses (see overview.html, article_versions.html). It reads as "a
forum forced to hold wiki data," not as a wiki. Offer a genuinely
wiki-shaped presentation as an alternative: article-first layout (content
front and center instead of nested in forumbg/topiclist list rows),
sidebar-style navigation instead of listing everything as forum rows, more
MediaWiki-like article chrome in general.
A per-board style choice, set from an ACP page for this extension (admin picks "Forum-style" or "Wiki-style" for how the extension's own templates render) rather than ripping out the current look — some boards will prefer wiki content to visually match the rest of the forum, others will want it to look like an actual wiki. Scope depends heavily on the table of contents and internal wiki links items above landing first, since a real wiki layout wants both.
A chronological list of every edit/approval across all articles, not
just the newest one per article. "Latest Articles" on the overview page
only shows the most recent version per distinct article — it can't answer
"what changed on the wiki in the last day," which is the primary
navigation view on most real wikis. Worth pairing with an RSS/Atom feed
the same way the board already has feed.php for forum activity.
"Everything this user has edited or created," the way MediaWiki's
Special:Contributions works. Version history already shows a User column
per edit (see article_versions.html), but there's no page that rolls
that up per-user across every article — today you'd have to check every
article's version history individually to find a user's activity.
Permissions are board-wide today — u_wiki_edit either lets a user edit
any article or none of them. No way to lock down a specific
high-traffic/important article to a smaller group, the way MediaWiki
protects frequently-vandalized pages. Should be group-based: an
article-level setting naming which phpBB group(s) can edit it, checked in
addition to (not instead of) the existing u_wiki_edit permission —
falling back to "any group with u_wiki_edit" when no restriction is set
on a given article, so this is opt-in per article rather than a behavior
change for existing ones.
Nothing currently warns two people editing the same article at once — they'd just end up with two competing pending versions and no idea the other happened until they check the pending-approval queue. Even a simple "someone else started editing this article at HH:MM" notice on the edit form would help; phpBB's own posting flow has similar double-submission awareness to look at for the pattern.