Page components/about

From Freephile Wiki
Revision as of 18:10, 6 December 2025 by Admin (talk | contribs) (add extensions section, describe BlueSpice)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

For a long time I've wanted to be able to package the "scaffolding" required to author beautiful pages in MediaWiki so that the first thing you do (as an author) is create content rather than to setup scaffolding. By scaffolding, I'm referring to all the things missing from MediaWiki like "help" namespace content, Templates (with a capital T), images and icons used in interface elements or general-purpose templates and other things that would be like a "Starter Kit" to make editing the first page easy. And it's not just scaffolding really. To continue the analogy of an 'unfurnished mansion', the Page Components system would come with a library of "furnishings" that a site administrator could pick and choose to make the site more "move-in ready": a cutting board and a block of knives, pots and pans, dinner ware, utensils in the kitchen, etc.

Disclaimer: I'm not an active editor in any wiki community so I'm sure I am lacking in the knowledge of how its done across various wiki communities.


Beginner experience in a new wiki[edit]

The out of the box experience is that you need to first create (a lot) of templates and come up with your own system for authors to follow. - especially if you want new authors to take advantage of the stuff MediaWiki has under the covers. Simple built-in facilities like 'collapsible' sections, or 'sortable' tables require knowledge since they are not immediately visible in some "quick reference" editor's handbook but rather "buried" in the enormous reference that is mediawiki.org's Help[1]. It is obviously great that the enormous reference exists, but the goal here is to find good ways to surface the most common editor tools in a way that doesn't require a deep dive or training on wiki syntax, Template syntax, parser functions, Vue.js, CSS, Lua scripting, or other technologies.

Goals[edit]

Adding a bit of focus and resolution to the goal at hand, we can look at something like the HarvardSites Design System (HarvardSites is their Drupal CMS offering to the university community for building digital products. The "Design System" comes with HarvadSites.)

The HarvardSites Design System has (we want)

  1. 50/50 Card
  2. Accordion
  3. Button-Style Cards
  4. Call to Action Links
  5. Columns
  6. Hero
  7. List Component
  8. Quote Card
  9. Simple Table
  10. Stats Cards
  11. Tabs
  12. Vertical Cards

These are all more or less available in MediaWiki from Codex. For example, the various cards are just special cases or compositions of Codex Card. Actually Codex does a lot more. Here are the classes of components in Codex:

  • Buttons
    • Button
    • etc...
  • Form elements
    • Checkbox
    • ChipInput
    • Combobox
    • Field
    • Label
    • Lookup
    • MultiselectLookup
    • Radio
    • Select
    • TextArea
    • TextInput
    • ToggleSwitch
  • Content & data
    • Accordion
    • Card
    • Dialog
    • Menu
    • MenuItem
    • Popover
    • Table
    • Tooltip
  • Feedback
    • InfoChip
    • Message
    • ProgressBar
    • ProgressIndicator
  • Media
    • Icon
    • Image
    • Thumbnail
  • Navigation
    • Link
    • Tabs
    • Tab
  • Search
    • SearchInput
    • TypeaheadSearch

Stretch Goals[edit]

Create a re-usable Style Guide that is easy to tweak or re-write in an enterprise setting to make it easier to follow the best practice of having this content earlier rather than later. The Codex system is designed to be easily overridden so that it can be customized locally.


Current Solutions[edit]

As an administrator of a wiki or wiki farm, how does MediaWiki provide a good editing experience? What do we need to assemble to make it available in a particular wiki? Here are some of the current solutions available.

Codex[edit]

Codex is the design system in MediaWiki. Actually it is available to any project, and MediaWiki is the primary use case. Codex has components like accordion and card that can be used by Skin or Extension developers; and also in JavaScript. The components are for building usable, accessible, translatable applications.

Skin[edit]

The skin system using Mustache which allows designers to vary the wireframe of the presentation in the user interface while still incorporating all the elements required for a page.

One particular skin, Chameleon offers the concept of 'layouts' which is the wireframe of your site design. Here is the standard layout. Aside from the packaged layouts, you can create your own custom layout as well. Chameleon incorporates the BootStrap framework design system and coupled with the BootStrap Components extension allows for easy reuse of those components.

For most intents and purposes, Chameleon, BootStrap extension and BootStrapComponents extension gets you a MediaWiki site that goes a long way towards being design friendly right out of the box. With all the examples provided by ProWiki, you at least get a visual reference and a copy/paste starter kit - like this one for 'card'.

Templates[edit]

Templates are one fundamental building block in MediaWiki that allows for consistently presenting information. The prime example is the 'infobox' ubiquitous to Wikipedia articles. There are many "problems" with templates. The polished result found on Wikipedia is dependent on a huge number of interconnected templates, CSS style pages, and Lua modules - all of which are not available in a "starter pack" that would be suitable or easily customizable for a 3rd-party wiki.

The Wikipedia infoboxes use CSS pages and Lua modules for the presentation and functionality.

On a page like WWE Championship there are over 100 templates and modules in use such as:

  • Template:Infobox
  • Template:Infobox pro wrestling championship
  • Template:Infobox professional wrestling championship
  • Module:Infobox
  • Module:Infobox/styles.css
  • Module:InfoboxImage
  • Module:InfoboxImage/data

Gadgets[edit]

One of the first gadgets I ever used was wikEd by User:Cacycle, a tremendous enhancement for editors back in the days of FCKeditor when WYSIWYG editing was a big deal for all web products. In 2025 wikEd still offers features not included in CodeMirror and VisualEditor. In any case, other Gadgets such as mw:ProveIt for easier citations are indispensable but also "impossible" due to the litany of templates required that are not easily installed to a 3rd-party wiki. What Gadgets are recommended to enhance the out-of-the-box editing experience for 3rd-party wikis? This wikis gadgets are at Special:Gadgets.

Lua Modules[edit]

Extensions[edit]

Many extensions are distributed with MediaWiki, and many more are recommended/included with top distributions of MediaWiki. Probably BlueSpice is the only distribution which actually has comprehensive documentation and a demo site on how to use the BlueSpice extensions making it a true SaaS product.

SemanticMediaWiki[edit]

SemanticResultFormats takes structured data and presents it in a multitude of compelling ways. SRF sits between structured data, and presentation. At the highest level, Page Components could allow for composability of SRF into a final page layout and visual presentation.

Page Forms[edit]

say something

Page Exchange[edit]

Page Exchange is a mechanism for publishing and syndicating wiki content plus the scaffolding that puts it all together - with an emphasis on the templates and functionality. Page Exchange uses the term packages. An example is the SkillsMatrix package.

Past Efforts[edit]

Central repository for gadgets, templates and Lua modules is tracked in the mega ticket phab:T121470 from 2015 which further relies on major efforts like "shadow namespaces" phab:T91162 and Global gadgets phab:T153332

  1. https://www.mediawiki.org/wiki/Help:Contents is the main page for Help and is actually quite good. Many wikis simply link to that page as their local wiki's "help".

Help Namespace Content[edit]

Starting a wiki without any Help namespace content is bad. Of course you can point to MediaWiki.org for the canonical, definitive, community collaborative Help that is always up-to-date - and you should encourage local wiki users to contribute there. But there should be a solution for populating some of the most basic pages. The shadow namespace effort stalled years ago. This wiki imported 50 or so pages to get started. It's a real "chicken and egg" problem. The canonical help references practices which are not available to a local wiki editor if you do not have some basic utility templates for highlighting, creating "pretty tables" and other referenced help content.