WordCamp Europe 2017: Tolle Vorträge aus Paris

Sicherheit und Co

Miriam Schwab ist aus Israel, wo Hacking ein sehr großes Problem ist und sie mit ihrem Unternehmen ständig hinter den aktuellsten Sicherheitsmechanismen hinterher ist. Es ist ein ständiges Katz&Maus-Spiel mit den Angreifern, denn während die Seite immer sicherer werden, entwerfen die Hacker ebenfalls neue Techniken und finden andere Schlupflöcher. In diesem Vortrag geht sie quer durch die Welt der WordPress-Sicherheit und worauf jeder achten sollte.

In Summe alles was im Codex unter „WordPress Hardening“ steht in 40 Minuten und ein paar kleine Extras.

 

Mehr Performance durch ständige Analysen

Zum Vortrag von Otto Kekäläinen gibt es leider noch kein Video, doch seine Anätze sind sehr interessant. Als Entwickler kennen wir alle Werkzeuge wie XDebug und den Profiler, um auf wirklich professionellem Wege herauszufinden, was die Seite langsam macht. Zusätzlich wurde noch xhprof und uprofiler vorgestellt, welche auch auf dem Live-Server permanent mitlaufen können und so einen Haufen von Daten über die Engpässe einer Seite liefern.

Wer von Apache auf nginx umgestiegen ist hat noch mehr in der Hand, da nginx ein viel besseres Logging bieten kann als das schlichte Apache. Während Apache nur aufnimmt, ob jemand auf der Seite war, kann ngin zusätzlich erfassen, wie lange die Anfragen gedauert haben und welche Dateien offensichtlich am meisten oder langsamsten geladen werden. Das alles über Tools aus der nginx Community.

Aus der deutschen Community

Interview zum Contributor Day

Auch beim Contributor Day war Gutenberg das Top-Thema der Veranstaltung. Der neue Editor ist mittlerweile als Plugin erhältlich und seit WordPres 4.8 ist auch der TinyMCE bereit diesen ordentlich abbilden zu können. Bisher konnte der Editor von WordPress nur mit viel Mühe erweitert werden, was sich seit der letzten Version erheblich geändert haben soll.

Birgit Olzem (bekannt aus der deutschen WP Community) wurde sogar von wptavern zum Contributor Day interviewed: https://wptavern.com/wpweekly-episode-278-recap-of-wordcamp-europe-2017

wp-core-bootstrap – Wie startet WordPress sich selbst ?

Auch Alain Schlesser, der seit kurzem bei wp-cli als Comitter dabei ist, muss genannt werden, da dieser wp-core-bootstrap ins Leben gerufen hat. Ein Projekt, das genau ergründet, was beim Besuch einer Webseite passiert, was WordPress in diesem Prozess alles startet und vieles mehr rund um das Thema Bootstrapping. Ein Projekt, das per GitHub weiter verfolgt werden kann: https://github.com/wp-core-bootstrap/documentation

Nächste WordCamp in NRW

Insgesamt ist die deutsche Community immer stärker im WordPress-Kern vertreren, sogar mehr als unsere Freunde aus Amerika. So geht es dann weiter beim nächsten WordCamp, was in NRW stattfinden soll. Voraussichtlich Köln, soweit wir gehört haben.

Den internen Autoloader von WordPress nutzen

Bei dem letzten Meetup war unter anderem der Autoloader für Klassen das Thema. Über diesen freue ich mich so sehr, dass ich ihn hier nochmal vorstellen möchte.

Was macht ein Autoloader?

In WordPress müssen zur Zeit Klassen-Definitionen / -Dateien wie class-mein-post-type.php einzeln geladen werden:

require_once 'foo/bar/class-baz.php';

    $x = new Baz();

Das ist in modernen Architekturen angenehmer gelöst, indem die Klassen und deren Namespaces passend im Dateibaum abgelegt sind:

  • mein-plugin/
    • includes/
      • classes/
        • class-mein-post-type.php
        • class-eine-tax.php

Mit einer passenden Struktur und einem Autoloader ist von da an viel einfacher ein Objekt zu erzeugen:

$x = new Mein_Post_Type();
    $y = new Eine_Tax();

Ein require_once oder include_once für diese Klassen wird nicht mehr benötigt. Vielmehr bittet PHP den Autoloader nach der Datei für diese Klasse zu suchen. Das kann der Autoloader sehr gut, da ihm die Struktur der Daten bekannt ist.

WordPress Autoloader

