Diese Seite ist der aktuell gültige Stand des Projekts. Sie ersetzt die verstreuten alten Chats. Wo sich KIs widersprochen haben oder später etwas anders entschieden wurde, gilt das, was hier steht. Punkte, die noch nicht entschieden sind, stehen unter „Offene Punkte“ und sind mit markiert.

• edwiki 2.0 bleibt DokuWiki (aktuelle Version „Mort“) mit struct + sqlite für strukturierte Daten. Entschieden am 08.10. und nochmals am 10.10.2026, nach Ausflügen zu Joomla (09/2026), eigenem Theme und ProcessWire.
• Seitenlayout: WRAP 2/3 Artikel + 1/3 rechts (Bild und Infobox). Die Infobox liefert das eigene Plugin structbox, gefüllt aus Vorlagenseiten im Namensraum wiki:vorlagen:.
• Sieben inhaltliche Hauptbereiche: codex, hangar, manual, news, shop, stories, tools.
• Das Testsystem „dev-wiki“ läuft auf lima-city (nemwar.lima-city.de, Ordner /dokuwiki/). Produktiv soll es edwiki.de bei UD MEDIA ersetzen.
• Die Textseiten werden per gitbacked automatisch nach GitHub (nemwar-ed/edwiki2.0, Branch stable) übertragen, als gemeinsame Wissensbasis für alle KIs.
• Für die Inhalte gibt es eigene Python-Skripte: Galnet alt fertig, Galnet neu fertig (Komplettlauf noch prüfen), Shop-Archiv läuft (Ablage noch unsauber). Geplant bzw. begonnen: Patch Notes, offizielle Timeline, Fandom-Wiki, Backup von edwiki.de.
• Offene Baustelle: alte Artikel von edwiki.de mit der neuen Struktur (Schemas, Vorlagen, Namensräume) in Einklang bringen.

• „Das schwarze Buch von Elite: Dangerous“: ein dauerhaftes, möglichst vollständiges Referenzarchiv aller offiziellen ED-Inhalte, von heute bis zurück zu den Anfängen. Lore aufarbeiten und zusammenfassen ist das wichtigste inhaltliche Ziel.
• Ein „ewiges Informationsgrab“, das auch in Jahren noch wertvoll ist. Zuerst für Oliver selbst, in der Hoffnung, dass andere die Arbeit schätzen.
• edwiki.de wird seit etwa 8–9 Jahren in Handarbeit mit DokuWiki gepflegt. Diese Arbeit soll verbessert, korrigiert und, wo möglich, automatisiert werden.
• Grundsatz der Datensammlung: erst vollständig und verlustfrei sammeln, Quelle direkt am Dokument festhalten, später sortieren. Das Archiv muss beim Download noch nicht perfekt geordnet sein.
• Hauptbereiche: siehe Abschnitt „Hauptbereiche (Namensräume)“ unter Datenmodell. Kern bleiben Schiffe (Hangar), Codex, Shop, Galnet.
• Gewünschte Funktionen und Ideen:
  • Beziehungen erzeugen automatisch Links und Infoboxen, z. B. Schiff → Hersteller, Hersteller → Schiffe und Galnet-Erwähnungen, später Schiff → Modulplätze → Module.
  • Begriffe im Fließtext automatisch verlinken (Idee: Plugin autolink4, z. B. „Faulcon DeLacy“ → codex:corporations:faulcon_delacy). Noch nicht getestet.
  • Shop abbilden: Katalog aller bekannten Kosmetik-Artikel (Skins, Kits, Anzüge …) mit Bildern, dazu wann etwas saisonal, limitiert oder dauerhaft verfügbar war. Laut Oliver ein Alleinstellungsmerkmal.
  • Galnet-Archiv: vollständig, deutsch bzw. übersetzt, chronologisch, durchsuchbar.
  • Patch-/Update-Historie von Alpha und Beta bis heute, mit Change-Logs, damit nachvollziehbar ist, wann was geändert wurde.
  • Codex ergänzen um die Versionen des Frontier-PDF-Handbuchs und um Frontier-YouTube-Tutorials. Die Quellenarten sollen erweiterbar bleiben, z. B. später Tools.
  • Timeline für die zeitlichen Zusammenhänge der Story, mit Text, Bildern und Links. Grundlage: die offizielle Frontier-Zeitlinie (Elite Academy), daneben die passenden Galnet-Artikel und Updates. Werkzeug noch offen (z. B. TimelineJS).
  • GalaxyMap von gbiobob (ED3D, GitHub) einbinden, um Informationen auf der Galaxiekarte zu zeigen. Die Karte braucht JSON; das soll aus den Wiki-Daten erzeugt werden, nicht von Hand gepflegt.
  • Grundrisse und Karten von Stationen, gute Fanprojekte aufbereiten.
  • Konzern-Geschichte abbilden, z. B. Faulcon Manspace + DeLacy Shipworks → Faulcon DeLacy (Vorgänger/Nachfolger).
  • Eigenes Erscheinungsbild in Schwarz/Orange bzw. mit den Farben von edassets.org, altes Puzzle-Globus-Logo vereinfacht weiterverwenden. Zurückgestellt, vorerst gilt das Standard-Theme.
