Support » Allgemeine Fragen » EDITOR Kommunikation mit der Website, um auf fatale Fehler zu prüfen…

  • Gelöst Peter der Makler aus Freiburg

    (@immobilienmakler79100)


    Hilfe!

    Ich bin langsam schon am Verzweifeln. Ich habe meine Webseite von Webhosting auf einen virtuellen Server umgezogen. Alles hat soweit geklappt. DB, wp-config, php.ini, .htaccess wurden ohne große Änderungen übernommen. Die Domain bliebt gleich, die Pfade auch, der DB-Name, der DB-User ebenfalls. Es funktioniert eigentlich auch alles – ausser das folgende Problem:

    Der Theme-Editor für mein selbst erstelltes Theme funktioniert nicht mehr. Ich bekomme immer die Meldung:

    Kommunikation mit der Website, um auf fatale Fehler zu prüfen, nicht möglich, daher wurde die PHP-Änderung rückgängig gemacht. Du wirst deine veränderte PHP-Datei mit anderen Mitteln hochladen müssen, wie per SFTP.

    Die gleiche Meldung bekomme ich, wenn ich ein selbst erstelltes Plugin editieren möchte.

    Da ich auf die mobile Möglichkeit, Kleinigkeiten am Theme zu ändern, angewiesen bin, ist SFTP absolut keine Alternative für mich. Ich habe das komplette Theme bisher komplett im Editor entwickelt ohne bisher dabei Probleme gehabt zu haben.

    Ich habe praktisch alles, was in diversen Foren dazu zu finden ist, ausprobiert. Alle Plugins deaktiviert, ich habe auch ein curl 60-Fehler bei der Gelegenheit behoben, der bei der Website-Health angezeigt wurde. Hat aber nichts geholfen.

    Ich habe verschiedene php-Versionen ausprobiert, verschiedene apache-Konfigurationen. Die Dateirechte auch überprüft.

    Jetzt stehe ich an dem Punkt, dass ich diese Funktion von WordPress hart deaktivieren möchte. Auf eine Weise, dass bei einem Update diese Funktion deaktiviert bleibt.

    Wie bitte kann ich dieses „Feature“ komplett ausschalten?

    Über eine Hilfe wäre ich wirklich richtig intensiv dankbar. Bitte gern etwas mehr als nur ein paar Stichworte. Ich bin kein Linux-Profi sondern nur ein mittel-intelligenter Bastler.

    Vielen Dank.

    Die Seite, für die ich Hilfe brauche: [Anmelden, um den Link zu sehen]

