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.

• 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 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:.
• 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: fertig; Shop-Archiv: läuft, Ablage noch unsauber). Geplant sind Patch Notes, Fandom-Wiki und ein 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.
• Hauptbereiche 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.
  • Shop abbilden: Skins-Galerie mit Bildern, dazu wann etwas saisonal, limitiert oder dauerhaft verfügbar war.
  • Galnet-Archiv: vollständig, deutsch bzw. übersetzt, chronologisch, durchsuchbar.
  • Patch-/Update-Historie von Alpha und Beta bis heute.
  • 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.
  • GalaxyMap von gbiobob (ED3D, GitHub) einbinden, um Informationen auf der Galaxiekarte zu zeigen.
  • Grundrisse und Karten von Stationen, gute Fanprojekte aufbereiten.
  • Eigenes Erscheinungsbild in Schwarz/Orange bzw. mit den Farben von edassets.org. 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.

• DokuWiki „Mort“ (getestet mit 2026-07-14c), Standard-Theme dokuwiki.
• Plugins (Basis): struct, sqlite, wrap, pagenavigation ([<>]), gitbacked, dazu die eigenen structbox und structhide.
• Auf dem früheren Testwiki waren außerdem im Einsatz: move, include, navbar, indexmenu, vshare. Für das dev-wiki prüfen, was davon wirklich gebraucht wird. pagenav warf dort ein PHP-Warning (syntax.php Zeile 41).

====== 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. Schiffe (hangar:ships:) noch umstellen: Dort steht das Bild bisher 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.

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.

• 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).

• 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).
• 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.
• Details: 2026-10-10_dokuwiki-github-sync

Zuweisung: Schiffsseiten unter hangar:ships: ( Zuweisungsmuster im Schema-Editor prüfen, früher hangar:**). Werte und Begriffe nach der Frontier-Schiffsseite.

• 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.
• vehicle_category bzw. eine Rollen-Einteilung nicht verwenden (siehe Vision).
• 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).

• Felder: name, 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).
• Feld picture (Typ Media) für das Hauptbild.
• 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.

• Schiffe und Fahrzeuge: je Typ ein Bereich (ship, srv, fighter, megaship inkl. Carrier), später modules, weapons. Personen und Ingenieure evtl. codex:persons.
• Schiffe: hangar:ships: (41 Seiten im dev-wiki)
• Hersteller: codex:corporations:
• Vorlagen für structbox: wiki:vorlagen:
• Weitere Bereiche im dev-wiki: manual, news, playground, shop, stories, tools.
• Seitennamen dürfen nicht mit „_“ beginnen.

• Problem: alte Struktur hangar/schiffe/adder/…, deutsch/englisch gemischt, Bilder wurden doppelt hochgeladen.
• Vorschlag von Oliver (05.10.): 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. Die alphabetische Sortierung ordnet von selbst.
• Galnet: wiederkehrende Bilder zentral ablegen statt doppelt.
• Namensräume grundsätzlich englisch. Umbenennen später mit dem move-Plugin.
• Bildstruktur endgültig festlegen. Es ist unklar, ob der Vorschlag bestätigt wurde.

Quelle	Stand
Galnet-News	Erledigt (mit ChatGPT): zwei Python-Skripte für das alte System (community.elitedangerous.com) und das neue (elitedangerous.com), alle Sprachen. Ideen dazu: Bilder per SHA256 nur einmal ablegen, Sprachvergleich (DE gegen andere) zum Finden von Veröffentlichungsfehlern, DokuWiki-Artikel pro News. Skripte ins Projekt laden („für die vollständige Sammlung“).
Ingame-Shop	Skript elite_shop_archiver (v4 → v5.x, mit ChatGPT und Gemini). API https://api.zaonce.net/3.0/store/product (~2.345 Produkte). Bilder über image-service.zaonce.net (Base64-JSON mit Bucket frontier-store-media-sync-production). Alte dlc.elitedangerous.com-Pfade liefern 404. Logs pro Lauf, um Neues und Weggefallenes zu erkennen. Problem: Kategorisierung/Ablage. Frontiers Benennung ist chaotisch. Zielstruktur siehe unten. Letzter Stand v5_3 mit get_wiki_path(). Testen.
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.
Patch Notes	geplant: neuere von der Website, ältere aus dem Frontier-Forum (XenForo). Gemini hat ein Skript-Gerüst XenForo → DokuWiki geliefert.
Fandom-Wiki (EN)	geplant: komplett sichern, z. B. mit wikiteam3 dumpgenerator (–images), danach KI-Übersetzung mit Glossar für Fachbegriffe, Umwandlung in DokuWiki-Syntax.
edwiki.de-Backup	ToDo: data/ (pages, media, meta) per FTP sichern.

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.

• 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.
• 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.
• ProcessWire: zu viel Handarbeit beim Einrichten, „ohne sichtbare Artikel“. Bleibt nur als Fallback.
• Drupal, WordPress+ACF, MediaWiki+Cargo, BookStack, Obsidian: geprüft und nicht gewählt. Directus, Strapi und NocoDB scheiden aus, weil sie Node/Docker brauchen.
• Git-Repository im Webroot (wie von Gemini vorgeschlagen): .git war öffentlich abrufbar.

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“).
• 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.

• 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.
• structhide im dev-wiki installieren (falls noch nicht geschehen).
• Schema ships bereinigen (Tippfehler, Dezimalzeichen, ja/nein), Feld picture ergänzen und die Schiffsseiten umstellen. Prüfen, ob manufacturer schon Typ Page ist.
• 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 und Shop-Skript ins Projekt aufnehmen.
• Galnet-Strategie: nur neue News oder auch historische beschaffen? Mehrsprachigkeit: nur Deutsch oder Deutsch + Englisch parallel?
• Skins: Skript weiterbetreiben, manuell oder hybrid?
• 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: Speichern-Button im Konfigurationsmanager oben (Usability).

1. ChatGPT-Export in diese Seite einarbeiten.
2. Schiffe auf das Bildfeld picture umstellen (wie bei den Konzernen).
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
• Frontier-Store-API: https://api.zaonce.net/3.0/store/product
• 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

Das System steht fest: DokuWiki + struct + structbox, WRAP 2/3 + 1/3, Standard-Theme. Bitte keine Systemwechsel mehr vorschlagen (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. Der nächste sinnvolle Schritt ist, einen einzelnen alten Artikel gemeinsam ins neue Muster zu bringen.