ci: update GitHub Actions workflow branch master → main

- Add .woodpecker.yml with build+push on main, dry-run on pull_request
- Image target: 192.168.178.6:8083/cschulz/rd13_media_wiki:latest
- Update copilot-instructions.md: GHCR → Forgejo Registry, GH Actions → Woodpecker
- Update README.md: replace GitHub Actions reference with Woodpecker CI

.github/copilot-instructions.md

@@ -0,0 +1,71 @@
+# GitHub Copilot – Project Instructions
+
+## Project
+MediaWiki deployment for rd13 – a self-hosted wiki running in Docker, served via a reverse proxy, with a MariaDB backend.
+
+## Stack
+- Language: PHP (MediaWiki core + extensions), YAML, Dockerfile
+- Framework: MediaWiki
+- Database: MariaDB
+- Infrastructure: Docker Compose, Forgejo (self-hosted Git), Woodpecker CI, Forgejo Container Registry, Linux Server (remote via VS Code Server)
+
+## Architecture
+- Pattern: Containerised deployment (App + DB as separate services)
+- Key constraints: No application code changes – configuration and infrastructure only
+- Image published to: `192.168.178.6:8083/cschulz/rd13_media_wiki:latest` (Forgejo Container Registry)
+- Extensions live in: `wikidata/extensions/`
+- Wiki config: `wikidata/LocalSettings.php`
+- Upload config: `wikidata/uploads.ini`
+
+## Conventions
+- Branch naming: `feat/<ticket>-description`, `fix/<ticket>-description`
+- Commit format: Conventional Commits (`feat|fix|chore|docs|refactor|ci`)
+- Secrets: never in `docker-compose.yml` or `LocalSettings.php` – use `.env` files or Docker secrets
+- CI/CD: Woodpecker CI pipeline defined in `.woodpecker.yml` at repo root
+- Images: always pin with a specific tag, avoid `:latest` in production compose files
+
+## Engineering Process
+
+### Before starting any task
+1. Clarify requirements – user story + acceptance criteria vorhanden?
+2. Impact analysis – welche bestehenden Komponenten sind betroffen?
+3. Architecture check – passt die geplante Lösung zur bestehenden Architektur?
+4. Test strategy – wie wird das Feature getestet?
+
+### Definition of Ready (DoR)
+A task can only be started when:
+- [ ] Acceptance criteria are clear and unambiguous
+- [ ] Non-functional requirements defined (performance, security, scalability)
+- [ ] Architectural approach agreed upon
+- [ ] No unresolved external blockers
+
+### Definition of Done (DoD)
+A task is only done when ALL of the following are true:
+- [ ] Change implements the acceptance criteria
+- [ ] No secrets or credentials in code or config
+- [ ] OWASP Top 10 reviewed
+- [ ] Relevant documentation updated (README, if applicable)
+- [ ] Commit message follows Conventional Commits
+- [ ] Docker image builds successfully (`docker buildx build --platform linux/amd64 .`)
+- [ ] No dead config, no TODOs left behind (or tracked as issues)
+
+## Testing Strategy
+- No unit/integration tests (deployment-only repo)
+- Validation: `docker compose config` for compose syntax
+- Build test: Woodpecker CI pipeline runs `docker buildx build` (dry-run) on PRs, build+push on merge to `main`
+
+## Security
+- No secrets in code or config files – use environment variables / `.env`
+- MediaWiki `$wgSecretKey` and DB passwords must come from env or secrets
+- Validate all extension configurations before enabling
+- Principle of least privilege for all container permissions
+- Dependency vulnerabilities: check before adding new extensions or base image versions
+
+## Documentation Standards
+- Code comments: explain WHY, not WHAT
+- Architecture decisions: write ADR in `docs/adr/` (template: `docs/adr/000-template.md`)
+
+## Non-Functional Requirements
+- Availability: 99% (self-hosted, single node)
+- Data retention: persistent volumes for `wikidata/` and `mdbdata/`
+- Response time: < 2s for wiki page loads

.github/prompts/architecture.prompt.md