• Bewusst keine Rollen-Einteilung bei Schiffen (Mehrzweck, Kampf …). Begründung von Oliver: Type-6 als Erkunder, Sidewinder bei Distant Worlds 2; „fast jedes Schiff kann alles, nur besser oder schlechter“.

• DokuWiki „Mort“ (getestet mit 2026-07-14c), Standard-Theme dokuwiki.
• Versionsgeschichte im Test: Ein Upgrade auf Mort zusammen mit struct führte am 21.09. zu Fehler 502; danach Neuinstallation mit „Librarian“ 2025-05-14b. Am 01.10. Upgrade auf Mort 2026-07-14c ohne Probleme (struct, sqlite, indexmenu liefen weiter). Das heutige dev-wiki wurde am 09.10. neu aufgesetzt.
• Plugins (Basis): struct, sqlite, wrap, pagenavigation ([<>]), gitbacked, simplenavi (Sidebar), dazu die eigenen structbox und structhide.
• Auf früheren Testwikis waren außerdem im Einsatz: move, include, navbar, indexmenu, vshare, captcha, gallery, translation. Für das dev-wiki prüfen, was davon wirklich gebraucht wird. pagenav warf dort ein PHP-Warning (syntax.php Zeile 41).
• Plugin-Einschätzung (ChatGPT, 25.09.): pagenavigation behalten (Seitenreihen wie Schiffe), tag nur gezielt als Ergänzung zu struct, toctweak eher später.

====== Achilles Corporation ======

<WRAP group>
<WRAP twothirds column box round>
Artikeltext …
</WRAP>

<WRAP third column box round>
{{structbox>corporations}}
</WRAP>
</WRAP>

• Das Hauptbild steckt als struct-Feld picture (Typ Media) in den Daten und erscheint über die Vorlage in der Infobox. Auf der Seite selbst steht im 1/3-WRAP nur noch die Box. Umgesetzt bei den Konzernen und in der Vorlage wiki:vorlagen:ships. Bei den Schiffsseiten sind 5 von 41 umgestellt (adder, anaconda, challenger, chieftain, crusader; Stand GitHub 24.10.). Restliche 36 Schiffsseiten umstellen: Dort steht das Bild noch direkt im WRAP, z. B. {{ :hangar:schiffe:adder:adder.jpg?nolink&200 |}}.
• Die <WRAP group> darum ist Pflicht, sonst zerfallen die Spalten.
• struct-Daten in einer Sidebar funktionieren nicht: Dort zeigt $ID$ auf die Sidebar-Seite, nicht auf den Artikel.

• {{structbox>VORLAGE}} lädt die Seite wiki:vorlagen:VORLAGE und füllt deren Platzhalter $$feld$$ bzw. $$schema.feld$$ mit den struct-Daten der angezeigten Seite.
• Die Gestaltung ist normale Wiki-Syntax in der Vorlage. Das Plugin bringt kein eigenes Layout mit und zerlegt deshalb das Theme nicht.
• Leere Zeilen, leere Zwischenüberschriften und leere Tabellen verschwinden. <structbox-section>…</structbox-section> blendet ganze Abschnitte aus, z. B. eine Produktliste ohne Treffer.
• Die struct-eigene Tabelle wird auf Seiten mit Box ausgeblendet. Vorlagenänderungen wirken sofort. Alte Revisionen zeigen die Daten von damals.
• Nur Seiten aus dem in der Konfiguration eingestellten Namensraum sind einbindbar (Schutz vor dem Auslesen geschützter Seiten). Einstellung namespace = wiki:vorlagen (Standard wäre vorlagen).
• Die Seiten schreiben nur den Vorlagennamen, z. B. {{structbox>corporations}}. Den Namensraum hängt das Plugin selbst davor.
• Version 0.2.0 läuft im dev-wiki. Selbst ausblendende Abschnitte werden in der Konzern-Vorlage genutzt.
• Grundlage im struct-Code: getData($page, null) im struct-Helper liefert die Daten aller der Seite zugewiesenen Schemas. Das hatte ChatGPT am 02.10. herausgefunden.

Grundregeln (vereinbart):

