Share
Wenn Sie kurz davor sind, Ihr WordPress-Plugin fertigzustellen, sollten Sie darüber nachdenken, ob Sie es für die breite Öffentlichkeit veröffentlichen möchten. Um ein Plugin veröffentlichen zu können, müssen Sie viel polieren, testen und optimieren, und Sie können leicht einige Schritte vergessen. Dieses Tutorial führt Sie durch das Veröffentlichen des Plugins im WordPress-Plugin-Verzeichnis und dient als Checkliste, mit der Sie sicherstellen können, dass Ihr Plugin zum Zeitpunkt der Veröffentlichung zur Hauptzeit bereit ist.
Einige Schritte, z. B. das Einrichten des Projekts, werden einmal in jedem Plugin-Leben durchgeführt, wobei viele Schritte bei jeder Veröffentlichung einer neuen Version Ihres Plugins wichtig sind. Aus diesem Grund kann es eine gute Idee sein, dieses Tutorial mit einem Lesezeichen zu versehen und beim nächsten Update darauf zurückzukommen.
Das Plugin-Verzeichnis auf WordPress.org ist für WordPress das, was AppStore für das iPhone ist: der einfachste und schnellste, integrierte Weg, Plugins für WordPress zu finden. Während es möglich ist, Ihr Plugin als ZIP-Datei zu veröffentlichen, die von Ihrer eigenen Website heruntergeladen wurde, wird die Integration zwischen WordPress und seinem Plugin-Verzeichnis mit jeder Version enger.
Indem Sie Ihr Plugin über das Plugin-Verzeichnis freigeben, erleichtern Sie es potenziellen Benutzern, Ihr Plugin zu finden und bei der Erstellung neuer Versionen auf dem neuesten Stand zu halten. Sie können das Plugin installieren, ohne das WordPress-Admin-Dashboard beenden zu müssen. Natürlich kennen die meisten WordPress-Benutzer das Plugin-Verzeichnis bereits und suchen es nach Plugins, die ihren Bedürfnissen entsprechen. Auf der anderen Seite erhalten Sie Downloadstatistiken, Feedback der Benutzer über die Plugin-Seite im Plugin-Verzeichnis und ein kostenloses Subversion-Repository zum Speichern der Dateien und des Versionsverlaufs der Plugins.
Gibt es einen Grund, warum Sie Ihr Plugin nicht im Plugin-Verzeichnis hosten? Wenn es sich um ein kommerzielles Plugin handelt, möchten Sie es möglicherweise an einem anderen Ort hosten (eigene Website oder einen eigenen Marktplatz, z. B. Envato's Codecanyon), da das Plugin-Verzeichnis geöffnet ist und keine Unterstützung für die Verwendung von Plugins bietet. Alles, was im WordPress-Plugin-Verzeichnis veröffentlicht wird, kann von jedem frei heruntergeladen werden.
Hier sind die Regeln für Plugins, die in dem Verzeichnis gehostet werden, den Anweisungen des Plugin-Verzeichnisses entnommen:
Es gibt nur einige Einschränkungen:
Nachdem Sie sich entschieden haben, Ihr Plugin im WordPress-Plugin-Verzeichnis zu hosten, müssen Sie zunächst ein WordPress.org-Benutzerkonto erstellen. Um eines zu erhalten, besuchen Sie das Plugin-Verzeichnis und klicken Sie auf "Registrieren" Link oben rechts auf der Seite, rechts neben der Anmeldeaufforderung.
Nachdem Sie Ihr Benutzerkonto registriert haben, können Sie WordPress auffordern, Ihr Plugin hinzuzufügen, indem Sie diesem Link folgen, der zu einer Seite führt, die wie in der Abbildung unten aussieht.
Füllen Sie das Formular aus und erklären Sie kurz, worum es in Ihrem Plugin geht. Seien Sie so genau wie Sie können, während Sie sich innerhalb einer angemessenen Länge befinden. Wenn Ihr Plugin bereits über eine Website verfügt, geben Sie die URL in das Feld "Plugin-URL" ein.
Bevor Ihr Projekt erstellt wird, wird ein Mitarbeiter von WordPress Ihre Anfrage lesen und genehmigen. WordPress gibt zwar keine Versprechungen ab, wie lange dies dauern könnte, und sagt, dass er sich "in einer vage definierten Zeitspanne" melden wird. Die Zeit wird jedoch in Stunden oder Tagen anstatt in Wochen berechnet - höchstwahrscheinlich haben Sie Ihr Plugin Innerhalb von 24 Stunden nach Absenden der Anfrage eingerichtet.
Sobald Ihr Plugin genehmigt wurde, erhalten Sie eine E-Mail mit der Website Ihres neuen Projekts und der darin enthaltenen SVN-URL. Beachten Sie die Repository-URL, da wir sie in den nächsten Schritten intensiv verwenden werden.
In den folgenden Schritten gehe ich davon aus, dass Sie sich mit SVN zumindest ein wenig auskennen. Wenn Sie also keine Ahnung haben, was SVN ist, überfliegen Sie ein Tutorial, bevor Sie mit dem nächsten Schritt fortfahren.
Auf einem Mac und den meisten Linux-Varianten (wenn nicht gar allen) wird ein Betriebssystem-Befehlszeilen-SVN-Client mitgeliefert. In Windows können Sie entweder den Befehlszeilenclient selbst installieren oder einen grafischen Client wie Tortoise SVN verwenden. Versions ist auf dem Mac ein sehr schöner grafischer Client.
Um das SVN-Repository von WordPress optimal zu nutzen, richten wir es so ein, dass die Entwicklungsversion des Plugins in gespeichert wird
Das Plugin-Verzeichnis liest den Tag, von dem aus Ihre aktuelle stabile Version verteilt werden soll, indem Sie die Datei readme.txt einchecken Kofferraum. Ich werde darauf im nächsten Schritt ausführlicher eingehen, während wir den Inhalt der readme.txt Datei, die im Plugin enthalten sein sollte.
Zuerst gehen wir jedoch die SVN-Befehle durch, die Sie meistens verwenden werden. Machen Sie sich keine Sorgen, wenn Sie keine Befehle in das Terminal schreiben möchten. Verwenden Sie stattdessen Ihren bevorzugten grafischen SVN-Client.
Beginnen wir mit dem Auschecken des Projekts von SVN. Im Moment ist das Projekt noch leer, sodass Ihrem Computer nur ein leeres Verzeichnis hinzugefügt wird.
$ svn co http: //[email protected]/ihr-plugin/trunk local-path
Kopieren oder verschieben Sie den Plugin-Code in das Verzeichnis (local-path), das mit dem Befehl svn erstellt wurde, und fügen Sie die Dateien dem SVN hinzu. Geben Sie im Verzeichnis Folgendes ein:
$ svn add file-path
Dateipfad kann ein Pfad zu einer bestimmten Datei sein oder ein Platzhalterzeichen wie * .php. Dadurch werden die Dateien markiert, die beim nächsten svn-Commit zum SVN-Repository hinzugefügt werden sollen - noch ist nichts festgeschrieben. Wenn Sie nicht sicher sind, welche Dateien Sie bereits hinzugefügt haben, können Sie den SVN-Status aller Dateien im aktuellen Arbeitsverzeichnis überprüfen:
$ svn status
Wenn Sie alles an das SVN-Repository senden möchten, übergeben Sie die Dateien schließlich. Scheuen Sie sich nicht, häufig ein Commit durchzuführen: Solange das "Stable-Tag" auf ein anderes Verzeichnis als Trunk verweist, haben Ihre Commits keine Auswirkungen auf die bereits veröffentlichte Version. Auf diese Weise sind Sie sicher, falls Sie Ihre lokale Kopie des Codes aus irgendeinem Grund verlieren.
$ svn commit -m "Eine kurze Erklärung zu den Änderungen"
Bevor Ihr Projekt im Plugin-Verzeichnis angezeigt werden kann, müssen Sie noch die Datei readme.txt hinzufügen. Bevor wir uns dem widmen, ist es an der Zeit, Ihr Plugin zu testen.
Auch wenn Ihre Benutzer nicht dafür bezahlen, Ihr Plugin zu verwenden, ist die Veröffentlichung eines Plugins ohne vorherige Prüfung nie eine gute Idee. In Open Source tolerieren die Leute hin und wieder einige fehlerhafte Releases, wenn Sie Ihre Fehler schnell beheben und schnell auf ihre Fehlerberichte reagieren. Wenn jedoch bei jeder einzelnen Version schwerwiegende Fehler auftreten, sind Ihre Benutzer früher oder später dabei wird zu anderen ähnlichen Plugins übergehen.
Gleichzeitig müssen wir bedenken, dass wir als Einzelentwickler oder kleine Teams nur über begrenzte Testressourcen verfügen. Wenn Sie Glück haben, können Sie jemand außerhalb des Teams testen, um Ihr Plugin zu testen, aber oftmals ist es nur der Entwickler, der die Tests durchführt. Aus diesem Grund ist es wichtig, einen klaren und einfachen, umsetzbaren Testplan zu erstellen.
Um einen zu erstellen, gehen Sie die folgenden Ratschläge durch, wählen Sie die Tipps aus, die für Sie geeignet sind, und passen Sie diese an Ihre eigenen Erfahrungen und die Besonderheiten des Plugins an, das Sie gerade veröffentlichen werden.
Ich bin der erste, der zugibt, dass ich kein perfekter Entwickler bin. Obwohl ich meine Schwachstellen kenne, neige ich dazu, meine Fehler zu wiederholen. Deshalb versuche ich in meinem Testverfahren, eine aktuelle Liste der Fehlertypen zu führen, die am häufigsten in meinem Code vorkommen und vor jedem Release zu testen sind, um meine häufigsten Fehler zu finden.
Das nennt man Regressionstests, Und es ist eine der wichtigsten Formen des Tests: Normalerweise werden neue Funktionen bei der Entwicklung ziemlich gut getestet, gleichzeitig können Sie jedoch Fehler in andere Teile des Codes einführen, die Sie bereits als abgeschlossen angesehen haben.
Um diese Fehler zu erkennen, erstellen Sie eine Liste von Tests zur Überprüfung der Kernfunktionalität Ihres Plugins und gehen Sie die Liste vor jeder Version durch, auch wenn Ihre Änderungen sie nicht berührt hätten.
Einige der Fehler treten nur bei neuen Benutzern auf, die das Plugin zum ersten Mal installieren, während andere nur die Benutzer stören, die ein Upgrade von einer früheren Version durchführen. Einige Fehler treten nur in einer Umgebung mit mehreren Benutzern auf und so weiter.
Um sicherzustellen, dass so viele Probleme wie möglich auftauchen, sollten Sie verschiedene Testumgebungen erstellen, mindestens eine mit einer vorhandenen Version Ihres Plugins und die andere eine saubere WordPress-Installation.
Wenn Sie wissen, dass Ihre nächste Version neue Datenbanktabellen erstellt oder vorhandene ändert, prüfen Sie sorgfältig, ob die erwarteten Änderungen tatsächlich zutreffen und die Datenbank den korrekten Endzustand erreicht. Mein Testverfahren sagt über die Datenbankstruktur aus:
Wenn sich die DB-Struktur geändert hat:
- Testen Sie das Datenbank-Upgrade, ohne das Plugin zu deaktivieren
- Testen Sie das Datenbank-Upgrade mit Deaktivierung / Reaktivierung
Dies sind Zustände, die Sie nicht bemerken, wenn Sie das Plugin nur so ausführen, wie es beabsichtigt war. Daher kann es eine Weile dauern, bis Sie die Fehler feststellen, sofern Sie nicht absichtlich darauf testen.
Dies ist nicht etwas, das Sie in einem Fehlerbehandlungscode sehen möchten, der den Fehlerfall ordnungsgemäß behandeln soll:
Um sicherzustellen, dass Ihr Plugin mit Änderungen in der neuesten WordPress-Version funktioniert, sollten Sie Ihre Testumgebung immer auf die neueste Version aktualisieren, bevor Sie die letzte Testrunde durchführen.
Gehen Sie das Benutzerfeedback durch und prüfen Sie, ob es noch Fehler gibt, die Sie noch nicht angesprochen haben. Ignorieren Sie Funktionsanfragen für jetzt (notieren Sie sie jedoch, damit Sie sie bei der Planung der nächsten Version als Eingabe verwenden können), da Sie sowieso nicht alles in einer Version tun können. Glauben Sie Ihren Benutzern immer, wenn sie sagen, dass sie einen Fehler gefunden haben, aber haben Sie keine Angst, nach weiteren Informationen zu fragen, um den Fehler zu ermitteln.
Wenn Ihr Plugin HTML oder CSS schreibt, entscheiden Sie sich für eine Reihe von unterstützten Browsern, und testen Sie Ihr Plugin vor jeder Version auf diesen Browsern.
Einige potenzielle Probleme lassen sich leichter durch das Betrachten des Codes als durch Testen finden. Daher ist es ebenso wie beim Testen eine gute Idee, die Schwachstellen zu verfolgen und eine Liste der Dinge aufzuschreiben, die vor der Veröffentlichung des Plugins überprüft werden müssen. Wenn Sie mehr Versionen freigeben, erhalten Sie mehr Informationen darüber, was in diesem Projekt unbedingt getestet werden muss. Aktualisieren Sie daher die Liste, während Sie etwas lernen, einige Dinge herausnehmen und andere hinzufügen.
Hier sind einige Ideen, die ich aus eigener Erfahrung überprüfen muss:
Wenn Sie mit Formularen arbeiten, die vom Benutzer bereitgestellt werden, stellen Sie sicher, dass Sie die Attribute in der einfachsten Form ordnungsgemäß überprüfen, indem Sie die Option esc_attr Methode.
$ user_name = esc_attr ($ _ POST ["Benutzername"]);
Wenn Ihr Plugin nicht mithilfe von Objekten geschrieben wurde, befinden sich alle Funktionen in demselben Namespace wie der Rest des Codes in WordPress und installierte Plugins. Um zu verhindern, dass Ihre Funktionsnamen mit denen von WordPress oder anderen Plugins kollidieren, stellen Sie ihnen einen kurzen Namen des Plugins voran.
Funktion pluginname_print_error ($ message) ? // ist sicherer als: function print_error ($ message) ?
Gehen Sie alle Ihre TODO- oder FIXME-Kommentare durch, um zu sehen, dass Sie nichts verpasst haben, an dem Sie später arbeiten wollten.
Wenn Ihr Plugin die Lokalisierung unterstützt, gehen Sie vor jeder Version durch die gesamte Zeichenfolge des Plugins, um sicherzustellen, dass sie alle für die Lokalisierung korrekt markiert sind. Dies kann leicht vergessen werden, wenn Sie einem Plugin neue Zeichenfolgen hinzufügen.
Accentsconagua
// Verwende $ text = __ ("Hallo, Welt", "Mein_Plugin"); // statt nur $ text = "Hallo, Welt" // und _e ("Hallo!", "Mein_Plugin"); // statt echo "Hallo!"; Im WordPress-Codex finden Sie ein Dokument, das den Codierungsstil beschreibt, der beim Entwickeln von Plugins für die WordPress-Plattform zu beachten ist. Das Befolgen dieses Dokuments ist zwar nicht obligatorisch, macht es jedoch anderen Entwicklern leichter, Sie mit dem Plugin zu unterstützen.
Stellen Sie sicher, dass jede Datei in Ihrem Plugin den GPL-Header enthält und dass die license.txt der GPL-Lizenz im Hauptordner Ihres Plugins enthalten ist.
/ * Copyright (c) 2011, Ihr Name. Dieses Programm ist freie Software. Sie können es unter den Bedingungen der GNU General Public License, wie von der Free Software Foundation veröffentlicht, weitergeben und / oder ändern. entweder Version 2 der Lizenz oder (nach Ihrer Wahl) eine spätere Version. Dieses Programm wird in der Hoffnung verteilt, dass es nützlich ist, jedoch OHNE JEDE GARANTIE; sogar ohne die implizite Garantie der MARKTFÄHIGKEIT oder EIGNUNG FÜR EINEN BESTIMMTEN ZWECK. Weitere Informationen finden Sie in der GNU General Public License. Sie sollten eine Kopie der GNU General Public License zusammen mit diesem Programm erhalten haben. Wenn nicht, schreiben Sie an die Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. * /
Jedes Plugin, das für das WordPress-Plugin-Verzeichnis festgelegt wurde, muss über ein readme.txt Datei formatiert nach den in dieser Vorlage definierten Regeln. Es ist wichtig, die Formatierung wie folgt zu befolgen: Wenn Sie Ihr Plugin in das Plugin-Verzeichnis schreiben, wird diese Datei automatisch in die Beschreibung des Plugins konvertiert, die beim Durchsuchen von Plugins im Plugin-Verzeichnis angezeigt wird.
Sehen Sie sich beispielsweise an, wie dieses Snippet vom Anfang der Readme.txt-Vorlage in Informationen umgewandelt wird, die dem Plugin-Verzeichnisbenutzer angezeigt werden:
=== Plugin-Name === Mitwirkende: markjaquith, mdawaffe (Dies sollte eine Liste der Benutzer-IDs von wordpress.org sein). Spenden-Link: http://example.com/ Tags: Kommentare, Spam Erforderlich mindestens: 2.8 Getestet bis: 3.1.3 Stabiler Tag: 1_5_4
Kopieren Sie die Vorlage in Ihr Plugin-Verzeichnis und beginnen Sie mit der Bearbeitung mit Informationen zu Ihrem Plugin. Wenn Sie mit der Datei readme.txt zufrieden sind, testen Sie sie mit dem von WordPress bereitgestellten Validator readme.txt, bevor Sie sie an SVN übergeben.
Wenn Sie dies oben auf der Überprüfungsseite sehen, können Sie ein Commit ausführen:
Ich habe das Stable-Tag in dem Schritt erwähnt, in dem wir über die richtige Verwendung von SVN in der Plugin-Entwicklung gesprochen haben. Nun ist es an der Zeit, es zu verwenden: Sie haben Ihr Plugin getestet, Ihren Code überprüft und die Dokumentation geschrieben. Es bleibt nichts übrig, außer das Plugin freizugeben:
Schauen Sie sich die Haupt-PHP-Datei Ihres Plugins an und aktualisieren Sie den Kommentar, indem Sie Ihre Versionsnummer in die "Ausführung:" Feld:
/ * Plugin Name: A Plugin Version: 1.0 Plugin URI: http://wp.tutsplus.com Beschreibung: Mein großartiges Plugin Autor: Jarkko Laine Author URI: http://jarkkolaine.com * /
In readme.txt gibt es zwei Abschnitte, in denen Sie Ihre Versionsänderungen dokumentieren: "Änderungsprotokoll" und "Upgrade-Benachrichtigung."Fügen Sie Changelog einen Abschnitt für Ihre neue Version hinzu, der detaillierte Informationen dazu enthält, welche Änderungen und Fehlerbehebungen in dieser Version enthalten sind. Eine Upgrade-Benachrichtigung enthält eine kurze Zusammenfassung (höchstens 300 Zeichen), aus der hervorgeht, warum ein Update auf diese Version des Plugins erforderlich ist.
Hier ein Beispiel für eine Änderungsprotokollzeile aus meinem Spenden-Plugin:
= 1.5.2 = * Fehlerbehebung: Ein in der vorherigen Version eingeführter Fehler bei der Aktualisierung der Datenbankdatenbank wurde behoben
Immer noch in readme.txt, Schauen Sie in der Zeile nach (fast am Anfang der Datei), in der steht "Stable-Tag:"und aktualisieren Sie die Zeile mit dem Namen des Tags, den Sie für Ihre nächste Version verwenden werden. Meine Konvention bestand darin, den Tag mit der Versionsnummer zu benennen, wobei Punkte durch Unterstriche ersetzt wurden (z. B. wäre der Tag für Version 1.0 1_0). Das funktioniert ziemlich gut, aber noch besser ist es, es mit der Versionsnummer gleichzusetzen:
Stabiler Tag: 1,0
Wenn jemand auf der Seite "Andere Versionen" nach einer älteren Version Ihres Plugins sucht, kann er leicht herausfinden, welches Tag zu welcher Version gehört, wie in diesem Beispiel aus dem beliebtesten Plugin im Plugin-Verzeichnis:
Übertragen Sie Ihre Änderungen in die Haupt-PHP-Datei des Plugins und in die readme.txt. Erstellen Sie dann das Tag, das Sie für Ihr nächstes "Stable-Tag" ausgewählt haben:
$ svn copy http: //[email protected]/ihr-plugin/trunk http: //[email protected]/ihr-plugin/tags/1.0 -m "Markieren einer neuen Version "
Das ist es: die readme.txt in Kofferraum zeigt auf das richtige Tag und Sie müssen nur warten, bis die automatische Software im Plugin-Verzeichnis Ihre Änderungen bemerkt und das Verzeichnis aktualisiert. Es dauert etwa eine halbe Stunde, bis die neue Version aus dem Plugin-Verzeichnis heruntergeladen werden kann, und es dauert noch ein paar Stunden, bis Ihr WordPress-Blog feststellt, dass ein Update für das Plugin verfügbar ist (falls dies ein Update statt des ersten Commits war)..
Sobald Sie das Update im Plugin-Verzeichnis bemerken, laden Sie es herunter und testen Sie es erneut, um sicherzustellen, dass alle Änderungen und Korrekturen korrekt in der Version enthalten sind. Informieren Sie Ihre Freunde und Anhänger über das Plugin und warten Sie, bis Feedback eingeht, und sehen Sie, wie Ihre Downloadstatistiken wachsen.
Wenn Sie anfangen, Feedback zu erhalten, oder wenn Sie eigene Ideen zur Verbesserung des Plugins haben, empfiehlt es sich, alle paar Wochen neue Versionen bereitzustellen. Dies zeigt Ihren Benutzern, dass Ihr Plugin noch am Leben ist und sich in der aktiven Entwicklung befindet, und erhöht die Wahrscheinlichkeit, dass Sie Ihre Zeit in dieses Plugin investieren.
