WordPress-Widgets: Beginnend mit Standards

Der Zweck dieser Serie ist es, tiefer in die Arbeit mit objektorientierter Programmierung im Kontext von WordPress einzutauchen.

Und da die WordPress-Widgets-API eine der APIs ist, die objektorientierte Praktiken verwendet, ist dies ein logischer Ausgangspunkt. Darüber hinaus wird es uns einige grundlegende Techniken vermitteln, die wir für zukünftige Arbeiten anwenden können, wenn wir sehen, wie wir in zukünftigen Serien mehr objektorientierte Projekte auf WordPress erstellen können.

Bisher haben wir Folgendes behandelt:

1. WordPress-Widgets: Ein objektorientierter Ansatz. Die Widgets-API bietet einen soliden Lackmustest und ein Beispiel für den Einstieg in die objektorientierte Programmierung in WordPress.
2. WordPress-Widgets: So erkennen Sie objektorientierte Programmierung Das Ziel ist es, Sie mit allem auszustatten, was Sie brauchen, um objektorientierte Praktiken zu erkennen.

Wenn Sie nicht aufgeholt sind, ist jetzt ein guter Zeitpunkt, dies zu tun. Und wenn ja, dann werden Sie sich an den letzten Beitrag erinnern, den wir mit der folgenden Anmerkung beendet haben:

Das heißt, wir werden das WordPress-Widget Boilerplate erneut besuchen  und ich werde es in seinem aktuellen Zustand umgestalten, um modernere PHP-Standards zu übernehmen.

Um mit der Aktualisierung des WordPress Widget Boilerplate zu beginnen, um diesen Standards zu entsprechen, müssen wir ein paar Dinge tun:

1. Erstellen Sie einen Zweig aus der vorhandenen Boilerplate,
2. Codequalitätstools installieren,
3. Stellen Sie sicher, dass unsere IDE richtig eingerichtet ist,
4. und mit dem Refactoring des Codes an die Standards beginnen.

Und damit fangen wir mit diesem Beitrag an.

Beginnend mit Standards

Wenn Sie schon länger Mitglied dieser Seite sind, dann wissen Sie, dass ich am liebsten Visual Studio Code verwende. Wenn nicht, habe ich eine ganze Reihe von Artikeln, die sich damit befassen, wie ich es verwende (und wie wir es in dieser Reihe von Beiträgen verwenden werden).

Und wenn Sie an Informationen zu Codierungsstandards, Debugging, IDEs, Entwicklungsumgebungen usw. interessiert sind, lesen Sie The Independent WordPress Developer.

Ich gehe jedoch davon aus, dass Sie, wenn Sie dies lesen, das obige Material durchgelesen haben oder sich damit wohl fühlen, das gesamte obige Material durchzugehen.

Lassen Sie uns damit beginnen.

Herunterladen des Repositorys

Das erste, was Sie tun möchten, ist, eine Kopie des Repositorys zu klonen. Ich ziehe es vor, dies über die Befehlszeile zu tun.

Darüber hinaus denke ich, dass es sich auch lohnt, dies gegen die neueste Version von WordPress zu tun. Wenn Sie keine Kopie von Subversions Trunk-Kopie von WordPress haben, können Sie hier nachlesen, wie Sie das einrichten; Dies ist jedoch rein optional. Sie können dem Rest dieses Tutorials mit jeder beliebigen Version von WordPress folgen.

Dazu

1. Stellen Sie sicher, dass Sie sich im Plugins- Verzeichnis Ihrer WordPress-Installation befinden
2. Geben Sie dann die folgenden Befehle in eine Kopie Ihres Terminals ein

$ 

Dadurch wird ein WordPress-Widget-Boilerplate- Verzeichnis in deinem Plugins – Verzeichnis erstellt. Sie können durch einfache Eingabe dorthin navigieren:

$ cd WordPress-Widget-Boilerplate

Die Ergebnisse des Klonens des Repositorys sollten in etwa so aussehen:

Als nächstes müssen Sie sicherstellen, dass Sie zu dem von mir erstellten Entwicklungszweig wechseln. Es ist wirklich einfach, dies zu tun. Aber bevor wir das tun, warum richten Sie das Projekt nicht in Visual Studio ein?

Einrichten von Visual Studio-Code

Die Schritte zum Einrichten des Projekts in Visual Studio Code sind einfach:

1. Ziehen Sie das Verzeichnis für die Boilerplate in die IDE,
2. Öffnen Sie das integrierte Terminal,
3. Äste tauschen

Genau wie ich es oben getan habe, werde ich einen Screencast darüber bereitstellen, wie all dies zu tun ist. Das Ziehen eines Verzeichnisses in Visual Studio Code sollte einfach genug sein, aber das Austauschen von Zweigen in der Befehlszeile kann etwas anders sein.

Zuerst das Projekt in Visual Studio Code einrichten:

Beachten Sie hier, dass ich auch das integrierte Terminal öffne, indem ich die Tastenkombination CMD + P drücke (ich arbeite unter macOS, daher kann Ihre Tastenkombination anders sein). Dann gebe ich den Befehl ein, um den Entwicklungszweig auszuchecken.

Sobald Sie dies getan haben, sollte Ihr lokales Repository zum Entwicklungszweig wechseln. Sie können bestätigen, dass dies der Zweig ist, von dem aus Sie arbeiten, indem Sie Folgendes eingeben:

$ git branch

Überprüfen Sie dann den Inhalt des Terminals. Streng genommen  sollte sich entwickeln hervorheben.

An dieser Stelle werden wir ein paar neue Dateien in das Projekt einführen. Am Ende dieses Tutorials können Sie einen Pull bilden, um alles zu erhalten, was ich hier dokumentieren werde. Aber da wir mit unserer Arbeit einen zweifachen Zweck haben, ist es wichtig sicherzustellen, dass wir dies in der richtigen Reihenfolge tun, denn der erste Schritt ist etwas, das ich an dieser Stelle in jedem einzelnen Projekt für WordPress verwende.

Lassen Sie uns also einen Blick darauf werfen.

Composer- und Code-Qualität

Als Erstes richte ich gerne eine Reihe von Tools ein, um die Codequalität durchzusetzen. Dies wird durch eine Vielzahl von Composer-Paketen erreicht. Diese beinhalten:

• GrumPHP. Ein PHP-Code-Quality-Tool. Unterschätzen Sie nicht die Klarheit und den Grad, in dem dieses Repository voller Informationen ist. Wenn Sie jemals mit einem der anderen hier erwähnten Tools nicht weiterkommen, sehen Sie sich zuerst die Dokumentation in diesem Repository an.
• PHP CS Fixer. Ein Tool zur automatischen Behebung von Problemen mit PHP-Codierungsstandards.
• PHP-Parallel-Lint. Dieses Tool prüft die Syntax von PHP-Dateien schneller als die serielle Prüfung mit schickerer Ausgabe.
• PHPMD. Dieses Dienstprogramm nimmt eine bestimmte PHP-Quellcodebasis und sucht nach mehreren potenziellen Problemen innerhalb dieser Quelle
• PHP-Parser. Ein Parser ist nützlich für die statische Analyse, die Manipulation von Code und im Grunde jede andere Anwendung, die programmgesteuert mit Code umgeht.
• Proxy-Manager. Diese Bibliothek zielt darauf ab, eine Abstraktion zum Generieren verschiedener Arten von Proxy-Klassen bereitzustellen.

Ich möchte zwei Dinge klarstellen:

1. Die oben genannten Tools sind das absolute Minimum, das ich verwende, und Sie werden wahrscheinlich sehen, dass ich in Zukunft zusätzliche Tools verwende.
2. Die oben genannten Tools helfen dabei, Codequalitätsregeln durchzusetzen, bevor Code in ein Repository eingecheckt wird. Es soll die Einrichtung in Ihrer IDE ergänzen.

Um diese Tools innerhalb des Projekts einzurichten und auszuführen, müssen wir eine composer.json -Datei erstellen, die so aussieht :

