DomainFactory-Umstellungen verhindern WordPress-Update

Quo Vadis DomainFactory? Nach der Übernahme durch GoDaddy stellt das US-Unternehmen immer weiter die Technik auf die eigene Infrastruktur um. Wie schon bei der Umstellung der Mail-Konten oder der Preismodelle geht dabei so einiges schief. Von einem krassen Beispiel eines Kunden von mir handelt dieser Artikel.

Startpunkt war, dass ich alle meine Wartungskunden darauf überprüfte, ob das automatische Sicherheit-Update auf WordPress 7.0.2 erfolgreich angekommen ist. Bei einer Kundin war das nicht der Fall. Innerhalb von WordPress sah ich keine Hinweise. Insbesondere der Health-Check, der meckert, wenn Background-Updates aus irgendeinem Grund verhindert werden, schlug nicht an. Also wollte ich mich auf dem Server umschauen. Aber das ging nicht. Mein Zugang wäre angeblich falsch.

FTP over SSL oder SFTP – ist doch egal!

Ich habe mit diesem Zugang schon immer gearbeitet und warum sollte die Kundin an einem explizit nur für mich eingerichteten FTP-Zugang etwas ändern?

Also loggte ich mich bei DomainFactory im Kundenmenü ein und checkte den FTP-Zugang. Da fiel mir auf, dass der Benutzername neuerdings nicht mehr nur Zahlen und gewählter Name sind, sondern auch noch die Domain umfasst.

Statt „123456-eigenername“ musste es jetzt „123456-eigenername@example.com“ heißen.

Auch war der FTP-Zugang nicht mehr SFTP über Port 22, sondern jetzt FTP over SSL über Port 21.

Was kann ein Background-Update verhindern?

Okay, dann weiter suchen, was das Problem sein könnte. Wenn es keine Konstante, Filter oder Versionierung ist, woran kann es denn noch liegen?

Da mir auf die Schnelle nichts einfiel, fragte ich ChatGPT, was ich nur empfehlen kann. Es muss gar nicht die perfekte Lösung treffen, es reichte mich in eine bestimmte Richtung zu bringen. In diesem Fall erwähnte ChatGPT, dass die Update-Prüfung durch einen Cronjob gestartet wird und somit kaputtgehen kann, wenn der Cronjob nicht ausgeführt wird.

Ich installierte also WP Crontrol und checkte, ob etwas mit den Cronjobs nicht stimmt. Und ja, da gab es ein ganz erhebliches Problem. Seit einem halben Jahr (!) wurde hier kein einziger Cronjob mehr ausgeführt. Okay, das war eine low-traffic Broschüren-Website, aber die Website hat durchaus ein paar Besucher, müsste also zumindest verspätet die Cronjob ausführen. Aber keine einzige Ausführung seit einem halben Jahr. Das war krass.

Der WP-Cron war aber auch nicht via Konstante deaktiviert. Gut, also testen wir mal, was passiert, wenn ich den Cron manuell starte. Hoppala, der Cron wird als „Immediatley Non-repeating“ in die Liste hinzugefügt, aber da bleibt er auch. Auch nach einem Reload der Seite. Der Cronjob wird also auch nicht ausgeführt und bleibt einfach unausgeführt in der Liste. Was nun?

Vielleicht ein versteckter Fehler im Ladeprozess vorher, der die Ausführung verhindert? Also DEBUG-Modus an und debug.log gecheckt. Leider kein Fehler sichtbar.

PHP-Extensions – einfach mal abschalten …

Nun war ich gefragt, denn ChatGPT kennt ja nicht das konkrete Setup. Zur Performance-Optimierung läuft da APCu, vielleicht ist da etwas durcheinander geraten. Die Möglichkeit zum Deaktivieren des Tools war ausgegraut, was rückblickend schon ein Hinweis auf das Problem war. Da ich diese Option also nicht nutzen konnte, wollte ich die /wp-content/object-cache.php kurz umbenennen. Statt die Datei umzubenennen, verschwand sie jedoch komplett. Was war das denn? Das hatte ich auch noch nicht erlebt.