1. Eine Vorlage pro Seitentyp (wiki:vorlagen:ships, wiki:vorlagen:corporations …) mit allen möglichen Abschnitten. Was leer ist, verschwindet.
2. Eine Verknüpfung wird nur an einer Stelle gepflegt: Das Schiff kennt seinen Hersteller, der Hersteller bekommt seine Schiffsliste automatisch über struct list mit filter: manufacturer = $ID$.
3. Lange Listen begrenzen (limit plus Link „alle anzeigen“).
4. Datenstruktur flach halten. struct kann keine Abfragen über mehrere Ebenen.
5. Namensraum und Datenmodell sind unabhängig: Der Namensraum sagt, wo eine Seite liegt; das struct-Schema sagt, was sie ist.

• Blendet deaktivierte struct-Felder im Schema-Editor aus, mit Hinweis „N deaktivierte Felder ausgeblendet“. Schalter in der Konfiguration (hide_disabled). Keine Eingriffe in die Datenbank. Version 0.1.0.
• Hintergrund: struct kann Felder nicht löschen, nur deaktivieren. Deaktivierte Felder erscheinen ohnehin nur im Schema-Editor, nicht in der Ausgabe.

Datei conf/userstyle.css (per FTP angelegt am 11.10.2026). Die Infobox passt sich der Spaltenbreite an, auch auf dem Handy. Kein Scrollbalken mehr.

/* Infobox in der 1/3-Spalte: passt sich der Spaltenbreite an */
.dokuwiki .wrap_third table.inline {
    width: 100%;
    table-layout: fixed;
}
.dokuwiki .wrap_third table.inline img {
    max-width: 100%;
    height: auto;
}
.dokuwiki .wrap_third table.inline td,
.dokuwiki .wrap_third table.inline th {
    overflow-wrap: anywhere;
}

• Nach Änderungen an CSS: im Konfigurationsmanager einmal speichern, damit der CSS-Zwischenspeicher geleert wird.
• conf/ wird nicht nach GitHub übertragen. Diese Seite ist deshalb die einzige Dokumentation der Regeln für KIs.
• Bildgröße in der Box: struct-Feld picture mit width z. B. 600 und height leer, damit nichts beschnitten wird. Das CSS verkleinert passend. agg_width/agg_height gelten nur für Listen und Tabellen über mehrere Seiten (klein halten, z. B. 60).

• Aktuell im dev-wiki: Seite sidebar mit {{simplenavi>}}.
• simplenavi kann keine Namensräume ausblenden (kein exclude-Parameter; hidepages greift nur bei Einträgen ohne Unterseiten). Im Testwiki vom September wurde deshalb indexmenu verwendet, das funktionierte:

====== Navigation ======
{{indexmenu>..|js navbar noscroll notoc tsort nsort skipfile=/sidebar/ skipns=/^(wiki|playground)$/}}

• Entscheiden, ob im dev-wiki wieder indexmenu genutzt wird, damit wiki und playground nicht in der Navigation erscheinen.

• Repository nemwar-ed/edwiki2.0 (privat), Branch stable. Erster Push am 10.10.2026 mit 78 Seiten.
• Das Git-Repository liegt in data/ auf lima-city. Versioniert werden nur pages/ und .gitignore. Medien sind ausgeschlossen (Größe, für KIs irrelevant).
• gitbacked: pushAfterCommit an, repoPath = ./data, ignorePaths = data/media/.
• Regel: Ins Repository schreibt nur das Wiki. Kein direkter Commit oder Upload auf GitHub, sonst schlägt jeder weitere Push fehl.
• Claude kann das Repository lesen, seit 11.10.2026 getestet. Voraussetzungen: GitHub-Konto in claude.ai verbunden und die Claude GitHub App für edwiki2.0 freigegeben (GitHub → Settings → Applications → Claude → Repository access).
• ChatGPT hatte am 10.10. denselben Weg empfohlen: Projektdateien auf GitHub als gemeinsame Wahrheit, nicht die Chatverläufe. Zugriff von ChatGPT, Gemini und Mistral ist noch nicht getestet (siehe Offene Punkte).
• Was darf per FTP geändert werden? conf/, lib/plugins/, lib/tpl/, data/media/: ja, Git merkt davon nichts. data/pages/: nein, Seiten nur im Wiki bearbeiten, sonst landen Änderungen nicht auf GitHub. data/.git/: niemals anfassen.
• Ausblick (ChatGPT, 16.10.): Vergleich mit „OpenWiki“ (Gedächtnis für Coding-Agenten). Das Wiki ist schon ein externes Gedächtnis; was fehlt, ist direkter Agenten-Zugriff, z. B. über das DokuWiki-MCP-Plugin. Nur Idee, nichts installiert.
• Details: 2026-10-10_dokuwiki-github-sync

Festgelegt am 25.09.2026, bestätigt am 10.10.2026. Technische Bereiche (wiki, playground, sidebar) gehören nicht dazu.