Die Struktur für den WP Coding Standards ist bestimmt bekannt:

  • Alle Dateinamen beginnen mit „class-“ und haben ein „-“ als Trenner (z.B. „class-mein-post-type.php“)
  • Alle Klassen können in einem Namespace sein und haben ein _ als Trenner (z.B. Mein_Post_Type)

Dies ließe sich in einer der kommenden WordPress-Versionen für ein Plugin oder Theme wie folgt umsetzen:

global $spl_autoloaders;

    // hole alle Klassen die "Acme_*" heißen aus dem Plugin-/Theme-Verzeichnise "includes/acme/"
    $spl_autoloaders[] = new WP_Autoload_Prefixed( 'Acme_', __DIR__ . 'includes/acme' );

    $x = new Acme_Post_Type_Foo();
    // holt nun automagisch die Datei "includes/acme/class-acme-post-type-foo.php"

Das ist ein cooler Schritt vorwärts, für WordPress selbst. Nach der Einführung dieser Autoloader soll auch der Verzeichnisbaum von WordPress, insbesondere die Klassen, etwas aufgeräumt werden. Hoffentlich ist es bald einfacher sich durch den Wust an Klassen zurechtzufinden.

PSR0 / PSR4 Autoloader in WordPress

Auch für alle Freunde des Composers gibt es eine Lösung zu PSR0 und PSR4. Das ist ähnlich einfach geplant:

$spl_autoloader[] = new WP_Autoload_PSR0( 'Acme', 'includes/' );

    $x = new Acme\Foo\Bar();
    // holt automatisch die Datei "includes/Acme/Foo/Bar.php"

Wem der WordPress-Standard nicht so wichtig ist und gern mit PSR0 und PSR4 arbeitet, für den ist diese Lösung wie geschaffen. Mittels WP_Autoload_Classmap ließe sich auch eine Classmap wie in Composer lösen. Es wird sicherlich von Vorteil sein, nur die relevanten Sachen in die WordPress-Blase zu heben, anstatt bei jedem Aufruf der Webseite alle Composer-Pakete zu laden.

Das geht noch besser

Das Proposal und die Umsetzung welche im Trac zum Core Autoloader aktuell läuft ist für ein Future Release geplant und wird noch debattiert. Von meiner Seite werde ich in den kommenden Tagen einbringen, dass Namespaces ebenfalls Beachtung finden sollten. Zwar sind diese nicht im WP-Coding-Standard beschrieben, dennoch arbeitet die Welt seit Jahren damit und WordPress hinkt hinterher.

Zumindest holt es dank diesem Autoloader bald wieder ein bisschen auf.

WordPress 4.6 und danach

Bei unserem letzten Meetup haben wir uns darüber unterhalen, was uns mit WordPress 4.6 erwartet und was zu Problemen führen könnte. Aber auch Features die es nicht in den Release geschafft haben sind interessant, da sie später in kommenden Versionen erscheinen werden. Die tollsten und wichtigsten haben wir hier zusammengefasst.

WordPress 4.6 Beta

Im folgenden wird gezeigt, wass alles in der Beta-Version drin ist.
Darüber hinaus gibt es noch andere Features für 4.6, die anschließend gezeigt werden.

Customizer mit Validierung

Customizer mit Validierung

Der Theme-Customizer wird immer toller. Diesmal kommt eine Validierung der eingegebenen Daten hinzu. Ganz recht,
das war vorher nicht möglich. Nun kann dem Kunden eine Rückmeldung gegeben, falls die Daten unvollständig sind (wie im Screenshot zu sehen).
Ohne die Eingabe dieser Daten weigert sich der Customizer sogar die Daten abzuspeichern oder er speichert nur die gültigen ab – das lässt sich konfigurieren.
Ganz einfach, indem man sich an den customize_value_{id}-Filter hängt.
Das ist super, um den Benutzer zu führen und Fehler zu vermeiden!

$wp_customize->add_setting( 'established_year', array(
    'sanitize_callback' => 'absint',
    'validate_callback' => 'validate_established_year'
) );

function validate_established_year( $validity, $value ) {
    $value = intval( $value );
    if ( empty( $value ) || ! is_numeric( $value ) ) {
        $validity->add( 'required', __( 'You must supply a valid year.' ) );
    } elseif ( $value < 1900 ) {
        $validity->add( 'year_too_small', __( 'Year is too old.' ) );
    } elseif ( $value > gmdate( 'Y' ) ) {
        $validity->add( 'year_too_big', __( 'Year is too new.' ) );
    }
    return $validity;
}
class Established_Year_Setting extends WP_Customize_Setting {
    function validate( $value ) {
        if ( empty( $value ) || ! is_numeric( $value ) ) {
            return new WP_Error( 'required', __( 'Moron!' ) );
        }
        if ( $value < 1900 ) {
            return new WP_Error( 'year_too_small', __( 'Too old.' ) ); 
        } 
        if ( $value > gmdate( 'Y' ) ) {
            return new WP_Error( 'year_too_big', __( 'Too new.' ) );
        }
        return true;
    }
}

