Wenn Updaten nicht funktioniert und WordPress FTP Verbindungsdaten verlangt…

…stehen bald Schweißperlen auf der Stirn.

Dabei gibt es ein paar relativ einfache Möglichkeiten um WordPress dazu zu bringen, seiner Arbeit ganz normal nachzugehen.

Einstellen der FTP Zugangsdaten in wp-config.php

Oft reicht es einfach, die FTP Zugangsdaten einzugeben und von FTP auf FTPS umzustellen.

Wenn das nicht funktioniert oder das dauernde Eingeben nervt, kann man die Zugangsdaten in der wp-config.php hinterlegen:

define('FS_METHOD', 'direct');
define('FTP_BASE', '/var/pfad/zum/richtigen/wordpress/verzeichnis');
define('FTP_USER', 'meinftpusername');
define('FTP_PASS', 'dasftppasswort');
define('FTP_HOST', 'ftp.meinedomain.com');
define('FTP_SSL', true);

Es kann sein, dass diese Einstellungen nicht gleich funktionieren. In dem Fall muss man sich mit den einzelnen Parametern ein bisschen spielen, und zb FS_METHOD auf auf ftpext, ssh2 o.ä umstellen.
Natürlich kann es sein, dass man SSL nicht verwenden kann. Dann muss man einfach die letzte Zeile weglassen.

Die einzelnen Möglichkeiten sind im WordPress Codex nachzulesen:

 http://codex.wordpress.org/Editing_wp-config.php#WordPress_Upgrade_Constants

http://codex.wordpress.org/Editing_wp-config.php#WordPress_Upgrade_Constants

Änderung der Berechtigung am Server mittels SSH

Wenn sich WP oder Plugins nicht updaten lassen kann auch ein Rechteproblem vorliegen. Der erste Schritt ist mal zu schauen, ob die Dateien/Ordner schreibgeschützt sind und dann den User zu überprüfen. Oft ist der FTP-Benutzer ein anderer als der Webserver und wenn da die Gruppe nicht passt, geht das Update nicht weil die Berechtigungen fehlen.

Wenn man SSH-Zugang (SFTP mit Shell) hat, dann kann man die Eigentümer evtl. direkt am Server auf den Webserver-Benutzer ändern (sofern der SSH/SFTP-Benutzer dazu das Recht hat). Der Webserver Benutzer heißt meistens www-data (lässt sich rausfinden indem man ein php-Script hochlädt und dann ausführt, welches eine Datei anlegt).

Mit folgendem Einzeiler kann man den Eigentümer recht zügig ändern:

find . -user <alterBenutzer> -exec chown www-data:www-data {} \;

Der Befehl macht folgendes:

Finde alle Dateien im aktuellen Verzeichnis oder darunter (.) die dem Benutzer <alterBenutzer> gehören und übereigne sie an Benutzer www-data und Gruppe www-data.

UPDATE: Wie ist das mit den Rechten gemeint?

Kurz: Es fehlt die Schreibberechtigung. Die aktuelle WP-Instanz darf eventuell nicht auf die Festplatte schreiben. Also der Benutzer, der für das Ausliefern der Seiten zuständig ist. Auf einem Webserver laufen viele Dienste. Diese werden oft direkt einem Benutzer zugewiesen. Der Webserver auf Linuxgeräten ist oft dem Benutzer „www-data“ zugewiesen.

Wenn der Benutzer “ www-data“ jetzt keine Schreibberechtigung hat, können auch keine Updates durchgeführt werden. Updates lösen ja einen Schreibvorgang auf der Festplatte des Servers aus.

Wenn das Problem bei einer bisher funktionierenden WordPress-Instanz auftritt, kann auch der Host/Server/vServer daran Schuld haben.

UPDATE: Ich kann mich per FTP verbinden, aber diese Daten funktionieren in der wp-config.php nicht!

Das Problem lässt sich oft lösen, indem man mit dem FS_METHOD-Parameter herumspielt.

Es gibt da vier Auswahlmöglichkeiten, die man durchprobieren kann:

Näheres befindet sich im Bereits verlinkten Artikel im Codex zum Thema wp-config.php.

Eine andere Möglichkeit ist, dass der Hoster auf eine sichere Verbindung umgestellt hat, dann muss man FTP_SSL auf true setzen:

define( 'FTP_SSL', true );

Es kann auch sein, dass man den Port explizit angeben muss, wobei 666 nur als (unrealistisches!) Beispiel für den Port herhalten muss. Ein Standard wäre zb der Port 21.

define( 'FTP_HOST', 'ftp.meinedomain.com:666' );

Dont’s

Natürlich könnte man per FTP zb die Verzeichnisrechte auf 777 setzen. Das ist eine ganz ganz schlechte Idee, denn dann hat jeder alle Berechtigungen.

Neue Tabellen-Spalte per Code mit wpdb oder dbDelta hinzufügen

Grundsätzlich bietet WordPress als Basis für Webapps ja eine einfache Möglichkeit, um Daten in die von WP mitgebrachten Tabellen einzugeben.