• Seitennamen dürfen nicht mit „_“ beginnen.
• Namensräume grundsätzlich englisch. Umbenennen später mit dem move-Plugin.
• Im dev-wiki: hangar:ships: (41 Seiten), codex:corporations: (22 Seiten), Vorlagen unter wiki:vorlagen:.

• hangar:* gilt nur für Seiten direkt in hangar. hangar:** gilt auch für alle Unter-Namensräume (hangar:ships:…, hangar:fighters:…). Am 01.10. getestet.
• Im Schema-Editor prüfen, welches Muster aktuell für ships eingetragen ist (hangar:ships:* oder hangar:**).

Zuweisung: Schiffsseiten unter hangar:ships:. Werte und Begriffe nach der Frontier-Schiffsseite (offizielle Daten; Preis, Klasse oder Rolle gehören nicht ins Schema).

• Feldnamen wie in der Vorlage wiki:vorlagen:ships (Stand 24.10.).
• Einheiten stehen als Postfix mit führendem Leerzeichen in der Feldkonfiguration, nie im Wert.
• Feldnamen englisch (wie die Quellen Frontier, EDSY, Coriolis), Beschriftung deutsch.
• Tippfehler im ersten Schema (landing_pad_requierement, manoevrability, lenght) sollten korrigiert werden. Oliver hat landing_pad_requirement bestätigt. Die anderen beiden prüfen.
• Keine Rollen-Einteilung (kein role/purpose), siehe Vision.
• Widerspruch klären – Fahrzeugart: Mit ChatGPT wurde am 01.10. ein gemeinsames Schema für alle Fahrzeuge festgelegt, mit zwei Auswahlfeldern: vehicle_type = Player / NPC / Thargoid und vehicle_category = Ship / Fighter / SRV / Megaship (SRV als Frontier-Oberbegriff für Scarab, Scorpion, Rhino; Fleet Carrier = Player + Megaship). Das ist keine Rollen-Einteilung. Die 3. Fassung dieser Seite hatte vehicle_category fälschlich mit einer Rolle gleichgesetzt und gestrichen. Die aktuelle Vorlage nutzt beide Felder nicht. Oliver muss entscheiden, ob sie (wieder) ins Schema kommen, bevor Jäger, SRV und Megaschiffe angelegt werden.
• Dezimalzeichen steht auf „.“. Entscheiden, ob „,“ (deutsch).
• Schiffs-Pilot, Umfang (Oliver, 07.10.): aktuelle Werte und Beschreibungstext von der Frontier-Seite, Frontier-Bilder, Fan-Blaupausen (nur noch aus dem englischen Wiki erhältlich) mit Quelle/Urheber pro Bild. Module und Waffen später (EDSY/Coriolis).
• Spätere Schemas für Waffen und Module: Feldnamen mit fachlichem Präfix, z. B. weapon_type, module_type (Vorschlag ChatGPT, 01.10.).

• Felder: name, picture (Typ Media, Hauptbild), type (Schiffshersteller, Megakonzern, Waffenhersteller …), headquarters, founded.
• Zuweisung codex:corporations:*. Beispielseite codex:corporations:faulcon_delacy. Im dev-wiki angelegt (22 Seiten, u. a. Faulcon DeLacy, Core Dynamics, Gutamaya, Supratech).
• Vorlage wiki:vorlagen:corporations (Stand 11.10.): Kopfzeile Name, Zeile mit dem Bild, dann Typ, Hauptsitz und Gegründet. Darunter <structbox-section> mit der Schiffsliste (filter: manufacturer = $ID$). Konzerne ohne Schiffe (z. B. Bank of Zaonce) zeigen den Abschnitt nicht. Kein eigenes Ja/Nein-Feld „Hersteller“ nötig, die Daten entscheiden selbst.
• Weitere Abschnitte (Waffen, Galnet-Erwähnungen) nach demselben Muster ergänzen. Idee: Felder für Vorgänger/Nachfolger.

• Problem: alte Struktur hangar/schiffe/adder/…, deutsch/englisch gemischt, Bilder wurden doppelt hochgeladen. Seitenstruktur und Medienstruktur müssen nicht gleich sein.
• Zwei Vorschläge von Oliver liegen vor:
  • 25.09. (mit ChatGPT): wenige Medien-Namensräume news, shop, codex, hangar; Dateien mit Präfix, z. B. ship_krait_mkii.jpg, ship_krait_mkii_cockpit.jpg. Regel: Namensraum = grober Bereich, Dateiname = Identität, Kategorien = inhaltliche Zuordnung.
  • 05.10. (mit Claude): ein flacher Medien-Namensraum pro Schema, Singular wie das Schema, Dateien <objekt>_<art>.<ext>, z. B. adder.jpg, adder_profile.jpg, adder_schematic_de.png, adder_icon.png.
