Skip to main content
Howdy! How can we help you?
Table of Contents
< All Topics
Print

📝 Arbeits-Codex (Yuyo & ChatGPT)

Posted
Updated
Bysmerdjakoff

Pflichten ChatGPT

  • Keine Mutmaßungen: Keine Tabellennamen oder Feldnamen raten. Ich frage explizit nach, wenn unklar.
  • Version selbst ermitteln: Versionsnummer aus Plugin-Header oder readme lesen.
  • „Go“ abwarten: Vor großen Code-Blöcken oder ZIPs frage ich nach deinem „Go“.
  • Minimal ändern: Nur die gewünschten Stellen anfassen, Rest bleibt unberührt.
  • Transparenz: Wenn etwas unklar ist, sage ich es klar.
  • Keine Eigen-Plugins: Neue Plugins nur, wenn du es explizit willst. Sonst nur Vorschlag in Frageform.
  • Track halten: Nach jeder Änderung dokumentiere ich Version, betroffene Funktionen, Tabellen/Felder.
  • Die Konversation der Entwicklung der Plugins, etc. verläuft auf Deutsch. Hingegen wird die Menüführung auf der Website immer in english ausgegeben.
  • Liefert Drop-in ZIPs (bevorzugt). Falls ZIP wirklich nicht möglich ist, dann vollständige Datei („Wall of Code“) zum 1:1 Ersetzen.

Pflichten Yuyo

  • Neueste Basis liefern: Letzte funktionierende oder aktuelle Plugin-Version hochladen.
  • Scope angeben: Klare Ansage, was geändert werden soll („nur Feldname ändern“, „nur Bugfix X“).
  • Tabellenübersicht bereitstellen: Ich sage dir, welche Tabellen/Felder ich brauche → du lieferst mir die echte Struktur.
  • Feedback geben: Nach Tests kurz Rückmeldung, ob es läuft.

Gemeinsame Leitlinien

  • Kleine Schritte: Lieber 1–2 gezielte Änderungen pro Version.
  • Feedback-Schleifen: Iterativ arbeiten.
  • Respekt: Keine Vorwürfe, Fokus auf Lösung.

Support-Plugins

Definition

  • Support-Plugins sind einzelne Dateien oder Module innerhalb eines Haupt-Plugins (z. B. im Ordner inc/), die keine eigenen Plugin-Header haben, aber eigenständig Logik kapseln (z. B. class-fwt-telegram.php).
  • Sie erweitern oder unterstützen das Haupt-Plugin, sind aber kein eigenständiges WordPress-Plugin.

Versionierung

  • Support-Plugins erhalten eine eigene Versionierung im Kommentarblock am Anfang der Datei.
  • Format:
  /* =========================================================
     Support-Plugin: class-fwt-telegram.php
     Update: 21.08.2025, 08:47
     Version: 0.2.0
     Change: Added /start handler (Welcome-Message + chat_id)
     Vorgängerversion: ohne Versionskommentar
     ========================================================= */
  • Neue Versionen werden bei jeder Änderung hochgezählt (Patch-Level: 0.2.1, 0.2.2 …).

Umgang mit bestehenden Dateien

  • Falls eine Datei noch keine Versionierung hat:
  • Beim ersten Update wird Version 0.2.0 eingeführt.
  • Kommentarblock beschreibt kurz die Änderung und vermerkt „Vorgängerversion: ohne Versionskommentar“.
  • Ab diesem Punkt wird die Versionierung konsistent fortgeführt.

Änderungsregeln

  • Änderungen an Support-Plugins werden wie bei Haupt-Plugins iterativ dokumentiert.
  • Wir verändern nur die besprochenen Stellen, Rest bleibt unberührt.
  • Nach jeder Änderung dokumentiere ich:
  • neue Version,
  • betroffene Funktionen,
  • was konkret geändert wurde.

📅 Datumsformat

Grundsatz

  • Darstellung (UI/Texte/Logs für Menschen):
    24th Aug ’25 (Ordinal st/nd/rd/th, engl. Monatskürzel, zweistelliges Jahr mit typografischem Apostroph).
  • Speicherung & interne Vergleiche:
    ISO 8601 (YYYY-MM-DD für Datum, HH:MM:SS für Uhrzeit). Keine Änderung am DB-Format.

Geltungsbereich

  • Gilt ab sofort für alle Plugins/Support-Module, die wir anfassen.
  • Bei jeder Änderung prüfen wir betroffene Stellen und ziehen uneinheitliche Formate glatt.

Verantwortlichkeiten

  • Beide Seiten verpflichten sich, auf uneinheitliche Datumsformate hinzuweisen und deren Vereinheitlichung anzustoßen – für eine konsistente UX.

Implementierungsregeln

  1. Einheitlicher Helper (pro Modul/Datei):
   protected static function format_date($dateYmd) {
       $dt = DateTime::createFromFormat('Y-m-d', $dateYmd);
       if (!$dt) return $dateYmd;
       $day = (int)$dt->format('j');
       $suf = 'th';
       $mod100 = $day % 100;
       if (!in_array($mod100, [11,12,13])) {
           $mod10 = $day % 10;
           if ($mod10 === 1) $suf = 'st';
           elseif ($mod10 === 2) $suf = 'nd';
           elseif ($mod10 === 3) $suf = 'rd';
       }
       return $day.$suf.' '.$dt->format('M').' ’'.$dt->format('y');
   }
  • Nur Anzeige via format_date(); keine Änderungen am DB-Format.
  1. Zeitzone: Anzeige standardmäßig in America/Costa_Rica (Server/WP-TZ beachten).
  2. Code-Änderungen:
  • Vor Ausgabe: esc_html(self::format_date($date)).
  • Keine hart codierten d.m.Y/m/d/Y/usw. im UI-Code.
  1. Versionierung: Jede Anpassung, die Datumsformat-Ausgaben ändert, bekommt einen Changelog-Hinweis („Date format unified“).

Review-Checkliste

  • [ ] Wird überall format_date() genutzt?
  • [ ] Bleibt DB/Compare bei ISO 8601?
  • [ ] Stimmt TZ (America/Costa_Rica)?
  • [ ] Changelog/Version erhöht?

Categories