Erinnert sich noch jemand an die “Fairy Ultra”-Werbung mit Villarriba und Villabajo?

Zwei fiktive spanische Dörfer, die jeweils nach einer großen Party ihre Pfannen schrubben. Und während die Bewohner von Villabajo (mit herkömmlichem Spülmittel) noch tapfer vor sich hin putzen, wird in Villarriba (die Fairy Ultra nehmen) schon wieder gefeiert.

Der Vergleich hinkt zwar, aber trotzem spiegelt das die Situation der beiden oben genannten Content Management Systeme irgendwie wider:

Am 12. Mai veröffentlichte das Joomla!-Team eine Sicherheitsankündigung mit dem Hinweis, Joomla!-Installationen mit erscheinen des nächsten Updates am 17.05.2017 um 16 Uhr möglichst direkt zu aktualiseren.

Mit der Veröffentlichung von Joomla! 3.7.1 wird u.a. eine kritische Sicherheitslücke geschlossen. Das Update erscheint voraussichtlich am 17.05.2017 um 16 Uhr.

Das Joomla Sicherheits-Team (JSST) wurde über eine kritische Sicherheitslücke im Joomla! Core informiert. Da dies eine sehr wichtiger Sicherheitspatch ist, bereitet euch bitte darauf vor, eure Joomla Seiten nächsten Mittwoch zu aktualisieren.

Solch ein Hinweis ist richtig und wichtig, doch in einer globalen Welt ist es nicht überall zum gleichen Zeitpunkt 16 Uhr. Und während die einen in der Nachtruhe schlummern, sind andere unterwegs fernab jedes PCs und der Patch - mit dessen Erscheinen auch die kritische Sicherheitslücke selbst bekannt wird - wird nur auf einem Bruchteil der Systeme zeitnah (also innerhalb weniger Minuten) eingespielt werden können. Es beginnt ein Wettrennen - auf der einen Seite finstere Gestalten, die möglichst schnell die Sicherheitslücke auszunutzen wollen und auf der anderen Seite Admins, die versuchen, die von Ihnen betreuten Systeme zeitnah zu aktualisieren.

Ganz anders dagegen in der WordPress-Welt, seit mit Version 3.7 automatische Hintergrund-Updates eingeführt wurden: während der Administrator dieser Seiten in der Nacht vom 16. auf den 17. Mai vor sich hinschlummerte, hat sich WordPress automatisch auf die Version 4.7.5 aktualisiert und anschließend per E-Mail darüber informiert.

Sicherlich sind automatische Updates kein Allheilmittel und bergen die Gefahr, dass eine Aktualisierung nicht reibungslos verläuft und die Funktionalität einer Website beeinträchtigt wird. Vorbehalte gegen solche Automatismen gibt es - besonders bei denjenigen, die sie nicht verwenden - viele und viele Unternehmen haben bei der aktuell durch die Welt schwappenden Erpressungstrojaner-Welle mal wieder gezeigt, wie wenig hilfreich es ist, monatelang auf Systemaktualisierungen zu verzichten.

Betrachtet man die Zahl an Websites von Privatleuten, klein(er)en Unternehmen und Vereinen, deren Komplexität durchaus überschaubar ist und deren Admin meist nach dem “Du machst doch irgendwas mit Computer, kannst Du nicht mal …” ausgewählt wurde, scheinen automatische Updates eine sinnvolle Möglichkeit, ohne allzu hohes Ausfallrisiko die Sicherheit für den Betreiber und auch Dritte (sowohl Besucher der Website als auch andere Kunden in shared Hosting Umgebungen) deutlich zu erhöhen.

Wer sich für viel Geld eine hochkomplexe Webpräsenz erstellen lässt, der ist seinem dedizierten Admin hoffentlich für eine Rechnung mit Nachtzuschlag dankbar, weil dieser im Bedarfsfall um 2 Uhr Nachts lieber geschrubbt statt gefeiert hat.

Wenn eine Firma Meister darin ist, sinnvolle Funktionen zu streichen, sinnbefreite Funktionen einzuführen und mit Konfigurationsmöglichkeiten zu geizen, dann ist das Google.

So war ich auch wenig begeistert, als mir in einem neuen Tab unter der Überschrift “Artikel für Sie” als erstes die News “Kevin Großkreutz im Krankenhaus” und “Nachholspiel gegen Dortmund” angeboten wurden. Tröstlich, daß selbst akribische jahrelange Beobachtung und Datenspeicherung offensichtlich nicht dazu führt, ein halbwegs sinnvolles Nutzerprofil erstellen zu können.