• Galnet: wiederkehrende Bilder zentral ablegen statt doppelt.
• Entscheidung 10.10.: Bilder und Logos (z. B. die sehr unterschiedlichen Konzern-Logos) werden erst in einem eigenen Update-Schritt vereinheitlicht, wenn die wesentlichen Teile von edwiki 2.0 stehen.
• Bildstruktur endgültig festlegen (einer der beiden Vorschläge).

Alle Skripte liegen in WIKI_ARCHIV/scripts/ und brauchen nur die Python-Standardbibliothek, soweit möglich (eine venv lässt sich auf der SD-Karte nicht anlegen).

Quelle	Stand
Galnet alt (community.elitedangerous.com)	Erledigt (mit ChatGPT, 27.–28.08.): elitearchive.py (Python) bzw. EliteArchive.ps1 (PowerShell 5.1 für die Arbeit). Liest die Tagesseiten /galnet/DD-MMM-YYYY (EN: 2.070), mehrere Artikel pro Tag, Ablage EliteArchive/<Sprache>/<Jahr>/<MM_MON>/ als TXT, vorhandene Dateien werden übersprungen, Log. Nur EN, DE, FR: Für ES/PT/RU gibt es auf der alten Seite keine Pfade (404). Lief fehlerfrei durch.
Galnet neu (elitedangerous.com)	Skript fertig (mit ChatGPT, 28.08.), Vollständigkeit des Komplettlaufs prüfen: elitearchive_new.py. Interne API https://www.elitedangerous.com/elite-webstore-proxy/v1/galnet/articles?date_from=…&date_to=…, Datum aus dated_at. Ablage EliteArchiveNew/<Sprache>/<Jahr>/<Monat>/, Sprachen EN, EN-US, DE, ES, FR, PT-BR, RU. Bilder nur einmal gespeichert, Zuordnung über image_index.csv. Reicht bis Januar 3301 zurück; für 3301 gibt es nur Englisch (EN und EN-US identisch). Ein Lauf brach einmal ab, weil die SD-Karte nicht mehr beschreibbar war; einzelne russische Artikelseiten liefern 404.
Galnet, frühere Versuche	Okt./Nov. 2025: Python-Tool galnet_tool (Linux Mint, Thonny) mit API cms.zaonce.net/<lang>/jsonapi/node/galnet_article, Modul zum Ergänzen fehlender Artikel der Hauptsprache aus anderen Sprachen (Datum als Schlüssel), DeepL-Free-Übersetzung mit Nachholen bei aufgebrauchtem Kontingent. Durch die Skripte oben ersetzt. Ideen daraus bleiben gültig: Bilder per SHA256 nur einmal ablegen, Sprachvergleich zum Finden fehlender oder fehlerhafter Veröffentlichungen, DokuWiki-Artikel pro News. Gemini hatte am 27.08. ebenfalls an einer Python-Fassung gearbeitet.
Galnet-Blog (galnetnews.blogspot.com)	Okt. 2025: Import in einen DokuWiki-Blog (Plugins BlogTNG + tag, Namensraum blog:) über feed.atom und ein Python-Konvertierskript. Bilder und Theme lagen getrennt vor. Klären, ob dieser Bestand noch gebraucht wird.
Ingame-Shop	Skript elite_shop_archiver (v1–v5, mit ChatGPT 30.08.–01.09., dazu Gemini). Versuche, die Shop-Seiten (Nuxt-HTML) zu parsen, sind gescheitert. Funktionierender Weg: API https://api.zaonce.net/3.0/store/product (~2.345 Produkte, Bundles mit Einzel-SKUs). Bilder über image-service.zaonce.net (Base64-JSON mit Bucket frontier-store-media-sync-production); alte dlc.elitedangerous.com-Pfade liefern 404. Ablage in EliteShopArchive/: pro Artikel ein Ordner mit TXT (Name, Preis, Beschreibung, Bildlink) und Bildern, nichts wird überschrieben, Log mit Zeitstempel. Problem: Kategorisierung. Frontiers Benennung ist chaotisch; unklare Artikel lieber in „Other/Unknown“ lassen als falsch einsortieren. Letzter Stand v5_3 mit Olivers get_wiki_path(). Testen.
ARX-Preise	CSV EliteShop_ARX_EUR_Werte.csv (ChatGPT, 01.09.): theoretischer Euro-Wert je ARX-Betrag zwischen günstigstem Paket (54,99 € / 100.000 ARX) und teuerstem (3,49 € / 5.000 ARX). Beispiel 7.000 ARX = 3,85–4,89 €. Im Wiki als „theoretischer EUR-Wert“, nicht als Preis; ARX lassen sich auch erspielen.
Schiffsbilder (Full HD)	direkt unter https://cms-cdn.zaonce.net/<JJJJ-MM>/…shipyard….jpg, aus script#__NUXT_DATA__ der Frontier-Seite (41 URLs). Server-Downloads werden blockiert (403), deshalb ein Browser-Tool ed_ship_downloader.html. Ergebnis bestätigen.
Updates (neu)	Offizielle Update-Artikel unter https://www.elitedangerous.com/news/updates/<version> bzw. /de-DE/neues/updates/<version> (z. B. 4-4-0-3). Reichen nicht weit zurück. Idee: Versionsnummer als Schlüssel. Noch kein Skript.
Patch Notes (alt)	Frontier-Forum forums.frontier.co.uk/forums/elite-dangerous-news/ (ca. 48 Seiten). Beiträge sind mit Labels wie „Patch Notes“, „Update“, „Dev Post“ markiert. Skriptversuch elite_patchnotes_archiver.py (ChatGPT, 01.09.) scheitert: Das Forum steht hinter AWS WAF und liefert Skripten nur eine Challenge-Seite (HTTP 202, 2 KB). Nötig wäre ein echter Browser (z. B. Playwright). Gemini hat ein Skript-Gerüst XenForo → DokuWiki geliefert.
Offizielle Timeline	Frontier, Elite Academy → Zeitlinie: https://www.elitedangerous.com/de-DE/elite-academy#history. Oliver hat den deutschen Text am 28.08. kopiert; ChatGPT hat ihn unverändert als EliteDangerous_Official_Timeline_DE.txt formatiert (mit Quelle und Abrufdatum im Kopf). Ziel: Timeline/DE/official_timeline.txt, keine KI-Ergänzungen.
Fandom-Wiki (EN)	geplant, geparkt: komplett sichern, z. B. mit wikiteam3 dumpgenerator (–images) oder Fandom Special:Export. Kürzester Weg nach DokuWiki: Pandoc (MediaWiki → DokuWiki), ggf. über mediawiki-to-markdown. Alte Konverter (MediaWiki2DokuWiki, mw2dw) sind nicht mehr gepflegt. Danach KI-Übersetzung mit Glossar für Fachbegriffe.
X/Twitter (@EliteDangerous)	verworfen (28.08.): nur mit Login-Cookies/Token und internen GraphQL-Aufrufen, Ergebnis HTTP 403, API kostenpflichtig. Oliver: „dann sollen sie ihre Infos behalten“.
edwiki.de-Backup	ToDo: data/ (pages, media, meta) per FTP sichern. Ältere Sicherungen (dw-backup-*.tar.bz2) liegen im Altbestand auf dem Vivobook. Lesen von außen: ?do=export_raw liefert den Quelltext einzelner Seiten.