@@ -0,0 +1,66 @@
+---
+mode: agent
+description: Architektur-Review und Architecture Decision Record (ADR) erstellen
+tools:
+  - codebase
+  - editFiles
+---
+
+# Architecture Review & ADR
+
+**Entscheidung:** ${input:decision:Welche architektonische Entscheidung steht an?}
+**Kontext:** ${input:context:Warum wird diese Entscheidung gerade getroffen?}
+
+---
+
+## 1. Kontext & Problem
+
+Beschreibe:
+- Den aktuellen Zustand des Systems (relevante Teile lesen mit `codebase`)
+- Was sich ändern soll und warum
+- Welche Constraints existieren (Performance, Security, Teamgröße, Time-to-Market)
+
+## 2. Optionen
+
+Evaluiere **mindestens 3 Ansätze** (inkl. Status-Quo als Option):
+
+### Option A: [Name]
+**Beschreibung:**
+**Vorteile:**
+**Nachteile:**
+**Risiken:**
+
+### Option B: [Name]
+**Beschreibung:**
+**Vorteile:**
+**Nachteile:**
+**Risiken:**
+
+### Option C: [Name / Status Quo beibehalten]
+**Beschreibung:**
+**Vorteile:**
+**Nachteile:**
+**Risiken:**
+
+## 3. Entscheidung
+
+**Gewählte Option:** [A / B / C]
+
+**Begründung:** (Warum ist das die beste Option gegeben den Constraints?)
+
+**Trade-offs die wir bewusst eingehen:**
+
+## 4. Konsequenzen
+
+**Positiv:**
+**Negativ / Akzeptierte Risiken:**
+**Folgeentscheidungen die nötig werden:**
+
+---
+
+## ADR-Datei erstellen
+
+Erstelle die ADR unter `docs/adr/NNN-[kurzer-titel].md` mit obigem Inhalt im
+[MADR-Format](https://adr.github.io/madr/).
+
+Nummerierung: nächste freie Nummer in `docs/adr/` verwenden.

.github/prompts/code-review.prompt.md

@@ -0,0 +1,46 @@
+---
+mode: agent
+description: Gründliches Code-Review – Qualität, Security (OWASP), Performance
+tools:
+  - codebase
+  - problems
+---
+
+# Code Review
+
+**Ziel:** ${input:target:Datei, Funktion oder Feature-Bereich}
+
+## Checkliste
+
+### Korrektheit
+- Logikfehler oder unbehandelte Edge-Cases?
+- Fehlerbehandlung vollständig und sinnvoll?
+- Alle Inputs an Systemgrenzen validiert?
+
+### Security (OWASP Top 10)
+- Injection-Risiken (SQL, Command, XSS)?
+- Secrets oder Credentials im Code?
+- Broken Access Control?
+- Vulnerable Dependencies?
+
+### Performance
+- N+1 Queries oder unnötige DB-Roundtrips?
+- Blocking I/O in async Kontext?
+- Unnötige Re-Renders oder recalculations?
+
+### Code-Qualität
+- Funktionen >50 Zeilen → aufteilen?
+- Duplizierter Code (DRY)?
+- Naming klar und konsistent?
+- Dead Code?
+
+## Output-Format
+
+Für jedes gefundene Problem:
+```
+[CRITICAL|HIGH|MEDIUM|LOW] datei.ts:42
+Problem: ...
+Fix: ...
+```
+
+Abschluss: Gesamtbewertung (1–10) + die 3 wichtigsten Maßnahmen.

.github/prompts/debug.prompt.md

@@ -0,0 +1,32 @@
+---
+mode: agent
+description: Root-Cause-Analyse und gezielter Fix für Bugs und unerwartetes Verhalten
+tools:
+  - codebase
+  - editFiles
+  - runCommands
+  - problems
+  - terminalLastCommand
+---
+
+# Debug & Fix
+
+**Problem:** ${input:problem:Beschreibe den Fehler oder das unerwartete Verhalten}
+
+**Fehlermeldung / Stack-Trace** (optional einfügen):
+```
+${input:stacktrace:Stack-Trace oder Fehlermeldung hier – oder leer lassen}
+```
+
+## Debugging-Strategie
+
+1. **Reproduce** – Unter welchen Bedingungen tritt der Fehler auf?
+2. **Isolate** – Kleinsten betroffenen Code-Bereich identifizieren
+3. **Root Cause** – Eigentliche Ursache finden (nicht nur Symptom bekämpfen)
+4. **Fix** – Minimaler, gezielter Fix ohne Refactoring nebenbei
+5. **Verify** – Fix löst das Problem, keine Regression
+
+## Regeln
+- Nicht den ersten offensichtlichen Fix wählen – erst Root Cause verstehen
+- Nie mehr Code ändern als für den Fix notwendig
+- Wenn der Fix >10 Zeilen braucht: hinterfrage ob das Symptom nicht woanders liegt

.github/prompts/docker.prompt.md

@@ -0,0 +1,30 @@
+---
+mode: agent
+description: Docker / Compose Service analysieren, debuggen oder erweitern
+tools:
+  - codebase
+  - editFiles
+  - runCommands
+  - terminalLastCommand
+---
+
+# Docker / Infrastructure
+
+**Aufgabe:** ${input:task:Was soll analysiert, gefixt oder gebaut werden?}
+
+## Kontext
+- Basis: Docker Compose
+- Umgebung: Linux-Server (remote via VS Code Server)
+- Typische Services: Datenbank, App-Container, Reverse Proxy
+
+## Workflow
+1. Bestehende `docker-compose.yml` und `.env`-Dateien lesen
+2. Logs / Fehlermeldungen analysieren (terminalLastCommand)
+3. Minimale Änderung umsetzen
+4. Validierung: `docker compose config` für Syntax, Service-Status prüfen
+
+## Sicherheitsregeln
+- Keine Secrets in docker-compose.yml – immer `.env` oder Docker Secrets
+- Ports nur soweit nötig exponieren
+- Container nie als root (außer explizit begründet)
+- Images immer mit Tag pinnen (kein `:latest` in Produktion)

.github/prompts/done-check.prompt.md

@@ -0,0 +1,66 @@
+---
+mode: agent
+description: Definition of Done – vollständige Abnahme-Checkliste vor dem Merge
+tools:
+  - codebase
+  - runCommands
+  - problems
+---
+
+# Definition of Done – Abnahme-Check
+
+**Task / Feature:** ${input:task:Was wurde implementiert?}
+
+Führe alle Checks durch. Behebe gefundene Probleme bevor du abschließt.
+
+---
+
+## 1. Funktionalität
+- [ ] Alle Acceptance Criteria erfüllt (gegen ursprüngliche ACs prüfen)
+- [ ] Happy Path funktioniert
+- [ ] Edge Cases behandelt
+- [ ] Error Cases mit sinnvollen Fehlermeldungen
+
+## 2. Code-Qualität
+- [ ] Kein roter Code (`problems`-Tool)
+- [ ] Kein Dead Code, keine auskommentierten Blöcke
+- [ ] Keine TODOs ohne zugehöriges Issue
+- [ ] Funktionen ≤ 50 Zeilen, Klassen ≤ 200 Zeilen
+- [ ] Naming: klar, konsistent, keine Abkürzungen
+
+## 3. Tests
+- [ ] Unit-Tests für alle neuen/geänderten Funktionen
+- [ ] Integration-Tests wo Services zusammenspielen
+- [ ] Alle Tests grün
+- [ ] Keine Tests deaktiviert/übersprungen ohne Begründung
+- [ ] Coverage nicht gesunken
+
+## 4. Security (OWASP Top 10)
+- [ ] Keine Secrets, API-Keys, Passwörter im Code
+- [ ] Alle Inputs an System-Grenzen validiert
+- [ ] SQL/Command-Injection nicht möglich
+- [ ] Auth/Authz korrekt
+- [ ] Keine neuen Abhängigkeiten mit bekannten CVEs
+
+## 5. Dokumentation
+- [ ] Code-Kommentare erklären das WHY (nicht das WHAT)
+- [ ] Public APIs dokumentiert
+- [ ] README aktualisiert (wenn Verhalten sich ändert)
+- [ ] ADR erstellt (wenn architektonische Entscheidung getroffen wurde)
+- [ ] CHANGELOG.md aktualisiert (wenn Release-relevant)
+
+## 6. Git
+- [ ] Commits atomar (ein Commit = eine logische Änderung)
+- [ ] Commit-Messages: Conventional Commits Format
+- [ ] Keine unrelated changes im Branch
+- [ ] Branch up-to-date mit main/master
+
+## 7. Nicht-funktionale Anforderungen
+- [ ] Performance: keine Regression (bekannte Benchmarks)
+- [ ] Keine neuen Warnungen in Logs
+- [ ] Ressourcenverbrauch vertretbar (CPU, Memory, DB-Queries)
+
+---
+
+**Ergebnis:** Wenn alle Punkte ✓ → Task ist Done. Jeden offenen Punkt mit konkretem
+Problem und Fix-Vorschlag benennen.

.github/prompts/new-feature.prompt.md

@@ -0,0 +1,88 @@
+---
+mode: agent
+description: Neues Feature – vollständiger Engineering-Prozess von Requirements bis Commit
+tools:
+  - codebase
+  - editFiles
+  - runCommands
+  - problems
+---
+
+# New Feature – Full Engineering Workflow
+
+**Feature Request:** ${input:feature_description:Beschreibe das gewünschte Feature}
+
+---
+
+## Phase 1 – Requirements Engineering
+
+Bevor eine Zeile Code geschrieben wird:
+
+**User Story:**
+> Als [Rolle] möchte ich [Aktion], damit [Nutzen].
+
+**Acceptance Criteria** (konkret, testbar, kein Interpretationsspielraum):
+- [ ] AC1:
+- [ ] AC2:
+- [ ] AC3:
+
+**Non-Functional Requirements:**
+- Performance: (z.B. Response <200ms unter Last X)
+- Security: (z.B. Auth erforderlich, Input-Validierung)
+- Scalability: (z.B. muss bei Y gleichzeitigen Usern funktionieren)
+
+**Out of Scope** (explizit ausschließen):
+-
+
+→ Prüfe: Sind alle ACs klar und unambiguös? Wenn nicht, stelle Rückfragen.
+
+---
+
+## Phase 2 – Architecture Review
+
+**Bestandsanalyse:** Lies relevante bestehende Dateien mit dem `codebase`-Tool.
+
+**Ansätze** (mindestens 2 evaluieren):
+| Ansatz | Vorteile | Nachteile | Empfehlung |
+|---|---|---|---|
+| A | | | |
+| B | | | |
+
+**Entscheidung:** [Begründung warum Ansatz X gewählt wird]
+
+**Impact Analysis:**
+- Welche bestehenden Komponenten werden berührt?
+- Gibt es Breaking Changes?
+- Datenbankmigrationen erforderlich?
+
+---
+
+## Phase 3 – Implementation
+
+Implementiere gemäß dem gewählten Ansatz. Halte dich strikt an:
+- Bestehende Code-Patterns und Naming-Konventionen
+- Kein Code außerhalb des definierten Scopes
+- Jeden Schritt kompilierbar lassen
+
+---
+
+## Phase 4 – Tests (nicht überspringen)
+
+Test-Strategie für dieses Feature:
+- **Unit Tests:** Alle neuen Funktionen mit Arrange/Act/Assert
+- **Integration Tests:** Zusammenspiel der Komponenten
+- **Edge Cases:** Leer-Input, Grenzwerte, Fehlerszenarien
+
+Tests müssen grün sein bevor weitergemacht wird.
+
+---
+
+## Phase 5 – Definition of Done
+
+Bevor der Task als abgeschlossen gilt:
+- [ ] Alle Acceptance Criteria erfüllt
+- [ ] Alle Tests grün, keine `problems`-Fehler
+- [ ] Keine Secrets im Code
+- [ ] OWASP Top 10 geprüft
+- [ ] Dokumentation aktualisiert (README / API-Docs / ADR falls nötig)
+- [ ] Commit mit Conventional Commits Format erstellt

.github/prompts/refactor.prompt.md

@@ -0,0 +1,33 @@
+---
+mode: agent
+description: Refactoring – Code verbessern ohne Verhalten zu ändern
+tools:
+  - codebase
+  - editFiles
+  - problems
+---
+
+# Refactoring
+
+**Ziel:** ${input:target:Was soll refactored werden und warum?}
+
+## Grundregeln (nicht verhandelbar)
+- **Kein Behavior-Change** – Tests müssen vorher und nachher grün sein
+- Scope klar definieren – nichts außerhalb des Ziels anfassen
+- Inkrementell vorgehen – nach jedem Schritt kompilierbar/lauffähig
+
+## Was ist erwünscht?
+Wähle was zutrifft (oder beschreibe selbst):
+- Lesbarkeit verbessern (Naming, Struktur)
+- Duplizierung eliminieren (DRY)
+- Komplexität reduzieren (Cyclomatic Complexity)
+- Performance-kritischen Pfad optimieren
+- Testbarkeit erhöhen (Dependency Injection, Pure Functions)
+
+## Prozess
+1. Analyse: Aktuelle Probleme konkret benennen
+2. Plan: Welche Änderungen in welcher Reihenfolge
+3. Durchführung: Schrittweise, jeder Schritt single-purpose
+4. Verifikation: `problems`-Tool, kein roter Code
+
+Nach dem Refactoring: diff-Zusammenfassung mit Begründung für jede wesentliche Änderung.

.github/prompts/requirements.prompt.md

@@ -0,0 +1,73 @@
+---
+mode: agent
+description: Requirements Engineering Workshop – User Stories, ACs und NFRs erarbeiten
+tools:
+  - codebase
+---
+
+# Requirements Engineering Workshop
+
+**Ausgangspunkt:** ${input:raw_request:Was wurde grob angefragt oder gewünscht?}
+
+Führe einen strukturierten Requirements-Workshop durch. Stelle Rückfragen wo nötig,
+aber arbeite so weit wie möglich mit dem vorhandenen Kontext.
+
+---
+
+## 1. Problem Statement
+
+**Problem:** Was ist das eigentliche Problem, das gelöst werden soll?
+**Betroffene Nutzer:** Wer hat dieses Problem?
+**Aktueller Workaround:** Wie lösen Nutzer das Problem heute?
+**Impact:** Was passiert wenn wir es nicht lösen?
+
+## 2. User Stories
+
+Erstelle User Stories im Format:
+> Als **[Rolle]** möchte ich **[Aktion/Feature]**, damit **[geschäftlicher Nutzen]**.
+
+Identifiziere: Wer sind die Nutzer-Rollen in diesem System?
+
+## 3. Acceptance Criteria
+
+Für jede User Story: konkrete, testbare, unambiguöse ACs.
+
+**Format:** `Given [Vorbedingung], When [Aktion], Then [Erwartetes Ergebnis]`
+
+Checkliste für gute ACs:
+- [ ] Eindeutig – nur eine mögliche Interpretation
+- [ ] Testbar – kann automatisch oder manuell verifiziert werden
+- [ ] Vollständig – Happy Path + wichtigste Error-Cases abgedeckt
+- [ ] Kein "wie" – ACs beschreiben WAS, nicht WIE
+
+## 4. Non-Functional Requirements
+
+| Kategorie | Anforderung | Messbar? |
+|---|---|---|
+| Performance | z.B. Response <200ms bei 100 concurrent users | |
+| Security | z.B. Auth erforderlich, keine PII in Logs | |
+| Availability | z.B. 99.9% uptime, <1h RTO | |
+| Scalability | z.B. skaliert bis 10.000 Einträge ohne Perf-Degradation | |
+| Maintainability | z.B. neue Entwickler können in <1h onboarden | |
+
+## 5. Out of Scope (explizit)
+
+Was wird explizit **nicht** gebaut (jetzt):
+-
+
+## 6. Open Questions & Risiken
+
+Offene Fragen die vor dem Start beantwortet werden müssen:
+-
+
+Bekannte Risiken:
+-
+
+## 7. Definition of Ready
+
+Dieser Task ist ready to start wenn:
+- [ ] Alle ACs klar und unambiguös
+- [ ] NFRs definiert
+- [ ] Scope abgegrenzt
+- [ ] Open Questions geklärt
+- [ ] Architektureller Ansatz skizziert

.github/prompts/write-tests.prompt.md

@@ -0,0 +1,34 @@
+---
+mode: agent
+description: Tests schreiben – Unit, Integration oder E2E für bestehenden Code
+tools:
+  - codebase
+  - editFiles
+  - runCommands
+  - problems
+---
+
+# Tests schreiben
+
+**Ziel:** ${input:target:Welcher Code soll getestet werden?}
+**Test-Typ:** ${input:test_type:unit / integration / e2e}
+
+## Strategie
+
+1. **Analyse** – Bestehende Tests lesen, Test-Framework und Patterns verstehen
+2. **Coverage-Lücken** – Welche Fälle sind ungetestet?
+3. **Test-Cases** – Happy Path + Edge Cases + Error Cases definieren
+4. **Implementierung** – Tests schreiben, bestehende Patterns und Helpers nutzen
+5. **Ausführen** – Tests laufen grün
+
+## Gute Tests
+- **Arrange / Act / Assert** – klare Struktur
+- Ein Test = eine Assertion (oder eng verwandte Gruppe)
+- Test-Namen beschreiben das erwartete Verhalten: `should return empty array when input is null`
+- Keine Implementation Details testen – nur Verhalten
+- Keine Mocks wo Echte Objekte möglich sind
+
+## Nicht erwünscht
+- Tests die nur Code paraphrasieren ohne Mehrwert
+- Fragile Tests die bei jedem Refactor brechen
+- Tests mit versteckten Abhängigkeiten zwischen sich

.github/workflows/rd13_media_wiki_docker_build.yml

@@ -2,9 +2,9 @@ name: Multiarch Build Docker CI for the rd13_media_wiki project
 
 on:
   push:
-    branches: [master]
+    branches: [main]
   pull_request:
-    branches: [master]
+    branches: [main]
   workflow_dispatch:
 
 jobs:
@@ -15,11 +15,11 @@ jobs:
         uses: actions/checkout@v2
         with:
           fetch-depth: 0 # fetch depth 0 is required for nx commands to properly compare code against main branch
-      - name: Create local master branch to use as baseline
+      - name: Create local main branch to use as baseline
-        if: github.ref != 'refs/heads/master'
+        if: github.ref != 'refs/heads/main'
-        run: git branch master origin/master
+        run: git branch main origin/main
       - name: install buildx
-        if: github.ref == 'refs/heads/master'
+        if: github.ref == 'refs/heads/main'
         id: buildx
         uses: docker/setup-buildx-action@v1
         with:
@@ -30,7 +30,7 @@ jobs:
       #        with:
       #          platforms: linux/amd64,linux/arm/v7,linux/arm64
       - name: Login to GitHub Container Registry
-        if: github.ref == 'refs/heads/master' || github.event.label.name == 'dependencies'
+        if: github.ref == 'refs/heads/main' || github.event.label.name == 'dependencies'
         uses: docker/login-action@v1
         with:
           registry: ghcr.io
@@ -42,7 +42,7 @@ jobs:
           docker buildx build \
             --platform linux/amd64 .
       - name: build and push the image
-        if: github.ref == 'refs/heads/master'
+        if: github.ref == 'refs/heads/main'
         run: |
           docker buildx build --push \
             --tag ghcr.io/c-schulz-rd13/rd13_media_wiki:latest \

.vscode/extensions.json

@@ -0,0 +1,6 @@
+{
+    "recommendations": [
+        "github.copilot",
+        "github.copilot-chat"
+    ]
+}

.vscode/settings.json

@@ -0,0 +1,11 @@
+{
+    // Repo-specific overrides only. Global Copilot settings are in User/settings.json (Settings Sync).
+    "search.useIgnoreFiles": false,
+    "editor.rulers": [
+        100
+    ],
+    // YAML schema validation
+    "yaml.schemas": {
+        "https://json.schemastore.org/github-workflow.json": ".github/workflows/*.yml"
+    }
+}

.woodpecker.yml

@@ -0,0 +1,26 @@
+steps:
+  # Build and push image on push to main
+  - name: docker-build-push
+    image: woodpeckerci/plugin-docker-buildx
+    settings:
+      registry: 192.168.178.6:8083
+      repo: 192.168.178.6:8083/cschulz/rd13_media_wiki
+      tags: latest
+      platforms: linux/amd64
+      username: cschulz
+      password:
+        from_secret: RD13_MW_DOCKER_BUILD_TOKEN
+    when:
+      - event: push
+        branch: main
+
+  # Build only (no push) on pull requests
+  - name: docker-build-only
+    image: woodpeckerci/plugin-docker-buildx
+    settings:
+      repo: 192.168.178.6:8083/cschulz/rd13_media_wiki
+      platforms: linux/amd64
+      dry_run: true
+    when:
+      - event: pull_request
+        branch: main

README.md

@@ -16,9 +16,11 @@ To start use this command:
 docker run --rm -it -v ./maps_data:/data -p 8091:80 klokantech/openmaptiles-server
 ```
 
-# Update of Nextcloud
+# Update of Media Wiki
 
-Um eine neues Dockerimages mit der neusten NC Version zu bauen kann mann entweder einen neuen Commit im Master machen, falls Code änderungen nötig sind, oder händisch im Github über Actions den Build Workflow auslösen.
+## Update of the MediaWiki Core
+
+Um ein neues Docker-Image mit der neusten Version zu bauen, kann man entweder einen neuen Commit auf `main` pushen (Woodpecker CI baut und pushed das Image automatisch), oder den Build-Workflow händisch in Woodpecker über die UI auslösen.
 
 Nach dem das neue Images gebaut ist, kann es mit gepulled und gestartet werden.
 Hierfür kann man folgende Kommandos nehmen.
@@ -28,3 +30,12 @@ $ sudo docker-compose down
 $ sudo docker-compose pull
 $ sudo docker-compose up -d
 ```
+
+Tried to update to 1.39 from 1.35.5 did not work. Maybe a step by step update is needed now from 1.35.9
+
+## Update of Plugins
+
+This is in the best case done with composer.
+
+### How to bring Plugins into the composer workflow
+

docker-compose.yml

@@ -23,7 +23,7 @@ services:
       - ./wikidata/LocalSettings.php:/var/www/html/LocalSettings.php
     restart: always
   database:
-    image: mariadb:media-wiki-1.35.2
+    image: ghcr.io/c-schulz-rd13/rd13_media_wiki_mariadb:1.35.13
     environment:
       MYSQL_DATABASE: rd13mediawikidb
       MYSQL_USER: wikiuser

dockerfile

@@ -1,4 +1,4 @@
-FROM mediawiki:lts
+FROM mediawiki:1.35
 
 ARG DEBIAN_FRONTEND=noninteractive
 ENV DEBIAN_FRONTEND=noninteractive
@@ -29,6 +29,7 @@ RUN apt install -y fluidsynth
 
 RUN curl https://getcomposer.org/download/2.1.14/composer.phar > composer.phar && mv composer.phar /usr/local/bin/composer && chmod +x /usr/local/bin/composer
 RUN cd /var/www/html && COMPOSER=composer.local.json composer require --no-update mediawiki/maps:~8.0
+RUN cd /var/www/html && COMPOSER=composer.local.json composer require --no-update wikimedia/normalized-exception
 
 ############################################################
 ############################################################
@@ -52,4 +53,4 @@ RUN cd /var/www/html && COMPOSER=composer.local.json composer require --no-updat
 RUN cd /var/www/html
 
 # Start from the webserver neccessary or not? Test from 23.04.2021 -> not needed
-#CMD ["apache2-foreground"]
+CMD ["apache2-foreground"]

example.LocalSettings.php

@@ -36,7 +36,14 @@ $wgServer = "https://wiki.rd13server.de";
 #$wgServer = "http://192.168.178.5:8090";
 
 # May cause Visual editor error Curl 7 in this case change setting
-$wgForceHTTPS = false;
+$wgForceHTTPS = true;
+
+# Suppress Errors because of this issu: https://phabricator.wikimedia.org/T264735
+# After update to MW >=1.38 erneut löschen und Prüfen ob das Problem behoben wurde.
+# Dies unterdruckt nur das Problem: CURLPIPE_HTTP1 is no longer supported
+# This is related to:
+# <b>Warning</b>:  curl_multi_setopt(): CURLPIPE_HTTP1 is no longer supported in <b>/var/www/html/includes/libs/http/MultiHttpClient.php</b> on line <b>455</b><br />
+error_reporting(0);
 
 # Fix to solve net::ERR_HTTP2_PROTOCOL_ERROR 200 in Browsers other than Firefox in Desktops
 $wgDisableOutputCompression  = true;
@@ -325,6 +332,11 @@ $wgPdftoText = '/usr/bin/pdftotext';
 $wgAllowExternalImages = true;
 $wgAllowExternalImagesFrom = [ 'http://127.0.0.1/', 'https://cloud.rd13server.de/' ]; // MediaWiki 1.14+
 
+# Extend preview creation file size and pixel size
+# Maximum amount of virtual memory available to shell processes under Linux, in KiB.
+$wgMaxShellMemory = 307200;
+$wgMaxShellFileSize = 307200;
+
 # Support Video Files and external Video Sources
 ################################################
 wfLoadExtension( 'EmbedVideo' );