{
    "name": "wordpress-widget-boilerplate/wordpress-widget-boilerplate",
    "description": "An organized, maintainable boilerplate for building widgets using WordPress best practices.",
    "type": "wordpress-plugin",
    "license": "GPL-3.0-or-later",
    "homepage": "https://github.com/tommcfarlin/WordPress-Widget-Boilerplate",
    "authors": [
      {
        "name": "Tom McFarlin",
        "email": "tom@pressware.co",
        "homepage": "https://pressware.co"
      }
    ],
    "support": {
      "issues": "https://github.com/tommcfarlin/WordPress-Widget-Boilerplate/issues"
    },
    "config": {
      "preferred-install": "dist",
      "platform": {
          "php": "7.1"
      }
    },
    "repositories": [
      {
        "type": "composer",
        "url": "https://wpackagist.org"
      }
    ],
    "require": {
      "php": "7.1",
      "composer/installers": "^1.4"
    },
    "require-dev": {
        "friendsofphp/php-cs-fixer": "^2.13.1",
        "jakub-onderka/php-parallel-lint": "^1.0.0",
        "phpmd/phpmd": "^v2.6.0",
        "nikic/php-parser": "^4.0",
        "ocramius/proxy-manager": "^2.0.0",
        "phpro/grumphp": "^0.13.1"
    },
    "scripts": {
      "test": [
        "./vendor/bin/grumphp run"
      ]
    },
    "minimum-stability": "stable"
  }

Denken Sie daran, dass Sie dies am Ende dieses Beitrags manuell herunterziehen können. Wenn Sie jedoch mitmachen möchten, können Sie dies gerne manuell tun. Davon möchte ich Sie nie abbringen. 🙂

Nachdem Sie die  Datei composer.json erstellt haben, sollten Sie sicherstellen, dass Sie den folgenden Befehl vom Terminal aus ausführen:

$ composer install

Dies könnte eine Weile dauern; Sobald es jedoch fertig ist, sollte Ihnen die folgende Meldung angezeigt werden:

Achtung! GrumPHP schnüffelt an Ihren Commits!

Geben Sie für einen Probelauf den folgenden Befehl in Ihr Terminal ein:

$ vendor/bin/grumphp run

Je nachdem, wie Sie mit dem Projekt arbeiten, sehen Sie möglicherweise eine Ausgabe, die etwa so aussieht:

Aber es gibt noch mehr zu tun. Wir müssen nämlich:

• aktualisiere unsere .gitignore -Datei,
• Konfiguration für GrumPHP vorstellen
• Konfiguration für PHPMD einführen,
• Konfiguration für PHPCS einführen,
• restrukturieren Sie schließlich die Verzeichnisstruktur der Boilerplate.

Alles bis zum letzten Schritt werden wir in diesem Beitrag tun.

Aktualisieren der Ignorieren-Datei

Erstens wollen wir weder das Vendor-Verzeichnis noch die Composer-Sperrdatei festschreiben. Diese können generiert werden, wenn ein Benutzer das Verzeichnis herunterlädt. Sie können leicht aus der Synchronisierung geraten und das Verzeichnis des Projekts enorm vergrößern.

Zu diesem Zweck sollte Ihre Gitignore -Datei wie folgt aussehen :

*.DS_Store
*.log
wp-config.php
wp-content/advanced-cache.php
wp-content/backup-db/
wp-content/backups/
wp-content/blogs.dir/
wp-content/cache/
wp-content/upgrade/
wp-content/uploads/
wp-content/mu-plugins/
wp-content/wp-cache-config.php
wp-content/plugins/hello.php

/.htaccess
/license.txt
/readme.html
/sitemap.xml
/sitemap.xml.gz

vendor/
composer.lock

Dies weist das Plugin an, alles außer dem zu ignorieren, was sich im Stammverzeichnis des Plugin-Verzeichnisses befindet (und einige der eventuellen Verzeichnisse, die wir erstellen), zusammen mit einigen grundlegenden Dateien, die wir in WordPress-Installationen gewohnt sind.

Einiges von dem, was Sie sehen, wie wp-config.php oder wp-content/ backups, werden Sie wahrscheinlich nie im Kontext eines Plugins sehen, aber dies sind standardmäßige WordPress-Ignorierungsanweisungen, die ich gerne griffbereit habe.

Sie werden feststellen, dass ich auch den Anbieter  und die Composer-Sperrdatei am Ende der Datei hinzugefügt habe.

Konfigurieren Sie GrumPHP

GrumPHP kann viel, und wenn Sie Zeit damit verbracht haben, das Repository zu lesen, bevor Sie bis hierhin gelesen haben, dann wissen Sie das wahrscheinlich; Ich werde es jedoch so schlank wie möglich halten, damit es die Anweisungen enthält, die es für die Tools benötigt, die wir verwenden, und nicht mehr.