Siehe:

http://www.wp-entwickler.at/was-ist-dbdelta-und-wofuer-brauch-ich-das/
http://www.wp-entwickler.at/was-ist-dbdelta-und-wofuer-brauch-ich-das/

http://www.wp-entwickler.at/ueberpruefen-ob-tabelle-tabellenspalte-oder-tabellenzeile-existiert-mit-wpdb/
http://www.wp-entwickler.at/ueberpruefen-ob-tabelle-tabellenspalte-oder-tabellenzeile-existiert-mit-wpdb/

Eigene Tabellen sind in vielen Fällen aber besser.
Will ich nun zu einer Tabelle eine neue Spalte per PHP-Code hinzufügen, gibt es mehrere Möglichkeiten:

 

ALTER TABLE

$wpdb->query( "ALTER TABLE {$table_name} ADD {$column_name} LONGTEXT" );

Die einfachste und durchschaubarste Lösung ist wahrscheinlich ALTER TABLE.
Hier erstelle ich in einer Tabelle, notiert mit {$table_name}, eine Spalte mit dem Type LONGTEXT, notiert mit {$column_name}.

dbDelta

DbDelta ist eigentlich dafür da, um Tabellen in der Datenbank zu erstellen. Siehe auch den vorherigen Blogeintrag zu dbDelta.

Man kann dbDelta aber auch dazu verwenden, um Spalten anzufügen.

Aber nur um Spalten hinzuzufügen – dbDelta löscht keine Spalten. Daher funktionieren folgende Beispiele gleich, ohne Fehler zu werfen. Für euch getestet 🙂

 

		
$sql =
	"CREATE TABLE {$table_name} (
          ID mediumint(9) NOT NULL AUTO_INCREMENT,
          post_ID mediumint(9) NOT NULL,
          term_ID mediumint(9) NOT NULL,
          {$column_name} LONGTEXT,
          PRIMARY KEY  (id)
        ) ENGINE = InnoDB {$charset_collate};";

dbDelta( $sql );

 

$sql =
	"CREATE TABLE {$table_name} (
          {$column_name} LONGTEXT,
        ) ENGINE = InnoDB {$charset_collate};";

dbDelta( $sql );

 

In beiden Fällen füge ich der Tabelle {$table_name} die Spalte {$column_name} hinzu.
Im ersten Fall verwende ich den gleichen Code wie zum erzeugen der Tabelle.
Im zweiten Fall Fall fehlen die meisten Zeilen aus dem ersten Beispiel. Dennoch funktioniert beides gleich.

Kleiner Hinweis: Will ich dbDelta verwenden, muss ich die wp-admin/includes/upgrade.php Datei einbinden:

require_once( ABSPATH . 'wp-admin/includes/upgrade.php' );

 

https://developer.wordpress.org/reference/functions/dbdelta/
https://developer.wordpress.org/reference/functions/dbdelta/

http://wordpress.stackexchange.com/questions/78667/dbdelta-alter-table-syntax
http://wordpress.stackexchange.com/questions/78667/dbdelta-alter-table-syntax

https://codex.wordpress.org/Creating_Tables_with_Plugins#Adding_an_Upgrade_Function
https://codex.wordpress.org/Creating_Tables_with_Plugins#Adding_an_Upgrade_Function

 

http://stackoverflow.com/questions/21330932/add-new-column-to-wordpress-database/21331762#21331762
http://stackoverflow.com/questions/21330932/add-new-column-to-wordpress-database/21331762#21331762

Überprüfen ob Tabelle, Tabellenspalte oder Tabellenzeile existiert mit WPDB

WordPress bietet viele und einfache Möglichkeiten, um Daten zu speichern, ohne eigenen SQL-Code schreiben zu müssen.

Custom Fields (oder Post Metas) werden oft für allerhand Daten verwendet.
Man muss sich nicht selbst um Userinterfaces oder Update- und Löschmechanismen kümmern.

Doch die Tabellenstruktur von WordPress reicht oft nicht, oder ergibt bei größeren Projekten keinen Sinn.

Wenn es dann darum geht, kurze Checks und Überprüfungen an eigenen Tabellen durchzuführen, gehen mir die WordPress eigenen Mittel aus.

Daher nachfolgend ein paar Snippets als Hilfestellung:

Überprüfen ob Tabelle existiert

$table_exists = $wpdb->get_var( "SHOW TABLES LIKE '{$table_name}'" );

Das ist eine recht einfache Übung – {$table_name} ist dabei der Tabellennamen, auf den man überprüfen möchte.

Überprüfen ob Zeile existiert

$wpdb->get_row( "SELECT * FROM {$table_name} WHERE post_ID = {$post_id}" );
$wpdb->get_row( "SELECT post_ID FROM {$table_name} WHERE post_ID = {$post_id}" );

