Die häufigsten Fehler bei der Entwicklung von WordPress-Themes (und wie man sie behebt)

Veröffentlicht: 2019-05-14

Das Einreichen eines Themes in das Theme-Verzeichnis von WordPress.org ist eine großartige Möglichkeit, deine Arbeit zu teilen und einen Beitrag zur WordPress-Community zu leisten. Derzeit enthält das Verzeichnis über 7000 Themen, von denen das beliebteste mehr als 300.000 aktive Installationen aufweist. (Ohne Twenty____ Themes, die mit WordPress verpackt sind und Installationen in Millionenhöhe haben.)

Bevor Sie Ihr Thema beim Verzeichnis einreichen, ist es wichtig, zuerst den Überprüfungsprozess zu verstehen, denn wenn Ihr Thema diese Anforderungen nicht erfüllt, kann es sofort abgelehnt werden.

Themen mit 3 oder mehr unterschiedlichen Problemen können als nicht genehmigt geschlossen werden. Themenautoren können das Thema jedoch erneut einreichen, sobald sie die Probleme behoben haben.

https://make.wordpress.org/themes/handbook/review/required/

Prüfer sind auf Ihrer Seite und wollen sehen, wie Ihr Thema live geht, sobald es die erforderlichen Standards erfüllt. Wenn Ihr Thema nur geringfügige Probleme hat, die verhindern, dass es in das Verzeichnis aufgenommen wird, wird Ihr Prüfer mit Ihnen zusammenarbeiten, um diese zu beheben.

Wenn Ihr Thema zu viele Probleme aufweist, wird es leider als nicht genehmigt geschlossen. Wenn Sie sich entscheiden, die Probleme zu beheben, können Sie das Design erneut hochladen – es wird jedoch ans Ende der Warteschlange gestellt.

Aus meiner Erfahrung bei der Überprüfung von über 100 Themen konnte ich die häufigsten Probleme identifizieren, die verhindern, dass Themen genehmigt werden. Indem ich diese in diesem Artikel mit Ihnen teile, hoffe ich, dass ich Ihnen helfen kann, zu vermeiden, dass Sie in der Warteschlange hängen bleiben oder abgelehnt werden.

Hochladen Ihres Designs

Wenn Sie ein Design hochladen, wird es zur Überprüfung in die Warteschlange aufgenommen. Im Durchschnitt dauert es zwei Monate, bis Ihr Thema an der Spitze der Warteschlange steht und seine erste Bewertung erhält. Alle Rezensenten sind Freiwillige mit begrenzter Zeit, die zum Ausfüllen von Rezensionen zur Verfügung steht. Eine Vielzahl von Faktoren kann die Wartezeit beeinflussen. Wenn sich mehr Personen freiwillig melden, um Themen zu überprüfen, bewegt sich die Warteschlange schnell. Umgekehrt verlangsamt es die Warteschlange, wenn Themen mit vielen Problemen eingereicht werden.

Indem Sie ein Design einreichen, das alle Anforderungen erfüllt, wird der Überprüfungsprozess viel reibungsloser und Ihr Design wird letztendlich schneller live geschaltet. In diesem Leitfaden werden wir die häufigsten Probleme untersuchen, die Ihr Design in der Warteschlange festhalten und verhindern, dass es genehmigt wird.

Hinweis: Themenautoren, die nachweislich problemfreie Themen eingereicht haben, können sich bewerben, um „vertrauenswürdige Autoren“ zu werden.

Namensprobleme

Wenn Sie ein Design hochladen, wird zuerst geprüft, ob der Name bereits vergeben ist. Häufig wird Ihnen mitgeteilt, dass der von Ihnen gewählte Name bereits vergeben ist, auch wenn Sie kein Thema mit diesem Namen im Verzeichnis sehen können.

Wie kann das sein? Der Grund dafür ist, dass der Test nicht nur das Verzeichnis überprüft, sondern das gesamte WordPress-Ökosystem. Wenn ein Design irgendwo veröffentlicht wurde (Github, ThemeForest usw.) und über 50 aktive Installationen verfügt, kann dieser Name nicht verwendet werden.

Hinweis: Wenn Sie Ihr Thema an anderer Stelle veröffentlicht und mehr als 50 Installationen angesammelt haben, können Sie diesen Namen weiterhin im Verzeichnis verwenden.

