Costa Sano MediaWiki - User contributions [en]

ICT:Wiki - Debugging

2026-05-14T16:55:06Z

Mngr: Mngr moved page ICT:Debugging to ICT:Wiki - Debugging without leaving a redirect

= Troubleshooting Philosophy for MediaWiki & Multi‑Layer Systems =

Maintaining this MediaWiki installation involves several interacting layers:

* IIS ARR (reverse proxy)
* Apache
* PHP-FPM
* MediaWiki
* ImageMagick
* SELinux
* Filesystem permissions
* Hashed upload directories
* Rewrite rules

When something breaks, it’s tempting to blame the most external or mysterious component — often the reverse proxy. This can lead to “ghost hunting”: chasing symptoms that look like proxy failures but originate elsewhere.

This page outlines a disciplined approach that avoids that trap.

== 1. Start with direct, observable facts ==

Before forming a hypothesis, gather concrete evidence:

* Can the file be read on disk?
* Does <code>curl -I</code> return a status code?
* Does Apache log the request?
* Does MediaWiki show a specific error?
* Does the file exist in the hashed directory?

This prevents assumptions from steering the investigation.

== 2. Test each layer independently ==

A multi-layer system fails in multi-layer ways. Always test each layer in isolation:

* '''Filesystem:''' <code>ls -lZ</code>, verify ownership and SELinux
* '''Apache:''' direct URL tests, static file serving
* '''Rewrite rules:''' confirm exceptions for static files
* '''MediaWiki:''' file page metadata, thumbnail generation
* '''ImageMagick:''' command-line conversion
* '''Reverse proxy:''' external vs internal URL behavior

This reveals where the failure actually occurs.

== 3. Avoid the “reverse proxy reflex” ==

Reverse proxies are often blamed first because they sit at the edge and feel like the “gatekeeper.”
But many failures originate deeper:

* Apache rewrite rules
* MediaWiki switching from GD → ImageMagick
* SELinux blocking read access
* PHP-FPM socket issues
* Incorrect <code>$wgUploadPath</code>
* Missing static-file exceptions

Only blame the proxy when evidence points there.

== 4. Prefer reproducible tests over assumptions ==

A single <code>curl</code> test can eliminate entire categories of hypotheses:

<pre>
curl -I https://mwiki.example.com/images/x/xy/file.png
</pre>

Interpretation:

* <code>200 OK</code> → routing works
* <code>404</code> → proxy or rewrite issue
* <code>403</code> → permissions or SELinux
* <code>500</code> → PHP/ImageMagick
* blank page → rewrite rule catching static files

This is faster and more reliable than guesswork.

== 5. Remember that MediaWiki changes behavior when ImageMagick is installed ==

This is a subtle but important point:

* With '''GD''', MediaWiki reads images directly from disk.
* With '''ImageMagick''', MediaWiki validates images via URL and MIME type.

This means:

* A misconfigured rewrite rule may be invisible under GD.
* The same misconfiguration becomes catastrophic under ImageMagick.

This explains why image failures sometimes appear “out of nowhere.”

== 6. Document the fix, not just the cause ==

Future admins benefit from:

* The symptom
* The root cause
* The exact fix
* The reasoning behind it

This prevents rediscovering the same issue years later.

== 7. Stay calm and methodical ==

The most important principle:

<blockquote>
'''Don’t let any single hypothesis dominate before the evidence supports it.'''
</blockquote>

This avoids tunnel vision and keeps the investigation grounded.

ICT:Wiki - Data Model and Media Architecture

2026-05-14T16:54:40Z

Mngr: Mngr moved page ICT:Data Model and Media Architecture to ICT:Wiki - Data Model and Media Architecture without leaving a redirect

= Data Modelling & Media Management Architecture =

This page documents the architectural decisions and working principles used for structuring data, relationships, and digital media in this MediaWiki installation.

It reflects conclusions reached during the design phase and serves as a reference for future development and maintenance.

== Purpose ==

The goal of this architecture is to:

* Support complex research data with many relationships
* Separate internal research work from public presentation
* Manage digital media (files, derivatives, metadata) in a controlled and scalable way
* Avoid schema drift and ad-hoc solutions
* Remain compatible with MediaWiki core and extensions

== Core Technologies ==

The system is based on the following components:

* '''Cargo''' – authoritative data storage (database schema)
* '''Page Schemas''' – page structure and data-entry UI
* '''Forms''' – controlled data input
* '''Namespaces''' – separation of concerns and access control
* '''File namespace''' – physical file storage (MediaWiki core)

Each component has a clearly defined responsibility.

== Authority and Responsibility ==

{| class="wikitable"
! Component !! Responsibility
|-
| Cargo tables || Define and own the database schema
|-
| Page Schemas || Define page types and map fields to Cargo
|-
| Forms || Control how editors enter data
|-
| Templates || Store data via Cargo
|-
| Database (MySQL) || Implementation detail only
|}

'''Important:'''
Database tables must '''not''' be created or modified directly in MySQL.
The Cargo table pages are the single source of truth for schema definition.

== Workflow Principle ==

The general workflow is:

# Design the model (DBML / diagrams)
# Create or update Cargo tables
# Activate Cargo tables by saving the Cargo page
# Create Page Schemas using the UI
# Generate forms
# Enter and test real data
# Iterate carefully

== Namespaces and Their Roles ==

Namespaces are used to separate concerns and control access.

{| class="wikitable"
! Namespace !! Purpose !! Visibility
|-
| (Main) || Public research results and narratives || Public
|-
| HO: || Structured Heritage Objects || Club members
|-
| DA: || Digital Asset metadata and relationships || Club members
|-
| File: || Physical file storage || Uploads restricted
|-
| ICT: || Technical and architectural documentation || Club members
|}

Namespaces must not be redefined.
The built-in '''File:''' namespace remains unchanged.

== File Management Strategy ==

MediaWiki’s file model is page-centric and limited for complex workflows.
To address this, a clear separation is enforced:

* '''File:''' pages store physical files only
* '''DA:''' pages store semantic metadata about digital assets

Digital Assets (DA) act as the central abstraction layer.

=== Internal vs Public Files ===

Not all files are equal:

* Internal files:
** High-resolution masters
** OCR outputs
** Working derivatives
* Public files:
** Curated, approved derivatives
** Downscaled or watermarked versions

Internal and public files are managed by convention, not by redefining namespaces.

== Upload Permissions ==

* Uploading files is restricted to club members
* Viewing files remains public (to support public pages)
* Editors must ensure that only approved files are embedded on public pages

Public pages must never depend on internal-only files.

== Digital Assets (DA) ==

A '''Digital Asset''' represents a conceptual media object and may reference:

* One or more File: pages
* A parent Digital Asset (for derivatives)
* One or more Heritage Objects

DA pages are internal and never directly exposed to the public.

== Handling Many-to-Many Relationships ==

Relational join tables from the original data model are implemented as:

* '''Cargo subtables'''
* '''Repeatable sections in Page Schemas'''

Example use cases:
* Object–Person relationships
* Object–Set memberships
* Provenance chains

This avoids page explosion and keeps relationships contextual.

== Page Schemas vs Cargo Tables ==

Cargo tables may be created in two ways:

* Manually (Cargo-first)
* Via Page Schemas UI (UI-first)

In both cases:

* The Cargo table page must be saved manually to activate the database table
* Page Schemas do not execute database changes automatically

For complex, stable models, a Cargo-first approach is preferred.

== Design Principles ==

The following principles guide all future development:

* Cargo owns structure, Page Schemas own usability
* Internal complexity is allowed; public simplicity is required
* Publication is a controlled act, not a permission toggle
* Add fields freely; rename or remove fields carefully
* Prefer conventions over hacks
* Avoid direct database manipulation

== Status ==

This architecture is considered the current baseline.

Changes must be documented and reviewed before implementation.

ICT:Wiki - Dashboard help function

2026-05-14T16:46:33Z

Mngr: Mngr moved page ICT:Dashboard help function to ICT:Wiki - Dashboard help function without leaving a redirect

= Dashboard Help System – Implementation Guide =

== Purpose ==

This page explains how dashboard pages provide integrated user help.

Goal:

* guide club members directly inside the system
* explain what each dashboard is for
* avoid separate manuals or PDFs
* reduce mistakes during data entry

Help must be visible '''at the place where the user works'''.

== Design principles ==

The help system follows these rules:

* documentation is integrated, not external
* each dashboard has its own explanation
* help is easy to maintain
* help does not clutter the screen
* layout is identical on all dashboards

Technical approach:

* one help subpage per dashboard
* one reusable template
* transclusion into dashboard page
* collapsible display

== Structure ==

For every dashboard:

Dashboard:Chapter
Dashboard:Chapter/Help

Dashboard:Place
Dashboard:Place/Help

Dashboard:Organisation
Dashboard:Organisation/Help

etc.

Each dashboard has its own help subpage.

== Step 1 – Create the reusable template ==

Create:

Template:DashboardHelp

Content:

<pre>
<includeonly>
<div class="mw-collapsible mw-collapsed"
style="border:1px solid #ccc; padding:8px; margin-bottom:12px; background:#f8f9fa;">

'''ℹ️ Help – click to open'''

<div class="mw-collapsible-content">
{{{1}}}
</div>

</div>
</includeonly>
</pre>

Purpose:

* provides consistent styling
* provides collapsible behaviour
* keeps dashboards compact
* avoids repeating HTML everywhere

== Step 2 – Create a Help subpage ==

Example:

Dashboard:Chapter/Help

Typical content:

<pre>
== Purpose ==
Use this page to manage historical chapters.

== When to use ==
Create a chapter when you define a new historical period or theme.

== Examples ==
* CH01 – Early History
* CH02 – Interwar Period

== Do NOT use for ==
* buildings
* persons
* organisations
</pre>

Guidelines:

* keep short
* use examples
* avoid technical language
* focus on practical usage

== Step 3 – Include help in the dashboard ==

At the top of the dashboard page:

<pre>
{{DashboardHelp|{{/Help}}}}
</pre>

Explanation:

* {{/Help}} loads the subpage
* DashboardHelp wraps it in a collapsible box

Result:

User sees:

ℹ️ Help – click to open

Click → explanation appears.

== Why use subpages instead of writing help directly in the dashboard? ==

Advantages:

* separation of concerns
* easier editing
* cleaner dashboard source
* reusable template
* successors immediately understand structure
* documentation can be updated without touching logic

== Why collapsible? ==

Dashboards often contain:

* large tables
* many records
* frequent data entry

Permanent help text would push content down.

Collapsible:

* visible when needed
* hidden during work
* better UX

== Recommended writing style ==

Write for non-technical users.

Good:

* short sentences
* concrete examples
* “do this / do not do this”

Avoid:

* database terminology
* technical explanations
* long paragraphs

== Example complete dashboard ==

Dashboard:Chapter

<pre>
= Chapter Management =

{{DashboardHelp|{{/Help}}}}

{| class="wikitable sortable"
! Code !! Title !! Parent
{{#cargo_query:
tables=Chapters
|fields=_pageName,code,title,parent
|format=template
|template=ChapterRow
|named args=yes
}}
|}

{{#forminput:
form=Chapter
|namespace=Chapter
|button text=➕ New chapter
}}
</pre>

== Maintenance ==

When rules change:

1. edit only the /Help subpage
2. dashboards update automatically

No template changes required.

== Conclusion ==

This system:

* integrates documentation directly into the workflow
* improves usability
* reduces training effort
* prevents data entry mistakes
* keeps dashboards clean

This approach is recommended for all present and future dashboards.

ICT:Wiki - Dashboard autopurge architecture

2026-05-14T16:46:01Z

Mngr: Mngr moved page ICT:Dashboard autopurge architecture to ICT:Wiki - Dashboard autopurge architecture without leaving a redirect

= ICT: Dashboard Auto‑Purge Architecture =

This page documents why dashboards in this wiki require an automatic purge after saving a Page Forms form, why several intuitive approaches fail, and why the final solution works reliably.

== 1. The Problem ==

Dashboards such as '''Dashboard:Place''' display data stored in Cargo tables.
After saving a form, the updated Cargo data does not appear immediately because:

* Cargo updates are asynchronous
* MediaWiki caches parser output
* APCu/object cache may serve stale HTML
* Reverse proxies may cache responses
* Page Forms redirects do not trigger a purge

A reliable, automatic purge mechanism is required.

== 2. Why Simple Solutions Do Not Work ==

=== 2.1. HTML <meta> refresh ===
MediaWiki sanitizes <meta> tags, even inside <code><nowiki>#tag:html</nowiki></code>.
The tag is displayed as text and never executed.

'''Conclusion:''' HTML refresh cannot be used.

=== 2.2. Redirecting to <code>?action=purge</code> ===
A redirect to <code>?action=purge</code> always triggers MediaWiki’s confirmation dialog.
This dialog cannot be suppressed via GET requests.

'''Conclusion:''' GET‑based purge is never silent.

=== 2.3. Page Forms limitations ===
Page Forms does not provide hooks or callbacks that run after saving.
It cannot trigger a purge.

'''Conclusion:''' Page Forms cannot be used for purge logic.

=== 2.4. JavaScript redirect loops ===
Redirecting to <code>?action=purge</code> causes:

# Purge dialog
# Page reload
# JavaScript fires again
# Loop

'''Conclusion:''' Redirect‑based purge is unstable.

=== 2.5. Query parameters being stripped ===
Reverse proxies, skins, and canonical URL rewrites may strip unknown parameters such as <code>?purged=1</code>.
This prevents loop‑detection.

'''Conclusion:''' Only parameters MediaWiki preserves can be used.

== 3. Requirements for a Working Solution ==

A correct solution must:

* purge silently
* avoid loops
* work for all dashboards
* survive reverse proxies
* be centralized
* be successor‑friendly

== 4. The Final, Working Solution ==

=== 4.1. Purge via the MediaWiki API ===
Silent purge requires:

* POST request
* CSRF token
* API module

=== 4.2. Use a preserved query parameter ===
MediaWiki never strips parameters beginning with <code>mw_</code>.
We use:

<code>?mw_purged=1</code>

=== 4.3. Centralize logic in <code>MediaWiki:Common.js</code> ===
One place, all dashboards.

== 5. The Working Code (Common.js) ==

<syntaxhighlight lang="javascript">
$(function () {
const title = mw.config.get('wgPageName');

if (title && title.startsWith('Dashboard:')) {

// Only purge once
if (!location.search.includes('mw_purged=1')) {

new mw.Api().get({
action: 'query',
meta: 'tokens',
type: 'csrf'
}).done(function (data) {

const token = data.query.tokens.csrftoken;

new mw.Api().post({
action: 'purge',
titles: title,
token: token
}).always(function () {

// Reload the dashboard normally, marked as purged
const url = mw.util.getUrl(title, { mw_purged: 1 });
location.replace(url);
});
});
}
}
});
</syntaxhighlight>

== 6. Why This Works ==

=== Silent purge ===
* API POST + CSRF token
* No confirmation dialog

=== No loops ===
* <code>mw_purged=1</code> is preserved
* JS sees the marker and stops

=== Works for all dashboards ===
* Uses <code>wgPageName</code>

=== Infrastructure‑safe ===
* Survives reverse proxies
* Survives canonical URL rewrites
* Survives short URLs

=== Successor‑friendly ===
* One central rule
* No per‑page hacks

== 7. Architecture Diagram ==

The following ASCII diagram shows the complete flow from saving a form to the final dashboard refresh.

<pre>
+-----------------------+
| User saves form |
| (Page Forms) |
+-----------+-----------+
|
v
+-----------------------+
| Page Forms redirect |
| to Dashboard:XYZ |
+-----------+-----------+
|
v
+-----------------------+
| Dashboard loads |
| Common.js executes |
+-----------+-----------+
|
| JS checks:
| - Is this Dashboard:* ?
| - Is mw_purged=1 absent?
v
+-----------------------+
| Request CSRF token |
| via API (GET) |
+-----------+-----------+
|
v
+-----------------------+
| Silent purge via API |
| (POST + token) |
+-----------+-----------+
|
v
+-----------------------+
| Reload dashboard with |
| ?mw_purged=1 marker |
+-----------+-----------+
|
v
+-----------------------+
| Dashboard loads fresh |
| JS sees mw_purged=1 |
| -> No purge triggered |
+-----------------------+
</pre>