Dazu gibt es mehrere Möglichkeiten – siehe die Doku zu wpdb.
Hier wird aus einer Tabelle, hier dargestellt mit {$table_name}, eine Zeile mit einer bestimmen post_ID geholt.
Im ersten Fall werden alle Datenfelder der Zeile geholt. Für das Überprüfen ob eine Zeile vorhanden ist, könnte das zu viel an Information und Speicherbelegung sein.
Es reicht vollkommen, wenn ich mir nur ein Datenfeld oder eine Spalte aus der Zeile hole.

Überprüfen ob Spalte existiert

$columns = $wpdb->get_results(
"DESC {$table_name}"
);

{$table_name} ist wieder der Tabellenname.
DESC ist shorthand für DESCRIPTION. Mit obigem Befehl hole ich mir alle Informationen zu einer speziellen Tabelle. Ich bekomme nicht nur die Spaltennamen sondern eine Fülle an Infos..
In dem obigen Fall kommt ein Objekt an Arrays zurück. Jedes Array stellt eine Spalte dar. Ich kann diese Arrays mit einer Schleife durchlaufen, oder zb. auch das Objekt serialisieren und nach Text (= die spezielle Spalte) durchsuchen.

 

Dort wo es nötig ist, bitte nicht auf das Absichern der Abfragen vergessen. WordPress bietet dazu eine Hilfestellung mit $wpdb->prepare an.
Hineiws: Dabei handelt es sich nicht um prepared statements auf DB-Ebene sondern um WordPress-Funktionalität.

 

https://codex.wordpress.org/Class_Reference/wpdb
https://codex.wordpress.org/Class_Reference/wpdb

Javascript-Dateien für alten Internet Explorer richtig mit WordPress laden

Worum geht’s?

Microsofts Internetexplorer ist für Webentwickler immer noch ein schwarzes Tuch. Zu stark kochte Microsoft ein eigenes Süppchen, hielt sich nicht an Standards und hinkte mit der Entwicklung hinterher.

Daher muss auch noch im Jahr 2016 auf alte Internet-Explorer-Versionen Rücksicht genommen werden.

Wer ein eigenes Theme entwickelt, wird daher auch folgende Codepassage aus der header.php kennen:

<!--[if lt IE 9]>
    <script src="<?php echo get_stylesheet_directory_uri() ?>/js/html5shiv.min.js"></script>
 <![endif]-->

Damit wird alten Internetexplorern HTML5 beigebracht. (Nebenbei erwähnt:  html5shiv ist eine fantastische Arbeit von Alexander Farkas)
Dieses Schnippsel findet sich in den meisten WordPress-Themes wieder.

Problem – Conditional Comments und wp_enqueue_script()

So richtig schön und richtig ist dieser Code aber nicht – WordPress bietet dazu eh eine Hilfestellung:
Grundsätzlich sollte man JavaScript-Dateien mit wp_register_script() und/oder  wp_enqueue_script() zb in der functions.php  laden, und nicht in der eigentliche Theme-Datei wie header.php.

Leider gab es bis WordPress 4.2 keine Möglichkeit, die JavaScript-Dateien nur für bestimmte Browserversionen zu laden. Conditional Comments und wp_enqueue_script() verstanden sich nicht miteinander.

(Kleiner Hinweis: Man sollte das auch mit respond.js uÄ machen)

Lösung

Das änderte sich in der WordPress Version 4.2 mit der Einführung der Funktion wp_script_add_data().

Damit war es möglich, mit wp_enqueue_script() JavaScript-Dateien zu notieren und WordPress darauf hinzuweisen, diese Datei nur unter bestimmten Umständen zu laden.
Das funktioniert so:

  wp_enqueue_script( 'html5shiv', get_template_directory_uri() . '/js/html5shiv.min.js' );
 wp_script_add_data( 'html5shiv', 'conditional', 'lt IE 9' );

Hier sehen wir

  • laden der html5shiv Datei mit wp_enqueue_script()
  • Hinzufügen von Metadaten für dieses Skript mit wp_script_add_data()
  • Anleitung, das Skript nur für Internetexplorer-Versionen kleiner 9 zu laden.

Jetzt können wir alle Javascript-Dateien gebündelt zb in der functions.php laden.
Damit gibt es nur mehr einen Punkt im Theme, wo dies passiert und wird haben dadurch die header.php bereinigt.

 

Links

 

https://core.trac.wordpress.org/ticket/16024#no0
https://core.trac.wordpress.org/ticket/16024#no0

 

https://developer.wordpress.org/reference/functions/wp_script_add_data/
https://developer.wordpress.org/reference/functions/wp_script_add_data/

http://hookr.io/functions/wp_script_add_data/
http://hookr.io/functions/wp_script_add_data/

 

https://msdn.microsoft.com/en-us/library/ms537512(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/ms537512(v=vs.85).aspx
https://codex.wordpress.org/Using_Javascript
https://codex.wordpress.org/Using_Javascript
https://developer.wordpress.org/reference/functions/wp_enqueue_script/
https://developer.wordpress.org/reference/functions/wp_enqueue_script/
https://github.com/aFarkas/html5shiv
https://github.com/aFarkas/html5shiv
https://github.com/aFarkas/
https://github.com/aFarkas/
https://github.com/scottjehl/Respond
https://github.com/scottjehl/Respond