Zielstruktur Shop-Ablage (Olivers Vorgabe, nach dem Store-Menü): Equipment → Cosmetic → Model → Colour → Subtype.

• Ships: Pre-Built Ships/<Modell>, Paint Jobs/<Modell>/<Farbe>, Kits/<Modell>, Holo-Kits/<Modell>, Detailing/<Farbe>/<Subtype>, Nameplates/<Subtype>, Cockpit Customisation/<Subtype>, Cockpit Voice Assistants, Decals
• Stations (… Ocellus, Orbis, Outpost)
• Commanders: CMDR Customisation; Suit Customisation (Artemis, Dominator, Flight Suit, Maverick); Weapon Customisation (Karma AR-50, C-44, L-6, P-15; Manticore Executioner, Intimidator, Oppressor, Tormentor; TK Aphelion, Eclipse, Zenith)
• Fleet Carriers: Layouts, Paint Jobs, Detailing (Drive Colours, Holo-Markers), ATC
• Vehicles: Paint Jobs (Scorpion, SRV)
• Frontier-Codenamen zuordnen: lander01 → Nomad, smallcombat01 → Kestrel Mk II, mediumtransport01 → Lynx Highliner, explorer nx → Caspian Explorer.

• Leitfaden für Plugin-Arbeit: leitfaden, README-Seiten: structbox, structhide
• structbox und structhide sollen später als GitHub-Projekte veröffentlicht werden.
• Ausprobierte fremde Themes: ad-hominem (01.10., dunkler Modus gefiel, keine rechte Sidebar), Mikio (rechte Sidebar über die Seite rightsidebar), Bootstrap3 (schön, aber zu „schwer“).