== 8. Summary ==

The final solution works because it respects all of MediaWiki’s constraints:

* Purge must be done via API POST
* CSRF token is required
* GET purge always shows a dialog
* Page Forms cannot trigger purge
* Unknown query parameters may be stripped
* Only <code>mw_*</code> parameters survive reliably

This produces a stable, silent, automatic purge mechanism for all dashboards.

== 9. Failure Mode Diagrams ==

The following diagrams illustrate each attempted solution, why it seemed plausible, and why it ultimately failed.
These are included so future administrators can immediately understand the architectural traps and avoid repeating them.

=== 9.1. Failure Mode 1 — HTML <meta> Refresh (Sanitized) ===

<pre>
+---------------------------+
| Dashboard page contains |
| <meta http-equiv="refresh">
+-------------+-------------+
|
v
+---------------------------+
| MediaWiki sanitizes HTML |
| <meta> is escaped |
| (displayed as text) |
+-------------+-------------+
|
v
+---------------------------+
| No refresh occurs |
| Dashboard stays stale |
+---------------------------+
</pre>

'''Reason for failure:'''
MediaWiki strips or escapes <meta> tags for security. They never execute.

---

=== 9.2. Failure Mode 2 — Redirect to ?action=purge (Confirmation Dialog) ===

<pre>
+---------------------------+
| JS redirects to |
| Dashboard:XYZ?action=purge
+-------------+-------------+
|
v
+---------------------------+
| MediaWiki shows dialog: |
| "Do you want to purge?" |
+-------------+-------------+
|
v
+---------------------------+
| User must click OK |
| (not silent) |
+---------------------------+
</pre>

'''Reason for failure:'''
GET-based purge always triggers a confirmation dialog.

---

=== 9.3. Failure Mode 3 — JS Redirect Loop ===

<pre>
+---------------------------+
| Dashboard loads |
| JS sees "not purged" |
+-------------+-------------+
|
v
+---------------------------+
| JS redirects to purge |
+-------------+-------------+
|
v
+---------------------------+
| Purge dialog appears |
| User clicks OK |
+-------------+-------------+
|
v
+---------------------------+
| Dashboard reloads |
| URL has no marker |
| JS thinks "not purged" |
+-------------+-------------+
|
v
+---------------------------+
| JS redirects again |
| (infinite loop) |
+---------------------------+
</pre>

'''Reason for failure:'''
The dashboard reloads without a marker, so JS purges again.

---

=== 9.4. Failure Mode 4 — Query Parameter Stripping ===

<pre>
+---------------------------+
| JS reloads dashboard with |
| ?purged=1 |
+-------------+-------------+
|
v
+---------------------------+
| Reverse proxy / skin |
| strips unknown parameter |
| (purged=1 removed) |
+-------------+-------------+
|
v
+---------------------------+
| Dashboard loads as |
| Dashboard:XYZ |
| (no marker) |
+-------------+-------------+
|
v
+---------------------------+
| JS purges again |
| (loop) |
+---------------------------+
</pre>

'''Reason for failure:'''
Unknown parameters like <code>purged=1</code> are removed by canonical URL rewriting.

---

=== 9.5. Failure Mode 5 — API Purge Without CSRF Token ===

<pre>
+---------------------------+
| JS calls API purge |
| without CSRF token |
+-------------+-------------+
|
v
+---------------------------+
| MediaWiki rejects purge |
| "badtoken" or "permission"|
+-------------+-------------+
|
v
+---------------------------+
| Dashboard reloads |
| still stale |
+-------------+-------------+
</pre>

'''Reason for failure:'''
MediaWiki requires a CSRF token for all write operations, including purge.

---

=== 9.6. Failure Mode 6 — API Purge Works, But Loop Continues ===

<pre>
+---------------------------+
| JS purges via API |
| (correct) |
+-------------+-------------+
|
v
+---------------------------+
| JS reloads dashboard with |
| ?purged=1 |
+-------------+-------------+
|
v
+---------------------------+
| Skin / proxy strips |
| ?purged=1 |
+-------------+-------------+
|
v
+---------------------------+
| Dashboard loads without |
| marker |
+-------------+-------------+
|
v
+---------------------------+
| JS purges again |
| (loop) |
+---------------------------+
</pre>

'''Reason for failure:'''
Even with correct API purge, the loop persists if the marker is stripped.

---

=== 9.7. Final Working Architecture (for comparison) ===

<pre>
+---------------------------+
| Dashboard loads |
| JS executes |
+-------------+-------------+
|
| JS checks:
| - Is Dashboard:* ?
| - Is mw_purged=1 absent?
v
+---------------------------+
| Request CSRF token |
| via API (GET) |
+-------------+-------------+
|
v
+---------------------------+
| Silent purge via API |
| (POST + token) |
+-------------+-------------+
|
v
+---------------------------+
| Reload dashboard with |
| ?mw_purged=1 |
+-------------+-------------+
|
v
+---------------------------+
| Dashboard loads fresh |
| JS sees mw_purged=1 |
| -> No purge triggered |
+---------------------------+
</pre>

'''Reason for success:'''
<code>mw_purged=1</code> is preserved by MediaWiki, and API POST purge is silent.

ICT:Wiki - Choosing MediaWiki

2026-05-14T15:34:13Z

Mngr: Mngr moved page ICT:Choosing MediaWiki to ICT:Wiki - Choosing MediaWiki without leaving a redirect

= Why MediaWiki (and not Omeka-S or Zotero) =

This page explains the rationale for choosing MediaWiki as the technical platform for this project, instead of Omeka-S or Zotero.

It is intended for collaborators who are familiar with digital research tools but not with system architecture or MediaWiki extensions.

The goal is to provide sufficient context to understand later design documents without requiring technical expertise.

== Initial Context ==

At the start of the project, two existing platforms were considered:

* '''Zotero''' – for managing references and sources
* '''Omeka-S''' – for publishing cultural heritage collections

Both tools are well-established and widely used.

However, as the research progressed, it became clear that neither tool fully matched the needs of the project.

== What the Project Actually Requires ==

The project is not only about collecting items or references.

It requires the ability to:

* Describe complex historical objects at multiple levels
* Represent relationships between objects, people, places, and institutions
* Handle uncertainty and interpretation explicitly
* Structure research into overlapping periods or chapters
* Manage large numbers of digital files and derivatives
* Separate internal research work from public presentation
* Allow the data model to evolve over time

These requirements go beyond what a simple collection or bibliography system can provide.

== Limitations of Zotero ==

Zotero is excellent for:

* Bibliographic references
* Citation management
* Personal or shared libraries

However, Zotero:

* Treats items as flat records
* Has limited support for complex relationships
* Is not designed for narrative structuring
* Is not intended as a publication platform
* Cannot model historical entities beyond references

Zotero remains useful as a *supporting tool*, but not as the core research platform.

== Limitations of Omeka-S ==

Omeka-S is designed for:

* Publishing cultural heritage collections
* Describing items with metadata
* Linking items to vocabularies

However, Omeka-S:

* Assumes relatively flat “items”
* Is rigid once a data model is chosen
* Handles hierarchy and recursion poorly
* Does not support complex, evolving research structures well
* Makes it difficult to separate internal research from public publication
* Is less suitable for long-term exploratory research

Omeka-S is strongest when the structure is known in advance.
This project requires the structure to emerge through research.

== Why MediaWiki Was Chosen ==

MediaWiki is not a heritage platform by default.

Its strength lies elsewhere:

* It is concept-centric, not item-centric
* It supports gradual formalization
* It allows separation between content, structure, and presentation
* It scales well with complexity
* It supports collaborative knowledge building
* It can serve both internal and public audiences

Most importantly:

''MediaWiki allows the research model to evolve without locking decisions too early.''

== How MediaWiki Is Used in This Project (Conceptually) ==

MediaWiki is used as a **knowledge platform**, not just a wiki.

Conceptually, the system distinguishes between:

{| class="wikitable"
! Concept !! Meaning
|-
| Heritage Objects || What is being studied (buildings, places, concepts)
|-
| Digital Assets || How something is represented digitally
|-
| Actors || Who was involved historically
|-
| Research Chapters || How the research is structured narratively
|-
| Files || Physical digital files (images, scans, PDFs)
|}

These concepts exist independently of the technical implementation.

== Why Additional Components Are Needed ==

MediaWiki core handles pages and files very well.

However, it does not natively support:

* Structured data fields
* Repeating relationships
* Explicit modeling of uncertainty
* Querying structured relationships

For this reason, additional components are used internally.

These components are **implementation tools**, not concepts.

== Meaning of the Main Components (Non-Technical) ==

The following table explains the role of the main components without technical detail:

{| class="wikitable"
! Component !! What it does (conceptually)
|-
| MediaWiki || Provides pages, collaboration, and publication
|-
| Structured forms || Guide users when entering information
|-
| Structured storage || Ensures data is consistent and queryable
|-
| Internal documentation || Records design decisions and reasoning
|}

Collaborators are not expected to understand or manage these components directly.

== Internal vs Public Use ==

The system deliberately separates:

* Internal research work
* Public presentation of results

Internal work:
* May be incomplete
* May change
* May include uncertainty and discussion

Public content:
* Is curated
* Is stable
* Represents agreed results

This separation is difficult to achieve in Omeka-S or Zotero, but natural in MediaWiki.

== What This Means for Collaborators ==

For most club members:

* Interaction happens through forms
* Concepts are visible, not technical mechanisms
* No knowledge of MediaWiki internals is required
* The system behaves like a structured research environment

Architectural complexity exists only to support clarity and flexibility.

== How to Read the Other ICT Documents ==

The other ICT documents:

* Architecture
* Entity definitions
* ER model
* Workflow
* Policy

are written to ensure long-term consistency.

They are not manuals, but shared agreements.

This page should be read first to understand the context in which those documents exist.

== Status ==

This document explains the platform choice and conceptual approach.

It is intended to be stable and accessible to non-technical collaborators.

ICT:Wiki - Cargo and Page Forms Architecture Guide

2026-05-14T15:33:34Z

Mngr: Mngr moved page ICT:Cargo and Page Forms Architecture Guide to ICT:Wiki - Cargo and Page Forms Architecture Guide without leaving a redirect

= Cargo + Page Forms Architecture Guide =

== Purpose ==
This document explains the architectural principles used to build the Costasano Heritage system in MediaWiki.

The system uses:

* Cargo → structured data storage (database tables)
* Templates → schema definitions
* Page Forms → controlled data entry

We intentionally DO NOT use Page Schemas for production workflows.

----

== Core philosophy ==

MediaWiki is treated as:

Database + Forms + Pages

NOT as free-form wiki text.

We design like a relational application, not a document collection.

Goals:

* predictable behaviour
* explicit schemas
* enforced namespaces
* zero manual page naming
* minimal “magic”

Clarity beats automation.

----

== Responsibilities of each component ==

=== Cargo ===
Responsible for:
* storing structured data
* tables
* querying

Not responsible for:
* page creation
* validation
* UI

=== Templates ===
Responsible for:
* defining table structure using #cargo_store
* acting as schema definitions

Rule:
1 template = 1 Cargo table

=== Page Forms ===
Responsible for:
* creating/editing pages
* namespace enforcement
* page naming
* validation
* user experience

Forms control workflow.

----

== Standard stack ==

For every entity:

* Template
* Cargo table
* Form
* Namespace

Example:

DigitalAssets
Template:DigitalAsset
Form:DigitalAsset
Namespace: DA

----

== Why not Page Schemas? ==

Page Schemas lacks:

* enforced namespaces
* automatic page names
* strict workflow control
* flexibility

It is useful for learning, but too limited for production systems.

----

== Design principles ==

* explicit > implicit
* simple > clever
* small steps > big generation
* manual control > hidden automation

If something feels magical, redesign it.

ICT:Wiki - Cargo and PageForms

2026-05-14T15:33:15Z

Mngr: Mngr moved page ICT:Cargo and PageForms to ICT:Wiki - Cargo and PageForms without leaving a redirect

== Cargo and Page Forms Implementation Guide (2026) ==

This guide explains how to set up a structured data system using the '''Cargo''' and '''Page Forms''' extensions in MediaWiki 1.45.

=== 1. The Data Schema (Template:Book) ===
The template is the "brain" of the operation. It declares the database structure and stores the data when a page is saved.

'''Path:''' [[Template:Book]]
<pre>
<noinclude>
{{#cargo_declare:
_table = Books
|Title = String
|Author = String
|Year = Integer
}}
This template is used to store book metadata in the Cargo database.
</noinclude>
<includeonly>
{{#cargo_store:
_table = Books
}}
{| class="wikitable" style="width: 300px;"
! Title
| {{{Title|}}}
|-
! Author
| {{{Author|}}}
|-
! Year
| {{{Year|}}}
|}
[[Category:Books]]
</includeonly>
</pre>

=== 2. The Input Interface (Form:Book) ===
The form provides a user-friendly way to fill out the template without touching wikitext. It also enables autocompletion from existing Cargo data.

'''Path:''' [[Form:Book]]
<pre>
{{{standard input|itemname|label=Book Page Title}}}

{{{for template|Book}}}
{| class="formtable"
! Book Title:
| {{{field|Title|mandatory}}}
|-
! Author:
| {{{field|Author|input type=combobox|cargo table=Books|cargo field=Author}}}
|-
! Publication Year:
| {{{field|Year|input type=number}}}
|}
{{{end template}}}

'''Summary of changes:'''
{{{standard input|summary}}}

{{{standard input|save}}} {{{standard input|preview}}} {{{standard input|cancel}}}
</pre>

=== 3. Activation Steps ===
After saving the pages above, you MUST perform these steps to activate the database:
# Go to [[Template:Book]].
# Click the '''"Create data table"''' (or "Recreate data") tab at the top.
# Click '''OK''' to initialize the SQL table.
# Go to [[Category:Books]] and add {{code|{{#default_form:Book}}}} to ensure the "Edit with form" button appears automatically.

=== 4. Querying the Data ===
To display the data stored in your "Books" table on any other page, use a Cargo query:

<pre>
{{#cargo_query:
|tables = Books
|fields = _pageName=Page, Title, Author, Year
|where = Year > 2000
|format = table
|display_columns = Page, Title, Author, Year
}}
</pre>

=== Resources ===
* [www.mediawiki.org Cargo Storing Documentation]
* [www.mediawiki.org Page Forms Definition Guide]

ICT:Wiki - Cargo Geo Coordinnates

2026-05-14T15:32:57Z

Mngr: Mngr moved page ICT:Cargo Geo Coordinnates to ICT:Wiki - Cargo Geo Coordinnates without leaving a redirect

== Handling Geographical Coordinates in Cargo ==

Geographical data is stored using the '''Coordinates''' field type. This allows for both precise database storage and interactive map displays using [[Extension:Page Forms|Page Forms]] and [[Extension:Cargo|Cargo]].

=== 1. Define the Cargo Table ===
In your table declaration, use the `Coordinates` field type.

<pre>
{{#cargo_declare:_table=Places
|Name=String
|Location=Coordinates
}}
</pre>

=== 2. Create the Input Form ===
Use the `leaflet` input type (part of [[Extension:Page Forms]]) to provide an interactive map where users can click to set coordinates.

<pre>
{{{field|Location|input type=leaflet|height=300|width=500}}}
</pre>

=== 3. Displaying Maps ===

==== Display a map for a single location ====
Use the `#cargo_display_map` function on the page itself to show where the specific place is located.
<pre>
{{#cargo_display_map:
|point={{{Location|}}}
|service=leaflet
|zoom=14
|height=400
}}
</pre>

==== Display all places on a master map ====
To show all entries from your `Places` table on one map, use a `#cargo_query` with a map format.
<pre>
{{#cargo_query:
|tables=Places
|fields=_pageName=Page, Name, Location
|format=leaflet
|height=500
}}
</pre>

=== Technical Note: Coordinate Format ===
* '''Storage''': Cargo stores coordinates as "Latitude, Longitude" in decimal degrees (e.g., `51.2194, 2.8972`).
* '''Precision''': Ensure you use a period (`.`) for decimals and a comma (`,`) to separate the two values.
* '''Services''': While `leaflet` is recommended for its ease of use, you can also use `googlemaps` or `openlayers` if they are configured on your wiki.