Was ist dbDelta() und wofür brauch ich das?

dbDelta() ist so eine WordPress-Funktion, die einem immer ein bisserl Kopfzerbrechen bereitet aber extremst hilfreich ist.

Worum geht’s bei dbDelta()?

Die Developer-Seite sagt:

Modifies the database based on specified SQL statements.

Also:
Ändert die Datenbank aufgrund von angegebenen SQL-Anweisungen.
Die Funktion ist sehr hilfreich wenn’s darum geht, eine neue, eigene Tabelle anzulegen. Wenn mir die WP eigene Tabellenstruktur nicht ausreicht und ich mit WP-Bordmitteln (Funktionen) also eine Tabelle erzeugen will.

Doch nicht nur erzeugen ist möglich, auch das Abändern.

Genau da wird’s praktisch! Ich kann meine eigenen Tabellen ohne großen Aufwand, ohne große Überlegungen ändern.
Also Spalten einfügen, Datentypen anpassen o.ä.
Was dbDelta() in dem Zusammenhang nicht kann, ist löschen.

Die Probleme?

Man muss sehr genau sein, was die Anweisungen für dbDelta() betrifft.
Genau heißt in dem Fall, dass es sogar auf ein Leerzeichen zu viel ankommt oder auf die komplette Großschreibung einzelner Wörter.
Die genaue Liste der einzelnen Problemfelder von dbDelta() ist bei folgenden Links ersichtlich:

https://codex.wordpress.org/Creating_Tables_with_Plugins#Creating_or_Updating_the_Table
https://codex.wordpress.org/Creating_Tables_with_Plugins#Creating_or_Updating_the_Table

 

http://wordpress.stackexchange.com/questions/78667/dbdelta-alter-table-syntax/78670#78670
http://wordpress.stackexchange.com/questions/78667/dbdelta-alter-table-syntax/78670#78670

Hilfe in Sicht?

Ja! Es tut sich natürlich immer irgendwo etwas im WordPres-Universum.

Dominik Schilling, ein Core-Entwickler hat Verbesserungen angekündigt, die zb. die oben angesprochenen Probleme beheben.

 

https://twitter.com/ocean90/status/753244345629827072
https://twitter.com/ocean90/status/753244345629827072

dbDelta() updates in 4.6


https://make.wordpress.org/core/2016/07/13/dbdelta-updates-in-4-6/

 

Wer sich für die noch offenen Baustellen interessiert wird hier fündig:

https://core.trac.wordpress.org/query?status=!closed&summary=~dbDelta
https://core.trac.wordpress.org/query?status=!closed&summary=~dbDelta

 

https://developer.wordpress.org/reference/functions/dbdelta/
https://developer.wordpress.org/reference/functions/dbdelta/

https://codex.wordpress.org/Creating_Tables_with_Plugins
https://codex.wordpress.org/Creating_Tables_with_Plugins

 

ACF – Felder vor dem Anzeigen und Speichern ändern

ACF ist ein wunderbares Tool, um strukturierter Daten in WordPress Posts speichern zu können.

Bevor das einzelne Felder im Backend angezeigt wird, kann es mit einem Hook verändert werden.
Das ist dann interessant, wenn ich mit diesen Metadaten vor dem Anzeigen etwas machen will. ZB Texte dranhängen, Berechnungen durchführen o.ä.

Nicht nur für’s Anzeigen gibts einen Hook sondern auch für den Fall, dass ich vor dem Speichern in die Datenbank etwas mit dem Feldinhalt anstellen will.

Warum können die Hooks so interessant sein?

Weil ich zb Daten in eine externe Tabelle speichern will – wie das zb hier besprochen wird:

 

https://support.advancedcustomfields.com/forums/topic/custom-database-table/
https://support.advancedcustomfields.com/forums/topic/custom-database-table/

https://support.advancedcustomfields.com/forums/topic/dynamic-select-from-other-plugin-table/
https://support.advancedcustomfields.com/forums/topic/dynamic-select-from-other-plugin-table/

Hook vor dem Anzeigen – acf/load_value

acf/load_value


https://www.advancedcustomfields.com/resources/acfload_value/

Für das Ändern des Feldinhaltes vor der Ausgabe gibt es den acf/load_value Hook.
Es gibt vier Möglichkeiten, um sich in das Feld vor dem Anzeigen reinzuhängen.

Genereller Hook

Dieser Filter greift für jedes Feld – schlägt also bei jedem Feld an.
Das ist dann sinnvoll, wenn ich jedes Feld ändern will oder ich einen Feldtyp nicht ausschließen kann. Oder wenn ich den Namen oder die ID des Feldes nicht kenne.
Da der Hook immer greift, kann es zu Performance-Problemen kommen.

