Willkommen zum letzten Teil dieser Serie. Wenn Sie gerade angekommen sind, überprüfen Sie bitte unsere beiden vorherigen Artikel. Bisher haben wir folgende Themen behandelt:
Tipps für Best Practices in der WordPress-Entwicklung
Weitere Tipps für Best Practices in der WordPress-Entwicklung
In diesem abschließenden Artikel werde ich über drei wichtige Dinge sprechen, die zwar den Plugin-Vorgang nicht beeinträchtigen, sie jedoch unerlässlich sind, wenn Sie ein Qualitäts-Plugin bereitstellen möchten.
Beim Codieren eines Plugins sollten Sie zunächst den Debug-Modus aktivierenwie WordPress empfiehlt. Auf diese Weise sehen Sie alle Fehler, Warnungen und Probleme.
So aktivieren Sie den Debug-Modus einfach in Ihrem wp-config.php
define ('WP_DEBUG', wahr);
Nach dem Neuladen der Site werden alle Warnungen und Probleme zusammen mit anderen Meldungen angezeigt, wie etwa veraltete WordPress-Funktionshinweise. Wenn Sie ein Qualitätsprodukt liefern möchten, stellen Sie sicher, dass die Verwendung des Plug-Ins im Debug-Modus das gleiche Ergebnis bewirkt oder deaktiviert (keine Fehler, Warnungen oder Hinweise)..
Wenn Sie stattdessen die Fehler in einer Datei speichern und nicht im HTML-Code anzeigen möchten, können Sie dies tun, indem Sie sie hinzufügen WP_DEBUG
die folgenden Zeilen.
// Alle Fehler werden in einer debug.log-Protokolldatei im Verzeichnis / wp-content / gespeichert. define ('WP_DEBUG_LOG', true); // Fehler in HTML nicht anzeigen define ('WP_DEBUG_DISPLAY', false);
Eine weitere Debug-Einstellung, die ich häufig verwende und die alle Datenbankabfragen in einem Array speichert, ist die folgende:
define ('SAVEQUERIES', wahr);
Normalerweise verwende ich all diese (besonders die letzte) mit dem Debug Bar-Plugin und der Debug Bar-Konsole. Wenn Sie sie nicht kennen, holen Sie sich eine Kopie und beginnen Sie mit dem Debuggen Ihrer Plugins und Designs. Sie werden sehen, wie einfach es geht.
Sie können auch die Liste der Plugins überprüfen, die ich für die Entwicklung in Wp Favs verwende.
Wenn Sie jeden Aspekt Ihres Plugins oder Themes dokumentieren, werden Ihre Benutzer und Ihr Leben wesentlich einfacher. Sie werden in der Lage sein, das Plugin oder das Thema zum Laufen zu bringen, indem Sie einem Leitfaden oder Video oder einer Kombination aus beidem folgen. Mit Support-Tickets und endlosen E-Mails sparen Sie viel Zeit.
Ich empfehle, die gesamte Dokumentation in Kategorien oder Abschnitte aufzuteilen, die am wichtigsten sind:
Je nach Thema oder Plugin können Sie dann den Rest der Abschnitte oder Kategorien hinzufügen. Wenn Sie die Dokumentationsseite von WordPress Social Invitations überprüfen, werden Sie sehen, was ich meine.
Wenn Sie, wie bereits im vorigen Artikel erwähnt, Filter und Hooks hinzugefügt haben, ist es eine gute Idee, eine Referenzseite für Filter / Aktionen zu erstellen, in der erklärt wird, was sie tun.
Hilfetabellen sind eine weitere Möglichkeit, Ihren Benutzern direkt in Ihrem Plugin Hilfe zu bieten, anstatt sie auf Ihre Website umzuleiten. Sie werden normalerweise verwendet, um Informationen zum aktuell verwendeten Bildschirm bereitzustellen.
Bei einem meiner Plugins mit dem Namen Social PopUP verwende ich zum Beispiel eine Hilfe, um die verfügbaren Kurzwahlen zu erklären.
Wenn Sie in Ihrem Plugin eine Klasse verwenden und die Registerkarte "Hilfe" einem benutzerdefinierten Beitragstyp hinzufügen möchten, können Sie Folgendes tun:
/ ** * Initialisieren Sie das Plugin, indem Sie Admin-Skripts und -Stile laden und eine * Einstellungsseite und ein Menü hinzufügen. * * @since 1.0.0 * / function __construct () […] // Registerkarte "Hilfe" add_action ('load-post.php', array ($ this, 'my_admin_add_help_tab')); / ** * Hilfetitel zum Spucpt-Pfosten-Typ hinzufügen * @since 1.0 * @return void * / function my_admin_add_help_tab () $ screen = get_current_screen (); if ('spucpt'! = $ screen-> id) return; // My_help_tab hinzufügen, wenn Post-Typ spucpt ist $ screen-> add_help_tab (array ('id' => 'my_help_tab', 'title' => __ ('Shortcodes'), 'content' => 'Hallo Inhalt geht hier' ,));
Es ist sehr wichtig, dass Sie überprüfen, ob die aktuelle Bildschirm-ID mit Ihrem benutzerdefinierten Beitragstyp übereinstimmt, oder die Registerkarte "Hilfe" wird überall angezeigt.
Wenn Sie stattdessen eine Optionsseite hinzugefügt haben, können Sie den Code verwenden, der im Codex als Beispiel verwendet wird.
add_help_tab (array ('id' => 'my_help_tab', 'title' => __ ('Registerkarte' Meine Hilfe ''), 'content' => ''. __ ("Der beschreibende Inhalt, der in der Registerkarte" Meine Hilfe "angezeigt wird, wird hier angezeigt."). '
',)); ?>
Meiner Meinung nach sind Registerkarten für Benutzer nicht sehr sichtbar, und die meisten von ihnen wissen gar nicht, dass sie existieren. Es ist jedoch empfehlenswert, einige Hilfszeilen in das Plugin selbst zu integrieren.
Internationalisierung auch bekannt als I18n (es gibt 18 Buchstaben zwischen i und n) ist das Sahnehäubchen eines Plugins oder Themas. Wie Sie WordPress bereits kennen, wird es von Menschen auf der ganzen Welt verwendet. Daher müssen wir zum Zeitpunkt der Bereitstellung eines Plugins oder Designs sicher sein, dass sie problemlos in ihre Muttersprache übersetzt werden können.
Zuerst sollten wir die Bedeutung dieser beiden Wörter lernen, die auch bekannt sind I18n und i10n. Internationalisierung bezieht sich auf den Prozess des Erstellens eines übersetzbaren Plugins oder Themas, wobei Lokalisierung im Wesentlichen der Vorgang ist.
WordPress verwendet die berühmte Gettext-Bibliothek, die in wenigen Worten erklärt wurde. Wir können sagen, dass dies folgendermaßen funktioniert:
Das erste, was Sie tun müssen, ist zu entscheiden Text-Domain das wird verwendet, um alle Ihre Plugin- oder Theme-Übersetzungen zu verpacken. Die Text-Domain sollte zu Ihrem Plugin-Slug passen.
Es gibt mehrere Möglichkeiten, um die übersetzbaren Zeichenfolgen zu erstellen, je nachdem, ob Sie Variablen erstellen, etwas wiederholen usw. Die häufigsten Funktionen sind __ ()
und _e ()
. Nachfolgend einige Beispiele:
// Erstellen einer Variablen $ hello = __ ('Hallo, ich bin eine übersetzbare Zeichenfolge', 'meine-Text-Domäne'); Echo ''. __ ("Hallo, ich bin eine übersetzbare Zeichenfolge", "Meine-Text-Domäne"). '
'; // für ein Echo können Sie _e verwenden ('Hallo, Im übersetzbaren String', 'Meine-Text-Domäne'); // Wenn Sie Variablen in der Zeichenfolge haben, müssen Sie Folgendes tun: printf (__ ('% d Beiträge wurden gelöscht.', 'Meine-Text-Domäne'), $ count); // Oder mehrere Variablen printf (__ ('Ihr Name ist% 1 $ s und Ihr Nachname ist% 2 $ s.', 'Meine-Text-Domäne'), $ name, $ lastname);
Eine weitere coole Funktion, die Sie verwenden können, ist _n ()
was es für Pluralformen verwendet wird. Diese Funktion benötigt 4 Argumente:
Um auf unser vorheriges Beispiel zurückzukommen, sieht Plurals etwa so aus:
printf (_n ('Wir haben einen Beitrag gelöscht.', 'Wir haben% d Beiträge gelöscht.', $ count, 'my-text-domain'), $ count);
Wenn Sie Strings in Ihrem JavaScript übersetzen müssen, können Sie alle Strings mit dem. Übergeben wp_localize_script ()
Funktion, die wir im zweiten Artikel dieser Serie besprochen haben.
wp_enqueue_script ('script-handle',…); wp_localize_script ('script-handle', 'objectL10n', array ('alert' => __ ('Dies ist eine Alarmmeldung', 'meine-Text-Domain')), 'submit' => __ ('Submit', ' my-text-domain '),));
Wir haben bereits den gesamten übersetzbaren String um unser Plugin herum hinzugefügt und jetzt ist es an der Zeit, es zu aktivieren. Um das zu tun, machst du einfach:
function myplugin_init () $ plugin_dir = Basisname (dirname (__FILE__)); load_plugin_textdomain ('my-text-domain', false, $ plugin_dir); add_action ('plugins_loaded', 'myplugin_init');
Dieser Code wird versuchen, eine MO-Datei mit dem Namen "MO" des Plugins zu laden Meine-Text-Domain-
locale
.mo
. Abhängig von Ihren Spracheinstellungen in wp-config.php wird der locale -Teil durch Ihren Sprachcode ersetzt. Zum Beispiel wenn mein wp-config.php
ist wie folgt konfiguriert:
define ('WPLANG', 'es_ES');
Die zu ladende Datei lautet my-text-domain-es_ES.mo
. Für Themes ist es ziemlich ähnlich, Sie müssen nur in Ihr Functions.php
folgende:
load_theme_textdomain ('meine_theme_textdomain');
Das Hauptunterschied ist, dass diese Funktion suchen wird locale .mo
anstatt my_theme_textdomain- locale .mo
wie wir am vorherigen Beispiel gesehen haben.
Weitere Informationen zu l18n finden Sie im WordPress-Codex.
Wir sind am Ende dieser Serie und ich hoffe, es hat Ihnen genauso gut gefallen, wie ich es geschrieben habe. Wie ich bereits sagte, habe ich diese Serie über meine Anfänge als Entwickler geschrieben. Ich habe versucht, alle Informationen zu sammeln, die ich für wichtig halte, um ein gutes Plugin zu erstellen, und fasse in großem Umfang all das zusammen, was bereits im Codex erläutert wurde. Obwohl ich wahrscheinlich viel ausgelassen habe, reicht es für ein solides Fundament aus.
Ich würde mich freuen, wenn Sie Ihre Gedanken, Tipps und Ideen für eine solide Entwicklung in den Kommentaren mitteilen.