Ausgabe ohne Escapezeichen

Theme-Rezensenten nehmen Sicherheit sehr ernst, es gibt sogar eine spezielle Ressource. Über das Schreiben sicherer Themen könnte ein ganzer Artikel geschrieben werden, aber in diesem Abschnitt werden wir einen Aspekt untersuchen: Ausgabe umgehen.

Nicht maskierte Ausgabe setzt Benutzer Ihres Themas einem Risiko aus. Hier ist ein Beispiel für einen Wert ohne Escapezeichen ($title):

 $title = get_option( 'my_custom_title' );
echo '<h2>' . $Titel . '</h2>';

Das Problem mit dem Obigen ist, dass wir zwar wissen, welche Art von Wert $title sein sollte , ein String, aber wir haben nicht überprüft, ob dies der Fall ist.

Wenn es einem Hacker gelungen ist, den Wert von „my_custom_title“ in der Datenbank zu ändern, gibt Ihr Design diesen Wert aus. Dies stellt ein großes Risiko dar, da sie die beabsichtigte Ausgabe durch Inline-Javascript ersetzen könnten:

 alert('Das ist gefährlich');

Die Lösung besteht darin, die gesamte Ausgabe zu maskieren, um sicherzustellen, dass sie nur die Art von Daten enthält, die wir erwarten.

Unser Beispiel könnte wie folgt behoben werden:

 $title = get_option( 'my_custom_title' );
echo '<h2>' . esc_html( $title ) . '</h2>';

Der Nachteil bei der Verwendung von esc_html ist, dass alle HTML-Tags entfernt werden. Wenn $title beispielsweise Fett- oder Kursivschrift enthält:

 $title = 'Dieser Artikel ist <strong>sehr</strong> nützlich';
echo esc_html( $title );

Das Wort „sehr“ wäre im Frontend nicht fett gedruckt; stattdessen würde es den Code <strong>sehr</strong> ausgeben.

Dies veranschaulicht, warum es wichtig ist, die richtigen Escape-Funktionen für den Kontext zu verwenden. Wenn wir etwas HTML in der Ausgabe erwarten, verwenden wir besser wp_kses_post() oder wp_kses() und setzen den Parameter $allowed_html.

Funktionen, die ausgeben, müssen ebenfalls maskiert werden:

 <a href="<?php echo esc_url( get_permalink() ); ?>">

Die Ausnahme sind WordPress-Kernfunktionen, die „the_“ in ihrem Namen enthalten, diese sind normalerweise bereits maskiert.

 Funktion the_permalink( $post = 0 ) {
    /**
     * Filtert die Anzeige des Permalinks für den aktuellen Beitrag.
     *
     * @seit 1.5.0
     * @seit 4.4.0 Parameter `$post` hinzugefügt.
     *
     * @param string $permalink Der Permalink für den aktuellen Beitrag.
     * @param int|WP_Post $post Beitrags-ID, WP_Post-Objekt oder 0. Standardwert 0.
     */
    echo esc_url( apply_filters( 'the_permalink', get_permalink( $post ), $post ) );
}

Unübersetzbarer Text

Um in das Verzeichnis aufgenommen zu werden, müssen alle Themen zu 100 % „übersetzungsreif“ sein. Das bedeutet, dass jede Textzeichenfolge, die Ihr Design ausgibt, übersetzbar sein muss.

WordPress verfügt bereits über die Systeme und Funktionen, um den Übersetzungsprozess zu handhaben, Sie müssen nur sicherstellen, dass Ihre Zeichenfolgen die richtigen Funktionen verwenden.

Obwohl dies einfach zu implementieren ist, wird dies oft übersehen, da es dem Fluss widerspricht, wie Menschen HTML schreiben.

Normalerweise könnten Sie so etwas tun:

 <h1>404 – Nicht gefunden</h1>

Um es übersetzbar zu machen, müssen Sie etwas PHP hinzufügen:

 // __-Funktionen sind die Basis der Lokalisierung.
<h1><?php echo __( '404', 'text-domain' ); ?>

// _e-Funktionen geben den Wert zurück.
<h1><?php _e( '404', 'text-domain' ); ?>

// Escape und Echo der Zeichenfolge.
<h1><?php esc_html_e( '404', 'text-domain' ); ?>

