Dokumentation · Entwickler-Dokumentation

Richtlinien für Beiträge

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

Wann dieses Dokument zu verwenden ist

Lesen Sie dieses Dokument, wenn Sie im Begriff sind:

  • Einen Pull-Request zu öffnen, 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 öffentlich wahrnehmbares Verhalten ändert – und diese Dokumentation öffentlich sicher halten.

Anforderungen oder Voraussetzungen

  • Lokal installiertes Git und ein Fork des Repositorys.
  • 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 per Unit-Test 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 sicheres Schreiben: 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, öffnen Sie bitte kein öffentliches Issue. Kontaktieren Sie AD Promotion privat, damit der Bericht vor der Offenlegung gesichtet und behoben werden kann.

Übersetzungen

Wenn Sie eine Übersetzung beitragen 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 Bestandteil der öffentlichen Dokumentation.