// acf/load_value
add_filter('acf/load_value', 'funktion_fuer_load_value_hook', 10, 3);

Hook für einen bestimmten Feldtyp

Wenn ich nur einen bestimmten Feldtypen behandeln will, ist das hier der richtige Hook.
Hier eine Übersicht der möglichen Feldtypen

Auswahlmöglichkeit der Feldtypen in ACF
Auswahlmöglichkeit der Feldtypen in ACF
// acf/load_value/type={$Feldtyp}
add_filter('acf/load_value/type=select', 'funktion_fuer_load_value_hook', 10, 3);

Hook für den vergebenen Namen eines Feldes

Wenn ich den Namen eines Feldes kenne und gezielt dieses Feld ansprechen will, bin ich hier richtig.
Der Name ist im Backend bei den Feld-Gruppen ersichtlich:

Feldname in ACF
Feldname in ACF
// acf/load_value/name={$Feldname}
add_filter('acf/load_value/name=e_mail_adresse_1', 'funktion_fuer_load_value_hook', 10, 3);

Hook für eine eindeutigen ID

Jedes Feld in ACF bekommt eine eindeutige ID, zb wie in folgendem Screenshot „field_56ac02513c8de“.
Diesen kann ich gezielt ansprechen. Dadurch wird der Code wenig dynamisch – da ich ja irgendwie den Key im PHP-Code hinterlegen muss. Unproblematischer ist das, wenn ich die ACF-Struktur sowieso per PHP bereitstelle.

Eindeutige ID - Key
Eindeutige ID – Key
// acf/load_value/key={$Feld-ID}
add_filter('acf/load_value/key=field_56ac02513c8de', 'funktion_fuer_load_value_hook', 10, 3);

 

Hook vor dem Speichern – acf/update_value

Gleich wie beim Filter load_value gibt es für den Schritt vor dem Speichern der Feldinhalte einen Hook.
Dieser nennt sich acf/update_value.
Dieser kann wieder die gleichen vier Szenarien wie oben abgreifen.
Daher gibt es je einen Hook für

  • alle Felder –  ‚acf/update_value‘
  • für einen bestimmten Feldtypen –  ‚acf/update_value/type=select‘
  • für einen vergebenen Feldnamen  – ‚acf/update_value/name=e_mail_adresse_1‘
  • für eine eindeutige ID –  ‚acf/update_value/key=field_56ac02513c8de‘

https://www.advancedcustomfields.com/resources/acfupdate_value/
https://www.advancedcustomfields.com/resources/acfupdate_value/

 

 

ACF Quelltext

Im Quelltext von ACF werden die Hooks so bereitgestellt:

ACF-Quelltext load_value Hooks
ACF-Quelltext load_value Hooks

 

https://github.com/elliotcondon/acf/search?utf8=%E2%9C%93&q=load_value
https://github.com/elliotcondon/acf/search?utf8=%E2%9C%93&q=load_value

 

Problem: Speichern leerer Inhalte in der Postmeta-Tabelle

Wenn ich zb manche ACF-Felder exklusiv in einer eigenen Tabelle speichern will, dann sollen die Daten ja nur dort auftauchen.
Das funktioniert, wenn ich mich in den acf/update_value Hook reinhänge und einen leeren Wert zurückgebe.
Das kann aber zu einem Problem werden, weil ACF dennoch Daten in der Postmeta-Tabelle speichert. Eben einen leeren Wert:

Leere Werte in Postmeta-Tabelle
Leere Werte in Postmeta-Tabelle

Beheben könnte ich das zb, indem ich mich in der WordPress eigenen Funktion update_metadata in den Hook „update_{$meta_type}_metadata“ reinhänge und bestimmte meta_keys behandle:

https://github.com/WordPress/WordPress/blob/e6267dcf19f1309954e04b65a7fa8e9e2df5d0a4/wp-includes/meta.php#L143

https://github.com/WordPress/WordPress/blob/e6267dcf19f1309954e04b65a7fa8e9e2df5d0a4/wp-includes/meta.php#L187

Update Metadata Hook
Update Metadata Hook

Links

acf/update_value

https://www.advancedcustomfields.com/resources/acfupdate_value/

 

acf/load_value

https://www.advancedcustomfields.com/resources/acfload_value/

 

https://www.advancedcustomfields.com/resources/#field-types
https://www.advancedcustomfields.com/resources/#field-types

Dynamic Select from other plugin table?


https://support.advancedcustomfields.com/forums/topic/dynamic-select-from-other-plugin-table/

Aktueller Status 2016

Wir bekommen die letzten Monate über öfters die Frage gestellt, warum wir keine neuen Blogartikel veröffentlichen.

Derzeit sind wir bis in den Herbst hinein mit einem großen und langfristigen Projekt betreut. Das freut uns auf der einen Seite sehr, weil es eine reizvolle Herausforderung ist. Auf der anderen Seite müssen wir die meisten Anfragen potentieller Kunden leider abweisen. Ab Herbst 2016 wird das aber besser 🙂