parameters:
    git_dir: .git
    bin_dir: vendor/bin
    process_timeout: 120
    tasks:
      securitychecker:
      composer:
      jsonlint:
      xmllint:
      yamllint:
      phplint:
        exclude:
          - vendor/
      phpcs:
        metadata:
          priority: 200
      phpcsfixer2:
        allow_risky: true
        config: '.php_cs.dist'
        metadata:
          priority: 300
      phpparser:
        visitors:
          forbidden_function_calls:
            blacklist:
              - "exit"
              - "var_dump"
      phpversion:
        project: '7.1'
      phpmd:
        exclude: ['vendor']
        ruleset: ['phpmd.xml']

Kurz gesagt bedeutet dies, eine Vielzahl von Überprüfungen durchzuführen für:

• Sicherheit,
• Komponist,
• JSON,
• XML,
• Jaml,
• PHP,
• PHPCS,
• PHP-Parser,
• PHPMD,
• und mehr.

Sobald wir alles andere eingerichtet haben, werde ich Ihnen sicher zeigen, wie all dies zusammenpasst. Aber lassen Sie uns zuerst die Konfiguration der restlichen Dienstprogramme beenden.

PHPCS

Dabei werden zwei separate Dateien verwendet – eine dist -Datei und eine XML – Datei – die jeweils unterschiedlichen, aber sehr hilfreichen Zwecken dienen.

Die erste Datei, php_cs.dist, die Sie am Ende dieses Beitrags im Repository sehen werden, stellt einen Header bereit, der auf alle PHP-Dateien in unserem Projekt angewendet wird. Es erzwingt auch einige andere Regeln, die die Codequalität verbessern.

Die Regeln sind selbsterklärend, und Sie können sehen, was durchgesetzt wird, indem Sie sich einfach die einzelnen definierten Regeln ansehen .

Als Nächstes möchten Sie auch die XML-Datei erstellen, um die obige Datei zu ergänzen. Sie werden feststellen, dass ich in der Datei, die ich zur Verfügung stelle, dies für meine Arbeit bei Pressware verwende. Darüber hinaus erkennt es auch das Tests- Verzeichnis an.

Zu diesem Zeitpunkt haben wir keine Komponententests geschrieben, aber sollten Sie sich dafür entscheiden, sie in Ihr Widget einzuführen, ist dies bereit, sie ordnungsgemäß zu handhaben.

Es gibt nur eine kleine Menge an Konfigurationen, die ich hier angebe, aber ich habe festgestellt, dass sie für meine Anforderungen bisher mehr als ausreichend sind. Wenn ich mehr entdecke oder mich entscheide, mehr zu verwenden, werde ich den Inhalt in zukünftigen Beiträgen sicherlich aktualisieren.

PHPMD konfigurieren

Und schließlich müssen wir den PHP Mess Detector (oder PHPMD) konfigurieren. Glücklicherweise verwendet dies eine XML-Datei, die Regelsätze verwendet, wie sie in dem von Composer installierten Paket definiert sind. Wir müssen lediglich auf die Regel in der Konfigurationsdatei verweisen.

Zweitens werden wir auch einen kleinen Ausschluss für einen ShortVariable- Namen bereitstellen, wie Sie im folgenden Kern sehen werden :

Und sobald all dies vorhanden ist, sollten wir in der Lage sein, GrumPHP erneut von der Befehlszeile aus auszuführen und etwas andere Ergebnisse zu erhalten.

GrumPHP erneut ausführen

Geben Sie Folgendes in Ihr Terminal ein:

$ vendor/bin/grumphp run

Und Sie sollten so etwas sehen:

Andere Ergebnisse als beim ersten Mal, oder? Dies liegt daran, dass wir gegen einige Regeln und Standards verstoßen, die ein moderner Teil von PHP und der objektorientierten Entwicklung sind.

Und das werden wir im nächsten Beitrag bereinigen.

Kommen

Woher kommt also die objektorientierte Natur davon? Bis zu diesem Punkt haben wir über die Verwendung der Widgets-API als objektorientiertes Modell zum Schreiben von objektorientiertem Code in WordPress gesprochen.

Einiges von dem, was wir bisher getan haben, war genau das (indem wir seine Prinzipien durchsprachen, sahen, wie es angelegt ist, und mehr).

Aber wie ich zu Beginn dieses Beitrags erwähnt habe, bietet uns das Verlegen von Codequalitätstools zunächst eine Grundlage, die wir verwenden können, wenn wir die Boilerplate umgestalten (was wir angesichts der Menge an Rot, die von GrumPHP angezeigt wird, eindeutig tun müssen).

Und genau da setzen wir im nächsten Beitrag dieser Serie an.