Costa Sano MediaWiki – System Strategy and Architecture

Purpose of this document

This page explains the design philosophy and architectural strategy of the Costa Sano information system.

It answers:

Why MediaWiki?
Why namespaces?
Why Cargo + PageForms?
Why dashboards?
Why virtual machines?
Why this structure?

Future maintainers should understand the reasoning, not only the configuration.

The system was designed for:

long-term stability
low cost
easy maintenance
non-technical users
independence from vendors

Core Principles

1. Simplicity over cleverness

The system must be:

boring
predictable
repeatable

Clever or fashionable solutions were deliberately avoided.

Boring systems survive longer.

2. Open-source only

No paid licenses or vendor lock-in.

Reason: The club must survive with a limited budget.

All core components are:

MediaWiki
MariaDB
Apache
Linux

These are mature, stable, and free.

3. Separation of concerns

Each tool has a clear responsibility.

MediaWiki → structured knowledge system
Cargo → structured data storage
PageForms → data entry
WordPress → public publication
Virtual machines → isolation and portability

Trying to make one tool do everything was intentionally avoided.

System Layers

The system is organised in layers. Each layer is independent.

Layer 1 – Hardware

Standard PC/server hardware.

No special requirements.

Must be easily replaceable.

Layer 2 – Virtualisation

Hyper-V today, possibly Proxmox/Linux in future.

Reason:

hardware independence
easy migration
easy backup
easy recovery

VMs are copied, not rebuilt.

Layer 3 – Operating System

Linux (AlmaLinux) preferred for long term.

Reason:

no licenses
stability
low resource usage
long lifetime

Layer 4 – Web stack

Apache + PHP + MariaDB

Classic LAMP stack.

Reason:

extremely stable
widely documented
easy for successors
works everywhere

Layer 5 – Application

MediaWiki with extensions:

Cargo
PageForms
Lockdown

Reason: Transforms MediaWiki from a wiki into a structured database application.

Why MediaWiki

MediaWiki was chosen because it is:

mature (20+ years)
widely used
low resource requirements
open source
very extensible
future-proof

Important: The goal is not a modern fancy UI. The goal is durability.

MediaWiki is ideal for long-term knowledge preservation.

Why Cargo + PageForms

Cargo

Adds database tables and structured queries.

Provides:

typed fields
SQL-like queries
fast reports
clean data model

PageForms

Adds:

forms
validation
controlled data entry
no wiki syntax for users

Together they transform MediaWiki into: → a lightweight database application.

Why namespaces

Namespaces are used for both organisation and security.

Structure

Research: → dashboards and UI
Chapter:, Place:, Organisation:, Asset: → data
ICT: → documentation

Benefits

clean separation
easier permissions
users never see technical pages
simpler navigation

Users should only work in Research:.

Why dashboards

Users never use:

Special pages
raw wiki editing
manual page creation

Instead they use:

dashboards
buttons
forms

Reason: Club members are not IT specialists.

The system must behave like a normal application.

Design Workflow Pattern (for each entity)

Each entity follows exactly the same pattern:

Template with #cargo_declare
PageForms form
Dashboard page
#formlink for editing
returnto dashboard

This pattern must be reused without redesign.

Consistency is more important than optimisation.

Architectural Philosophy

The system was designed with the mindset:

survives hardware failure
survives maintainer change
survives budget constraints
survives 5–10+ years

Technology choices were guided by longevity, not trendiness.

If unsure, always choose: → simpler and older technology