Intern passiert bei uns im Moment aber einiges:

Fixer Mitarbeiter

In unserem Umkreis bewegen sich zwar einige Freelancer und Partner, bis dato haben wir aber noch keinen fixen Mitarbeiter. Das ändert sich gerade und es schaut gut aus mit einem zukünftigen Kollegen. Wenns dann soweit ist, werden wir auch eine Blogartikelserie starten, die das Thema „Wie werde ich WordPress-Entwickler/Webentwickler“ behandelt.

GmbH

Wir sind gerade dabei unsere GesbR in eine GmbH umzugründen. Das ist ein logischer Schritt ab einer gewissen Größe, einem gewissen Umsatz und aufgrund der angedachten Zielen.
Für unsere Kunden ändert sich nix in der Geschäftsbeziehung. Wir haben dann einfach eine andere UID und eine Firmenbuchnummer.

Zukäufe/Übernahmen

Derzeit stehen wir in Verhandlungen, eine andere bekannte WordPress-Marke aus Österreich zu übernehmen. Wir werden diese Marke weiterführen und mit neuem Leben füllen. Dadurch wird ein Firmenbereich geschaffen, der nichts mit Agenturzusammenarbeit zu tun hat. Mehr dazu dann gegen Jahresende.

 

WordCamp Europe in Wien

Natürlich lassen wir uns das erste WordCamp Europe auf österreichischem Boden nicht entgehen! Wir werden mit drei Mann von 24. bis 26. Juni vor Ort sein und freuen uns auf andere interessante WordPress Geister 🙂

https://2016.europe.wordcamp.org/

Pro bono

Wie jedes Jahr bieten wir zu Weihnachten ein Projekt im Wert von ca 1.000 € pro bono an. Da unser Zeitbudget heuer knapp wird bitten wir darum, eventuell uns schon jetzt die Ideen zukommen zu lassen. Wie gehabt setzen wir ein Projekt gratis um, wenn es einem guten Zweck dienen soll.

 

 

 

 

 

Wie werde ich Emojis los – soll ich überhaupt?

Kurzerklärung

Emojis sind ein moderner Weg der Kommunikation. Die Verwendung kostet aber Ladezeit und Geschwindigkeit. Emojis wird man mit dem Disable Emojis Plugin los.

https://wordpress.org/plugins/disable-emojis/
https://wordpress.org/plugins/disable-emojis/

Die Basics

Die Entwicklung von Emoji-Support begann rund um den Februar 2015.
Mit der Version 4.2 unterstützte WordPress Emojis dann im Core.

Emojis sind diese kleinen smileyähnlichen Bildchen wie das hier:

Emoji aus dem Noto Font
Urheber: Google

Damit kann man sprachunabhängig kommunizieren, wenn man will.
Emojis helfen zumindest recht einfach und schnell, seine Emotionen in größerem Umfang wiederzugeben.

Das Problem: Viele Smartphones unterstützen Emojis von Haus aus, daher steigt die Verwendung.
Aber nicht alle Geräte und (Desktop-) Browser können von sich aus Emojis anzeigen, deshalb wird in WordPress eine kleine JavaScript-Datei geladen die überprüft, ob Emojis korrekt angezeigt werden können.

Wenn das nicht passiert, könnte es so ausschauen wie im WordPress Codex:
Textstelle ohne Emojisupport
Daher werden Emojis dort durch Bilder ersetzt, wo der Browser keine Emojis anzeigen kann.

Damit hab ich nicht so unschöne Ergebnisse wie im WordPress Codex.

 

Probleme?

  • Verlängerung der Ladezeit und der Geschwindigkeit
  • Einbinden von Inhalten, die auf fremden Servern gehostet werden

 

Damit das jetzt reibungslos funktioniert, wird eben eine kleine JavaScript-Datei geladen. Diese ist ca 5Kb groß und verursacht einen eigenen Request.
Das Script checkt jetzt, ob Emoji Support da ist. Wenn dem nicht so ist, werden Emojis durch Bilder ersetzt, damit der Inhalt nicht verschandelt ausschaut.

Welche Auswirkungen hat das auf die Seiten-Renderzeit?
Hier die Angaben aus dem entsprechenden Ticket:

Now the JS takes 1.6ms to run – 1.5ms for the JS, and 0.1ms for the style recalculation. About 0.01ms is added per emoji replaced. If we need to load Twemoji: Parsing twemoji.js: 0.8ms

Die JS Datei braucht also 1.6 ms für das Parsen. Das Behandel pro Emojis kostet 0.01ms. Wenn die Twemoji Datei geladen werden muss, kommen noch 0.8ms hinzu. (Twemoji bietet Unterstützung für Emojis, wenn der Browser/das Gerät keine Emojis versteht)

Der zweite Punkt ist, dass die Emojis von wordpress.org geladen werden, wenn diese in Bilder umgewandelt werden müssen:

😐