Ansicht von 7 Antworten - 1 bis 7 (von insgesamt 7)
  • Ich sehe keine Möglichkeit, die Prüfung mit einem Hook zu umgehen.

    Workaround: Plugin WP File Manager

    Könnte es nicht irgendwie in den nächsten Versionen einen „Schalter“ dafür geben? Ich meine ich bin ja nicht der Einzigste mit dem Problem.

    Ich probier jetzt mal „Theme Edit“ aus, was offenbar kein Schreibproblem hat.

    Ich meine ich bin ja nicht der Einzigste mit dem Problem.

    Das ist wohl eher eine Frage der Sichtweise.

    Vor dieser Umstellung hat es immer wieder Fälle gegeben, in denen sich AnwenderInnen (auch mit zunächst valide aussehendem Code, z.B. durch Aufruf einer nicht vorhandenen Funktion) aus ihrer WordPress-Installation ausgesperrt haben.
    Da „Cowboy-Coding“ (also direkte, ungeprüfte Änderungen in einer produktiven Umgebung) als wenig professionell gesehen werden, kam auch der Gedanke auf, den Editor komplett abzuschalten (was viele Entwickler durch eine Konstante in der wp-config.php umsetzen, um sich vor Anrufern technisch unbedarfter Anwender zu schützen).
    Statt dessen wurde ein Weg gewählt, bei dem fehlerhafte Code-Änderungen rückgängig gemacht werden können, was allerdings eine bestimmte Funktionalität des Servers voraussetzt. Und genau um die geht es hier: Nicht WordPress ist defekt, sonder in deiner Serverkonfiguration oder dem Zusammenspiel der Plugins ist irgendwas so, dass die Umkehr fataler Code-Änderungen verhindert. Resultat: dann lieber kein Editor, kein Cowboy-Coding, kein Nutzer der sich aussperrt und anschließend bitter darüber beschwert, wie die WordPress-Community einer breiten Masse so ein gefährliches Tool an die Hand geben kann.

    Den Wunsch, dieses „Problem“ zu beseitigen, kann ich zwar verstehen, halte ihn aber für den verkehrten Weg. Besser wäre es, alle Voraussetzungen zu schaffen, damit der Code-Editor funktioniert. Health-Check-Plugin installieren, Fehlermeldungen abarbeiten, im Problembehandlungsmodus mit einem Standard-Theme und ohne aktivierte Plugins testen, dabei vor allem auf die Deaktivierung von Fastest Cache (auch in der wp-config.php, Konstante WP_DEBUG) achten, Transients löschen …

    Den „Schalter“ (oder eine Konstante für die wp-config.php) wird es aus den genannten Gründen wohl nicht geben, wobei das hier im Support auch niemand zu verantworten hat. Vielleicht magst du ja mal ein Bug-Ticket schreiben?

    Danke für Deine ausführlichen Erklärungen der „Sichtweise“.

    Selbst wenn man sich aussperren sollte, was ich mit einem Security-Plugin auch schon mal gemacht habe, kann man ja noch immer sich mit sftp einloggen und die betroffene Datei wieder aus einem Backup herstellen oder ein anderes Theme unterschieben und in der DB dieses einstellen.

    So groß finde ich eigentlich den Unterschied nicht. Nur dass man auf der einen Seite „nur im Notfall“ sftp bemühen muss und auf der anderen Seite „jedesmal“ darauf zurückgreifen muss.

    Wer keine Backups macht, wird sowohl links wie rechts Probleme haben. Wer Backups macht, dem ist es auch egal, ob er daheim oder im live-System einen Tippfehler gemacht hat.

    Ich erkenne jetzt aber wenigstens die Bemühungen an, die dahinter standen. Das ist wohl schon ein Schritt in die richtige Richtung. Und ich stimme Dir zu, ich würde lieber den Fehler finden, als was anderes machen.

    Ich hab heute den ganzen Tag danach gesucht. Bin verschiedenen Ansätzen nachgegangen. Ich vermutete erst versteckte Zertifikatsfehler, nachdem mir die Server Health einen Fehler im loopback angezeigt hat – den curl 60 halt… Habe da lange recherchiert und am Ende bei der php.ini einen manuellen Pfad auf ein Zwischenzertifikat gelegt. Hat funktioniert, der Fehler in der Serverhealth ist damit verschwunden.

    Aber das Editorproblem ist geblieben. Das Theme habe ich selber geschrieben und ich habe da nichts drinnen, was irgendwie ungewöhnlich wäre. Bei den Plugins hab ich alle durchprobiert. Hatte sich ja auch nichts geändert im Vergleich zu vor dem Umzug.

    Weiterhin denke ich, dass es irgendwie mit dem Server zu tun haben müsste und nicht direkt mit wp. Aber ich kann mir außer dem Zertifikat jetzt nichts mehr vorstellen.

    Ich habe jetzt das Plugin Theme Edit getestet. Damit geht es nun ohne alle Probleme.

    Das ist zwar keine Lösung, aber ich komme damit wenigstens klar. Falls wer noch eine Idee hat, wo ich nachsehen kann, um die tatsächliche Ursache zu finden, probiere ich es gern aus und berichte wieder.

    Vielen Dank

    Peter Eppich

    Selbst wenn man sich aussperren sollte, … kann man ja noch immer sich mit sftp einloggen …

    Mit dieser Aufgabe sehen sich aber viele AnwenderInnen bereits überfordert, landen dann hier im Supportforum und schreiben dass sie „völlig verzweifelt“ sind, weil ihre Website im Front- wie Backend nur noch leere Seiten ausgibt.

    Außerdem ist das wie gesagt Cowboy-Coding.

    😉

    Ein Hoch auf alle Cowboys, die es sich nicht nehmen lassen wollen, solche zu sein…

    Aber danke für die Geduld. Ich hab jetzt bei der Migration noch was anderes festgestellt. Esoterisch irgendwie.

    Mein php-Session-Cookie ist pfutsch. Ich wollte es irgendwie schon immer loswerden, weil ich es nicht brauche und ohne cookie-Banner auskommen wollte. Und
    jetzt ist es gar nicht mehr da.

    Umzug hat sich also dennoch mehrfach gelohnt. Also nicht nur ein First Byte von unter 100ms trotz https.

    Machen wir also einen Haken dran, alles gut. Das Plugin Theme-Edit hat als Lösung geholfen, die Ursache bleibt leider vorerst ungeklärt.

    Schau doch mal, ob sich was ändert, wenn du mit dem Plugin Transients Manager die Transients (vereinfacht gesagt: WordPress-interne Cache-Dateien) löschst.

Ansicht von 7 Antworten - 1 bis 7 (von insgesamt 7)