• Eigenes Theme mit rechter Sidebar: Das Float-Layout des Standard-Themes ließ sich nicht sauber erweitern. Arctic ist „hässlich“, der Mikio-Fork war zu groß für den Extension Manager und danach fehlerhaft. Bootstrap3 zu überladen.
• struct-Tabelle per JavaScript in die Sidebar verschieben (ChatGPT, 02.10.): von Oliver abgelehnt („aber doch nicht mit Java…“).
• structtemplating (Twig): braucht Composer (vendor/autoload.php fehlt), ohne SSH nicht nutzbar.
• structtemplate: Der Datenblock steht in jeder Seite selbst. Zuletzt 2022 aktualisiert, für Mort nicht offiziell freigegeben.
• struct-Ausgabe per CSS verstecken oder per Regex aus dem HTML schneiden: zerbrechlich, hat Layout und Edit-Leiste zerstört.
• Joomla (6.1.1, 11.–21.09.): Schiff → Hersteller ließ sich über ein SQL-Auswahlfeld abbilden, aber es gibt keine gepflegte Joomla-DokuWiki-Anbindung mehr (alte Bridges, JFusion tot).
• Tiki Wiki und andere „eierlegende Wollmilchsäue“: von Oliver nicht gewollt.
• ProcessWire: zu viel Handarbeit beim Einrichten, „ohne sichtbare Artikel“. Bleibt nur als Fallback.
• Drupal, WordPress+ACF, MediaWiki+Cargo, BookStack, Obsidian, Wiki.js: geprüft und nicht gewählt. WordPress mag Oliver nicht (Paywalls). Directus, Strapi und NocoDB scheiden aus, weil sie Node/Docker brauchen. Obsidian höchstens als privates Werkzeug, nicht als öffentliche Wissensbasis.
• Git-Repository im Webroot (wie von Gemini vorgeschlagen): .git war öffentlich abrufbar.
• Shop-Seiten per HTML/Nuxt parsen (ChatGPT, 30.08.–01.09.): zu groß und zu instabil, durch die Store-API ersetzt.
• X/Twitter archivieren: siehe Datenquellen.

Diese Aussagen aus alten Chats sind falsch oder überholt. Bitte nicht wiederholen:

• ~~NOSTRUCT~~ gibt es in struct nicht (Claude hatte es erfunden).
• {{struct>ship}} ist keine gültige struct-Syntax.
• {{page>…}} gehört nicht zum DokuWiki-Kern, sondern braucht das include-Plugin.
• „Mort = 2024-02-06“ ist falsch. Mort ist das Release vom 2026-07-14 (2024-02-06 war „Kaos“). Eine Version „Mort 1.4c“ (ChatGPT) gibt es nicht; gemeint ist 2026-07-14c.
• CSS-Klasse .plugin_struct_pagedata (Gemini) existiert so nicht. Der struct-Container heißt <div id="plugin__struct_output">.
• Ein leeres repoPath in gitbacked wird relativ zum DokuWiki-Root aufgelöst, nicht zu data/. Richtig ist ./data.
• „ProcessWire liefert kein Frontend“ (Gemini) ist übertrieben. Die Seiten müssen dort aber per Template selbst gebaut werden.
• Oliver hatte am 07.10. kein Git-Archiv für edwiki geplant (Claude hatte das unterstellt). Der GitHub-Sync vom 10.10. dient nur dem KI-Zugriff.
• ChatGPT (15.10.) schlug für die Hersteller ein Ja/Nein-Feld is_manufacturer, ein Lookup-Feld und den Namensraum code:corporations vor. Gilt nicht: Der Namensraum heißt codex:corporations, manufacturer ist Typ Page, und es gibt bewusst kein Hersteller-Feld beim Konzern.
• „Galnet in allen Sprachen“ stimmt nur für die neue Seite. Die alte Community-Seite hat nur EN, DE, FR.
• hidepages blendet in simplenavi keine Namensräume mit Unterseiten aus (ChatGPT-Vorschlag vom 25.09. hat nicht funktioniert).