Firebug Ansicht vom Emoji img src

Das kostet einerseits wieder einen Request und eine DNS Abfrage des wp.org Hosts und andererseits hat dann ein anderer Server als mein eigener, Zugriff auf Daten meiner Besucher.

Wie werde ich die Emoji-Unterstützung los?

Der einfachste und empfohlene Weg ist das Disable Emojis Plugin.

https://wordpress.org/plugins/disable-emojis/

Der Code hinter dem Plugin ist umfangreicher als gedacht:

function disable_emojis() {
	remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
	remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
	remove_action( 'wp_print_styles', 'print_emoji_styles' );
	remove_action( 'admin_print_styles', 'print_emoji_styles' );	
	remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
	remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );	
	remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );
	add_filter( 'tiny_mce_plugins', 'disable_emojis_tinymce' );
}
add_action( 'init', 'disable_emojis' );

https://plugins.trac.wordpress.org/browser/disable-emojis/trunk/disable-emojis.php#L29

Aus der Sicht eines WordPress-Entwicklers ist das ziemlich umständlich.
Eigentlich hätte man den gleichen Weg wie beim Deaktivieren anderer JS erwartet.
Nämlich die Verwendung von wp_deregister_script.
jQuery deaktiviert man zb einfach so:

wp_deregister_script( 'jquery' );

 

Leider geht’s halt nicht so einfach. Daher entweder das Plugin installieren – was meist die besere Option ist. Alternativ kann man ja Teile des Plugin-Codes in ein (Child-)Theme übernehmen.

 

Soll ich den Emoji-Support deaktivieren?

Diese Frage muss jeder für sich selbst beantworten.

Es gibt genug Personen, die Emojis in ihren Inhalten verwenden. Wird der Support dafür deaktiviert, schauen die Text eventuell nicht mehr so gut aus.

Wird der Support deaktiviert, erspare ich mir weitere Requests und beschleunige die Ladezeit.

 

Lustiges Detail am Rande: Die Emoji-Unterstützung geht so weit, dass diese sogar in der Url erlaubt sind, siehe:


https://make.wordpress.org/core/2015/04/02/omg-emoji-%F0%9F%98%8E/

https://make.wordpress.org/core/2015/04/02/omg-emoji-%F0%9F%98%8E//

https://wordpress.org/plugins/disable-emojis/
https://wordpress.org/plugins/disable-emojis/

https://github.com/thierrypigot/mu-plugins/blob/master/deregister-emoji.php
https://github.com/thierrypigot/mu-plugins/blob/master/deregister-emoji.php

 

https://core.trac.wordpress.org/ticket/31701#comment:18
https://core.trac.wordpress.org/ticket/31701#comment:18

 

https://github.com/twitter/twemoji
https://github.com/twitter/twemoji

 

https://codex.wordpress.org/Emoji
https://codex.wordpress.org/Emoji

 

https://make.wordpress.org/core/tag/emoji/
https://make.wordpress.org/core/tag/emoji/

 

http://wordpress.stackexchange.com/a/185578
http://wordpress.stackexchange.com/a/185578

WordCamp Europe nächstes Jahr in Wien!

Tu felix Austria – wieder einmal 🙂

Nachdem heuer das erste Mal überhaupt ein WordCamp in Österreich stattfand, setzt man noch eines drauf und macht Wien nächstes Jahr zum Veranstaltungsort des WordCamp Europe 2016.
Vom 24. bis zum 26. Juni wird es stattfinden:

https://twitter.com/WPVienna/status/614830584658063360

 

 

https://twitter.com/onthisearth/status/614827378506903552

 

 

 

https://twitter.com/RubenSutiloFoto/status/614832840618983424

 

 

 

Update vom 29. Juni 2015:
Es gibt jetzt auch eine offizielle Stellungnahme, warum Wien das Rennen als Veranstaltungsort für das WordCamp 2016 gemacht hat:
Wien hat die perfekten Veranstaltungsräumlichkeiten und mit Paolo Belcastro hat man einen Organisator vor Ort, der auch schon in den letzten drei Jahren bei der Organisation des WordCamp Europe dabei war.
Hier der Originalartikel mit weiteren Details zur Auswahl des Veranstaltungsortes:

https://europe.wordcamp.org/2015/how-we-selected-vienna-the-wordcamp-europe-2016-host-city/
https://europe.wordcamp.org/2015/how-we-selected-vienna-the-wordcamp-europe-2016-host-city/

 

Vom 24. bis 26. Juni 2016 darf Wien also die WordPress-Gemeinde zum Stelldichein begrüßen.

Wir freuen uns darauf!

 

 

https://europe.wordcamp.org/2015/
https://europe.wordcamp.org/2015/

Quo vadis custom fields?

Im Jahr 2013 haben wir hier kurz darüber berichtet, dass man Custom Fields (Post Meta) besser nutzbar machen und umfangreiche Funktionalität dazu in den Core geben möchte. Es gab Bestrebungen, das Handling, Aussehen und die Funktionalität in „Richtung“ Advanced Custom Fields (ACF) zu treiben.

