Dokumentation · Entwickler-Dokumentation

Richtlinien für Beiträge

Diese Seite erklärt, wie Sie Änderungen am Plugin auf einer öffentlich zugänglichen Ebene beisteuern können. Interne Klassennamen, interne Konstanten und Verweise auf die private Release-Infrastruktur werden hier nicht veröffentlicht.

Wann Sie dieses Dokument verwenden sollten

Lesen Sie dieses Dokument, wenn Sie im Begriff sind:

  • Einen Pull-Request zu erstellen, der einen Fehler behebt, eine Funktion hinzufügt oder die Dokumentation verbessert.
  • Das Plugin in eine neue Sprache zu übersetzen.
  • Einen Sicherheitsbericht einzureichen.

Übersicht

Beiträge werden über Pull-Requests entgegengenommen. Jede Änderung sollte:

  • Der bestehenden Struktur und den Konventionen entsprechen (siehe Coding Standards).
  • Wenn möglich durch Unit-Tests abgedeckt sein (siehe Testing Guide).
  • Übersetzbare Strings unter Verwendung der Textdomain des Plugins enthalten (siehe Internationalization For Developers).
  • Die richtige Bereinigung und Maskierung anwenden (siehe Sanitization And Escaping) und das übergeordnete Sicherheitsmodell respektieren (siehe Security And Capability Checks).
  • Die relevante Dokumentation unter docs/en/ aktualisieren, wenn sich das öffentlich wahrnehmbare Verhalten ändert – und diese Dokumentation öffentlich zugänglich halten.

Anforderungen oder Voraussetzungen

  • Lokal installiertes Git und ein Fork des Repositories.
  • Die im Plugin-Header deklarierten PHP- und WordPress-Versionen.
  • Installiertes Composer für Entwicklungsabhängigkeiten (nur Test-Framework).
  • Eine funktionierende lokale WordPress-Installation zur Validierung von Änderungen, die über die mittels Unit-Tests prüfbare Logik hinausgehen (siehe Local Development Setup).

Schritt-für-Schritt-Anleitung

  1. Forken Sie das Repository und erstellen Sie einen Feature-Branch.
  2. Nehmen Sie Ihre Änderung vor. Befolgen Sie bei Aktualisierungen der Dokumentation die Richtlinien für öffentlich zugängliche Texte: Fügen Sie dem veröffentlichten docs/-Set keine internen Klassennamen, Option-Keys, REST/AJAX-Routennamen, Cron-Hook-Namen, Capability/Nonce-Identifikatoren oder Details zur Release-Infrastruktur hinzu.
  3. Fügen Sie nach Möglichkeit Unit-Tests hinzu oder aktualisieren Sie diese.
  4. Führen Sie die Test-Suite lokal aus, bevor Sie den Pull-Request öffnen.
  5. Öffnen Sie einen Pull-Request von Ihrem Branch aus. Beschreiben Sie die Änderung, die von Ihnen durchgeführten Tests und alle Aktualisierungen der Dokumentation.

Sicherheitsberichte

Wenn Sie glauben, ein Sicherheitsproblem entdeckt zu haben, eröffnen Sie bitte kein öffentliches Issue. Kontaktieren Sie AD Promotion privat, damit der Bericht vor der Veröffentlichung gesichtet und behoben werden kann.

Übersetzungen

Wenn Sie eine Übersetzung beisteuern möchten, basieren Sie Ihre Arbeit auf der POT-Datei des Projekts unter /languages und reichen Sie Ihre .po / .mo-Dateien über den normalen Pull-Request-Prozess ein. Siehe Internationalization For Developers.

Hinweis zur öffentlichen Dokumentation. Diese Seite bietet nur eine allgemeine Integrationsübersicht. Interne Implementierungsdetails, private APIs, Speicherinterna und sicherheitsrelevante Release-Infrastrukturen werden separat gepflegt und sind nicht Teil der öffentlichen Dokumentation.