Shiny updates

  • Mehrere Updates installieren / Queue
  • Meine Lösung ist nicht dabei 🙁
  • Kein terminalmäßiger Screen mehr

    An sich cool, dass ein eingeschlafenes Plugin neu aufgegriffen wird. Ein Fork vom Plugin pento/shiny-updates wurde genutzt, um die Plugin-Seite von WordPress schöner zu gestalten. So können jetzt mehrere Updates gleichzeitig angestoßen werden, zurücklehnen und warten bis es fertig ist. Eigentlich wie von den Updates bekannt nur in schön.

WP_Post_Type

Eine neue Klasse (hurra!) die leider final ist (oh…) repräsentiert einen Post-Type. Alle Felder, die auch bei register_post_type vertreten sind können in dieser Klasse hinterlegt und abgefragt werden. Mit einer Instanz davon lassen sich zum Beispiel Post-Types anlegen und das Autocomplete der IDE hilft einem dabei.

Das könnte wehtun

Der Rückgabewert der Methode „ wurde so designt, dass er als Array behandelt werden kann, obwohl ein Objekt zurückgegeben wird.
Daher ging WordPress hin und hat das Objekt nun durch ein echtes Array ersetzt.
Allerdings werden dort vermutlich nicht alle Daten ausgegeben (vgl. https://core.trac.wordpress.org/attachment/ticket/37097/37097.2.diff).

Das Auffinden der Übersetzungsdateien wurde überarbeitet, als dass nun erst immer im „wp-content/languages“-Ordner nachgesehen wird.
Die Sprachpakete von translate.wordpress.org werden nun also höher gewichtet.
Eine tolle Sache, um Default-Übersetzungen eines Themes oder Plugins zu verändern.
Könnte aber auch bei einigen Instanzen übel aufstoßen, die von der vorherigen Priorisierung (erst im Plugin/Theme, dann WP_LANG_DIR) gelebt haben.

Nach all den Jahren WordPress sind einige Hooks ohne jede Funktion oder nur als Platzhalter da und gelten daher als „deprecated“.
Damit diese möglichst nicht weiter benutzt werden wird nun immer ein Fehler geschmissen (https://core.trac.wordpress.org/ticket/10441).
Dieser zusätzliche Fehler bläht Logs stark auf und bringt bei mangelhaften Error-Reporting die Anwendung ins wackeln.

Besonders lustig finde ich das Ticket, dass Benutzer, die nach Namen sortiert werden, fälschlicherweise nach Benutzernamen sortiert werden.
Die Lösung war, die Sortierbarkeit nach Name schlichtweg zu entfernen.
Auch eine Art Bugs zu beheben – Features abschalten.

Wer sich darauf verlässt, dass get_page_by_path stets aktuelle Daten liefert wird über das Caching stolpern (https://core.trac.wordpress.org/ticket/36711).
Ähnlich wie andere get_*-Funktionen ist zum Wohle der Performance dort nun ein Caching eingebaut.

Zu guter Letzt und wie jedes Mal werden ganze Klassen ausgelagert – noch nicht schlimm – und auch Funktionsdeklarationen – aua.
Das heißt, falls eure Anwendung komplett zusammenbricht, weil eine Funktion nicht vorhanden ist, dann weil Sie künftig an einem anderen Ort wohnt
(z.B. Walker_Nav_Menu https://core.trac.wordpress.org/ticket/37035).

Das finde ich super

Bisher gab es erst eine Fehlermeldung über ungültige Dateitypen, wenn die Datei vollständig hochgelade war.
Bei großen Videos dauert das einige Zeit und frustriert ganz schön.
Mit WordPress 4.6 wird bereits vor dem Upload anhand des Dateinamens geprüft,
ob diese Art von Datei erlaubt ist (https://core.trac.wordpress.org/ticket/14244).
Eine Warnung erscheint dann direkt im Backend vor dem Upload. Super!

Auch toll ist, dass native Schriften im Backend benutzt werden.
Die Verwaltung brauch nicht schön sein, finde ich, sondern muss funktionieren.
Mit nativen Schriften wird eine etwas schnellere Lade- und Renderingzeit erhofft.

Bisher schlug comments_template fehl, sobald es mehr als einmal auf der selben Seite benutzt wird.
Die hierarchie der Kommentare konnte nicht richtig aufgelöst und somit nicht korrekt dargestellt werden.
Ein Bug im Caching wurde behoben, damit comments_template mehrfach benutzt werden kann.

Regelmäßiges Problem sind die Queries in WordPress.
Verrückte große dynamische Arrays machen nicht nur das korrekte Anwenden schwer sondern scheinbar auch das Debugging.
So kam es dass irgendwann die Funktionalität von der Sortierung „meta_value_num“ nicht mehr griff und nun in WordPress 4.6 behoben ist
(https://core.trac.wordpress.org/ticket/37151).

Aber nicht nur bei WordPress schleichen sich Features davon, sondern auch bei PHP.
In Version 7.1 ist die String- und Array-Behandlung leicht verändert, als dass ein String nur noch mit numerischen Indizes als Array behandelt werden kann.
Dinge wie $string['foo'] waren bisher möglich, schmeißen in PHP 7.1 allerdings einen Fehler.
WordPress reagiert in seiner Version 7.6 darauf (https://core.trac.wordpress.org/ticket/37071).

$responses = wp_remote_get( [
    [ 'http://api.example.org/artists/Coheed.json', [ 'timeout' => 2 ] ],
    [ 'http://api.example.org/artists/Cambria.json', [ 'timeout' => 2 ] ]
] );

WordPress 4.7 und später

Eher unwichtig aber dennoch gehyped sind weitere get_post_by*-Funktionen – kann ich drauf verzichten.
Zum Wohle der Performance kommt hoffentlich bald eine native gettext Unterstützung,
denn in „wp-includes/l10n.php“ ist eine komplett eigene PHP-Lösung vom gettext-Framework (https://core.trac.wordpress.org/ticket/17268).
Die Überarbeitung der Export-API (https://core.trac.wordpress.org/ticket/22435) wird darin bestehen,
dass die Klasse WP_WXR_Export im per CLI ansprechbar ist und es mehr Kontrolle über die Ausgabe gibt.
Auch gut für die CLI ist ein überarbeitetes wp_insert_post, welches keine current_user_can Prüfungen mehr beinhalten soll.
Und endlich (hurra!) ein paar Autoloader für Klassen – Willkommen im 21. Jhd WordPress!

Quellen:

Recap des WordPress Meetup Paderborn am 08. Juni

Das dritte WordPress Meetup in Paderborn fand am 8. Juni in der gemütlichen Atmosphäre des Deutschen Hauses statt. Es fanden sich insgesamt fünf WordPress-Interessierte zusammen, die nach echt gutem Essen (und Dessert!) reichlich zu quatschen hatten.

Mike stellte kurz vor, was sich im WordPress Core tun wird: Es wird ein AutoLoader für Klassen kommen (bzw. mehrere, je nachdem ob man WP-Standard, PSR-0 oder PSR-4 verwenden möchte). Natürlich, wie bei WordPress fast obligatorisch, wird man auch eigene Loader implementieren können. Des Weiteren kommt mit den Shiny-Updates eine schönere Variante Updates von Plugins zu machen. Weitere neue Features kommen wahrscheinlich mit der Version 4.6 nicht.

Ebenfalls lange besprochen wurde das Thema Hosting, weil Matthias wissen wollte, wieviel Aufwand es eigentlich ist, alle möglichen Dienste selbst zu betreiben.
Angefangen beim Webserver, aber insbesondere auch Mail- oder z.B. DNS-Server. Und ob man dann Virtualisierung macht. Und welche? Und vor allem, ob das nicht alles viel zu zeitintensiv ist. Zum Glück konnten wir die meisten Fragen auf Basis der unterschiedlichen Erfahrungen in der Runde beantworten.

Zwischendurch konnten wir vom Orga-Team uns auch kurz auf der Meta-Ebene unterhalten – wie wir die kommenden Meetups gestalten wollen war dabei das wesentliche Thema. Einig waren wir uns schnell, dass wir gerne Programmpunkte anbieten möchten, beispielsweise Vorträge, die wir schon vor dem Meetup ankündigen. Daher werden wir zum nächsten Termin (es wird der 5. Juli, soviel steht schon fest) etwas vorbereiten, und freuen uns über Eure Vorschläge oder sogar Angebote, selbst einen Programmpunkt zu gestalten.

Schreibt Eure Eindrücke vom Meetup in den Kommentaren – und Eure Wünsche für’s nächste Mal!