Senden von Patches an den WordPress-Kern: der Prozess des Erstellens und Teilens von Änderungen

Wenn Sie WordPress nutzen, um Ihren Lebensunterhalt zu verdienen und Ihre Geschichte zu erzählen, ist es sehr spannend zu sehen, wie die von Ihnen geschriebenen Änderungen zur WordPress-Codebasis hinzugefügt werden. Ich weiß, das ist für mich.

In diesem Tutorial lernen Sie einige der einfachen Dinge, die Sie wissen müssen, um einen WordPress-Patch zu erstellen, der von der Kernsoftware akzeptiert wird.

Obwohl WordPress eine Open-Source-Software ist, die jeder herunterladen und ändern kann, sind nur eine Handvoll Hauptmitwirkender in der Lage, ihre Änderungen in WordPress selbst zu übernehmen. Wenn Sie eine Änderung an den Kerndateien von WordPress vornehmen möchten, können Sie einen Vorschlag machen, indem Sie ein Ticket erstellen, in dem die vorgeschlagene Änderung detailliert beschrieben wird, und einen Patch anhängen, oder indem Sie den Patch an ein vorhandenes Ticket anhängen.

Eine Patch- oder Diff-Datei ist eine Datei, die die von Ihnen an Ihrem Quellcode vorgenommenen Änderungen detailliert beschreibt und von einem Versionskontrollsystem wie SVN oder GIT verwendet werden kann, um Ihre Änderungen anzuwenden. Patches können einfach über die Befehlszeile oder über GUI-Tools wie SourceTree erstellt werden.

In diesem Artikel werde ich detailliert beschreiben, wie Sie mit der hervorragenden GIT-GUI-Anwendung SourceTree nach der neuesten Version von WordPress suchen und eine Patch-Datei erstellen. Wenn Sie möchten, können Sie ein GUI-Tool Ihrer Wahl oder die Befehlszeile verwenden.

Tickets in Core Trac finden oder erstellen

Wenn Sie einen Patch an WordPress Core senden, muss er an ein Ticket im WordPress Issue Tracker (Trac genannt) angehängt werden. Daher besteht der erste Schritt beim Einreichen eines Patches darin, ein Ticket zu finden oder zu erstellen.

Es ist zwar möglich, dass neue Tickets mit neuen Funktionen akzeptiert werden, aber unwahrscheinlich. WordPress hat Millionen von Benutzern und es macht Sinn, dass große Entwickler bei der Einführung neuer Funktionen vorsichtig sind. Fast alle neuen Funktionen werden mittlerweile zunächst separat als Plugins entwickelt und erst nach umfangreichen Tests und Entwicklung in den Kern integriert.

Der beste Weg, einen Patch zu akzeptieren, besteht darin, einen Patch für ein bestehendes Ticket zu erstellen. Kürzlich wurde Core Trac neu gestaltet, um das Auffinden von Tickets mit einfachen Korrekturen zu erleichtern, die höchstwahrscheinlich in der nächsten Version und Version von WordPress enthalten sein werden.

Einen Fehler melden

Wenn Sie ein neues Ticket in Core Trac erstellen möchten (was eine tolle Sache ist, wenn Sie einen neuen Fehler finden), können Sie das hier tun. Stellen Sie einfach sicher, dass Sie trac nach Berichten zum gleichen Problem durchsuchen, bevor Sie ein neues Ticket erstellen, und überprüfen Sie, ob der Fehler in der neuesten Version von WordPress vorhanden ist.

Ich meine nicht die neueste Version, sondern den Master-Branch in der GIT-Terminologie oder Trunk in der SVN-Terminologie. Ich werde später in diesem Tutorial detailliert beschreiben, wie Sie die neueste Version erhalten.

Sie müssen mindestens das Zusammenfassungsfeld (den Titel des Tickets) und das Beschreibungsfeld, das den Inhalt des Tickets darstellt, ausfüllen. Seien Sie in Ihrer Ticketbeschreibung so aussagekräftig wie möglich.

Beim WordCamp Orlando-Mitwirkenden-Workshop 2013, an dem ich teilgenommen habe, haben die führenden WordPress-Entwickler Mark Jaquith und Andrew Nacin diese Liste großartiger Fehlerberichte erstellt:

• Schritte zur Reproduktion des Problems (beginnend mit dem frühesten Schritt)
• Fehlerbeschreibung
• Was Sie sehen im Vergleich zu dem, was Sie erwarten
• Fehlermeldung oder Fehlercode
• PHP-Fehler (Was sind die Warnungen auf der Seite, was erscheint in den Protokollen, gibt es JavaScript- oder Apache/Nginx-Fehler?)
• Welcher Browser?
• Umgebung (Ihre PHP-Version, MySQL-Apache- oder Nginx-Version)
• Wird dies ohne Plugin und Standard-Theme passieren?
• Screenshots von UI-Problemen
• Klar und prägnant
• Lass uns zunächst auf den Punkt kommen und es dann im Detail erklären.
• Zugehörige Ticketnummer
• Ein Fehler pro Ticket
• Permalink-Einstellungen
• Multisite aktiviert?
• WP_DEBUG oder gleichwertig aktiviert?
• Die Benutzerrolle, die angemeldet war, als das Problem auftrat (oder die Rolle in der Datenbank ändern)