Mit etwas mehr als einer Million aktiven Installationen weltweit gehört ACF zu den beliebtesten Plugins und dürfte das führende Post Meta Plugin sein.
Warum?
Weil es die Metadaten aufwertet und sich unsagbar viele Dinge damit umsetzen lässt.

Das blieb dem Core-Entwicklerteam natürlich nicht verborgen und deswegen gab es auch schon im Jahr 2013 diesen Feature-as-a-Plugin-Ansatz, den wir in einem Blogpost kurz thematisiert haben.

Leider ist daraus nichts geworden – das Projekt ist eingeschlafen.

Helen Hou-Sandí, ein relativ neues Mitglied im Core-Entwicklerteam, hat sich dieser Sache nun angenommen und haucht der Idee neues Leben ein, Metadaten stärker in den Vordergrund zur rücken.

Durch den Erfolg der WP (JSON) API wird WordPress immer mehr zum Framework oder zur Grundlage für WebApps. Was auf der Hand liegt, weil man sich dadurch die Datenbankabstraktion, Benutzerverwaltung, Medienverwaltung usw usf spart.

Die JSON API ist eeextremst Gold wert – aber sie deckt nicht alles ab? Was nicht? GENAU! Custom Fields sind derzeit nicht zufriedenstellend implementiert.

 

Daten leben  nicht nur vom vordergründigen Inhalt alleine, sondern auch von den Metadaten und genau da hakt es ein wenig bei WordPress.

Zwei Eingabefelder alleine reichen im Jahr 2015 nicht mehr, um Metainformationen zu speichern.

Deswegen ist ACF ja so genial. Responsive Images, Slider, rudimentäre Webshopfunktionalität, globale Texte, Suchkriterien, Sortierkriterien, Front-End-Editing, Tag-, Category-, Termimages, zusätzliche Termoptions, rudimentäre Übersetzungen, flexible Inhalte usw usf.
Alles, was man sich an Funktionalität und verbundenen Daten wünscht und aufgrund der Tabellenstruktur der Post-Meta-Tabelle noch einigermaßen performant mit Custom Fields lösbar ist, lässt sich mit ACF leicht realisieren.

Was sich leicht realisieren lässt, wird auch von Entwicklern dankend angenommen und verwendet – dann soll so eine Funktionalität aber in den Core, um die Weiterentwicklung zu sichern. (Man sieht es beim Ausscheiden von Sergej Müller aus dem WordPress Universum, dass wir zu Abhängig von einzelnen Personen sind und diese dann auch noch zu wenig finanzieren.)

Automattic macht das eh ziemlich gut, und angelt sich die bekannteren Entwickler. (Ja! Es geht um die Entwickler! Die Plugins stehen alle unter der GPL und können von jedem geforkt werden.)
Durch den Schritt, WooCommerce zu kaufen, wandert ein weiteres, sehr stark verwendetes Plugin in „Richtung“ Core. WooCommerce wird voraussichtlich nicht direkt in den Core aufgenommen werden sondern wahrscheinlich das JetPack Plugin bereichern. Dennoch ist es für uns WordPress-Entwickler wichtig, dass WooCommerce unter der Obhut des Core-Entwicklerteams steht, die Weiterentwicklung gesichert ist und nicht die Gefahr besteht, eingestellt zu werden.

Uns als Entwickler kommen solche Schritte sehr entgegen, weil dadurch eine Planungssicherheit entsteht.

Daher ist es auch ziemlich unverständlich, warum man Elliot Condon, den Mann hinter ACF, nicht anstellt oder ACF kauft. Elliot wird vielleicht persönliche Gründe haben, davon Abstand zu nehmen.

Schade ist es aber, dass so ein Deal anscheinend nicht zustande kommt.

Dennoch geht hier etwas weiter. Das Core-Team ist dran, fängt aber bei Null an. ACF oder Elliot mit im Team zu haben wäre ein Raketenstart für die Verbesserung des Meta Handlings. Das spielt’s leider nicht, daher werden derzeit kleinere Brötchen gebacken.

Mehr Infos dazu gibt es hier:

https://make.wordpress.org/core/2015/05/27/metadata-api-project-reborn-the-new-fields-api-project/
https://make.wordpress.org/core/2015/05/27/metadata-api-project-reborn-the-new-fields-api-project/

 

https://make.wordpress.org/core/components/options-meta/
https://make.wordpress.org/core/components/options-meta/

 

Wir werden sehen, ob sich zwei Jahre später mehr tut und Erfolge erzielt werden, wenn es um Meta Handling im Core geht. Das Vorhaben ist ja schon einmal gescheitert – ich wünsche Helen daher mehr Erfolg bei diesem Versuch. Im Optimalfall können wir dann kompliziertere Daten- und Beziehungsstrukturen im Backend in Core-Mentalität abbilden und per JSON auslesen. Out of the box.