Natürlich ist auf den ersten und zweiten Blick keine Möglichkeit vorgesehen, dem unnützen Daten- und Akkuverbrauch ein Ende zu bereiten.

bis einschließlich Chome 57:

Erst ein Blick in die erweiterten Einstellungen, die über die URL “chrome://flags” erreichbar sind, bietet die Möglichkeit, “Show content snippets on the New Tab page” auf “Deaktiviert” zu stellen.

ab Chrome 58:

Mit Chome 58 hat Google den Parameter geändert, dieser lautet nun „Show server-side suggestions on the New Tab page“, der Weg zu den Einstellungen führt weiterhin über die URL “chrome://flags”.

ab Chrome 68:

In Chome 68 heisst der Parameter immer noch „Show server-side suggestions on the New Tab page“, die Optionen wurden aber umbeannt und die gesuchte Einstellung ist nun “Disabled”. Der Weg zu den Einstellungen führt weiterhin über die URL “chrome://flags”.

ab Chrome 78:

Wie NoNPerfect in den Kommentaren gepostet hat, reicht “Show server-side suggestions on the New Tab page“ auf „Disabled“ alleine nicht mehr aus. Zusätzlich muß noch „Interest Feed Content Suggestions“ ebenfalls auf „Disabled“ gesetzt werden.

ab Chrome 80:

Wie den Kommentaren zu entnehmen ist, scheinen die oben aufgezeigten Lösungen unter Chrome 80+ nicht mehr zu funktionieren. Da ich Google Chrome inzwischen sowohl vom Mobilgerät als auch vom Desktop verbannt habe, kann ich selbst keine Lösung mehr liefern - falls jemand fündig wird, bitte in den Kommentaren posten.

Gerade nach langer Zeit mal wieder den Windows XP-Modus gestartet und über die Statusmeldung der Microsoft Security Essentials gestaunt:

Das grüne Häkchen sowohl in der Tastleiste als auch in der Anwendung selbst (obwohl es da ja eigentlich ein weißer Haken auf grünem Grund ist) halte ich schon für seeeeeehr optimistisch.

Mit PHP 4 wurden Konstruktoren eingeführt, welche den gleichen Namen haben wie die Klasse, in der sie definiert wurden:

class tolleKlasse {

    function tolleKlasse() {
    
        // ...
    }
}

In PHP 5 wurden diese Konstruktoren beibehalten, gleichzeitig aber mit der Methode

__construct()

eine neue Art der Konstruktor-Definition eingeführt. Seit PHP 7 wird bei der Verwendung von PHP 4 Konstruktoren nun die Warnung “Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP” ausgegeben, die darauf hinweist, daß ab PHP 8 die gleichnamigen Methoden nur noch als normale Methoden, nicht aber als Konstuktoren behandelt werden.

Um vorhandenen Code fit für die Zukunft zu machen, reicht es, den Namen der Funktion zu ersetzen:

class tolleKlasse {

    function __construct() {
    
        // ...
    }
}

Da hierdurch vorhandener Code, welcher z.B. im Rahmen einer Vererbung auf den Funktionsnamen des Konstuktors zugreift, in einen Fehler läuft, kann nach dem Konstruktor eine zweite Methode mit dem ursprünglichen Funktionsnamen angelegt werden, welche den eigentlichen Konstruktor aufruft.

WordPress bietet standardmäßig keine Möglichkeit, einmal hinzugefügte Medien zu einem anderen Beitrag oder Seite zu verschieben und dort anzuhängen. Gerade für einmalig durchzuführende Aufräum- oder Umbauarbeiten macht es wenig Sinn, sich auf die Suche nach einem Plugin zu begeben, da die Aufgabe auch mit einem einzigen SQL-Statements zu erledigen ist.

Zu beachten ist, daß hierbei lediglich die Zuordnung zwischen Medien-Datei und Beitrag geändert wird, am Inhalt der Beiträge ändert sich nichts. Die so verschobenen Medien können allerdings anschließend über den “Zu diesem Beitrag hochgeladen”-Filter deutlich einfacher aufgefunden und verwaltet werden.

Zunächt müssen die IDs der beiden Beiträge ermittelt werden, zwischen denen verschoben werden soll. Wer das nicht direkt in der Datenbank erledigen will, kann auch die WordPress-Oberfläche zu Rate ziehen: einfach beim jeweiligen Artikel auf “Bearbeiten” klicken und die ID aus der URL entnehmen, z.B. “/wp-admin/post.php?post=3527&action=edit”.

Dann können die Medien verschoben werden:

UPDATE wp_posts SET post_parent = <neue_ID> WHERE post_parent = <alte_ID> AND post_type='attachment';