ICT:MW new MediaWiki Blueprint: Difference between revisions
Created page with "= Blueprint for Organising the New MediaWiki Instance = This document provides a structured approach for building a clean, maintainable, successor-friendly MediaWiki installation dedicated to documenting the Drupal platform, the server environment, and operational procedures. The goal is to replace the experimental, Cargo-based wiki with a new, purpose-built documentation system that is clear, predictable, and easy to maintain. == 1. Purpose of the New Wiki == The new..." |
m Mngr moved page ICT:MW new MediaWIki Blueprint to ICT:MW new MediaWiki Blueprint without leaving a redirect |
(No difference)
| |
Latest revision as of 11:31, 3 April 2026
Blueprint for Organising the New MediaWiki Instance
This document provides a structured approach for building a clean, maintainable, successor-friendly MediaWiki installation dedicated to documenting the Drupal platform, the server environment, and operational procedures.
The goal is to replace the experimental, Cargo-based wiki with a new, purpose-built documentation system that is clear, predictable, and easy to maintain.
1. Purpose of the New Wiki
The new MediaWiki instance will serve as:
- A technical maintenance manual for Drupal
- A user documentation space for historians and editors
- A server operations manual (AlmaLinux, MariaDB, reverse proxy)
- A stable, structured knowledge base for long-term stewardship
It replaces the experimental wiki, which accumulated Cargo, PageForms, temporary namespaces, and unstructured pages.
2. High-Level Structure
The new wiki is organised around three pillars:
2.1 Technical Documentation (System Internals)
Covers:
- Drupal configuration
- Views, fields, display modes
- Custom modules and CSS overrides
- Multilingual configuration
- Asset architecture
- Maintenance workflows
2.2 User Documentation (Functional Use)
Covers:
- How historians use the system
- How to add/edit content
- How to attach assets
- How to use the publisher view
- How to navigate multilingual content
2.3 Server Documentation (Infrastructure)
Covers:
- AlmaLinux installation and updates
- MariaDB backup/restore
- Reverse proxy configuration
- Web server layout
- Deployment procedures
3. Namespaces
Namespaces provide top-level grouping. Suggested namespaces:
- Tech: – Technical implementation documentation
- Guide: – User-facing documentation
- Server: – Server and infrastructure documentation
- Admin: – Operational procedures, backups, deployments
These names are placeholders; choose names that fit your style.
4. Subpage Hierarchy (Pseudo-Folders)
Subpages create a clear, navigable hierarchy.
4.1 Technical Documentation
Tech/Overview Tech/ContentTypes/Places Tech/ContentTypes/Objects Tech/Views/RecordView Tech/Views/AssetChain Tech/Modules/CustomWidgets Tech/CSS/Overrides Tech/Multilingual/Configuration Tech/Permissions/Roles
4.2 User Documentation
Guide/Overview Guide/Editing/AddingRecords Guide/Editing/Assets Guide/Editing/Translations Guide/Publishing/RecordView
4.3 Server Documentation
Server/AlmaLinux/Installation Server/AlmaLinux/Updates Server/MariaDB/Backup Server/MariaDB/Restore Server/ReverseProxy/Configuration Server/Web/DirectoryLayout
4.4 Admin Procedures
Admin/Backup/Drupal Admin/Backup/MediaWiki Admin/Deployment/Drupal Admin/Deployment/Server Admin/Monitoring/Checks
5. Categories
Categories allow cross-cutting grouping across namespaces.
Suggested categories:
Pages can belong to multiple categories.
6. Page Template for Consistency
Use a standard template for all technical pages:
= [Page Title] = == Purpose == == Where Implemented == == Configuration Summary == == Dependencies == == Interaction With Other Subsystems == == Known Quirks == == How to Modify Safely == == How to Debug ==
This ensures clarity and successor-friendliness.
7. Migration Strategy
The old wiki remains online as an archive.
Migration steps:
- Identify important pages worth keeping.
- Copy/paste them into the new wiki.
- Rewrite them using the new structure and template.
- Discard Cargo/PageForms-specific content.
- Delete or ignore experimental pages in the old wiki.
This avoids contamination of the new clean structure.
8. Extensions to Install
Keep the new wiki minimal.
Recommended:
- SyntaxHighlight (for code/config snippets)
- CategoryTree (optional)
- VisualEditor (optional)
Avoid:
- Cargo
- PageForms
- Semantic extensions
9. Benefits of This Approach
- Clean, predictable structure
- Easy navigation via namespaces and subpages
- Clear separation between technical, user, and server documentation
- No legacy noise from early experiments
- Easy onboarding for future maintainers
- Documentation grows in a controlled, organised way
10. Conclusion
This blueprint provides a structured foundation for building a new, clean, long-term MediaWiki documentation system. It supports the survival of the Drupal platform, the server environment, and the operational knowledge needed to maintain them.