// Lokalisierung und Variablen.
<h1><?php _n( 'Ein Beitrag', '%s Beiträge', $count, 'Text-Domain' ); ?>

Von Funktionen ausgegebene Strings müssen ebenfalls übersetzungsbereit sein:

 // nicht übersetzungsbereit :-(
<?php next_posts_link( 'Ältere Einträge' ); ?>

// übersetzungsbereit :-)
<?php next_posts_link( esc_html__( 'Ältere Einträge', 'text-domain' ) ); ?>

Tipp: Viele Codebeispiele in codex.wordpress.org verwenden die Übersetzungsfunktionen nicht, seien Sie also vorsichtig, wenn Sie diese kopieren und einfügen.

Falsches Einreihen von Ressourcen

Die .css- und .js-Dateien, die Ihr Design verwendet, müssen mit den richtigen Funktionen in die Warteschlange gestellt werden: wp_enqueue_style() für CSS und wp_enqueue_script() für Javascript.

Ein häufiger Fehler besteht darin, Skripte und Stile direkt in <head> oder vor </body> festzucodieren. Bei diesem Ansatz gibt es zwei Probleme:

1. Unmöglich zu entfernen

Wenn ein Plugin eine von Ihnen geladene Ressource entfernen muss, ist dies nicht möglich. Wenn Sie die richtigen Enqueue-Funktionen verwendet hätten, könnte dies folgendermaßen erfolgen:

 /**
 * Entferne das Design-Javascript.
 *
 * Verbunden mit der Aktion wp_enqueue_scripts, mit einer späten Priorität (100),
 * so dass es ist, nachdem das Skript in die Warteschlange gestellt wurde.
 */
Funktion wptavern_dequeue_script() {
   wp_dequeue_script( 'theme-scripts' );
}
add_action( 'wp_enqueue_scripts', 'wptavern_dequeue_script', 100 );

2. Doppeltes Laden

Wenn Sie eine Ressource, z. B. jQuery, in die Warteschlange einreihen und ein Plugin sie ebenfalls in die Warteschlange einreiht, ist WordPress intelligent genug, um sie nur einmal zu laden.

 /**
 * jQuery einreihen
 *
 * jQuery wird trotz zweier Enqueues nur einmal geladen.
 * jQuery ist mit WordPress gepackt, sodass wir keinen src angeben müssen. 
 */
Funktion wptavern_enqueue_script() {
   wp_enqueue_script( 'jquery' );
   wp_enqueue_script( 'jquery' );
}
add_action( 'wp_enqueue_scripts', 'wptavern_enqueue_script' );

Wenn Sie stattdessen jQuery in Ihrem <head> fest codiert hätten, hätte WordPress keine Möglichkeit, dies zu erfahren, und es würde zweimal geladen werden.

Plugin-Territory-Funktionalität

Der Umfang eines Themes sollte nur das Design und die Ästhetik einer Website abdecken, alle anderen Funktionen sollten von WordPress selbst oder Plugins übernommen werden.

In dem Versuch, ihren Themes mehr Wert zu verleihen, versuchen Theme-Autoren oft, zusätzliche Funktionen zu integrieren, zum Beispiel SEO-Kontrollen oder benutzerdefinierte Beitragstypen.

Das Problem beim Bündeln von Funktionalität in einem Thema besteht darin, dass die Daten nicht portierbar sind. Nehmen Sie SEO-Kontrollen als Beispiel: Wenn der Benutzer das Thema ändert, verliert er die gesamte Arbeit, die er zur Optimierung seiner Seiten geleistet hat. Beim Einsatz eines SEO-Plugins hingegen sind die Daten und Funktionalitäten unabhängig vom Theme und bleiben bei einem Theme-Wechsel erhalten.

Einige Beispiele für die Funktionalität von Plugin-Gebieten:

  • Analytik/Tracking
  • SEO-Kontrollen
  • Kontaktformulare
  • Kurzwahlen
  • Gutenberg-Blöcke

Tipp: Wenn Ihr Code in die Datenbank schreibt, handelt es sich höchstwahrscheinlich um Plugin-Territorium. Ausgenommen sind designbezogene Einstellungen (Sidebar-Position, Farben etc.).

Nicht voranstellen

