Verbindung verloren. Speichern wurde bis zum wiederverbinden deaktiviert.

Diese Fehlermeldung kommt in genau dem Wortlaut definitiv nicht von WordPress selbst. Entweder wird sie durch ein Plugin oder Theme generiert (dann man alle Plugins und Custom Themes deaktivieren) oder durch den Hoster ausgelöst (dann den Hoster kontaktieren)

Das Plugin "Revision Control 2.3" verursacht den selben Fehler bei Wordpress 3.6.1. Hat lange gedauert diesen Fehler zu finden, aber ich wurde fündig.

VG

Charly

Zitat von schaffner

Das Plugin "Revision Control 2.3" verursacht den selben Fehler bei Wordpress 3.6.1. Hat lange gedauert diesen Fehler zu finden, aber ich wurde fündig.

Wenn es denn ein Fehler ist. Habe jetzt nicht gelesen, was genau dieses Plugin macht, würde es aber allgemein für eine gute Idee halten, wenn eine Zwischenspeicherung per DOM Storage auf dem Computer erfolgt, statt laufen eine Verbindung zum Server aufzubauen und die Datenbank mit Revisionen vollzumüllen.

Ich habe das gleiche Problem, nutze aber keins der genannten Plugins:

Allerdings meldet mir Firefox unter Mac an mehreren Rechnern auch das hier:

Unter Windows konnte ich das Phänomen komischerweise nicht nachvollziehen.

Also auch lokale Ursache denkbar oder nur Zufall?

Welche Gründe könnte es für so ein Verhalten noch geben? Kann es auch sein, das die Internetverbindung gerade zu langsam oder unterbrochen ist oder der Webserver überfordert ist? Ich kann mir darauf irgendwie keinen Reim machen...

In wp-content/languages/admin-de_DE.po in WP 3.7.1:

#: wp-admin/edit-form-advanced.php:375
msgid "<strong>Connection lost.</strong> Saving has been disabled until you’re reconnected."
msgstr "<strong>Verbindung wurde unterbrochen.</strong> Speichern wurde deaktiviert, bis die Verbindung wieder hergestellt ist."

Die Ausgabe ist in der wp-admin/edit-form-advanced.php Zeile 375 zu finden, verstehe aber gerade den Zusammenhang nicht, wann dieser Spruch ausgegeben wird.

In anderen Versionen soll es wohl diesen Eintrag geben, habe den bei mir nicht gefunden, nur im Web:

#: wp-admin/edit-form-advanced.php:327
msgid "<strong>Connection lost.</strong> Saving has been disabled until you’re reconnected."
msgstr "<strong>Verbindung verloren.</strong> Speichern wurde bis zum wiederverbinden deaktiviert."

Wenn Du jetzt nach der englischen Mitteilung suchst, sollten sich mehr Hinweise finden lassen.

Moin.
Zwei Monate nach dem Neuaufsetzten von wp habe auch ich dieses Problem. Immer dann, wenn ich einen neuen Beitrag verfasse. Aber nicht immer. Mal passsiert es während des Schreibens, mal bei Aussuchen des Beitragsbildes, mal beim Abspeichern, mal beim Aufrufen des fertigen Artikels. Mal ist es schnell vorbei, mal ist minutenlang die komplette Seite blockiert.

Eines der obigen plugins verwende ich nicht, meine DSL-Leitung ist in Ordnung.

wp 3.7.1 - php 5.4.21

P.S:
Aus meiner admin-de_DE.po, beide Meldungen tauchen IMMER zusammen auf:

#: wp-admin/edit-form-advanced.php:375
msgid "<strong>Connection lost.</strong> Saving has been disabled until you’re reconnected."
msgstr "<strong>Verbindung wurde unterbrochen.</strong> Speichern wurde deaktiviert, bis die Verbindung wieder hergestellt ist."

#: wp-admin/edit-form-advanced.php:376
msgid "We’re backing up this post in your browser, just in case."
msgstr "Wir sichern diesen Beitrag in deinem Browser, nur für den Fall."

Na ja, die gehören halt zusammen. Was ich nicht so richtig verstehe, ein vorausgehendes if-Statement wird mit endif beendet und es folgt keine Fallunterscheidung, wann der Spruch eingeblendet wird oder halt nicht eingeblendet wird.

wp-admin/edit-form-advanced.php:

<?php endif; ?>
<div id="lost-connection-notice" class="error hidden">
    <p><span class="spinner"></span> <?php _e( '<strong>Connection lost.</strong> Saving has been disabled until you’re reconnected.' ); ?>
    <span class="hide-if-no-sessionstorage"><?php _e( 'We’re backing up this post in your browser, just in case.' ); ?></span>
    </p>
</div>

