• http://wpgear.org/
• Mobil entwicklen https://t3n.de/news/apps-entwickler-1101700/amp/?post_type=post&p=1101700&__twitter_impression=true

Es ist einer der ärgerlichsten Probleme mit WordPress die man kennt.

Ein Fehler beim Upload von Bildern.

Man sucht alle Logdaten durch, schaut sich die Firewall und Jails an und kommt nicht dahinter, woher das Problem kommt.

Es gibt für das Problem mehrere Ursachen und einige Lösungen.

Gesperrte IP-Adresse?

Es kann zb bei Plesk passieren, dass die eigenen IP-Adresse gesperrt ist.

Das kann man einfach begutachten und beheben, indem man bei den Tools & Einstellungen die eigenen Adresse wieder freischaltet:

ModSecurity/WebAppFirewall überprüfen

ModSecurity kannn oft die Ursache für ein Problem beim Medienupload sein.

In den Einstellungen von Plesk wird sogar darauf hingewiesen, dass manche ModSecurity Regelsätze Probleme mit zb WordPress bereiten.

Sicherheitsplugins überprüfen

Plugins wie iThemes Security, Wordfence o.ä. können auch dafür zuständig sein, dass gewisse Anfrangen an WordPress nicht weitergeleitet oder geblockt werden.

PHP-Version ändern

Oft hilft es auch einfach die PHP-Backend-Version auf zb FastCGI zu ändern.

So geht das beispielhaft:

Apache oder Server neu starten

Die Holzhammer-Methode wäre es, den Apache oder den Server neu zu starten.

Das hilft aber manchmal!

…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

Ä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:

• direct (Standardwert)
• ssh2
• ftpext
• ftpsockets

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.

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.

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.

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/

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:

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:

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:

?

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://wordpress.org/plugins/disable-emojis/

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

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

https://github.com/twitter/twemoji

https://codex.wordpress.org/Emoji

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

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