• Alte Artikel überführen: ein Muster an EINEM Artikel (Schiff oder Hersteller) gemeinsam durchgehen: Was ist Infobox, was Fließtext, was Verknüpfung? Oliver fühlte sich am 10.10. von der Struktur überfordert. Tempo raus, Schritt für Schritt. Bisheriger Arbeitsweg: Quelltext der alten Seite von Hand kopieren, an die neue Struktur anpassen, struct-Daten von Hand eintragen. Bei ca. 3.000 Seiten schätzt Oliver das auf etwa ein Jahr; deshalb später prüfen, was sich automatisieren lässt.
• Fahrzeugfelder vehicle_type/vehicle_category ins Schema aufnehmen oder nicht (siehe Schema ships).
• Sicherheit edwiki.de: Am 28.08. wurde dort für einen Test die Remote-API (remote) eingeschaltet, remoteuser leer (= alle). Prüfen und wieder ausschalten, falls nicht gebraucht.
• Restliche Schiffsseiten auf structbox und Feld picture umstellen (5 von 41 erledigt).
• structhide im dev-wiki installieren (falls noch nicht geschehen).
• Schema ships bereinigen (Tippfehler, Dezimalzeichen, ja/nein). Prüfen, ob manufacturer schon Typ Page ist und welches Zuweisungsmuster gilt.
• Navigation: simplenavi oder indexmenu (wiki und playground ausblenden).
• Medienstruktur endgültig festlegen.
• DokuWiki- und PHP-Version bei UD MEDIA prüfen (?do=check bzw. phpinfo).
• Shop-Archiver v5_3 testen. Klären, ob das alte Skript noch funktioniert.
• Galnet-Skripte, Shop-Skript, Timeline-TXT und ARX-CSV ins Projekt aufnehmen. Ebenso die ChatGPT-Dateien EDWIKI_2.0_Grundlagen_Hauptkategorien.md und EDWIKI_2.0_StructSidebar_Chat-Zusammenfassung.txt, falls noch vorhanden.
• Galnet-Strategie: Rohdaten liegen vollständig vor; offen ist, ob im Wiki nur Deutsch oder Deutsch + Englisch parallel erscheint, und wie fehlende deutsche Artikel ergänzt werden (übersetzen?).
• Skins: Skript weiterbetreiben, manuell oder hybrid?
• Patch Notes aus dem Forum: Abruf über einen echten Browser (Playwright) testen oder Gemini-Gerüst weiterverfolgen.
• Altbestand auf dem Vivobook: Duplikate bereinigen, edwiki-relevante Dateien (alte Übersetzungen, PDFs) mit dem Wiki abgleichen.
• Zugriff der anderen KIs auf GitHub testen: ChatGPT Go (GitHub-App), Gemini kostenlos („Code importieren“), Mistral Le Chat (GitHub-Connector, Beta).
• Performance von structbox bei Tausenden Galnet-Seiten auf dem Hosting messen, bevor alles migriert wird.
• Optional: DokuWiki-MCP-Plugin (direkter KI-Zugriff auf das Wiki inkl. struct-Daten) auf dem dev-wiki testen. Unklar ist, ob claude.ai statische Bearer-Tokens annimmt.
• Optional: autolink4 testen.
• Optional: Speichern-Button im Konfigurationsmanager oben (Usability).

1. Entscheidung zu vehicle_type/vehicle_category treffen.
2. Restliche Schiffe auf das Bildfeld picture und structbox umstellen.
3. Einen alten edwiki.de-Artikel als Muster überführen.
4. Danach die Schiffe nach diesem Muster nachziehen, dann die Hersteller.
5. Erst wenn das trägt: weitere Bereiche (Codex, Galnet, Shop) und die Performance-Messung.

• dev-wiki: https://nemwar.lima-city.de/ → Server-Pfad /home/webpages/lima-city/nemwar/dokuwiki/
• Cache leeren: ?purge=true an die URL hängen. Nach Änderungen an Plugin-CSS/JS irgendeine Einstellung im Konfigurationsmanager speichern.
• Seite direkt bearbeiten: &do=edit; Quelltext lesen: &do=export_raw
• Frontier-Store-API: https://api.zaonce.net/3.0/store/product
• Frontier-Galnet-API (neu): https://www.elitedangerous.com/elite-webstore-proxy/v1/galnet/articles?date_from=3301-01-01&date_to=3301-01-31
• Frontier-Bilder: https://image-service.zaonce.net/<Base64-JSON> bzw. direkt https://cms-cdn.zaonce.net/<Pfad>
• Werkzeuge: https://github.com/tracker-user/dokuwiki-claude (Vorlage für den Plugin-Leitfaden), DokuWiki-MCP-Plugin https://www.dokuwiki.org/plugin:mcp, Pandoc https://github.com/jgm/pandoc, Czkawka (CachyOS-Paket czkawka-gui)

Das System steht fest: DokuWiki + struct + structbox, WRAP 2/3 + 1/3, Standard-Theme. Bitte keine Systemwechsel mehr vorschlagen (Joomla, ProcessWire, Drupal, eigenes Theme …), das wurde mehrfach durchgespielt und verworfen. Oliver programmiert nicht selbst: Erkläre einfach, plane zuerst, und schreib Code erst nach „leg los“. Gehe in kleinen Schritten vor, er war zuletzt von zu viel Struktur auf einmal überfordert. Recherchiere selbst (GitHub, DokuWiki-Forum, Plugin-Seiten), bevor du etwas vorschlägst, und gib fertige Dateien statt Schnipsel. Der nächste sinnvolle Schritt ist, einen einzelnen alten Artikel gemeinsam ins neue Muster zu bringen.