== Choosing a Map Service for Forms ==

To display a map in a form for coordinate input, use the `input type` parameter.

=== Option A: Leaflet (Recommended) ===
Uses OpenStreetMap. No API key required.
<pre>
{{{field|Location|input type=leaflet}}}
</pre>

=== Option B: OpenLayers (Default) ===
Solid open-source alternative.
<pre>
{{{field|Location|input type=openlayers}}}
</pre>

=== Option C: Google Maps ===
Requires a Google Maps API Key to be configured in your wiki's LocalSettings.php.
<pre>
{{{field|Location|input type=googlemaps}}}
</pre>

=== Common Parameters ===
You can customize the map's appearance in the form using these parameters:
* `height`: Height in pixels (e.g., `300`).
* `width`: Width in pixels (e.g., `500`).
* `starting bounds`: Initial map area if no coordinate is set yet (e.g., `-20,-15;50,55`).

=== Leaflet Troubleshooting ===
* '''Map not appearing:''' Ensure the `height` parameter is set (e.g., `height=400`).
* '''Marker not saving:''' Make sure you clicked the map to place the marker; simply zooming in won't store coordinates in the field.
* '''Search box:''' To add a search-by-address bar to your form map, add `|show search box` to the field parameters.

== Automating Place Data with Geocoding ==

The [[Extension:Maps|Maps extension]] provides the `{{#geocode:}}` function, which can automatically turn human-readable addresses into Cargo-compatible coordinates.

=== 1. Using Geocode in a Template ===
You can set up your template so that it accepts a "Street Address" but stores "Coordinates" in Cargo.

<pre>
{{#cargo_store:_table=Places
|Name={{{Name|}}}
|Location={{#geocode:{{{Address|}}}}}
}}
</pre>

=== 2. Using Geocode in a Query ===
You can also geocode "on the fly" to find distances or filter by location without having coordinates stored.
<pre>
{{#cargo_query:
|tables=Places
|fields=Name
|where=DISTANCE(Location, '{{#geocode:Brussels, Belgium}}') < 5000
}}
</pre>

=== 3. Configuration Tips ===
* '''Default Service:''' By default, Maps uses '''Nominatim''' (OpenStreetMap). This is free and requires no API key.
* '''Accuracy:''' Geocoding results depend on the external service. For high-volume wikis, results are cached to improve performance.
* '''Manual Overrides:''' Always provide a field for manual coordinates in case the auto-geocoding fails for a specific obscure location.

SearchBox
<pre>
{{{field|Location|input type=leaflet|show search box}}}
</pre>

== Research Documentation: Sanatoria of the Belgian Coast (1850–2026) ==

This research tracks the spatial and chronological evolution of tuberculosis (TBC) treatment centers for children.

=== 1. Cargo Table Structure ===
We use a specific table to link physical coordinates with historical time periods.

<pre>
{{#cargo_declare:_table=Sanatoria
|Name=String 
|HistoricalName=String 
|City=String 
|OpeningYear=Date 
|ClosingYear=Date 
|Location=Coordinates 
|Type=String 
}}
</pre>

=== 2. Mapping Historical "Existence" ===
To show where a sanatorium "was" during a specific historical period, use a query that filters by your year fields.

==== Example: Map of all sites active in 1920 ====
<pre>
{{#cargo_query:
|tables=Sanatoria
|fields=Name, Location, OpeningYear
|where=YEAR(OpeningYear) <= 1920 AND (YEAR(ClosingYear) >= 1920 OR ClosingYear IS NULL)
|format=leaflet
|height=500
}}
</pre>

=== 3. Historical Map Layers (Advanced) ===
Since modern OpenStreetMap didn't exist in 1850, you can overlay historical Belgian maps using WMTS services (e.g., from the NGI or AGIV).

In your Leaflet display, you can add a historical base layer:
* '''Vandermaelen (1846-1854):''' Useful for the start of your study period.
* '''Ferraris (1777):''' For pre-industrial coastal context.

<pre>
{{#cargo_display_map:
|point={{{Location|}}}
|service=leaflet
|layers=HistoricalBelgianMap 
}}
</pre>

=== 4. Research Notes on Coordinates ===
* '''Lost Buildings:''' If a sanatorium was demolished (e.g., many coastal villas during WWII), use coordinates from historical cadastral maps (Atlas der Buurtwegen).
* '''Accuracy:''' If the exact coordinate is approximate, document this in a "Notes" field so other researchers know the marker is an estimate.

=== Using Map Clustering ===
To keep the map clean when many sanatoria are close together, always add `|cluster=yes` to your queries.

<pre>
{{#cargo_query:
|tables=Sanatoria
|fields=Location
|format=leaflet
|cluster=yes
}}
</pre>

* '''Advantage:''' Improved performance and a cleaner user interface.
* '''Behavior:''' Clicking a cluster zooms the map automatically to reveal the individual markers.

ICT:Wiki - Cargo - Adding a New Entity/Table

2026-05-14T15:30:52Z

Mngr: Mngr moved page ICT:Cargo - Adding a New Entity/Table to ICT:Wiki - Cargo - Adding a New Entity/Table without leaving a redirect

= How to Add a New Entity/Table =

== Purpose ==
Step-by-step guide for adding new data entities to the system.

Follow this order strictly.

Do not skip steps.

----

== Step 1 – Update DBML ==
Add the table definition to the DBML model first.

DBML is the source of truth.

----

== Step 2 – Create template ==

Create:

Template:EntityName

Add:

<pre>
{{#cargo_store:
_table=EntityNames
|field1={{{field1|}}}
|field2={{{field2|}}}
}}
</pre>

Save.

----

== Step 3 – Create Cargo table ==

Go to:

Special:CargoTables

Click:

Recreate data

Verify table exists.

----

== Step 4 – Create form ==

Go to:

Special:CreateForm

Add:

* template
* fields
* target namespace
* page name formula
* hide title

----

== Step 5 – Test manually ==

Create one page.

Verify:

* page in correct namespace
* data stored
* queries work

Only then proceed.

----

== Step 6 – Add queries or lists ==

After structure works:

* Cargo queries
* lists
* reports

Never design UI before schema works.

----

== Checklist ==

Before marking complete:

[ ] template exists
[ ] cargo table created
[ ] form works
[ ] namespace enforced
[ ] page name automatic
[ ] test page saved
[ ] query returns data

If any box unchecked → fix first.

----

== Rule ==
Small working increments beat big automatic generation.

ICT:Wiki - Bullet Proof UI checklist

2026-05-14T15:30:25Z

Mngr: Mngr moved page ICT:Bullet Proof UI checklist to ICT:Wiki - Bullet Proof UI checklist without leaving a redirect

= Bullet-proof UI Checklist (MediaWiki / Page Forms) =

This page documents practical rules for designing robust,
low-error user interfaces in MediaWiki using Page Forms and Cargo.

The target users of the system are historians and domain experts,
not ICT specialists. The UI must therefore prevent mistakes by design,
not by training.

This checklist is based on real production observations.

----

== Core Principle ==

''If a user can make a mistake, eventually someone will.''

Therefore:
* Do not rely on user understanding
* Do not rely on documentation alone
* Encode rules directly into the form UI whenever possible

----

== 1. Prefer Guidance over Enforcement (v1 rule) ==

In early versions (v1):
* Guide users clearly
* Avoid complex enforcement logic
* Avoid JavaScript unless strictly necessary

Enforcement can be added later once behavior is understood.

----

== 2. Every Field Must Answer Three Questions ==

For each form field, the UI must make clear:

# What should I do here?
# What should I NOT do here?
# What happens after I do it?

If the UI does not answer these visually or textually,
the field is not safe.

----

== 3. Use Instructional Placeholders ==

Use placeholders to guide action and discourage typing
when typing is not intended.

Example:

<pre>
|placeholder=Click “Upload file” to select a file
</pre>

Good use cases:
* file uploads
* auto-generated values
* system-controlled fields

Placeholders are read before interaction and reduce errors.

----

== 4. Put Rules Next to the Field, Not in Documentation ==

Never rely on users reading separate documentation.

Rules must appear directly where the decision is made.

Example:

<pre>
<small>
Exactly one file must be uploaded for each Asset.
The file name cannot be changed afterwards.
</small>
</pre>

Short, explicit rules are preferred over long explanations.

----

== 5. Remove Wrong Affordances ==

Do not present UI elements that suggest the wrong action.

Examples:
* Avoid text inputs where free typing is not expected
* Prefer selectors, upload buttons, and controlled inputs

Do not “forbid” actions silently — avoid suggesting them visually.

----

== 6. Editable on Creation, Stable Afterwards ==

Many values should be decided once and then remain stable.

Use this pattern where applicable:

<pre>
|editifempty=yes
</pre>

Typical use cases:
* identifiers
* original file names
* source references
* archival metadata

This matches how archivists think:
''decide once, then preserve''.

----

== 7. Avoid Ambiguous Optionality ==

Avoid wording like:
* “optional”
* “if applicable”
* “you may leave empty”

Prefer explicit rules:

Bad:
<pre>
(Optional – leave empty if using Organisation)
</pre>

Better:
<pre>
Use either Place or Organisation, not both.
</pre>

Clear rules reduce hesitation and inconsistent data.

----

== 8. Separate Technical Identifiers from Human Labels ==

* Page names are technical identifiers
* Labels are human-readable and may change

Never expose technical identifiers unnecessarily in the UI.
Always display labels where possible.

This prevents:
* copying of technical IDs
* accidental misuse
* inconsistent conventions

----

== 9. No Silent Automation ==

If a value is generated automatically (now or in the future),
announce this clearly in the UI.

Example:

<pre>
<small>
This value is generated automatically by the system.
Do not try to change it manually.
</small>
</pre>

Users must understand when the system is in control.

----

== 10. Prefer Deterministic Storage ==

For v1:
* Prefer deterministic storage over strict typing
* Avoid race conditions between UI and storage
* Decouple user interaction from data persistence when necessary

Correctness is more important than elegance in early versions.

----

== Final Sanity Check ==

Before accepting a form field, ask:

# Can a user misunderstand this field?
# Does the UI invite the wrong action?
# Is the rule visible at the point of action?
# Is the value stable when it should be?
# Would a non-technical historian feel confident using this?

If any answer is “no”, improve the UI.

----

== Status ==

This checklist is considered **stable for v1**.
It will be extended when JavaScript-based enforcement
and v2 automation are introduced.

ICT:Wiki - Cargo-Workflow

2026-05-14T15:30:04Z

Mngr: Mngr moved page ICT:Cargo-Workflow to ICT:Wiki - Cargo-Workflow without leaving a redirect

= ICT:Cargo-Workflow – Final Working Configuration (Cargo + PageForms) =

This page documents the final, stable configuration for the postcard archive using Cargo and PageForms.
It contains the complete working setup in one place, ready for successors.

== 1) LocalSettings.php configuration ==

<pre>
# Cargo extension
$wgCargoDBtype = "mysql";
$wgCargoDBserver = "10.10.10.2";
$wgCargoDBname = "cargodb";
$wgCargoDBuser = "cargouser";
$wgCargoDBpassword = "Mhv+mak!90";
$wgCargoDBprefix = "";
$wgCargo24HourTime = true;

wfLoadExtension( 'Cargo' );

# PageForms extension
wfLoadExtension( 'PageForms' );
$wgPageFormsUploadableFiles = true;
</pre>

'''Important:'''
$wgPageFormsUploadableFiles = true; must appear ''after'' wfLoadExtension( 'PageForms' ).

----

== 2) Template:Item ==

This template defines the Cargo table and how each item page displays.

<pre>
<includeonly>
{{#cargo_declare:
_table=Items,
Title=String,
Image=File
}}

'''Title:''' {{{Title}}}

'''Image:''' [[File:{{{Image}}}|400px]]
</includeonly>
</pre>

Notes:
* Only the <includeonly> section is used by Cargo and PageForms.
* The Image field must be declared as File.

----

== 3) Form:Item ==

This is the form used to create new items.

<pre>
{{{info|page name=Item_<unique number>}}}
{{{for template|Item}}}

;Title
:{{{field|Title}}}

;Image
:{{{field|Image|input type=upload|uploadable}}}

{{{end template}}}

{{{standard input|save}}}
{{{standard input|cancel}}}
</pre>

Key points:
* The info directive '''must be the first line''' (no blank lines above it).
* input type=upload|uploadable enables the upload widget.
* Page names are automatically generated: Item_0001, Item_0002, …

----

== 4) AddItem page ==

This page provides a simple button for club members to add new items.

<pre>
== Add a new item ==

Click the button below to add a new item.

{{#formlink:form=Item|link text=➕ Add a new item|link type=button}}
</pre>

Users never see Special:FormStart and never choose page names.

----

== 5) BrowseItems page ==

This page shows all items in a gallery.

<pre>
== Browse Items ==

{{#cargo_query:
tables=Items
|fields=Title,Image
|format=gallery
|image size=200
}}
</pre>

Notes:
* tables=Items must be on its own line.
* All other parameters start with |.
* Produces a clickable gallery of all postcards.

----

== 6) Final User Workflow ==

Club members now follow a simple workflow:

# Go to '''Add a new item'''
# Click the button
# Fill in Title + upload an image
# Save
# The item appears automatically in '''Browse Items'''

No technical knowledge required.

----

== 7) System Status ==

The system now provides:

* A working Cargo table
* A working PageForms form
* Automatic page naming
* Working file uploads
* A clean Add Item button
* A gallery-style Browse page
* A stable foundation for future expansion

----

ICT:Wiki - Automatic Numbering

2026-05-14T15:29:18Z

Mngr: Mngr moved page ICT:Automatic Numbering to ICT:Wiki - Automatic Numbering without leaving a redirect

== ICT Documentation: Automatic Identifier Logic (Lua) ==

The `DigitalAssets` table uses a Lua script ([[Module:AssetIdentifier]]) to ensure unique, sequential numbering.

=== 1. Input Variables ===
The script requires three inputs from the [[Form:DigitalAsset]]:
* `chapter_id` (from ResearchChapters)
* `context_code` (from Places or Organisations)
* `sequence_number` (calculated automatically)

=== 2. Identifier Construction ===
The final ID is constructed using the pattern:
`[ChapterCode]-[ContextCode]-[Sequence]`
* Example: `CH01-OST-0001` (Chapter 1, Ostend, first asset)

=== 3. Maintenance Note ===
If a record is deleted, the `sequence_number` for that specific context will have a "gap." This is acceptable in archival practice to maintain the integrity of existing permalinks.

== ICT Documentation: Sequential Numbering (Lua) ==

To generate the `sequence_number` (e.g., 0007), the Lua module performs a Cargo query on the `DigitalAssets` table before the save is finalized.

=== 1. The Lookup Query ===
The script filters by `chapter_id` AND `context_code`:
<pre>
local results = mw.ext.cargo.query(
'DigitalAssets',
'sequence_number',
{
where = 'chapter_id = "' .. selectedChapter .. '" AND context_code = "' .. selectedContext .. '"',
order_by = 'sequence_number DESC',
limit = 1
}
)
</pre>

=== 2. Increment Logic ===
* If no records exist: `sequence_number = 1`
* If records exist: `sequence_number = results[1].sequence_number + 1`

=== 3. Format Padding ===
The number is always padded to 4 digits for visual consistency in the archive:
`string.format("%04d", sequence_number)`

ICT:WIKI - Architecture

2026-05-14T15:06:57Z

Mngr: Mngr moved page ICT:Architecture to ICT:WIKI - Architecture without leaving a redirect

= System Architecture =

This page describes the overall technical architecture of the MediaWiki installation used for heritage research and digital asset management.

It explains the roles of the main components and how they interact.

== Architectural Goals ==

The architecture is designed to:

* Support complex, relational research data
* Scale to many objects, persons, and digital assets
* Separate internal research work from public presentation
* Minimize future refactoring
* Remain compatible with MediaWiki core and extensions

== Layered Architecture ==

The system is structured in logical layers:

