Weisse Seite nach Umzug (Debug kein Effekt!)

Mal ne blöde Frage: Ich wollte den Theme-Ordner aus den Installationsdateien frisch machen. Dazu benannte ich meinen alten um, und erstellte einen leeren Themes-Ordner. Beim Kopieren der Dateien meckerte Nautilus, dass die Dateien bereits existieren würden. Erstellt WP im Fehlerfalle den Ordner mit Standard-Themes wirklich neu? Also… ist WP doch noch aktiv?
Wenn dem so ist, wieso bekomme ich dann keine Debug-Infos angezeigt?
define(‚WP_DEBUG‘, true);
define(‚WP_DEBUG_LOG‘, true);
define(‚WP_DEBUG_DISPLAY‘, true);
Steht direkt über dem Edit-Hinweis, wo es hingehört.

Auch die Dateirechte scheinen zu stimmen.
Plugins sind weg (in DB und Files), Themes sind weg (Files und DB (active, template, stylesheet).

Was mir noch auffällt:
Es befinden sich noch einige Einträge mit dem absoluten Pfad in der DB. Der lautete früher:
/var/www/vhosts/tellerrandforschung.de/httpdocs/hessburg.de
Ich will jetzt nicht wüst alles ersetzen, aber kann es sein, dass diese Einträge relevant sind und nicht dynamisch ersetzt werden können?

Es handelte sich bei dieser Installation um eine, die ich in Plex anstieß, weil die sich dann so nett über das Hoster-Backend integrieren liess.
Dagegen spricht, dass ich die Site lokal via lampp auch mit diesen Einträgen an den Start bekomme.

• Diese Antwort wurde geändert vor 2 Jahren, 10 Monaten von hessi2.
• Diese Antwort wurde geändert vor 2 Jahren, 10 Monaten von hessi2.

Okay… also… das mit Wordfence KOMPLETT (auch in der DB!) weghauen hat DOCH was gebracht. Und zwar im Backend! Das hatte ich natürlich zuerst nicht ausprobiert.
Dort musste ich die Permalinks wieder abnicken, damit WP die htaccess neu schreibt.
Warum aber WF die Site nicht in der lokalen Installation blockierte… keine Ahnung. Ich werde nun aber zu einzelnen Plugins für 2FA und Login-Restictions greifen. Nase voll von Schlangenöl.

Jetzt noch Themes und Plugins wieder aktivieren, dann sollte alles wieder funzen.

• Diese Antwort wurde geändert vor 2 Jahren, 10 Monaten von hessi2.
• Diese Antwort wurde geändert vor 2 Jahren, 10 Monaten von hessi2.

@bego Mario Garde: Das ist gut. Habe lieber 1.000 Zeilen in der .hataccess, als irgendwelche Schlangenöl-Tools, die wieder DSGVO-Recherche generieren.

@pezi: Verstehe. Das tut mir leid. 😀
Ich muss immer noch von der letzten Migration von vier Seiten (2xWP, 2xJ!–>WP) einige meiner Beitragsbilder per Hand anpassen, weil die wüst durcheinander gewürfelt wurden und sinngemäß Artikel 123 das Beitragsbild von Artikel 642 hatte.

Solange das nicht gefixt ist, wollte ich den Umzug nicht automatisiert durchführen lassen. Nichtsdestotrotz bin ich ein Freund von verschiedenen Backups und hätte das auch noch zur Sicherheit angestoßen.

Wie gesagt: Der Umzug war eine Kurzschlussreaktion und die Domains waren schneller neu registriert, als ich ein Backup im Backend hätte durchführen können. Früher dauert das etwas länger als zwei Minuten. So hatte ich keinen Zugriff mehr auf das Backend der alten Installation.

Muss man nicht lesen, nur als Bericht aus der Realität mit Hostern:
Kurzschluss warum? Weil der Provider keinen Support außerhalb der Geschäftszeiten gibt (nur gegen heftige Aufpreise), Matomo irgendwie komplett Amok lief und die Datenbank mit vielen GBs an Daten flutete, so dass die Website drei Tage down war. Die haben wohl keine Überwachung von solchen heftigen Auslastungen auf dem Userspace.

Wohl aber bei der Auslastung des Webspaces. Dort hatte ich nur 20 GB. Mails sind da auch mit drin. Ich hatte ein Backup lokal und auf die Cloud angestoßen, und eingestellt, dass drei Backups bitte vorgehalten werden. Die Website ist Bilderlastig und hat so schon fast 7 GB belegt. 3×7 zzgl. Mails waren dann 23 GB. Das passierte nachts, ist klar. Kam auch ne Mail. So gegen 03:00 Uhr oder so. Montag Morgen war dann mein Account gesperrt. Website down, Mails down, kein Backendzugriff mehr auf einen Dateimanager, kein FTP-Zugriff mehr. Musste einen Call aufmachen und dann einige Stunden warten.

Ja, wäre deren Schuld gewesen, hätten sie wieder freigeschaltet.

Vor einigen Jahren hatte ich das so schon einmal erlebt und mir wurde gesagt, dass die dieses Fehlverhalten der Automatisierung beim Überschreiten der Grenzen sinnvoller konfiguriert hätten. Haben sie wohl nicht.

Beim neuen Hoster habe ich für die Hälfte des Geldes 150 GB Webspace, vier de-Domains mit drin und auch für mich sinnfreie 50 Datenbanken. Dazu halt fette Grenze für den Upload von SQL-Dumps & Co. Schon nice.

Wo Licht, da Schatten. Einiges gefiel mir im Kundenbereich des alten Hosters besser, aber das ist wohl Gewohnheit und dafür reißt der SSH-Zugriff und die Cron-Jobs echt vieles wieder raus.

Das nur als Erklärung dafür, warum ich nicht ein Backup mit deaktivierten Plugins erstellte. Obwohl das auch in dem Falle nichts geholfen hätte. „Sicherheits-Tools“ als immer vor einem Umzug komplatt deinstallieren! Nicht nur deaktivieren.

Interessanter sollten nur meine Erfahrungen sein, die ich bei der Migration von vier Websites auf eine gemacht habe. Vor allem die Comments in Joomla sind ein echt trauriges Kapitel. 😀

Mein Weg ist genau anders herum: Ich wollte nicht mehr vier separate Sites mit zwei versch. CMS verwalten müssen, auf denen auch noch unterschiedliche Erweiterungen liefen. Ich habe daher meine Site „containert“, was auch irgendwie bei Google geklappt hat, aber nicht ganz so, wie gedacht. Aber das ist egal. Ich mache die Site nicht für Reichweite. Ist nett, wenn es den Leuten hilft. Habe auch keine Ahnung, was so eine Site bringen „muss“. 😉

• Diese Antwort wurde geändert vor 2 Jahren, 10 Monaten von hessi2.