Präfixe sind eine Möglichkeit sicherzustellen, dass Ihr Code nicht mit Code von Plugins kollidiert. Namespace in PHP ist ein besserer Weg, um den gleichen Effekt zu erzielen. Einige Benutzer verwenden jedoch immer noch alte Versionen von PHP (5.2), die diese Funktion nicht unterstützen.

Justin Tadlock hat eine Liste gängiger Dinge geteilt, die vorangestellt werden sollten:

  • PHP-Funktionsnamen.
  • PHP-Klassennamen.
  • Globale PHP-Variablen.
  • Action/Filter-Hooks.
  • Skriptgriffe.
  • Style-Griffe.
  • Namen der Bildgröße.

Quelle: https://themereview.co/prefix-all-the-things/

 // Funktionsbeispiel.
my_prefix_example();

// Klassenbeispiel.
Klasse My_Prefix_Example { … }

// Aktions- und Filterbeispiel.
do_action( 'my_prefix_action' );
apply_filters( 'my_prefix_filter', $values ​​);

// Enqueue-Beispiele.
wp_enqueue_script( 'my_prefix_script', get_template_directory_uri() . '/js/custom-script.js' );
wp_enqueue_style( 'my_prefix_style', get_template_directory_uri() . '/css/styles.css' );

// Beispiel für Bildgröße.
add_image_size( 'my_prefix_image_size', 220, 180 ); // 220 Pixel breit und 180 Pixel hoch.

Ausnahme: Fügen Sie beim Einreihen von Ressourcen von Drittanbietern kein Präfix hinzu:

 // Einreihung eines Skripts eines Drittanbieters (chosen.js).
 wp_enqueue_script( 'ausgewählt', get_template_directory_uri() . '/js/chosen.js' );

Lizenzprobleme

Ihr Design und alle seine Dateien müssen zu 100 % GPL-kompatibel sein. Dazu gehören Bilder, Bibliotheken, Skripte und Schriftarten.

Alle Ressourcen von Drittanbietern müssen ihre Quellen- und Lizenzinformationen auflisten.

Diese Anforderung kann besonders schwierig sein, da nicht alle Lizenzen GPL-freundlich sind. Die Unsplash-Lizenz hat nur eine Einschränkung:

„Diese Lizenz beinhaltet nicht das Recht, Fotos von Unsplash zusammenzustellen, um einen ähnlichen oder konkurrierenden Dienst nachzubilden.“

Diese eine Einschränkung reicht jedoch aus, um es nicht GPL-kompatibel zu machen, und daher werden Sie keine Unsplash-Bilder sehen, die in WordPress.org-Designs enthalten sind.

Eine Liste der GPL-kompatiblen Lizenzen finden Sie hier – https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

Vor kurzem, stocksnap.io war die häufigste Bildquelle im Verzeichnis, da alle aufgelisteten Bilder als CC0 (GPL-kompatibel) lizenziert sind.

Screenshot-Fehler

Die Anforderungen besagen, dass Ihr Screenshot eine unbearbeitete Darstellung Ihres Themas sein sollte, die nicht wie eine Werbung aussieht. Das bedeutet keine Photoshop-Arbeit, Überlagerungen, Ränder oder ausgefallene Effekte.

Bilder müssen auch die gleichen Lizenzanforderungen erfüllen, die wir oben untersucht haben.

abgebildetes Thema: Blocksy

Bonus: Verwenden Sie einen Kodierungsstandard

Code, der für Sie leicht lesbar und verständlich erscheint, kann für einen Prüfer, der nur 10-15 Minuten Zeit hat, um Ihren Code zu überprüfen, das komplette Gegenteil sein.

Während es keine Anforderungen an Codierungsstandards gibt, erleichtert die Befolgung eines Codes das Lesen, Verstehen und Verwalten Ihres Codes. Ich persönlich verwende und empfehle die „WordPress Coding Standards“, obwohl es noch andere gibt.

Die Verwendung von PHP_CodeSniffer und dem WordPress-Regelsatz in Ihrem Code-Editor kann die Einhaltung eines Standards erheblich erleichtern – https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards

Fazit

Die Theme-Anforderungen werden mit Blick auf den Endbenutzer erstellt. Vermeiden Sie die oben aufgeführten häufigen Fehler, und Ihr Design wird in kürzester Zeit genehmigt. Wenn Sie den Begutachtungsprozess von der anderen Seite erleben möchten, können Sie sogar Bewerter werden.