{| class="wikitable"
! Layer !! Component !! Responsibility
|-
| Presentation || Pages (Main namespace) || Public narratives and results
|-
| Structured Content || HO:, DA: namespaces || Internal structured entities
|-
| Data Entry || Forms (Page Schemas) || Controlled input
|-
| Schema Definition || Page Schemas || Mapping fields to storage
|-
| Data Storage || Cargo || Database schema and persistence
|-
| Physical Storage || File: namespace || Uploaded files
|}

Each layer has a single responsibility and must not take over the role of another layer.

== Core Components ==

=== Cargo ===

Cargo is the authoritative data storage layer.

* Defines database tables
* Controls field types
* Executes schema changes
* Stores normalized data

Cargo tables are defined on wiki pages (`Cargo:…`) and must be manually activated by saving the page.

=== Forms ===

Forms provide:

* Editor-friendly data entry
* Controlled creation of pages
* Enforcement of required fields
* Repeatable sections for relationships

Forms are the only supported way to create structured pages.

=== Namespaces ===

Namespaces separate concerns and enable access control.

Namespaces are structural and long-lived decisions.

== Files and the Digital Asset Abstraction ==

Digital Assets (DA) are metadata pages that represent conceptual media objects (files)

They abstract over:

* One or more files
* Derivatives
* OCR outputs
* Language versions
* Relationships to heritage objects

Files are never treated as data entities by themselves.

== Architectural Constraints ==

The following constraints apply:

* No direct database schema manipulation
* No semantic meaning stored only on File: pages
* No public dependency on private files
* No uncontrolled page creation in structured namespaces

== Status ==

This architecture is the baseline for all future development.

ICT:Wiki - Account protection

2026-05-14T14:38:32Z

Mngr: Mngr moved page ICT:Account protection to ICT:Wiki - Account protection without leaving a redirect

{{DISPLAYTITLE:Access Control: The "Lockdown" Model}}
__TOC__
== Philosophy ==
This wiki is a '''Private Research Platform'''. To simplify management, we avoid "blacklisting" individual default namespaces. Instead, we use a "White-room" approach: everything is forbidden by default, and access is granted only to the specific functional layers required for research.

== 1. Global Restrictions ==
Applied in `LocalSettings.php` to ensure the wiki is invisible to the public and restricted for standard users.

<syntaxhighlight lang="php">
# Full Privacy: Revoke read from all by default
$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['user']['read'] = false;

# Sysop Override: Ensure admins maintain full visibility
$wgGroupPermissions['sysop']['read'] = true;

# Essential Whitelist: Required for login and site rendering
$wgWhitelistRead = [
"Special:UserLogin",
"MediaWiki:Common.css",
"MediaWiki:Common.js"
];
</syntaxhighlight>

== 2. Research Environment Exceptions ==
Using [[Extension:Lockdown]], we grant the `user` group access to the specific namespaces required for the Dashboard, Cargo queries, and Page Forms.

<syntaxhighlight lang="php">
# Research Namespaces
$wgNamespacePermissionLockdown[NS_RESEARCH]['read'] = ['user', 'sysop'];
$wgNamespacePermissionLockdown[NS_DASHBOARD]['read'] = ['user', 'sysop'];

# Supporting Infrastructure (Required for Dashboard rendering)
# Researchers need 'read' access to these so templates and forms function.
$wgNamespacePermissionLockdown[NS_TEMPLATE]['read'] = ['user', 'sysop'];
$wgNamespacePermissionLockdown[NS_FORM]['read'] = ['user', 'sysop'];
</syntaxhighlight>

== 3. Page Forms & Cargo Interaction ==
The Dashboard utilizes `Template:EntityRow` for layout and queries the Cargo database.
* '''Note:''' If researchers can see the Dashboard but not the data results, ensure the Cargo-specific namespaces are also allowed.
* '''Editing:''' The `edit` permission is granted globally to the `user` group, but restricted by namespace via Lockdown.

== 4. Default System Accounts ==
* '''MediaWiki default:''' Internal system user. No password; no login allowed. Safe.
* '''Admin/Sysop:''' Full credentials required.

== Successor Notes ==
* '''Adding Entities:''' When creating a new Research Entity, ensure the associated Template and Form are placed in the permitted namespaces.
* '''Testing Access:''' Always test new Dashboard sections with a non-admin "Fellow" account to ensure no "Permission Denied" errors occur during template transclusion.

{{DISPLAYTITLE:User Experience & Stealth Configuration}}
__TOC__
== Strategy: Forbidden by Default ==
To prevent "clutter" and spying, the wiki uses a **Negative Lockdown** model. Users are explicitly denied access to all default MediaWiki namespaces.

== Configuration Implementation ==
=== 1. Namespace Stealth ===
The following namespaces are hidden from the Search bar and 'All Pages' list for standard members to prevent them from seeing technical infrastructure:
* {{ns:ICT}} (ID: 3000)
* {{ns:Template}} (ID: 10)
* {{ns:Form}} (ID: 106)

=== 2. Functional Access ===
Members are restricted to the following functional "Safe Zones":
* '''Dashboard:''' Entry point for all research.
* '''Research:''' The data repository.

=== 3. Maintenance Logic ===
Standard users (`group: user`) have had their global `['read']` permission revoked in [[LocalSettings.php]]. They only "see" what is explicitly whitelisted via the Lockdown extension.

== Successor Warning ==
If a researcher reports a "Broken Template" error (e.g., seeing raw {{...}} code), it usually means a new Template was created in a namespace that isn't yet whitelisted for the `user` group.

[[Category:ICT Documentation]]
[[Category:Security Operations]]

ICT:Wiki - Cargo - Adding a New Entity/Table

2026-05-14T14:37:55Z

Mngr: Mngr moved page ICT:Adding a New Entity/Table to ICT:Cargo - Adding a New Entity/Table without leaving a redirect

ICT:MWC/FinalConfig-Chapter

2026-04-13T09:01:02Z

Mngr: Mngr moved page ICT:MWC - FinalConfig-Chapter to ICT:MWC/FinalConfig-Chapter without leaving a redirect

= Final Configuration for the Chapter Entity =