Doch wenn ich dann nach "hide-if-no-sessionstorage" suche, wird es ein wenig klarer, denn "hide-if-no-sessionstorage" scheint sich auf die wp-includes/js/autosave.js zu beziehen:

wp-includes/js/autosave.js:

// When connection is lost, keep user from submitting changes.
    $(document).on('heartbeat-connection-lost.autosave', function( e, error, status ) {
        if ( 'timeout' === error || 503 == status ) {
            var notice = $('#lost-connection-notice');
            if ( ! wp.autosave.local.hasStorage ) {
                notice.find('.hide-if-no-sessionstorage').hide();
            }

Und somit wenn Timeout oder 503 Statuscode, wie es aussieht, womit ja wohl einiges gesagt ist.

Moin.

Sorry, aber mir sagt das für die praktische Arbeit gar nichts. WARUM reisst die Verbindung ab? Sie reisst jetzt sogar ab, wenn ich einen bestehenden Artikel überarbeite und neu speichere. Minutenlang ist dann nicht nur die Seite blockiert, sondern der ganze Server.
Ich habe:
- verschiedene themes ausprobiert
- Revisionen abgeschaltet / alte Revisionen gelöscht
- immer mal wieder ein plugin abgeschaltet.

Es nervt total, so kann man nicht vernünftig arbeiten. Lange schaue ich mir das nicht mehr mit an, dann trete ich wp in die Tonne.

Zitat von ostufer

Minutenlang ist dann nicht nur die Seite blockiert, sondern der ganze Server.

Das ist nun einmal bei einem 503er so. Die Frage die sich da stellt, kommt es zu diesen Serverausfällen auch wenn Du keine Seite bearbeitest und bemerkst Du nur, dass der Server des Öfteren nicht erreichbar ist, weil diese Meldung erscheint und bekommst es ansonsten nicht mit? Oder hängt diese Nichterreichbarkeit irgendwie mit der Bearbeitung zusammen?

Ich kann alles andere machen, Bilder hochladen, Menues und widgets bearbeiten, installieren ... es passiert nichts. Das passiert/e bisher nur bei einem neuen Beitrag. Und vor ein paar Tagen das erste Mal bei einem bereits bestehenden Beitrag (den ich allerdings vor dem neuen Speichern mit einem anderen Editor bearbeitet hatte).

So wie es aussieht, ist immer mal wieder ein anderes plugin schuld an dem Dilemma. autosave hochzusetzen habe ich auch schon probiert. Kein Erfolg.

http://wordpress.org/support/topic/…til-reconnected

http://dailypostal.com/2013/08/08/con…r-just-in-case/

Ich finde die Meldung reichlich unglücklich gewählt und die Übersetzung noch mehr irreführend als hinweisend. Für mich sieht es eher danach aus, falls der Server kurzeitig nicht erreichbar ist, werden die Änderungen in Session-Storage gespeichert.

Und genau dafür wurde Session-Storage eingeführt und ist Session-Storage gedacht, damit ein Browser nicht mehr wegen jeder kleinen Änderung einen Request an den Server senden muss. Somit kannst Du Bilder hochladen oder Menüs bearbeiten, doch wenn Du Texte bearbeiten möchtest, so genügt es die Änderungen vorübergehend lokal zu speichern, bis Du nach der Bearbeitung das Dokument endgültig speichern möchtest.

Weiß ich nun nicht, was da alles hineinspielt, doch im Dashboard brauchten keine Plugins mitlaufen, die nicht für den Admin-Bereich gedacht sind.

Weiß auch nicht, warum nur einige wenige diese Meldung erhalten und viele andere nicht.

Plugins und Themes sind natürlich immer eine der ersten Fehlerquellen die man prüfen sollte. Das ist schon klar. Was mich jedoch irritiert ist, das sich da bei meiner Wordpress-Installation schon seit geraumer Zeit gar nichts geändert hat. Das Problem war einfach plötzlich da.

In einem Beitrag wurde die Möglichkeit erwähnt, dass ein zu langsamer Webserver oder einer der nicht mit sovielen Requests umgehen kann, denkbare Ursache sein könnte. Da wäre meine Frage wo setze ich da am besten an bzw. was soll ich da meinen Hostmaster fragen?

Äußerst skurril finde ich auch die Tatsache das ich das Problem trotz mehrfacher Versuche an meinem Rechner nicht nachvollziehen kann... :confused: Ich jedoch immer wieder Screenshots von Autoren erhalte, die dieses Problem mit Posts bzw. Custom Post Types haben. In diesem Zusammenhang hatte ich ja oben den Screenshot aus dem Firefox gepostet: Bei diesen Autoren meldet Firefox zuweilen auch, das er zu langsam sei. Liegt es an meiner besseren PC-Ausstattung oder ist diese Meldung für Admins generell nicht sichtbar?

Desweiteren frage ich, wenn, wie ein User schreibt, diese Meldung keine Auswirkung hat auf geänderten Content, kann man das dann getrost ignorieren?

Nun gut, ich kenne mich nicht wirklich mit Protokollen oder so aus. Doch so wie ich das bisher verstanden habe, was jedoch nicht ganz richtig zu sein braucht:

Nur mal angenommen, ich würde jetzt im Firefox das Add-on "Live HTTP headers" mitlaufen lassen und diese Seite vom Forum neu laden. Dann würde mein Browser zuerst eine neue Anfrage an den Server von forum.wpde.org senden und dem Server mitteilen, dass der Browser die Verbindung zum Server nicht hinter jedem einzelnen Request beendet, sondern erst wenn alle im Quelltext referenzierten Quellen, wie Grafiken, CSS- und JavaScript-Dateien geladen wurden. Dieses Aufrechterhalten einer Verbindung bis alle referenzierten Grafiken geladen wurden, wird wohl mit keep-alive bezeichnet.

Zitat

Host: forum.wpde.org
...
Connection: keep-alive

Der Server teilt nun dem Browser mit, Ok, bin einverstanden, aber nur für die ersten 100 Anfragen, dann kappe ich die Verbindung wieder. Sollte eine Pause von mehr als 1 Sekunde zwischen zwei Anfragen entstehen, kappe ich die Verbindung ebenfalls.

Zitat

HTTP/1.1 200 OK
...
Keep-Alive: timeout=1, max=100

Und ich habe hier zumindest schon Startseiten gesehen, die 120 oder mehr Anfragen sendeten. Wie es im Dashboard bei denen aussieht, weiß ich nicht. Wobei bei den Startseiten die Anzahl der Abfragen verteilt wurden und nicht alle 120 Anfragen nur an einem Server gesendet wurden.
Und ob es nun wirklich damit zusammen hängt oder noch an anderen Dingen liegt, weiß ich auch nicht. Es gibt ja noch andere Möglichenkeiten für Timeouts, die mit anderen Dingen zusammenhängen. Somit ist da viel Spekulation bei, um es genauer sagen zu können, müsste man da noch tiefer einsteigen.

Wenn ich bei mir Firebug mitzählen lasse, so komme ich nur auf 6 bis 12 Anfragen beim Aktualisieren eines Beitrags. Somit könnte es daran eigentlich nicht liegen, es sei denn, da spielt noch etwas anderes hinein. Darunter sind ja auch Ajax-Request und was sich da dann wieder serverseitig abspielt, ist eine andere Frage.

Zitat von Melewo

, doch wenn Du Texte bearbeiten möchtest, so genügt es die Änderungen vorübergehend lokal zu speichern, bis Du nach der Bearbeitung das Dokument endgültig speichern möchtest.

Genau das tue ich. Ich bereite meine Texte in notepad++ im Quellcode vor und kopiere sie dann nach wp. Aber manchmal reisst die Verbindung auch dann ab, wenn ich noch das Beitragsbild einfügen möchte. Machmal reisst die Verbindung erst ab, wenn ich auf "Beitrag ansehen" klicke. Alles nicht nachzuvollziehen.

Bei mir kam es irgendwie auch aus "heiterem Himmel". Ich bin jetzt dabei, alle in dieser Zeit hinzugefügten plugs nicht nur zu deaktivieren, sondern komplett zu löschen. Und danach nochmal die db von Hand zu säubern.

Mein Server arbeitet bei meinen anderen Seiten sehr schnell und ist auf dem aktuellen Stand der Technik. Und auf meine IBM-Rechner lass ich nichts kommen :)

Also wenn ich mit HTTP Live Headers prüfe, komme ich auf 11 Anfragen und bei besagtem Wert steht:

Zitat

Keep-Alive: timeout=15, max=100

Firebug zeigt mir im Backend nach Aktualisieren in einem Post insgesamt 25 Anfragen und etwa alle 2 Sekunden wird die admin-ajax.php geladen. HTTP Live Headers zeigt mir auch hier wieder diesselben Keep-Alive-Werte. Manchmal steht bei "max" auch 99, 98, 97 oder 96.

Was nun serverseitig abläuft wissen wir in der Tat nicht.

Um an den Hostmaster heranzutreten, bräuchte ich allerdings schon einen besseren Anhaltspunkt als einen Screenshot aus dem Wordpress Backend.:?

Da wird so langsam der Hund in der Pfanne verrückt.

Neuen Artikel eingekippt: Alles gut.
Minuten später einen neuen Artikel etwa gleicher Länge eingekippt: Bruchlandung.
Eine Stunde später noch ein neuer Artikel: Wieder Bruchlandung.

Irgendwas werden sich die wp-Schrauber bei der Einführung der Meldung doch gedacht haben. Ob sich das rausfinden liesse?