Ein Blick ins Backend offenbart: Die Cronjobs wurden abgearbeitet. Es läuft wieder! Hurra! – Aber was war passiert?

DomainFactory hat bei seinen Umstellungen die vormals aktivierte APCu Extension deaktiviert. Das hätte ich zwar im cPanel auch wieder aktivieren können, aber das ist mir erst später aufgefallen. Dadurch, dass die /wp-content/object-cache.php immer noch vorhanden war, aber keine APCu Extension, hing der Object Cache vermutlich auf einer Uralt-Version und wurde nicht aktualisiert und blockierte seit Monaten das Cron-System.

Heidewitzka. Warum machen die das denn? Insbesondere, wenn die Extension aktivierbar gewesen wäre …

Es kann nur eine PHP-Version geben!

Wo ich schon mal im Backend war, wollte ich noch die PHP-Version auf eine aktuelle Version stellen. Die Einstellung war früher im Kundenmenü direkt, aber da gab es den Punkt PHP-Einstellungen nicht mehr. Also den cPanel-Login-Link folgen. Dann landen wir bei DomainFactory in einem merkwürdigen Zwischenreich, nicht mehr Kundenmenü, aber auch noch nicht cPanel.

Nächste Verwunderung: Hier könnte ich DKIM aktivieren. Warum machen die das nicht automatisch? Okay, aktiviere ich auch noch schnell, aber nein, ich soll die DNS-Einträge jetzt selbst setzen. Wozu haben wir denn Computer? Das könnten doch automatisiert passieren. Ernsthaft, ich muss das jetzt selber machen? Aber das kennen wir ja schon von DomainFactory. Die SSL-Zertifikate, die jetzt in vielen Tarifen nicht mehr inklusive sind, müssen ja jetzt auch selbst übertragen werden. Okay, DKIM-Exkurs abbrechen.

In diesem Zwischenreich steht eine globale PHP-Version, die aber nicht passt. WordPress zeigte mir PHP 8.2. Hier wird aber PHP 8.3 als angeblich global konfiguriert angegeben. Das wird vielleicht für die einzelne Domain überschrieben, also weiter zum cPanel.

Aber auch hier steht nicht die 8.2 für die PHP-Version der Domain, sondern etwas Aktuelleres. Aber ich kann’s eh nicht umstellen. Die Option ist ausgegraut und somit inaktiv. Woher kommt denn jetzt die PHP 8.2 her und wie und wo stelle ich das um?

Früher, sehr viel früher haben wir die PHP-Version in der .htaccess festgelegt. Die würden doch nicht etwa? Doch, genau das haben sie. Ganz oben im Wurzelverzeichnis des /public_html-Ordners befindet sich eine .htaccess, die einen Redirect auf den Ordner enthält, den ich im Kundenmenü konfiguriert habe. Ebenso die Konfiguration, welche Dateien versucht werden sollen, als Index-Datei zu starten (index.html, index.php, etc.). Und diese Zeile:

AddHandler application/x-httpd-alt-php82___lsphp .php

Die stammt nicht von mir und sicher nicht von meiner Kundin. Damit war die PHP-Version fest auf 8.2 eingestellt und keine Einstellung in keinem Menü konnten daran etwas ändern. WTF.

Fazit

Immerhin habe ich alles gefunden und reparieren können, aber was zur Hölle hat die Leute geritten, das so umzusetzen? Technisch eine Katastrophe und auch von der UX ist das ganze Kundenmenü nun fast schon auf Hosteurope-Niveau kaputt.

Du hast eine ähnliche Katastrophen-Geschichte, dann ab damit in die Kommentare!

Möchtest du von DomainFactory (oder Hosteurope) aus absolut verständlichen Gründen umziehen, dann melde dich gerne über das Kontaktformular!