Document revision: {{#time:Y-m-d|{{REVISIONTIMESTAMP}}}} by {{REVISIONUSER}}

The aim is to create an interface without MediaWiki clutter and well protected to avoid confusing users with unnecessary elements on the page.
The Cargo template follows what has been decided in the DBML and is fully aligned with the reference entities Place and Organisation.

The Chapter entity is structurally simple:
- it is recursive (parent chapter)
- it has no foreign keys to other entities

This entity serves as the reference for the simplest recursive pattern in the system.

This configuration deliberately favors explicit behavior and robustness over visual polish or implicit framework behavior, in order to ensure long-term maintainability.

= Cargo Table: =
Template:Chapter
<pre>
<noinclude>
Chapter data template
</noinclude>

{{#cargo_declare:
|_table=Chapters
|Code=Page
|Label=String
|Parent=Page
|Sequence=Integer
|Description=Text
|StartDate=Date
|EndDate=Date
|Notes=Text
}}

{{#cargo_store:
|Code={{FULLPAGENAME}}
|Label={{{Label|}}}
|Parent={{{Parent|}}}
|Sequence={{{Sequence|}}}
|Description={{{Description|}}}
|StartDate={{{StartDate|}}}
|EndDate={{{EndDate|}}}
|Notes={{{Notes|}}}
}}

== {{{Label|}}} ==
{{DISPLAYTITLE:{{{Label}}}}}

{{#if:{{{Parent|}}}|
'''Parent chapter:''' [[{{{Parent}}}]]
}}

'''Notes:'''
{{{Notes|}}}
</pre>

Once the template is created, the Cargo table must be created manually.
If modifications are made to the table structure, the table must be recreated and the temporary table swapped via the Cargo administration interface.

The field Code stores the full page name (including namespace) to ensure unambiguous identification.

Important conventions:
- Field names start with a capital letter
- Code is the page name and acts as the technical identifier
- Label is the human-readable name and is mandatory for all entities
- Parent is stored as a Page field
- The field name Label must not be renamed, as it is relied upon by shared JavaScript validation logic

Special lines at the bottom of the template:
<pre>
== {{{Label|}}} ==
{{DISPLAYTITLE:{{{Label}}}}}

{{#if:{{{Parent|}}}|
'''Parent chapter:''' [[{{{Parent}}}]]
}}

'''Notes:'''
{{{Notes|}}}
</pre>

These lines ensure that the human-readable name (Label) is consistently used as the visible page title, while the actual page name remains the stable technical identifier (Code).

This decoupling allows renaming the label without breaking Cargo relations or dashboards.

= Page Form: =
Form:Chapter
<pre>
<noinclude>
Form for creating and editing Chapter pages.
</noinclude>

{{{info
|no summary
|no preview
|no minor edit
|no watch
|no footer
}}}
''Fields marked with (*) are required.''

{{{for template|Chapter}}}

{| class="formtable"

! Code
| {{PAGENAME}}
|-

! Name (*)
| {{{field|Label}}}
|-

! Parent chapter
| {{{field|Parent
|input type=combobox
|values from namespace=Chapter
|placeholder=Top level (no parent)
}}}
|-

! Sequence
| {{{field|Sequence}}}
|-

! Description
| {{{field|Description|input type=textarea}}}
|-

! Start date
| {{{field|StartDate|input type=datepicker|year range=1800:2100|show year dropdown|show month dropdown}}}
|-

! End date
| {{{field|EndDate|input type=datepicker|year range=1800:2100|show year dropdown|show month dropdown}}}
|-

! Notes
| {{{field|Notes|input type=textarea}}}

|}

{{{standard input|save}}}

{{{end template}}}
</pre>

The first section avoids MediaWiki edit clutter.
<pre>
{{{info
|no summary
|no preview
|no minor edit
|no watch
|no footer
}}}
</pre>

The field Label (displayed to the user as “Name”) is mandatory for all entities.
This requirement is not implemented using the Page Forms |mandatory option, as this produces unusable white error boxes in the dark Vector-2022 environment.

Instead:
- the requirement is communicated via text and (*)
- enforcement is handled via JavaScript at save time

= Dashboard page =
Dashboard:Chapter
<pre>
= 📘 Costa Sano Research CHAPTER Dashboard =

📖 [[Dashboard:Chapter/Help|Need Help?]]

{| class="wikitable sortable"
! Code !! Name !! Parent
{{#cargo_query:
tables=Chapters
|fields=_pageName,_pageTitle,Label,Parent
|where=_pageNamespace=3004
|order by=_pageTitle
|format=template
|template=ChapterRow
|named args=yes
|cache=no
}}
|}

Choose your chapter code corresponding to above table and respecting the naming conventions.

{{#forminput:
form=Chapter
|namespace=Chapter
|button text=➕ New chapter
|returnto=Dashboard:Chapter
}}

<div style="text-align:right; font-size:90%;">
Last updated: {{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} – {{CURRENTTIME}} UTC
</div>
</pre>

IMPORTANT:
Dashboard tables are positional.
The number and order of:
- table headers
- Cargo query fields
- row template cells
MUST match exactly.

Only the first column (Code) is clickable and leads to the edit form.
All other columns are displayed as plain text to prevent navigation to record pages.

= Row transclusion Template =
Template:ChapterRow
<pre>
<includeonly>
|-
| {{#formlink:
form=Chapter
|target={{{_pageName}}}
|link text={{{_pageTitle}}}
|returnto=Dashboard:Chapter
}}
| {{{Label}}}
| {{#if:{{{Parent|}}}|{{#titleparts:{{{Parent}}}|1}}|—}}
</includeonly>
</pre>

Parent values are displayed as plain text (not links) to prevent users from navigating directly to record pages. All record editing is performed via forms accessed from the dashboard.

= Javascript =

The Chapter entity reuses the same shared JavaScript infrastructure as Place and Organisation:
- dashboard auto-purge
- save-time mandatory field enforcement (Label)
- no Page Forms |mandatory usage

No Chapter-specific JavaScript is required.

All Chapter pages are stored in the Chapter namespace with the page name acting as the Code.

Example:
<pre>
{{Chapter
|Label=In the beginning
|Description=Chapter describing what happened before Berck-sur-Mer...
|StartDate=1800-01
|EndDate=1849-12
|Notes=NIHIL
}}
</pre>

Such pages are configuration pages and must be accessed via the dashboard, not directly.

== References: ==

* [[mediawikiwiki:Extension:Cargo/Storing_data|Cargo table explanation]]
* [[mediawikiwiki:Extension:Page_Forms|Page Forms explained]]

[[Category:FinalConfig]]

ICT:MWC

2026-04-13T09:00:32Z

Mngr: Created page with "= Section for MediaWiki Cargo application = This application got stuck on the automatic numbering of the assests. Her the interesting pages about this application are collected."

= Section for MediaWiki Cargo application =

This application got stuck on the automatic numbering of the assests.

Her the interesting pages about this application are collected.

ICT:MWC/FinalConfig-Chapter

2026-04-13T08:43:33Z

Mngr: Mngr moved page ICT:FinalConfig-Chapter to ICT:MWC - FinalConfig-Chapter without leaving a redirect

IC:MW Talk Namespaces

2026-04-06T11:53:32Z

Mngr: Created page with "= Custom Talk Namespaces in MediaWiki = This document explains the purpose of Talk namespaces in MediaWiki, how custom Talk namespaces are defined, and why they only appear in the namespace list after specific configuration steps. == 1. Purpose of Talk Namespaces == MediaWiki separates *content* from *discussion* using paired namespaces: * Even-numbered namespace → content (e.g. <code>Network</code>) * Odd-numbered namespace → talk/discussion (e.g. <code>Network_Ta..."

= Custom Talk Namespaces in MediaWiki =
This document explains the purpose of Talk namespaces in MediaWiki, how custom Talk namespaces are defined, and why they only appear in the namespace list after specific configuration steps.

== 1. Purpose of Talk Namespaces ==
MediaWiki separates *content* from *discussion* using paired namespaces:

* Even-numbered namespace → content (e.g. <code>Network</code>)
* Odd-numbered namespace → talk/discussion (e.g. <code>Network_Talk</code>)

Talk namespaces serve several purposes:
* Keep content pages clean and factual.
* Provide a dedicated space for questions, decisions, and editorial notes.
* Preserve decision history for future maintainers.
* Support structured workflows (templates, categories, archiving).
* Allow experimentation and discussion without altering the main content.

Every content namespace should have a corresponding Talk namespace for long-term maintainability.

== 2. Why MediaWiki Does Not Auto‑Create Talk Namespaces ==
MediaWiki automatically creates Talk namespaces only for its built‑in namespaces (Main, File, Help, etc.).

For custom namespaces, MediaWiki does *not* assume a Talk namespace exists.
It will only register a Talk namespace when:

# A numeric ID is defined.
# A name is assigned in <code>$wgExtraNamespaces</code>.
# The ID is an odd number paired with the content namespace.

Until these conditions are met, the Talk namespace will not appear in:
* Special:SpecialPages → “Namespaces”
* Special:AllPages namespace dropdown
* API namespace lists

== 3. Defining a Custom Namespace Pair ==
A correct custom namespace definition looks like this:

<pre>
# --- Custom namespace: Network ---
define("NS_NETWORK", 3000);
define("NS_NETWORK_TALK", 3001);

$wgExtraNamespaces[NS_NETWORK] = "Network";
$wgExtraNamespaces[NS_NETWORK_TALK] = "Network_Talk";

# Optional: namespace shortcuts
$wgNamespaceAliases['N'] = NS_NETWORK;
$wgNamespaceAliases['N_Talk'] = NS_NETWORK_TALK;

# Optional: enable subpages
$wgNamespaceWithSubpage[NS_NETWORK] = true;
</pre>

=== Required elements ===
* <code>define("NS_NETWORK", 3000);</code>
* <code>define("NS_NETWORK_TALK", 3001);</code>
* <code>$wgExtraNamespaces[...]</code> entries for both

=== Optional but recommended ===
* namespace aliases
* subpage support

== 4. Why the Talk Namespace Appears Only After Full Definition ==
MediaWiki registers namespaces early during startup.
A Talk namespace will only appear when:

* Both the content and talk IDs are defined.
* Both names are assigned in <code>$wgExtraNamespaces</code>.
* The definitions are placed early enough in <code>LocalSettings.php</code>.

If the Talk namespace is defined later in the file, or after extensions that query namespaces, it may not appear until the next reload.

=== Rule of thumb ===
Place all custom namespace definitions **at the top of LocalSettings.php**, before loading extensions.

== 5. Namespace ID Pairing (Even/Odd Rule) ==
MediaWiki uses numeric pairing to link content and talk namespaces:

* Even ID → content namespace
* Odd ID → talk namespace
* The talk namespace must immediately follow the content namespace

Example:
* <code>3000 → Network</code>
* <code>3001 → Network_Talk</code>

If the pairing is broken, MediaWiki will not recognize the Talk namespace correctly.

== 6. Summary ==
* Talk namespaces store discussion, decisions, and editorial notes separate from content.
* MediaWiki does not auto-create Talk namespaces for custom namespaces.
* A Talk namespace appears only after proper definition (ID + name + pairing).
* Namespace definitions must be placed early in <code>LocalSettings.php</code>.
* Even/odd numeric pairing is essential for correct behavior.

This structure ensures clean content pages, clear editorial history, and a successor‑friendly wiki architecture.

ICT:MW Installation procedure 1.43 LTS -v2

2026-04-04T16:11:05Z

Mngr:

= Installation Procedure for a New MediaWiki Instance (MediaWiki 1.43 LTS) =
This document describes the clean, reproducible workflow for deploying a new MediaWiki instance on the existing 3‑VM infrastructure.

The installation is intentionally split into two phases:

* '''Phase 1:''' Local installation and testing on VM1 (Apache on port 8080)
* '''Phase 2:''' Public exposure through VM3 (nginx reverse‑proxy + HTTPS)

This staged approach ensures safe testing before the wiki becomes accessible from the internet.

== VM Overview ==
* '''VM1 (Web Layer):''' 192.168.33.231
* '''VM2 (Database Layer):''' 192.168.33.232
* '''VM3 (Reverse‑Proxy Layer):''' 192.168.33.233
* '''DB user host address (VM1 → VM2):''' 10.10.10.1

----

= 1. Create the Database (VM2 – MariaDB) =
All commands in this section run on VM2 (192.168.33.232).

=== 1.1 Connect to MariaDB ===
<pre>
mysql -u root -p
</pre>

=== 1.2 Create the database ===
<pre>
CREATE DATABASE newwiki
CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;
</pre>

=== 1.3 Create the database user ===
VM1 connects to MariaDB using its internal DB‑facing address: '''10.10.10.1'''.

<pre>
CREATE USER 'newwikiuser'@'10.10.10.1' IDENTIFIED BY 'strongpassword';
</pre>

=== 1.4 Grant privileges ===
<pre>
GRANT ALL PRIVILEGES ON newwiki.* TO 'newwikiuser'@'10.10.10.1';
FLUSH PRIVILEGES;
</pre>

=== 1.5 Exit ===
<pre>
EXIT;
</pre>

----

= 2. Prepare the Installation Directory (VM1 – Web Layer) =
All commands below run on VM1 (192.168.33.231).

=== 2.1 Create the target directory ===
<pre>
mkdir /var/www/newMW
</pre>

=== 2.2 Move into /var/www ===
<pre>
cd /var/www
</pre>

----

= 3. Download MediaWiki =
Example: MediaWiki 1.43.8 LTS.

<pre>
wget https://releases.wikimedia.org/mediawiki/1.43/mediawiki-1.43.8.tar.gz
</pre>

----

= 4. Extract MediaWiki =
<pre>
tar -xvzf mediawiki-1.43.8.tar.gz
</pre>

----

= 5. Move Extracted Files into newMW =
<pre>
mv mediawiki-1.43.8/* newMW/
mv mediawiki-1.43.8/.* newMW/ 2>/dev/null
rmdir mediawiki-1.43.8
rm mediawiki-1.43.8.tar.gz
</pre>

----

= 6. Ownership and Permissions =
Allows editing via VS Code while keeping Apache functional.

=== 6.1 Set owner and group ===
<pre>
chown -R mngr:apache /var/www/newMW
</pre>

=== 6.2 Ensure group write permissions ===
<pre>
chmod -R g+w /var/www/newMW
</pre>

=== 6.3 Directory/file permissions ===
<pre>
find /var/www/newMW -type d -exec chmod 775 {} \;
find /var/www/newMW -type f -exec chmod 664 {} \;
</pre>

=== 6.4 Enable group inheritance (setgid) ===
<pre>
chmod g+s /var/www/newMW
</pre>

----

= 7. Apache Configuration on VM1 (Port 8080) =

== 7.1 Enable Apache to listen on port 8080 ==
Edit:
<pre>
/etc/httpd/conf/httpd.conf
</pre>

Add:
<pre>
Listen 8080
</pre>

== 7.2 Validate and restart ==
<pre>
apachectl configtest
systemctl restart httpd
</pre>

== 7.3 Verify Apache is listening ==
<pre>
ss -tlnp | grep httpd
</pre>

Expected:
<pre>
0.0.0.0:80
0.0.0.0:8080
</pre>

== 7.4 Firewall rule (VM1) ==
Allow port 8080:

<pre>
firewall-cmd --add-port=8080/tcp --permanent
firewall-cmd --reload
</pre>

== 7.5 Local‑only Apache VirtualHost ==
<pre>
<VirtualHost *:8080>
ServerName newmw.local
DocumentRoot /var/www/newMW

<Directory /var/www/newMW>
AllowOverride All
Require all granted
</Directory>

ErrorLog /var/log/httpd/newmw-local-error.log
CustomLog /var/log/httpd/newmw-local-access.log combined
</VirtualHost>
</pre>

Restart Apache:
<pre>
systemctl restart httpd
</pre>

----

= 8. Run the Installer Locally =
Access:

* <code>http://192.168.33.231:8080</code>
* <code>http://newmw.local:8080</code> (if added to /etc/hosts)

== Internal DB Network Logic (10.10.10.x) ==
The internal network between VM1 and VM2 uses dedicated addresses:

* VM1 (Web Layer): '''10.10.10.1'''
* VM2 (Database Layer): '''10.10.10.2'''

When MediaWiki (running on VM1) connects to MariaDB on VM2, the connection originates from VM1’s internal NIC.
Therefore:

* VM1 connects **to** MariaDB at:
<code>10.10.10.2</code>

* VM2 sees VM1 **coming from**:
<code>10.10.10.1</code>

Because MariaDB authorizes users based on the client’s source address, database users must be created as:

<pre>
'wikiuser'@'10.10.10.1'
</pre>

This is why all MediaWiki instances on VM1 use the same host restriction.
It ensures that only VM1 can authenticate to MariaDB over the internal network.

== Result after installation flow ==

Installer will generate:
<pre>
$wgServer = "http://192.168.33.231:8080";
</pre>

Place <code>LocalSettings.php</code> in:
<pre>
/var/www/newMW/LocalSettings.php
</pre>

----

= 9. Local Testing =
Verify:

* Page creation
* Editing
* File uploads
* User accounts
* Extensions
* Permissions
* Logging

Only proceed when everything works locally.

----

= 10. Public Exposure via VM3 (Reverse‑Proxy Layer) =

== 10.1 Create minimal HTTP‑only nginx config (VM3) ==
File:
<code>/etc/nginx/conf.d/kb.costasano.club.conf</code>

<syntaxhighlight lang="nginx">
# ============================================
# Reverse proxy (HTTP only)
# kb.costasano.club
# ============================================

server {
listen 80;
listen [::]:80;
server_name kb.costasano.club;

location /.well-known/acme-challenge/ {
root /usr/share/nginx/html;
}

location / {
proxy_pass http://192.168.33.231:8080;

proxy_set_header Host kb.costasano.club;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto http;
}
}
</syntaxhighlight>

Reload nginx:
<syntaxhighlight lang="bash">
sudo nginx -t
sudo systemctl reload nginx
</syntaxhighlight>

----

= 11. Issue the Certificate (VM3) =
Use the nginx plugin:

<syntaxhighlight lang="bash">
sudo certbot --nginx -d kb.costasano.club
</syntaxhighlight>

Certbot will:

* inject temporary ACME config
* validate the domain
* obtain the certificate
* install it
* register it for renewal

----

= 12. Replace with Full HTTPS Reverse‑Proxy (VM3) =
<syntaxhighlight lang="nginx">
# ============================================
# Reverse proxy (HTTPS)
# kb.costasano.club
# ============================================

# --- HTTP (redirect + ACME) ---
server {
listen 80;
listen [::]:80;
server_name kb.costasano.club;

location /.well-known/acme-challenge/ {
root /usr/share/nginx/html;
}

return 301 https://$host$request_uri;
}

# --- HTTPS ---
server {
listen 443 ssl;
listen [::]:443 ssl;
http2 on;

server_name kb.costasano.club;

ssl_certificate /etc/letsencrypt/live/kb.costasano.club/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/kb.costasano.club/privkey.pem;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;

location /.well-known/acme-challenge/ {
root /usr/share/nginx/html;
}

location / {
proxy_pass http://192.168.33.231:8080;

proxy_set_header Host kb.costasano.club;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;

proxy_buffering on;
proxy_buffers 16 16k;
proxy_buffer_size 16k;

proxy_connect_timeout 60s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
}
}
</syntaxhighlight>

Reload nginx:
<syntaxhighlight lang="bash">
sudo nginx -t
sudo systemctl reload nginx
</syntaxhighlight>

----

= 13. Update LocalSettings.php for Public Access =
Change:
<pre>
$wgServer = "https://kb.costasano.club";
</pre>

Optional:
<pre>
$wgCanonicalServer = "https://kb.costasano.club";
</pre>

----

= 14. Final Verification =
* <code>curl -I https://kb.costasano.club</code> returns 200 or 301
* Browser loads the wiki
* Editing works
* Uploads work
* No rewrite errors
* nginx proxies correctly
* MariaDB connections succeed

----

= 15. Login Issues After Changing LocalSettings.php =
MediaWiki is very sensitive to stale cookies and cached sessions, especially
after changing settings such as:

* $wgServer
* $wgCookieSecure
* $wgCookieSameSite
* $wgUseReverseProxy
* $wgUseCdn

If login suddenly fails or a Captcha appears even though no Captcha extension
is enabled, the cause is usually old browser cookies.

'''Fix:''' open the wiki in a private/incognito window or clear cookies for the
domain. This forces MediaWiki to create a fresh session and resolves the issue.

=== Differences Between MediaWiki 1.43 and 1.45 (Login, Captcha, Reverse‑Proxy) ===
MediaWiki 1.43 and 1.45 behave differently when installed behind a reverse‑proxy
such as nginx. This affects login, session cookies, and the appearance of the
“phantom Captcha” (a throttle challenge that cannot be solved).

==== MediaWiki 1.45 (more tolerant) ====
MediaWiki 1.45 includes improved session and cookie handling. It automatically:

* detects HTTPS behind a reverse‑proxy
* regenerates session cookies when needed
* accepts SameSite=None cookies more reliably
* avoids triggering login throttling on fresh installs

As a result, MediaWiki 1.45 usually works immediately behind nginx without
showing any Captcha or blocking logins.

==== MediaWiki 1.43 (stricter behaviour) ====
MediaWiki 1.43 uses older, stricter session logic. If any of the following are
misconfigured:

* $wgServer
* $wgCookieSecure
* $wgCookieSameSite
* $wgUseReverseProxy
* $wgUseCdn
* missing $wgCdnServers entry

…MediaWiki may fail to create a valid login session. When this happens, it
displays a Captcha-like box even though no Captcha extension is enabled. This is
not a real Captcha but the built‑in login throttle, and it always fails.

==== Why this did not happen on the previous install ====
The earlier wiki was installed on MediaWiki 1.45, which is more forgiving of
reverse‑proxy setups. MediaWiki 1.43 requires explicit configuration to trust
the proxy and accept secure cookies.

==== Fix ====
Add the following lines to LocalSettings.php:

<pre>
$wgUseCdn = true;
$wgUseReverseProxy = true;
$wgCdnServers = [ "192.168.33.233" ]; # nginx reverse-proxy
$wgCookieSecure = true;
$wgCookieSameSite = "None";
</pre>

If login still fails, clear browser cookies or open the wiki in a private window
to force a fresh session.

= 16. Summary =
This procedure installs MediaWiki in two safe phases:

* '''Phase 1:''' Local installation and validation on VM1
* '''Phase 2:''' Public exposure through VM3 with HTTPS

This ensures a clean, reproducible, low‑risk deployment workflow.

== Apache fails to start after adding a new Listen port (SELinux) ==

When adding a new Apache <code>Listen</code> directive on AlmaLinux (e.g. <code>Listen 8081</code> or <code>Listen 8888</code>),
<code>httpd</code> may refuse to start even though <code>apachectl configtest</code> reports <code>Syntax OK</code>.

Typical symptoms:
* <code>httpd</code> does not restart after adding a new port
* <code>configtest</code> shows no errors
* <code>journalctl -xe</code> or <code>/var/log/audit/audit.log</code> contains an AVC denial similar to:

<pre>
type=AVC msg=audit(...): avc: denied { name_bind } for pid=XXXX comm="httpd" \
scontext=system_u:system_r:httpd_t:s0 \
tcontext=system_u:object_r:unreserved_port_t:s0 \
tclass=tcp_socket permissive=0
</pre>

=== Cause ===
SELinux only allows Apache (<code>httpd_t</code>) to bind to ports labeled as <code>http_port_t</code>.
By default, this includes ports such as 80, 443, 8008, 8009, 8443, and sometimes 8080.

Any new port (e.g. 8081, 8888) is labeled as <code>unreserved_port_t</code> and is therefore blocked by SELinux.
Apache reports this as a binding failure, often misleadingly shown as:

<pre>
No such device or address
</pre>

=== Check which ports Apache is allowed to use ===
<pre>
semanage port -l | grep http_port_t
</pre>

=== Fix: allow Apache to bind to the new port ===
Add the port to the SELinux <code>http_port_t</code> type:

<pre>
sudo semanage port -a -t http_port_t -p tcp 8081
sudo semanage port -a -t http_port_t -p tcp 8888
</pre>

If the port already exists under a different SELinux type, modify it instead:

<pre>
sudo semanage port -m -t http_port_t -p tcp 8081
</pre>

=== Restart Apache ===
<pre>
sudo systemctl restart httpd
</pre>

Apache will now start normally and bind to the newly added port.

=== Notes for maintainers ===
* This behaviour is normal on RHEL/AlmaLinux systems with SELinux in enforcing mode.
* Always document newly opened ports in the infrastructure notes to avoid confusion for successors.
* Avoid disabling SELinux; adjusting port labels is the correct and safe approach.

ICT:MW upgrade 1.43.8 to 1.46 LTS

2026-04-04T13:59:08Z

Mngr: Created page with "= MediaWiki Upgrade Procedure — 1.43.8 → 1.46 LTS = '''Document version:''' 2025‑04‑04 '''Author:''' Martin '''Purpose:''' Clean, reproducible, successor‑friendly upgrade to MediaWiki 1.46 LTS using a parallel installation in <code>/var/www/mw146</code> and a reverse‑proxy switch. This procedure ensures: * Zero downtime * Instant rollback * No leftover files from old versions * Clean, maintainable, successor‑friendly architecture The upgrade i..."

= MediaWiki Upgrade Procedure — 1.43.8 → 1.46 LTS =
'''Document version:''' 2025‑04‑04
'''Author:''' Martin
'''Purpose:''' Clean, reproducible, successor‑friendly upgrade to MediaWiki 1.46 LTS using a parallel installation in <code>/var/www/mw146</code> and a reverse‑proxy switch.

This procedure ensures:
* Zero downtime
* Instant rollback
* No leftover files from old versions
* Clean, maintainable, successor‑friendly architecture

The upgrade is executed on the '''web VM''' with a final switch on the '''reverse‑proxy VM'''.

----

== Preconditions ==
* Working MediaWiki '''1.43.8 LTS''' installation
* Database VM reachable and healthy
* PHP '''8.1 or 8.2'''
* Reverse proxy currently pointing to <code>/var/www/mw143</code>
* VM snapshot taken before starting
* SSH access to web VM and reverse‑proxy VM

----

== Step 1: Prepare new directory ==
On the '''web VM''':

<pre>
cd /var/www
mkdir mw146
</pre>

Download and extract MediaWiki 1.46 LTS:

<pre>
wget https://releases.wikimedia.org/mediawiki/1.46/mediawiki-1.46.0.tar.gz
tar -xzf mediawiki-1.46.0.tar.gz --strip-components=1 -C mw146
</pre>

Resulting structure:

<pre>
/var/www/mw146
</pre>

----

== Step 2: Copy required files from old installation ==
From the existing 1.43 installation (example path <code>/var/www/mw143</code>):

=== Copy LocalSettings.php ===
<pre>
cp /var/www/mw143/LocalSettings.php /var/www/mw146/
</pre>

=== Copy images directory ===
<pre>
cp -R /var/www/mw143/images /var/www/mw146/
</pre>

=== Copy custom logos (if stored outside images) ===
<pre>
cp /var/www/mw143/resources/assets/*logo* /var/www/mw146/resources/assets/
</pre>

Do '''not''' copy extensions yet.

----

== Step 3: Install or update extensions ==
MediaWiki 1.46 requires updated extensions.

For each extension used in 1.43:

# Download the '''1.46‑compatible''' version
# Place it in <code>/var/www/mw146/extensions/</code>
# Keep the same configuration lines in <code>LocalSettings.php</code>

Vector‑2022 is bundled in 1.46 → no action needed.

----

== Step 4: Run the database upgrade ==
On the web VM:

<pre>
cd /var/www/mw146
php maintenance/update.php
</pre>

This upgrades the schema '''in place'''.
No data is lost.
No new database is created.

----

== Step 5: Local testing before switching reverse proxy ==
Access the new installation directly via the web VM’s IP:

<pre>
http://<web-vm-ip>/mw146/
</pre>

Verify:

* Login
* Namespaces and subpages
* Uploads
* SMTP
* Dark mode
* Vector‑2022 behaviour
* Special pages (filter box present)
* Search
* Logo

Proceed only when everything is correct.

----

== Step 6: Switch reverse proxy ==
On the '''reverse‑proxy VM''', update the root path.

Example (Nginx):

<pre>
root /var/www/mw146;
</pre>

Reload:

<pre>
systemctl reload nginx
</pre>

The wiki now runs on '''1.46 LTS'''.

Rollback is instant: point back to <code>/var/www/mw143</code>.

----

== Step 7: Post‑upgrade checks ==
* Check error logs on web VM
* Check reverse‑proxy logs
* Verify job queue
* Verify uploads
* Verify Special pages
* Verify dark mode
* Verify email notifications

----

== Step 8: Cleanup ==
After several days of stable operation:

<pre>
rm -rf /var/www/mw143
</pre>

Or archive it for long‑term reference.

----

== Rollback Procedure ==
If any issue occurs after switching:

# Edit reverse‑proxy config
# Point root back to <code>/var/www/mw143</code>
# Reload proxy
# Wiki is instantly restored

Database remains compatible.

----

== Notes ==
* MediaWiki 1.46 includes native dark mode
* Vector‑2022 settings may be simplified
* The Special pages filter box is available in 1.46
* No database recreation is required for upgrades

ICT:MW Installation procedure 1.43 LTS -v2

2026-04-03T16:56:35Z

Mngr:

ICT:MW Installation procedure 1.43 LTS -v2

2026-04-03T16:44:41Z

Mngr:

ICT:MW Installation procedure 1.43 LTS -v2

2026-04-03T16:13:08Z

Mngr:

ICT:MW Installation procedure 1.43 LTS -v2

2026-04-03T16:04:05Z

Mngr: Created page with "= Installation Procedure for a New MediaWiki Instance (MediaWiki 1.43 LTS) = This document describes the clean, reproducible workflow for deploying a new MediaWiki instance on the existing 3‑VM infrastructure. The installation is intentionally split into two phases: * '''Phase 1:''' Local installation and testing on VM1 (Apache on port 8080) * '''Phase 2:''' Public exposure through VM3 (nginx reverse‑proxy + HTTPS) This staged approach ensures safe testing before..."

ICT:MW Installation procedure 1.43 LTS

2026-04-03T15:50:58Z

Mngr:

= Installation Procedure for newMW (MediaWiki 1.43 LTS) =
This document describes the clean, reproducible installation workflow for
deploying a new MediaWiki instance (newMW) on the existing 3‑VM infrastructure.
The installation is intentionally split into two phases:

* Phase 1: Local installation and testing on VM1 (no reverse‑proxy required)
* Phase 2: Public exposure through VM3 (nginx reverse‑proxy)

This staged approach allows safe testing before the wiki becomes accessible
from the internet.

== 1. Create the newwiki Database (VM2 – Database Layer) ==
All commands in this section are executed on VM2.

=== 1.1 Connect to MariaDB ===
<pre>
mysql -u root -p
</pre>

=== 1.2 Create the database ===
<pre>
CREATE DATABASE newwiki
CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;
</pre>

=== 1.3 Create the database user ===
Replace <code>VM1-IP</code> with the internal Hyper‑V IP of the web server.

<pre>
CREATE USER 'newwikiuser'@'VM1-IP' IDENTIFIED BY 'strongpassword';
</pre>

=== 1.4 Grant privileges ===
<pre>
GRANT ALL PRIVILEGES ON newwiki.* TO 'newwikiuser'@'VM1-IP';
FLUSH PRIVILEGES;
</pre>

=== 1.5 Exit MariaDB ===
<pre>
EXIT;
</pre>

== 2. Prepare the Installation Directory (VM1 – Web Layer) ==
All commands below are executed on VM1.

=== 2.1 Create the target directory ===
<pre>
mkdir /var/www/newMW
</pre>

=== 2.2 Move into the working directory ===
<pre>
cd /var/www
</pre>

== 3. Download MediaWiki ==
Download the latest LTS tarball (example: 1.43.8):

<pre>
wget https://releases.wikimedia.org/mediawiki/1.43/mediawiki-1.43.8.tar.gz
</pre>

== 4. Extract MediaWiki ==
Extract the archive. This creates a directory such as <code>mediawiki-1.43.8/</code>.

<pre>
tar -xvzf mediawiki-1.43.8.tar.gz
</pre>

== 5. Move Extracted Files into newMW ==
Move normal files:

<pre>
mv mediawiki-1.43.8/* newMW/
</pre>

Move hidden files (e.g. <code>.htaccess</code>):

<pre>
mv mediawiki-1.43.8/.* newMW/ 2>/dev/null
</pre>

Remove the now‑empty extraction directory:

<pre>
rmdir mediawiki-1.43.8
</pre>

Remove the tarball:

<pre>
rm mediawiki-1.43.8.tar.gz
</pre>

== 6. Ownership and Permissions ==
Use the preferred ownership model to allow editing via VS Code while keeping
Apache fully functional.

=== 6.1 Set owner and group ===
<pre>
chown -R mngr:apache /var/www/newMW
</pre>

=== 6.2 Ensure group write permissions ===
<pre>
chmod -R g+w /var/www/newMW
</pre>

=== 6.3 Apply clean directory/file permissions ===
Directories:

<pre>
find /var/www/newMW -type d -exec chmod 775 {} \;
</pre>

Files:

<pre>
find /var/www/newMW -type f -exec chmod 664 {} \;
</pre>

=== 6.4 Enable group inheritance (setgid) ===
Ensures new files created inside inherit the <code>apache</code> group.

<pre>
chmod g+s /var/www/newMW
</pre>

== 7. Enable Apache to Listen on Port 8080 (VM1) & Virtual Host file ==
Apache does not automatically listen on new ports defined in VirtualHost
blocks. The port must be explicitly enabled in the main configuration.

=== 7.1 Edit the main Apache configuration ===
Open the file:

<pre>
/etc/httpd/conf/httpd.conf
</pre>

Locate the existing Listen directive:

<pre>
Listen 80
</pre>

Add the following line directly below it:

<pre>
Listen 8080
</pre>

=== 7.2 Validate the configuration ===
<pre>
apachectl configtest
</pre>

Expected output:

<pre>
Syntax OK
</pre>

=== 7.3 Restart Apache ===
<pre>
systemctl restart httpd
</pre>

=== 7.4 Verify Apache is listening on port 8080 ===
<pre>
ss -tlnp | grep httpd
</pre>

Expected result:

<pre>
0.0.0.0:80
0.0.0.0:8080
</pre>

Apache is now ready to serve the temporary local-only vhost on port 8080.

=== 7.5 Local‑Only Apache Virtual Host (VM1) ===
This vhost allows installation and testing without involving the reverse‑proxy.

<pre>
<VirtualHost *:8080>
ServerName newmw.local
DocumentRoot /var/www/newMW

<Directory /var/www/newMW>
AllowOverride All
Require all granted
</Directory>

ErrorLog /var/log/httpd/newmw-local-error.log
CustomLog /var/log/httpd/newmw-local-access.log combined
</VirtualHost>
</pre>

Restart Apache:

<pre>
systemctl restart httpd
</pre>

== 8. Run the Installer Locally ==
Access the installer using one of:

* <code>http://VM1-IP:8080</code>
* <code>http://newmw.local:8080</code> (if added to /etc/hosts)

Complete the installation.

The installer will generate a <code>LocalSettings.php</code> with:

<pre>
$wgServer = "http://VM1-IP:8080";
</pre>

Place the file in:

<pre>
/var/www/newMW/LocalSettings.php
</pre>

== 9. Local Testing ==
Before exposing the wiki publicly, verify:

* Page creation
* Editing
* File uploads (if enabled)
* User accounts
* Extensions
* Permissions
* Logging

This phase is isolated and safe.

== 10. Prepare for Public Access (VM3 – Reverse‑Proxy Layer) ==
Only after local testing is complete, add the nginx server block:

<pre>
server {
listen 80;
server_name newwiki.example.com;

location / {
proxy_pass http://VM1-IP:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
</pre>

Reload nginx:

<pre>
systemctl reload nginx
</pre>

== 11. Update LocalSettings.php for Public Access ==
Change:

<pre>
$wgServer = "https://newwiki.example.com";
</pre>

Optionally:

<pre>
$wgCanonicalServer = "https://newwiki.example.com";
</pre>

== 12. Final Verification ==
* Public URL loads correctly
* <code>/wiki/Main_Page</code> resolves
* Editing works
* Uploads work
* No rewrite errors in Apache logs
* nginx proxies correctly
* MariaDB connections succeed

== 13. Summary ==
This procedure installs MediaWiki in two safe phases:

* Phase 1: Local installation and validation on VM1
* Phase 2: Public exposure through VM3

This staged approach avoids dependency on the reverse‑proxy during installation
and allows controlled, low‑risk rollout.

= Addendum =

== Adding a New Domain + Certificate on VM3 (nginx + Certbot) ==
This procedure is used when onboarding a new subdomain to the reverse‑proxy layer on VM3.
It avoids the nginx/Certbot “missing certificate” failure by always starting with a minimal HTTP‑only configuration, issuing the certificate, and then enabling HTTPS.

=== 1. Create a minimal HTTP‑only reverse‑proxy config ===
Create <code>/etc/nginx/conf.d/<domain>.conf</code> with:

<syntaxhighlight lang="nginx">
# ============================================
# Reverse proxy (HTTP only)
# <domain>
# ============================================

server {
listen 80;
listen [::]:80;
server_name <domain>;

# ACME challenge (Certbot uses this)
location /.well-known/acme-challenge/ {
root /usr/share/nginx/html;
}

# Temporary: no HTTPS redirect until certificate exists
location / {
proxy_pass http://<backend-ip>:<backend-port>;

proxy_set_header Host <domain>;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto http;
}
}
</syntaxhighlight>

Reload nginx:

<syntaxhighlight lang="bash">
sudo nginx -t
sudo systemctl reload nginx
</syntaxhighlight>

At this point the domain resolves over HTTP and Certbot can validate it.

=== 2. Issue the certificate using the nginx plugin ===
Run:

<syntaxhighlight lang="bash">
sudo certbot --nginx -d <domain>
</syntaxhighlight>

Certbot will:
* inject a temporary ACME location
* validate the domain
* obtain the certificate
* install it
* register it for automatic renewal

This step only works if nginx is running without SSL errors.

=== 3. Replace the config with the full HTTPS reverse‑proxy ===
After the certificate exists, replace the file with:

<syntaxhighlight lang="nginx">
# ============================================
# Reverse proxy (HTTPS)
# <domain>
# ============================================

# --- HTTP (redirect + ACME) ---
server {
listen 80;
listen [::]:80;
server_name <domain>;

location /.well-known/acme-challenge/ {
root /usr/share/nginx/html;
}

return 301 https://$host$request_uri;
}

# --- HTTPS ---
server {
listen 443 ssl;
listen [::]:443 ssl;
http2 on;

server_name <domain>;

ssl_certificate /etc/letsencrypt/live/<domain>/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/<domain>/privkey.pem;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;

location /.well-known/acme-challenge/ {
root /usr/share/nginx/html;
}

location / {
proxy_pass http://<backend-ip>:<backend-port>;

proxy_set_header Host <domain>;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;

proxy_buffering on;
proxy_buffers 16 16k;
proxy_buffer_size 16k;

proxy_connect_timeout 60s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
}
}
</syntaxhighlight>

Reload nginx again:

<syntaxhighlight lang="bash">
sudo nginx -t
sudo systemctl reload nginx
</syntaxhighlight>

=== 4. Verification checklist ===
* <code>curl -I https://<domain></code> returns <code>200</code> or <code>301</code>
* Browser loads the site over HTTPS
* Login works
* File uploads work
* Optional: <code>certbot renew --dry-run</code>

ICT:MW Installation procedure 1.43 LTS

2026-04-03T14:38:58Z

Mngr:

ICT:MW Installation procedure 1.43 LTS

2026-04-03T13:36:33Z

Mngr:

ICT:MW Installation procedure 1.43 LTS

2026-04-03T13:31:41Z

Mngr:

= Installation Procedure for newMW (MediaWiki 1.43 LTS) =
This document describes the clean, reproducible installation workflow for
deploying a new MediaWiki instance (newMW) on the existing 3‑VM infrastructure.
It includes directory preparation, file extraction, permissions, database
creation, and the preferred ownership model for VS Code access.

== 1. Create the newwiki Database (VM2 – Database Layer) ==
All commands in this section are executed on VM2.

=== 1.1 Connect to MariaDB ===
<pre>
mysql -u root -p
</pre>

=== 1.2 Create the database ===
<pre>
CREATE DATABASE newwiki
CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;
</pre>

=== 1.3 Create the database user ===
Replace <code>VM1-IP</code> with the internal Hyper‑V IP of the web server.

<pre>
CREATE USER 'newwikiuser'@'VM1-IP' IDENTIFIED BY 'strongpassword';
</pre>

=== 1.4 Grant privileges ===
<pre>
GRANT ALL PRIVILEGES ON newwiki.* TO 'newwikiuser'@'VM1-IP';
FLUSH PRIVILEGES;
</pre>

=== 1.5 Exit MariaDB ===
<pre>
EXIT;
</pre>

== 2. Prepare the Installation Directory (VM1 – Web Layer) ==
All commands below are executed on VM1.

=== 2.1 Create the target directory ===
<pre>
mkdir /var/www/newMW
</pre>

=== 2.2 Move into the working directory ===
<pre>
cd /var/www
</pre>

== 3. Download MediaWiki ==
Download the latest LTS tarball (example: 1.43.8):

<pre>
wget https://releases.wikimedia.org/mediawiki/1.43/mediawiki-1.43.8.tar.gz
</pre>

== 4. Extract MediaWiki ==
Extract the archive. This creates a directory such as <code>mediawiki-1.43.8/</code>.

<pre>
tar -xvzf mediawiki-1.43.8.tar.gz
</pre>

== 5. Move Extracted Files into newMW ==
Move normal files:

<pre>
mv mediawiki-1.43.8/* newMW/
</pre>

Move hidden files (e.g. <code>.htaccess</code>):

<pre>
mv mediawiki-1.43.8/.* newMW/ 2>/dev/null
</pre>

Remove the now‑empty extraction directory:

<pre>
rmdir mediawiki-1.43.8
</pre>

Remove the tarball:

<pre>
rm mediawiki-1.43.8.tar.gz
</pre>

== 6. Ownership and Permissions ==
Use the preferred ownership model to allow editing via VS Code while keeping
Apache fully functional.

=== 6.1 Set owner and group ===
<pre>
chown -R mngr:apache /var/www/newMW
</pre>

=== 6.2 Ensure group write permissions ===
<pre>
chmod -R g+w /var/www/newMW
</pre>

=== 6.3 Apply clean directory/file permissions ===
Directories:

<pre>
find /var/www/newMW -type d -exec chmod 775 {} \;
</pre>

Files:

<pre>
find /var/www/newMW -type f -exec chmod 664 {} \;
</pre>

=== 6.4 Enable group inheritance (setgid) ===
Ensures new files created inside inherit the <code>apache</code> group.

<pre>
chmod g+s /var/www/newMW
</pre>

== 7. Apache Virtual Host (VM1) ==
Create a vhost:

<pre>
<VirtualHost *:8080>
ServerName newwiki.example.com
DocumentRoot /var/www/newMW

<Directory /var/www/newMW>
AllowOverride All
Require all granted
</Directory>

ErrorLog /var/log/httpd/newwiki-error.log
CustomLog /var/log/httpd/newwiki-access.log combined
</VirtualHost>
</pre>

Restart Apache:

<pre>
systemctl restart httpd
</pre>

== 8. nginx Reverse‑Proxy (VM3) ==
Add a server block:

<pre>
server {
listen 80;
server_name newwiki.example.com;

location / {
proxy_pass http://VM1-IP:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
</pre>

Reload nginx:

<pre>
systemctl reload nginx
</pre>

== 9. Run the MediaWiki Installer ==
Navigate to:

<pre>
https://newwiki.example.com
</pre>

Provide:
* Database: <code>newwiki</code>
* User: <code>newwikiuser</code>
* Password: (as created on VM2)
* Site name
* Admin account

Download <code>LocalSettings.php</code> and place it in:

<pre>
/var/www/newMW/LocalSettings.php
</pre>

== 10. Minimal Post‑Install Configuration ==
Add or verify:

<pre>
$wgServer = "https://newwiki.example.com";
$wgScriptPath = "";
$wgArticlePath = "/wiki/$1";
$wgUsePathInfo = true;
</pre>

Enable uploads (optional):

<pre>
$wgEnableUploads = true;
</pre>

Enable SyntaxHighlight:

<pre>
wfLoadExtension( 'SyntaxHighlight_GeSHi' );
</pre>

== 11. Verification Checklist ==
* Site loads correctly
* <code>/wiki/Main_Page</code> resolves
* Editing works
* File uploads work (if enabled)
* No rewrite errors in Apache logs
* nginx proxies correctly
* MariaDB connections succeed

== 12. Summary ==
This procedure provides a clean, repeatable installation workflow for MediaWiki
1.43 LTS using the preferred ownership model (<code>mngr:apache</code>) and the
existing 3‑VM architecture. It ensures clarity, maintainability, and
successor‑friendly operation.

ICT:MW Installation procedure 1.43 LTS

2026-04-03T13:29:43Z

Mngr: Created page with "= Installation Procedure for newMW (MediaWiki 1.43 LTS) = This document describes the clean, reproducible installation workflow for deploying a new MediaWiki instance (newMW) on the existing 3‑VM infrastructure. It includes directory preparation, file extraction, permissions, and the preferred ownership model for VS Code access. == 1. Preparation == All commands are executed on VM1 (Web Layer). === 1.1 Create the target directory === <pre> mkdir /var/www/newMW </pre>..."

= Installation Procedure for newMW (MediaWiki 1.43 LTS) =
This document describes the clean, reproducible installation workflow for
deploying a new MediaWiki instance (newMW) on the existing 3‑VM infrastructure.
It includes directory preparation, file extraction, permissions, and the
preferred ownership model for VS Code access.

== 1. Preparation ==
All commands are executed on VM1 (Web Layer).

=== 1.1 Create the target directory ===
<pre>
mkdir /var/www/newMW
</pre>

=== 1.2 Move into the working directory ===
<pre>
cd /var/www
</pre>

== 2. Download MediaWiki ==
Download the latest LTS tarball (example: 1.43.8):

<pre>
wget https://releases.wikimedia.org/mediawiki/1.43/mediawiki-1.43.8.tar.gz
</pre>

== 3. Extract MediaWiki ==
Extract the archive. This creates a directory such as <code>mediawiki-1.43.8/</code>.

<pre>
tar -xvzf mediawiki-1.43.8.tar.gz
</pre>

== 4. Move Extracted Files into newMW ==
Move normal files:

<pre>
mv mediawiki-1.43.8/* newMW/
</pre>

Move hidden files (e.g. <code>.htaccess</code>):

<pre>
mv mediawiki-1.43.8/.* newMW/ 2>/dev/null
</pre>

Remove the now‑empty extraction directory:

<pre>
rmdir mediawiki-1.43.8
</pre>

Remove the tarball:

<pre>
rm mediawiki-1.43.8.tar.gz
</pre>

== 5. Ownership and Permissions ==
Use the preferred ownership model to allow editing via VS Code while keeping
Apache fully functional.

=== 5.1 Set owner and group ===
<pre>
chown -R mngr:apache /var/www/newMW
</pre>

=== 5.2 Ensure group write permissions ===
<pre>
chmod -R g+w /var/www/newMW
</pre>

=== 5.3 Apply clean directory/file permissions ===
Directories:

<pre>
find /var/www/newMW -type d -exec chmod 775 {} \;
</pre>

Files:

<pre>
find /var/www/newMW -type f -exec chmod 664 {} \;
</pre>

=== 5.4 Enable group inheritance (setgid) ===
Ensures new files created inside inherit the <code>apache</code> group.

<pre>
chmod g+s /var/www/newMW
</pre>

== 6. Apache Virtual Host ==
Create a vhost on VM1:

<pre>
<VirtualHost *:8080>
ServerName newwiki.example.com
DocumentRoot /var/www/newMW

<Directory /var/www/newMW>
AllowOverride All
Require all granted
</Directory>

ErrorLog /var/log/httpd/newwiki-error.log
CustomLog /var/log/httpd/newwiki-access.log combined
</VirtualHost>
</pre>

Restart Apache:

<pre>
systemctl restart httpd
</pre>

== 7. nginx Reverse‑Proxy (VM3) ==
Add a server block:

<pre>
server {
listen 80;
server_name newwiki.example.com;

location / {
proxy_pass http://VM1-IP:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
</pre>

Reload nginx:

<pre>
systemctl reload nginx
</pre>

== 8. Run the MediaWiki Installer ==
Navigate to:

<pre>
https://newwiki.example.com
</pre>

Provide:
* Database: <code>newwiki</code>
* User: <code>newwikiuser</code>
* Password: (as created on VM2)
* Site name
* Admin account

Download <code>LocalSettings.php</code> and place it in:

<pre>
/var/www/newMW/LocalSettings.php
</pre>

== 9. Minimal Post‑Install Configuration ==
Add or verify:

<pre>
$wgServer = "https://newwiki.example.com";
$wgScriptPath = "";
$wgArticlePath = "/wiki/$1";
$wgUsePathInfo = true;
</pre>

Enable uploads (optional):

<pre>
$wgEnableUploads = true;
</pre>

Enable SyntaxHighlight:

<pre>
wfLoadExtension( 'SyntaxHighlight_GeSHi' );
</pre>

== 10. Verification Checklist ==
* Site loads correctly
* <code>/wiki/Main_Page</code> resolves
* Editing works
* File uploads work (if enabled)
* No rewrite errors in Apache logs
* nginx proxies correctly
* MariaDB connections succeed

== 11. Summary ==
This procedure provides a clean, repeatable installation workflow for MediaWiki
1.43 LTS using the preferred ownership model (<code>mngr:apache</code>) and the
existing 3‑VM architecture. It ensures clarity, maintainability, and
successor‑friendly operation.

ICT:MW Clean installation checklist version 1.43 LTS

2026-04-03T11:37:52Z

Mngr: Mngr moved page ICT:MW Clean installaiton checklist version 1.43 LTS to ICT:MW Clean installation checklist version 1.43 LTS without leaving a redirect

= Installation Checklist – MediaWiki 1.43 LTS =
This document provides a clean, reproducible installation procedure for
MediaWiki 1.43 LTS on AlmaLinux with Apache, PHP, MariaDB, and an nginx
reverse-proxy. It is designed for long-term stability and successor-friendly
maintenance.

== 1. Preparation ==
Before installing MediaWiki, ensure the server environment is ready.

=== 1.1 System Requirements ===
* AlmaLinux (or compatible RHEL-based system)
* Apache (httpd)
* PHP 8.1 or later
* MariaDB 10.5 or later
* nginx reverse-proxy (optional but recommended)
* SELinux/AppArmor configured or disabled as needed

=== 1.2 Install Required Packages ===
Install PHP and required extensions:
<pre>
dnf install php php-mbstring php-xml php-intl php-mysqlnd php-gd php-json php-cli php-opcache php-apcu
</pre>

Install Apache and MariaDB:
<pre>
dnf install httpd mariadb-server
</pre>

Enable and start services:
<pre>
systemctl enable --now httpd mariadb
</pre>

== 2. Database Setup ==
Create a clean database for the new wiki.

=== 2.1 Secure MariaDB ===
<pre>
mysql_secure_installation
</pre>

=== 2.2 Create Database and User ===
<pre>
CREATE DATABASE newwiki CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'newwikiuser'@'localhost' IDENTIFIED BY 'strongpassword';
GRANT ALL PRIVILEGES ON newwiki.* TO 'newwikiuser'@'localhost';
FLUSH PRIVILEGES;
</pre>

== 3. Download MediaWiki 1.43 LTS ==
Download and extract the LTS release.

<pre>
cd /var/www
wget https://releases.wikimedia.org/mediawiki/1.43/mediawiki-1.43.0.tar.gz
tar -xvzf mediawiki-1.43.0.tar.gz
mv mediawiki-1.43.0 newwiki
</pre>

Set permissions:
<pre>
chown -R apache:apache /var/www/newwiki
</pre>

== 4. Apache Virtual Host ==
Create a dedicated vhost for the new wiki.

<pre>
<VirtualHost *:8080>
ServerName newwiki.example.com
DocumentRoot /var/www/newwiki

<Directory /var/www/newwiki>
AllowOverride All
Require all granted
</Directory>

ErrorLog /var/log/httpd/newwiki-error.log
CustomLog /var/log/httpd/newwiki-access.log combined
</VirtualHost>
</pre>

Enable the site and restart Apache:
<pre>
systemctl restart httpd
</pre>

== 5. nginx Reverse-Proxy ==
Duplicate the working configuration from the old wiki.

Only change:
* <code>server_name</code>
* <code>proxy_pass</code> target
* SSL certificate paths

Example:
<pre>
server {
listen 80;
server_name newwiki.example.com;

location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
</pre>

Reload nginx:
<pre>
systemctl reload nginx
</pre>

== 6. Run the MediaWiki Installer ==
Navigate to:
<pre>
https://newwiki.example.com
</pre>

Provide:
* Database name: <code>newwiki</code>
* Database user: <code>newwikiuser</code>
* Database password
* Site name
* Admin account

Download the generated <code>LocalSettings.php</code> and place it in:
<pre>
/var/www/newwiki/LocalSettings.php
</pre>

== 7. Minimal Post-Install Configuration ==
Add only the essential customizations.

=== 7.1 URL Structure ===
Ensure these lines exist:
<pre>
$wgServer = "https://newwiki.example.com";
$wgScriptPath = "";
$wgArticlePath = "/wiki/$1";
$wgUsePathInfo = true;
</pre>

=== 7.2 Enable File Uploads (optional) ===
<pre>
$wgEnableUploads = true;
</pre>

=== 7.3 Install SyntaxHighlight (recommended) ===
<pre>
wfLoadExtension( 'SyntaxHighlight_GeSHi' );
</pre>

=== 7.4 Create Custom Namespaces (optional) ===
<pre>
define("NS_TECH", 3000);
define("NS_TECH_TALK", 3001);
$wgExtraNamespaces[NS_TECH] = "Tech";
$wgNamespacesWithSubpages[NS_TECH] = true;
</pre>

== 8. Testing Checklist ==
Verify:
* <code>/wiki/Main_Page</code> loads correctly
* Editing works
* File uploads work (if enabled)
* Categories work
* Subpages work in custom namespaces
* Reverse-proxy preserves Host header
* No rewrite errors in Apache logs

== 9. Backup Checklist ==
Create a backup routine for:
* <code>/var/www/newwiki</code>
* <code>LocalSettings.php</code>
* MariaDB database <code>newwiki</code>

== 10. Maintenance Notes ==
* MediaWiki 1.43 is LTS until December 2027.
* Apply security updates within the 1.43 branch.
* Avoid unnecessary extensions to keep the system stable.

ICT:MW Clean installation checklist version 1.43 LTS

2026-04-03T11:07:58Z

Mngr: Created page with "= Installation Checklist – MediaWiki 1.43 LTS = This document provides a clean, reproducible installation procedure for MediaWiki 1.43 LTS on AlmaLinux with Apache, PHP, MariaDB, and an nginx reverse-proxy. It is designed for long-term stability and successor-friendly maintenance. == 1. Preparation == Before installing MediaWiki, ensure the server environment is ready. === 1.1 System Requirements === * AlmaLinux (or compatible RHEL-based system) * Apache (httpd) * PH..."

File:drupal flow 0 reverse.gif

2026-02-27T20:46:33Z

Mngr: Drupal Flow in Layers

== Summary ==
Drupal Flow in Layers

ICT:FinalConfig - Asset - v2.3 design proposal

2026-02-22T22:42:17Z

Mngr:

= Asset v2.3 – Lifecycle Proposal =

== 0. Purpose of this Document ==
This document defines **Asset v2.3**, a stabilization and completion step of the Asset v2.x line.

Its purposes are:
* Serve as a **conceptual study document**
* Provide a **clear implementation guide**
* Act as a **baseline for validation and later fine-tuning**

Asset v2.3 does not introduce new concepts.
It reorganizes responsibilities, clarifies lifecycle phases, and resolves ambiguities identified in Asset v2.1.

---

== 1. Locked Runtime Baseline (Unchanged) ==
The following environment and assumptions are **strictly locked** and MUST NOT change during Asset v2.x development:

* OS: AlmaLinux 10.1
* PHP: 8.3
* MediaWiki: 1.45.x
* Page Forms: 6.x
* Cargo (external database)
* Scribunto: Lua 5.1 (Lua 5.4 explicitly excluded)
* Private MediaWiki installation

Normative constraints:
* One Asset = exactly one digital file
* Asset identifier immutability
* Compatibility with existing Asset v2.1 data

---

== 2. Core Principle (Reaffirmed) ==
''An Asset is immutable after finalization.''

Immutability applies to:
* Asset identifier (page name)
* Label
* Chapter
* Place / Organisation
* File
* OriginalFilename

All other descriptive metadata MAY be edited after finalization.

---

== 3. Explicit Asset Lifecycle (Normative) ==
Asset v2.3 introduces a **three-phase lifecycle**.
Each phase has a single responsibility and MUST NOT overlap with others.

---

=== 3.1 Phase A – Draft Creation ===
'''Goal:''' Safely persist user input without committing archival identity.

Characteristics:
* Page name: timestamp-based (e.g. <code>Asset:20260222194733</code>)
* Status: <code>DRAFT</code>
* Identifier: placeholder (<code>GENERATING…</code>)
* File: uploaded under original filename

Allowed actions:
* Upload file
* Select Chapter
* Select Place or Organisation
* Enter descriptive metadata

Forbidden actions:
* Identifier generation
* File renaming
* Page moving

Rules:
* Draft pages MUST NOT appear in dashboards
* Draft pages MUST NOT be queried as Assets

---

=== 3.2 Phase B – Finalization ===
'''Goal:''' Atomically transform a Draft Asset into a Final Asset.

Phase B is the ONLY phase in which identity is assigned.
It MUST execute exactly once per Asset.

----

==== Preconditions ====
All of the following MUST be true before Phase B starts:

* Asset page exists
* <code>Status = DRAFT</code>
* Required fields present:
** Chapter
** Place OR Organisation
** File
* No final identifier has been assigned

If any precondition fails, Phase B MUST NOT start.

----

==== Trigger ====
Phase B is triggered by an explicit user action
(e.g. a “Finalize Asset” control).

Automatic finalization is forbidden.

----

==== Atomic Actions (execution order) ====
The following steps form a single atomic operation:

# Compute next sequence number (contextual)
# Generate final Asset identifier
# Rename file to match final identifier
# Move Asset page to final title
# Persist final Cargo data
# Set <code>Status = FINAL</code>
# Lock immutable fields

If any step fails:
* ALL changes MUST be aborted
* No partial state is allowed
* The failure MUST be logged

----

==== Rules ====
* Phase B MUST run exactly once
* Re-finalization is forbidden
* Partial finalization is forbidden
* Identifier and sequence allocation occur ONLY in Phase B
* Page move and file rename occur ONLY in Phase B

----

==== Resulting State ====
After successful Phase B:

* <code>Status = FINAL</code>
* Asset identifier is permanent
* File name is permanent
* Asset becomes visible on dashboards
* Immutable fields are locked

----

==== Explicitly Forbidden ====
* Running Phase B on a FINAL Asset
* Changing immutable fields after Phase B
* Skipping or reordering atomic steps

----

---

=== 3.3 Phase C – Post-Final Editing ===
'''Goal:''' Allow safe metadata enrichment without identity corruption.

Allowed:
* Description updates
* Notes
* Parent asset relations

Forbidden:
* Any change to immutable fields
* File replacement or rename
* Page move

---

== 4. Explicit Status Field (New) ==
Asset v2.3 introduces a mandatory field:

<syntaxhighlight lang="text">
Status = DRAFT | FINAL
</syntaxhighlight>

Purpose:
* Remove implicit draft detection
* Control lifecycle hook execution
* Prevent accidental re-finalization

The Status field is authoritative.

---

== 5. Identifier and Sequence Generation (Clarified) ==
Identifier format remains unchanged:

<syntaxhighlight lang="text">
<ChapterCode>-<ContextCode>-<SequenceNumber>
</syntaxhighlight>

Rules:
* Sequence numbers are allocated ONLY during Phase B
* Numbers are never reused
* Gaps are allowed
* Counter logic is centralized

Sequence allocation MUST be implemented as a single isolated function.

---

== 6. Hook Responsibility Separation ==
Asset v2.3 enforces strict separation of concerns.

Hooks MUST NOT:
* Parse wikitext for authoritative decisions
* Combine extraction, mutation, and page/file movement
* Decide identity before save completion

Hooks SHOULD:
* Detect lifecycle phase
* Validate preconditions
* Delegate work to dedicated functions

Wikitext inspection MAY be used for diagnostics only.

---

== 7. Page Move Strategy ==
Page moves are explicitly **post-save operations**.

Rationale:
* MediaWiki requires stable content before moving pages
* Page Forms target manipulation is fragile

Rule:
''A page MUST exist before it is moved.''

---

== 8. File Handling Strategy ==
* File upload occurs in Phase A
* File rename occurs only in Phase B
* Original filename is captured exactly once

After Phase B:
* File becomes immutable
* Further file operations are forbidden

---

== 9. Dashboard Visibility Rules ==
* <code>Status = DRAFT</code> → hidden
* <code>Status = FINAL</code> → visible

Dashboards MUST display only finalized Assets.

---

== 10. Migration and Compatibility ==
Asset v2.3:
* Does NOT invalidate Asset v2.1 Assets
* Introduces no breaking schema changes
* Adds lifecycle clarity without requiring data migration

---

== 11. Status ==
Asset v2.3 is a **design-level proposal**.

Next steps:
# Study and validate lifecycle clarity
# Implement Phase separation in the private extension
# Test finalization robustness
# Fine-tune UX only after correctness is proven

---

''End of first part of document''

------Actual status --------------

= Asset v2.3 – Current Working State (Checkpoint) =
''Date: 2026-02-22''

This page documents the **last known good state** of the Asset v2.3 system.
It exists to allow safe recovery if later experiments break functionality.

----

== 1. Scope ==
This document describes:
* What is implemented and validated
* What is intentionally NOT implemented yet
* Which architectural decisions are locked
* Where development must resume next

----

== 2. Environment (Locked) ==
* MediaWiki 1.45.x
* Page Forms 6.x
* Cargo (external database)
* PHP 8.3
* AlmaLinux
* Private MediaWiki installation

These were tested together and MUST NOT be changed mid-development.

----

== 3. Asset Lifecycle (Current Implementation) ==

=== Phase A – Draft Creation (IMPLEMENTED) ===
* Assets are created via Dashboard + Form:Asset
* Page name is timestamp-based (e.g. Asset:20260222222722)
* File is uploaded under its original filename
* Identifier is placeholder: <code>GENERATING...</code>

=== READY State (IMPLEMENTED) ===
READY is a **technical gate**, not a lifecycle phase.

Status transitions:
* <code>DRAFT</code> → incomplete
* <code>READY</code> → all required fields present

Required fields:
* Chapter
* Place OR Organisation
* File

READY detection is:
* Automatic
* Hook-based
* User-invisible
* Reversible

READY assets are still hidden from dashboards.

----

== 4. What Is Explicitly NOT Implemented Yet ==
* Phase B (Finalization)
* Identifier generation
* Sequence allocation
* File rename
* Page move
* Cargo writes during finalization
* Dashboard visibility of Assets

This is intentional.

----

== 5. Dashboard Rules (Locked) ==
Dashboards show:
* ONLY <code>Status = FINAL</code>

Dashboards hide:
* <code>DRAFT</code>
* <code>READY</code>

Dashboard emptiness at this stage is CORRECT.

----

== 6. Hook Architecture (Critical Knowledge) ==

=== The ONLY Hook Used ===
<code>PageForms::WritePageData</code>

Correct and tested signature:
<syntaxhighlight lang="php">
onPFWritePageData( $formName, $title, &$wikitext )
</syntaxhighlight>

Important rules:
* NO type hints in parameters
* Hook fires BEFORE page creation
* Hook MUST NOT assume page exists

=== What the Hook Does ===
* Reads fields from wikitext
* Computes READY vs DRAFT
* Writes <code>Status</code> back into wikitext
* Writes debug logs

=== What the Hook MUST NOT Do ===
* Write to Cargo
* Rename files
* Move pages
* Trigger second saves
* Perform Phase B logic

Violating these rules caused page creation to fail.

----

== 7. Logging ==
A debug log is used to confirm hook execution:

<syntaxhighlight lang="text">
/var/www/mediawiki/hook_debug.log
</syntaxhighlight>

Typical successful output:
<syntaxhighlight lang="text">
PF WritePageData fired: Asset:20260222222722
Fields: Chapter='CH02', Place='BRUG', Org='', File='Berck-Casino-371-ai.jpg'
Computed status: READY
Wikitext Status updated
</syntaxhighlight>

If logs stop appearing:
* The hook signature is wrong
* Or the extension is not loaded

----

== 8. Current Stable Code Reference ==
The current working hook:
* Updates wikitext only
* Does not touch Cargo
* Does not break saves

This state is backed up via full VM disk copies.

----

== 9. Known UX Side Effect ==
Because wikitext is modified in the Page Forms hook:
* MediaWiki shows the classic save confirmation screen

This is acceptable for now.
It will be removed later during Phase B refactoring.

----

== 10. Where to Resume Development ==
Next work session must start with:

'''Phase B – Finalization'''

Specifically:
* Trigger from the form (Finalize Asset button)
* Post-save logic only
* Atomic operations:
** sequence allocation
** identifier generation
** file rename
** page move
** Cargo persistence

Phase A MUST NOT be modified further.

----

''End of checkpoint document''

Asset:20260222222722

2026-02-22T22:28:15Z

Mngr: Created page with "{{Asset |Status=READY |Chapter=CH02 |Place=BRUG |Label=GENERATING... |File=Berck-Casino-371-ai.jpg |Description=T |Notes=T }}"

{{Asset
|Status=READY
|Chapter=CH02
|Place=BRUG
|Label=GENERATING...
|File=Berck-Casino-371-ai.jpg
|Description=T
|Notes=T
}}

File:Berck-Casino-371-ai.jpg

2026-02-22T22:28:06Z

Mngr:

File:Berck-Casino-370-ai.jpg

2026-02-22T21:15:33Z

Mngr:

File:Berck-553-ai.jpg

2026-02-22T21:08:32Z

Mngr:

Asset:20260222203155

2026-02-22T20:32:30Z

Mngr: Created page with "{{Asset |Status=DRAFT |Chapter=CH01 |Place=AMER |Label=GENERATING... |File=Berck-548-ai.jpg }}"

{{Asset
|Status=DRAFT
|Chapter=CH01
|Place=AMER
|Label=GENERATING...
|File=Berck-548-ai.jpg
}}

File:Berck-548-ai.jpg

2026-02-22T20:32:23Z

Mngr:

Asset:20260222202132

2026-02-22T20:22:24Z

Mngr: Created page with "{{Asset |Status=DRAFT |Chapter=CH00 |Place=ALTO |Label=GENERATING... |File=Berck-547-ai.jpg }}"

{{Asset
|Status=DRAFT
|Chapter=CH00
|Place=ALTO
|Label=GENERATING...
|File=Berck-547-ai.jpg
}}

File:Berck-547-ai.jpg

2026-02-22T20:22:03Z

Mngr:

Form:Asset

2026-02-22T20:04:45Z

Mngr:

<noinclude>
Form for creating and editing Asset pages (v2.3 – Phase A, Phase-B-ready)
</noinclude>

{{{info
|page name=Asset:<Asset[Label]>
|no summary
|no preview
|no minor edit
|no watch
|no footer
}}}

{{{for template|Asset}}}

{| class="formtable"

! Status
| {{{field|Status|readonly|default=DRAFT}}}
|-

! Chapter (*)
| {{{field|Chapter
|input type=combobox
|values from namespace=Chapter
|existing values only
}}}
|-

! Place
| {{{field|Place
|input type=combobox
|values from namespace=Place
|existing values only
|placeholder=Use Organisation instead
}}}
|-

! Organisation
| {{{field|Organisation
|input type=combobox
|values from namespace=Organisation
|existing values only
|placeholder=Use Place instead
}}}
|-

! Identifier
| {{{field|Label|readonly}}}
|-

! Sequence
| {{{field|Sequence|readonly}}}
|-

! File
| {{{field|File
|input type=page
|namespace=File
|uploadable=yes
}}}
|-

! Original filename
| {{{field|OriginalFilename|readonly}}}
|-

! Asset type
| {{{field|AssetType
|input type=combobox
|values from namespace=AssetType
|existing values only
}}}
|-

! Parent asset
| {{{field|Parent
|input type=combobox
|values from namespace=Asset
|existing values only
|placeholder=Top level
}}}
|-

! Description
| {{{field|Description|input type=textarea}}}
|-

! Notes
| {{{field|Notes|input type=textarea}}}

|}


{{#ifeq: {{{Status|DRAFT}}} | DRAFT |
{{{standard input|save|label=Save Draft}}}
}}


{{#ifeq: {{{Status|}}} | READY |
{{{standard input|save|label=🔒 Finalize Asset (irreversible)}}}
}}

{{{end template}}}

ICT:FinalConfig - Asset - v2.3 design proposal

2026-02-22T19:46:51Z

Mngr:

Asset:20260222193244

2026-02-22T19:36:25Z

Mngr: Created page with "{{Asset |Status=DRAFT |Chapter=CH00 |Place=ALTO |Label=CH00-ALTO-0001 |File=CH00-ALTO-0001.jpg |Description=TBD |Notes=TBD }}"

{{Asset
|Status=DRAFT
|Chapter=CH00
|Place=ALTO
|Label=CH00-ALTO-0001
|File=CH00-ALTO-0001.jpg
|Description=TBD
|Notes=TBD
}}

File:CH00-ALTO-0001.jpg

2026-02-22T19:36:25Z

Mngr: Mngr moved page File:Berck240-ai.jpg to File:CH00-ALTO-0001.jpg without leaving a redirect: Heritage Auto-Rename

File:CH00-ALTO-0001.jpg

2026-02-22T19:36:03Z

Mngr:

Form:Asset

2026-02-22T19:31:35Z

Mngr:

<noinclude>
Form for creating and editing Asset pages (v2.3 – Phase A)
</noinclude>

{{{info
|page name=Asset:<Asset[Label]>
|no summary
|no preview
|no minor edit
|no watch
|no footer
}}}

{{{for template|Asset}}}

{| class="formtable"

! Status
| {{{field|Status|readonly|default=DRAFT}}}
|-

! Chapter (*)
| {{{field|Chapter
|input type=combobox
|values from namespace=Chapter
|existing values only
}}}
|-

! Place
| {{{field|Place
|input type=combobox
|values from namespace=Place
|existing values only
|placeholder=Use Organisation instead
}}}
|-

! Organisation
| {{{field|Organisation
|input type=combobox
|values from namespace=Organisation
|existing values only
|placeholder=Use Place instead
}}}
|-

! Identifier
| {{{field|Label|readonly}}}
|-

! Sequence
| {{{field|Sequence|readonly}}}
|-

! File
| {{{field|File
|input type=page
|namespace=File
|uploadable=yes
}}}
|-

! Original filename
| {{{field|OriginalFilename|readonly}}}
|-

! Asset type
| {{{field|AssetType
|input type=combobox
|values from namespace=AssetType
|existing values only
}}}
|-

! Parent asset
| {{{field|Parent
|input type=combobox
|values from namespace=Asset
|existing values only
|placeholder=Top level
}}}
|-

! Description
| {{{field|Description|input type=textarea}}}
|-

! Notes
| {{{field|Notes|input type=textarea}}}

|}

{{{standard input|save}}}

{{{end template}}}

Dashboard:Asset

2026-02-22T19:28:56Z

Mngr:

= 🗂️ Asset Dashboard =

{| class="wikitable sortable"
! Code !! Chapter !! Place !! Organisation !! File !! Type
{{#cargo_query:
tables=Assets
|fields=_pageName,_pageTitle,Chapter,Place,Organisation,File,AssetType
|where=Status='FINAL'
|order by=_pageTitle
|format=template
|template=AssetRow
|named args=yes
|cache=no
}}
|}
{{#formlink:
form=Asset
|target=Asset:{{#time: YmdHis }}
|link text=➕ New Asset
|link type=button
|query string=Asset[Label]=GENERATING...&Asset[File]=
|returnto=Dashboard:Asset
}}

Template:Asset

2026-02-22T19:21:12Z

Mngr:

<noinclude>
Asset data template (v2.3 – Phase A)

{{#cargo_declare:
|_table=Assets
|Code=Page
|Status=String
|Label=String
|Chapter=Page
|Place=Page
|Organisation=Page
|Sequence=Integer
|File=String
|OriginalFilename=String
|Parent=Page
|AssetType=Page
|Description=Text
|Notes=Text
}}
</noinclude>

{{#cargo_store:
|Code={{FULLPAGENAME}}
|Status={{{Status|DRAFT}}}
|Label={{{Label|}}}
|Chapter={{{Chapter|}}}
|Place={{{Place|}}}
|Organisation={{{Organisation|}}}
|Sequence={{{Sequence|}}}
|File={{{File|}}}
|OriginalFilename={{{OriginalFilename|}}}
|Parent={{{Parent|}}}
|AssetType={{{AssetType|}}}
|Description={{{Description|}}}
|Notes={{{Notes|}}}
}}

== {{{Label|}}} ==
{{DISPLAYTITLE:{{{Label}}}}}

'''Status:''' {{{Status|DRAFT}}}

{{#if:{{{File|}}}|'''File:''' [[{{{File}}}]]}}

{{#if:{{{OriginalFilename|}}}|'''Original filename:''' {{{OriginalFilename}}}}}

{{#if:{{{Parent|}}}|'''Parent asset:''' [[{{{Parent}}}]]}}

'''Description:'''
{{{Description|}}}

'''Notes:'''
{{{Notes|}}}