Ja, der erste Teil der Überschrift ist dem aktuellen Stil in den Redaktionen dieser Welt geschuldet. Aber, man möge mir verzeihen :)
Immerhin sagt der zweite Teil der Überschrift eh, worum es geht, nämlich um Absichern von wp-admin mittels htaccess-Passwort.
Wozu das alles?
tl;dr
Das wp-admin-Verzeichnis sollte per .htaccess abgesichert werden!
Dadurch schließt man ohne Plugin viele potentielle Sicherheitslücken und Angriffsvektoren
Der nette Angreifer aus der Nachbarschaft!
Wir haben eine neue Seite aufgesetzt und in den erste Tagen beobachtet, welche Zugriffe passieren. Ohne SEO, ohne Werbung o.ä.
Es tut sich logischerweise nicht viel, aber was sich tut ist augenscheinlich.
WIR WERDEN ANGEGRIFFEN!111omfg
Worauf es Angreifer abgesehen haben und was wir absichern werden!
WordPress ist einer der sichersten Webanwendungen – aber jede Software hat ihre Schwächen. Mit jedem installierten Plugin kommt eine potenzielle Schwachstelle dazu.
Und wenn dann noch Plugins aus dubiosen Quellen installiert wird, schlägt man die Tür für Angreifer weit auf.
Und danach suchen Angreifer. Nach Schwächen in installierten WordPress-Plugins. Nach Einfallstoren.
Das passiert nicht händisch, sondern diese „Angriffe“ werden automatisch durchgeführt. Mit Bots. Angriffe in Anführungszeichen, weil das erstmals nur Austesten von Schwachstellen sein kann.
In obigem Screenshot sieht man sehr gut, worauf die Bots Lust haben:
Auf das wp-Admin-Verzeichnis.
wp-admin Verzeichnis absichern
Klar! Das wp-admin-Verzeichnis steht für das Backend von WordPress, für die Administrationsansicht.
Da würden Angreifer gern hinein.
Das abzusichern ist wirklich der einfachste Trick überhaupt – deshalb auch die reißerische Überschrift!
Dafür brauch ich kein Plugin, ich muss nix installieren und es geht so gut wie gar keine Funktionalität für eine normale 08/15 Webseite verloren.
Was also tun?
htaccess-Passwort setzen
Um das wp-admin-Verzeichnis abzusichern, muss man auf das Verzeichnis einfach mit htaccess absichern!
Also einen Usernamen und ein Passwort für das wp-admin Verzeichnis anlegen.
Das funktioniert bei den diversen Hostern ähnlich, schaut naturgemäß aber ein Bisserl anders aus. Als Hilfestellung hier ein paar Tutorials der bekannteren Hoster:
So schaut die Mediawiki-Syntax schlussendlich formatiert im Frontend aus!
Konvertierung mit Pandoc
Pandoc ist eine Kommandozeilen Bibliothek, mit der man Texte und Dateien aus verschiedene Formate in verschiedene Formate exportieren kann.
Habe ich zb die Datei reisen.wiki, die in der Mediawikisyntax geschrieben ist, hilft mir folgender Befehl, wenn ich die Seite nach HTML umwandeln will.
Wir haben daher die Seiten von der Wikimedia-Syntax in das Markdown Format überführt.
Warum? Weil man damit keinen unnötigen Code hat und es für WordPress super Markdown-Plugins gibt.
Ursprünglich war die Idee, die Wikieinträge nicht zb nach Markdown umzuwandeln, sondern gleich in ein sauberes (saubereres) HTML. Das Ergebnis schaut dann aus wie in den folgenden Screenshots wobei zu beachten ist, dass das oben gezeigte Bild (rosarotes Österreich) nicht verlinkt ist, weil aus der Mediawiki-Syntax nur der Bildname im SRC des Image-Tags übrig bleibt.
Problem der Umwanldung nach HTML
Hat man in einem Wiki-Artikel zb Codeteile drin, die mit Codehighlighting sichtbar gemacht werden, wirds umständlich:
Umständlich, weil Pandoc freundlicherweise Css-Regeln einfügt.
Was grundsätzlich eh super ist, weil ich dann das Code-Highlighting im Export/in der umgewandelten HTML-Datei habe:
Das ist für die Weiterverwendung in WordPress aber suboptimal.
Weil ich dann im Beitragsinhalt/im Content CSS-Regeln habe, und die dort nicht hin gehören.
Alternativen
Man könnte den XML-Export vom Mediawiki verwenden. Dann braucht man auf WordPress-Seite einen Importer. Die XML-Exportdatei gefällt mir nicht so gut. Mit der Umwandlung in ein aufgeräumtes HTML von Pandoc kann ich die Inhalte gleich in den WordPress-Editor reinkopieren.
Markdown in WordPress
Mit diesem Markdown-Plugin https://wordpress.org/plugins/wp-githuber-md/ wird der Inhaltseditor angepasst und schaut dann so aus:
Auf der linken Seite hab ich den markdown formatierten Text, rechts das Ergebnis, das auch im Frontend angezeigt wird:
Google macht ja schon länger in WordPress. Angefangen von Webinaren, Videoanleitungen und Tutorials über AMP und bezahlte Entwickler, die WordPress-Code beitragen.
Google hat also sowieso im WordPress-Universum einen Fuß in der Tür.
Jetzt geht man anscheinend einen Schritt weiter, was für die Zukunft einige Umbrüche bringen könnte.
Google sucht WordPress-Entwickler
Alberto Medinas Blogpost mit dem Aufruf an WP-Entwickler
Google sucht also nach WordPress-Entwicklern, die sich an folgende Themen ranmachen sollen:
Projekt Gutenberg vorantreiben, damit die Usability besser wird (Dringend notwendig)
Themes erstellen, die moderne Webtechnologien verwenden
Mitarbeit am AMP-Plugin (ich persönliche halte wenig von AMP!)
Mitarbeit am TIDE-Plugin (Plugin zur Bewertung der Codequalität von Plugins uvm)
Google Sitekit Plugin um AdSense-, Analytics-, PageSpeed- und Suchkonsolen-Daten gebündelt im WordPress Dashboard anzeigen zu können.
Diesem Aufruf sind schon mehrere bekannte Namen aus dem WordPress-Universum gefolgt, der bekannteste dürfte derzeit Weston Ruter sein, der in seinem Blogpost seine Beweggründe erklärt:
Gerücht am Rande: Laut Informierten, bezahlt Google in der Schweiz ein Einstiegsgehalt von 170.000 Franken – gerüchteweise ohne Garantie auf Richtigkeit.
Hintergründe: Mitbestimmung beim wichtigsten CMS?
Google meint es also ernst.
Warum überhaupt?
WordPress ist die Unterlage von ca 30% der Webseiten überhaupt. Es wäre von Google fahrlässig, hier irgendwelchen Playern das Feld allein zu überlassen ohne ein Mitspracherecht zu haben.
Die Strategie erinnert ein wenig an Microsoft – und das erste Bild in diesem Blogpost hat eine umwerfende Ähnlichkeit zu diesem Sujet:
Microsoft liebt Linux? Und Google jetzt WordPress? Zufall?
Microsoft weiß um die Dominanz von Linux in der Serverumgebung.
Google weiß um die Dominanz von WordPress im CMS-Umfeld.
Beide wissen, dass sie sich aktiv an der Entwicklung dieser Open Source Projekte kümmern müssen, um mitbestimmen zu können.
Das Problem bei Open-Source-Projekten aus der Sicht von Unternehmen ist halt, dass da meist Individualisten, Querköpfe und Spinner am Werk sind. Programmierer eben.
Und Programmierer sind meist schlechte Führungspersönlichkeiten.
Daher sind Ziele oft verwässert oder Entwicklungen gehen in falsche Richtungen oder Zersplittern sich uvm.
WordPress ist da ein bissl anders gelagert:
Besondere Situation von Automattic in der open source Welt
WordPress ist zwar open source, also kann von jedem verwendet und verändert werden.
Aber hinter WordPress steht eine erfolgreiche Firma, die eigentlich über alle Aspekte von WordPress bestimmen kann.
Angefangen vom Namen und Logo. Beides gehören Automattic bzw einer Stiftung rund um den Gründer von Automattic, Matt Mullenweg.
Matt gibt auch die Schlagrichtung vor. Also wohin sich WordPress als Projekt bewegen soll. Welche Ziele in den nächsten Releases, also den nächsten Versionen, verfolgt werden sollen.
Das hat alles sein Gutes. Automattic bezahlt eine Menge an Entwicklern, die am WP-Sourcecode weiterschreiben. Den Core also weiterentwickeln, verbessern und aktuell halten.
Gemäßigter Diktator als Warnsignal für Google?
Das ist ein großer Vorteil gegenüber anderen Open Source Projekten, die keinen potenten Geldgeber im Hintergrund haben.
Ohne Matt und Automattic gäbe es WordPress in der Form nicht. Da steckt sehr viel „privates“ Geld in einem quelloffenen CMS. Das eigentlich von Nerds und Spinnern programmiert wird. Gerade open source Communitys haben selten eine Führungsperson.
Liste bekannter gemäßigter Diktatoren (BDFL) auf Wikipedia
Und Diktatoren sind halt das, was sie sind: Machtmenschen, die oft irgendwann den Bezug zur Realität verlieren.
Wäre ich Entscheider bei Google, würde mich sowas hellhörig machen.
Realitätsverlust? Gutenberg-Drama? Betriebsblindheit? Wird Matt wunderlich?
WordPress ist gerade im Umschwung.
Mit Gutenberg kommt ein neuer Editor, der von der Idee her wirklich Gutes bringen wird.
Derzeit ist Gutenberg aber für Ottonormalverbraucher quasi unbenutzbar.
Die einfachsten Dinge sind nicht offensichtlich zu lösen.
Zb das Einfügen von Bildern in einen Text ist eine grenzwertige Erfahrung. Das hab ich von Anfang an kritisiert und auch den Core-Entwicklern mitgeteilt. Geändert hat man seitdem nix.
Das Bilder-Einfügen ist also seit Anbeginn ein ungelöstes Problem und wird auch nicht Behoben, da von den Entwicklern und von Matt als „kein Problem“ angesehen werden.
Und da beginnen die Probleme. Die Offenheit der Core-Entwickler, die ja zu einem guten Teil Automattic-Mitarbeiter sind, ist nicht gegeben.
Im Gegenteil: Man fühlt sich sogar angegriffen, wenn man konstruktive Vorschläge und Kritik vorbringt.
Rund um das Thema hat sich eine Posse entwickelt, die derzeitig problematische Situation und das Spannungsfeld Automattic <-> Matt <-> WP-Entwickler verdeutlicht:
Gutenberg und die Version 5.0 von WordPress hätten am 19. November veröffentlicht werden sollen.
Da war Gutenberg nicht fertig – daher gab es sehr viele Stimmen dagegen.
Und Moment. 19. November? Da war doch was! Ach ja, Thanksgiving-, Cybermonday- und BlackFriday-Woche. Die umsatzstärkste Woche im amerikanischen E-Commerce.
Was war das doch für ein grandioser Terminvorschlag….
Neuer Veröffentlichungstermin?
26. November.
Dieser Termin wird auch nicht halten.
Daher wird Dezember vorgeschlagen. Was natürlich keine gute Idee ist, kurz vor der Weihnachtszeit.
Also wird’s 2019 werden.
Das hört sich nicht nach stringentem Projektmanagement an…
Zudem fragen sich viele (Core-) Entwickler, wer denn das nun alles beschlossen hat.
WordPress wird von einer Open Source Community entwickelt. Diese ganzen Änderungen kommen aber nicht von der Community. Wer hat da also wohl das sagen und warum?
Ablenkungsmanöver
Im Moment dürfte Matt unter Stress stehen. Manche seiner Antworten sind daher ein bisserl wunderlich.
So gibt es Stimmen, dass es zu viele offene Issues für den Release Candidate von WordPress gibt. Wie antworten trotzige Kinder? Genau:
Viele haben Angst vor einer Veröffentlichung einer neuen Major-Version im Dezember. Eh schon wissen: Weihnachten und Weihnachtszeit bei uns und noch mehr in den Staaten. Die obligatorische Matt-Antwort im Core-Slack-Channel:
Weitere Meinungen zu Matt, Gutenberg und Leadership
Der Kollege wirft ein paar interessante Fragen rund um die Rolle von Matt und den Release von Gutenberg auf. Er spricht darauf an, dass WordPress eigentlich kein Automattic-Produkt sondern ein Community-Produkt ist.
Es stehen gravierende Änderungen an, die zukünftige User verstören oder verzücken könnten.
Dennoch herrscht ein bissl Chaos.
Durch die aktuellen Schritte, die Google im WordPress-Universum unternimmt, kommt es mir so vor, als wollte Google einen stabilisierenden Faktor reinbringen. Natürlich geht es da aber auch um Mitbestimmung.
Derweilen nur schleichend und nicht offensichtlich.
Ich bin gespannt, ob ich mit dieser Theorie auch nur annähernd richtig liege.
Aus betriebswirtschaftlicher Sicht wäre es nur logisch.
Links
Google Sitekit – Plugin zum gebündelten Anzeigen aus Google Spionage..äh..Tracking-Tools.
Im WP-Kontext sind Nonces eine zufällige Aneinanderreihung von Zahlen und Buchstaben, die zwar mehrmals verwendet werden (im Gegensatz zur üblichen Implementierung von Nonces – Number used once), aber ein klar definiertes Ablaufdatum haben.
werden mit wp_nonce_url( $actionurl, $action, $name ); aufgerufen.
$actionurl ist die URL, die wir mit der Nonce „absichern“ wollen.
required; Default: None
$action ist der Name der action, die wir frei wählen können.
optional; Default: -1
$name ist der Name der so generierten Nonce.
optional; Default: _wpnonce
Als Rückgabewert erhalten wir eine bereinigte URL mit zusätzlicher Nonce. Diese sieht in etwa so „http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204“ aus.
Forms
werden mit wp_nonce_field( $action, $name, $referer, $echo ); aufgerufen. Diese Funktion generiert uns bis zu zwei hidden input Elemente.
$action definiert den Namen der action.
optional, aber empfohlen; Default: -1
$name ist der Name der so generierten Nonce.
optional. Default: _wpnonce
$referer gibt an, ob ein zusätzliches hidden input Element erstellt werden soll, das den Output der Funktion wp_referer_field beinhaltet.
optional; Default: true
$echo gibt an, ob die so erstellten inputs im HTML ausgegeben werden.
optional; Default: true
Als Rückgabewert erhalten wir ein oder zwei hidden input Elemente, wenn $referer true ist.
Validierung
Allgemein
check_admin_referer( $action, $name ); überprüft sowohl die Nonce als auch den $referer.
$action ist der Name der action, die wir frei wählen können.
optional; Default: -1
$name ist der Name der so generierten Nonce.
optional; Default: _wpnonce
AJAX
check_ajax_referer( $action, $query_arg, $die ); überprüft nur die Nonce im Zuge eines AJAX-Requests.
$action ist der Name der action, die wir frei wählen können.
optional; Default: -1
$query_arg ist der Name der so generierten Nonce
optional; Default: false
$die gibt an, ob das script angehalten werden soll, wenn die Überprüfung fehlschlägt
optional; Default: true
Basic
wp_verify_nonce( $nonce, $action ); überprüft nur die Nonce.
$nonce ist der Name der Nonce, die überprüft werden soll.
required; Default: None
$action ist der Name der action.
optional; Default: -1
Eine einfache Überprüfung könnte z.B. so aussehen:
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.
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:
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:
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.
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:
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:
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.
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:
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.
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‘
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:
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.
Emojis sind ein moderner Weg der Kommunikation. Die Verwendung kostet aber Ladezeit und Geschwindigkeit. Emojis wird man mit dem Disable Emojis Plugin los.
Emojis sind diese kleinen smileyähnlichen Bildchen wie das hier:
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:
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.
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:
Sicherheitsplugins überprüfen