Bedenken Sie, dass nicht alle davon für jeden Fehler relevant sind, aber je mehr relevante Informationen Sie hinzufügen können, desto besser.

Sofern Sie sich nicht sicher sind, was Sie dort einstellen möchten, sollten Sie die unten beschriebenen Felder belassen und die wichtigsten Mitwirkenden damit beauftragen, Tickets entsprechend zu kategorisieren. Ich empfehle die Verwendung des Tags „Hat Patch“ oder „Benötigt Patch“, je nachdem, ob Sie einen Patch zur Behebung des Fehlers anhängen.

Sehen Sie sich das neueste WordPress von GitHub mit GUI-Tools an

Bevor Sie einen Patch für ein Ticket erstellen, ist es sehr wichtig, über die absolut neueste Version von WordPress zu verfügen, da täglich viele Änderungen daran vorgenommen werden. Sofern Sie nicht den neuesten Code verwenden, ist es unmöglich zu wissen, ob Ihr Fix funktioniert hat oder ob der Fehler weiterhin besteht. Wenn Ihr Patch Code ändert, der bereits geändert wurde, wird er möglicherweise nicht akzeptiert.

WordPress wird in SVN verwaltet, aber der Code wird als GIT-Repositorys an zwei Orten gespiegelt:

1. git://core.git.wordpress.org/
2. https://github.com/WordPress/WordPress

GitHub-Repositories sind am einfachsten zu verwenden. Bedenken Sie, dass es sich zwar um ein offizielles GitHub-Repository handelt, es aber dennoch nicht zur Problemverfolgung verwendet wird und Sie keine Pull-Requests an das Repository senden sollten.

Es gibt mehrere Möglichkeiten, die neueste Version von WordPress über SVN oder Git zu erhalten. Persönlich finde ich den einfachsten Weg, ein GitHub-Image mit dem hervorragenden GIT-GUI-Tool SourceTree zu klonen. Dies ist so einfach wie die Auswahl von „Neu/Klonen“ im Menü „Datei“, die Eingabe der Adresse Ihres Git-Repositorys in das Feld „Quellpfad/URL“ und die Angabe des lokalen Pfads für den Klon, der sich in Ihrer XAMMP- oder Vagrant-Testumgebung befindet.

Apropos Vagrant: Die beliebte WordPress-Vagrant-Konfiguration VVV verfügt über eine vorkonfigurierte Testumgebung für den WordPress-Kern, einschließlich der neuesten Code- und Unit-Tests.

Patchdatei erstellen

Nachdem Sie die Änderungen an WordPress vorgenommen haben, die zur Lösung des Problems, das Sie beheben möchten, erforderlich sind, und die Lösung getestet haben, müssen Sie eine Patch-Datei erstellen, um sie in ein Ticket hochzuladen. SourceTree enthält eine Methode zum Erstellen von Patchdateien. Alternativ können Sie die Befehlszeile verwenden.

In SourceTree können Sie eine Patch-Datei erstellen, indem Sie zu Ihrer Arbeitskopie gehen und mit der rechten Maustaste auf die geänderte Datei klicken. Wählen Sie „Patch erstellen“ aus dem Rechtsklick-Menü.

Alternativ können Sie im Terminal zum Stammverzeichnis Ihres WordPress-Repositorys navigieren und mit dem folgenden Befehl ein Diff erstellen:

git diff —非前缀 ~/name.path

Unabhängig davon, wie Sie die Patchdatei erstellen, sollten Sie sie nach der Zielticketnummer benennen. Wenn dies der zweite Patch ist, der zum Ticket hochgeladen wird, hängen Sie .2 an das Ende der Nummer an, wenn dies der dritte ist, hängen Sie .3 an und so weiter. Der fünfte Patch für Ticket Nr. 12358 heißt beispielsweise #12358.5

Laden Sie Patches auf Trac hoch

Da Ihr Patch nun fertig ist, müssen Sie ihn in ein Ticket in Core Trac hochladen. Auf jedem vorhandenen Ticket gibt es unterhalb der Beschreibung die Schaltfläche „Datei anhängen“, mit der Sie einen Patch hochladen können. Fügen Sie auf dem nächsten Bildschirm unbedingt eine Beschreibung der Funktion des Patches hinzu.

Seien Sie geduldig und verständnisvoll

WordPress ist ein riesiges Projekt, daher ist es unvernünftig, eine sofortige Reaktion auf Ihren Patch zu erwarten. Bitte haben Sie auch Verständnis dafür, dass der Standard für an WordPress übermittelte Patches sehr hoch sein muss, um allen Benutzern den bestmöglichen Nutzen zu bieten.

Nachdem Sie einen Patch eingereicht haben, haben Sie bitte etwas Geduld und haben Sie Verständnis für etwaiges Feedback, das Sie erhalten. Die Hauptentwickler sind sehr zugänglich. Wenn Sie Fragen zu einem Patch haben oder warum er nicht verbessert wurde, können Sie sie gerne im IRC-Kanal #wordpress-dev stellen.

Obwohl es frustrierend sein kann, auf eine Antwort zu warten und Änderungen vornehmen zu müssen, lohnt es sich, wenn Ihr Patch an WordPress übermittelt wird und die Beschreibung des Änderungssatzes Sie erkennt.

Das obige ist der detaillierte Inhalt vonSenden von Patches an den WordPress-Kern: der Prozess des Erstellens und Teilens von Änderungen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!