Seit heute Nacht habe ich etwas Probleme, Beiträge in den Blogs mit dem Windows Live Writer zu veröffentlichen. Ergänzung: Ich habe mal einige Nachträge verfasst, um auf Fragen der Leserschaft und einige Erkenntnisse einzugehen – zumal ich bei meinen Tests in diverse Folgefehler gelaufen bin und auch dort Lösungen gefunden habe. Aber das initiale Problem ist immer noch vorhanden.
Anzeige
Es kommt "Antwort auf die Methode metaWeblog.newPost ist ungültig". Der Beitrag erscheint zwar, aber die Veröffentlichung wird nicht sauber abgeschlossen. Da durch können Beiträge doppelt und mehrfach auftreten. Aktuell bin ich am forschen – könnte ein Speicherproblem sein. Daher gibt es ggf. auch kurze Zeiten, in denen die Blogs wegen Script-Fehlern nicht abrufbar sind. Mal schauen, wie ich da raus komme.
Nachträge zu diversen Kommentaren und zum Fortschritt – aktuell kommt es wohl knüppeldick.
Zuerst ein dickes Danke schön an die Leserschaft, die mit zahlreichen Tipps versucht, mich auf die richtige Spur zu bringen! Natürlich habe ich einiges an Artikeln gelesen.
Zeitweise ist der Blog nicht erreichbar
Ich teste momentan viel, lasse Datenbanken aufräumen etc. Daher kommt es immer wieder temporär vor, dass die Blogs nicht erreichbar sind (entweder Datenbankfehler oder der Aufruf reagiert gar nicht).
Anzeige
Die Seiten diverser Blogs werden nicht mehr gefunden
Gerade hatte ich in den Multisite-Blogs (englischer IT-Blog, Senioren, Japan etc.) den kuriosen Effekt, dass die Homepage zwar alle Artikel mit Überschrift und Anreißertext anzeigte. Klickte ich aber auf einen Link einer Überschrift, wurde mir auf der Folgeseite angezeigt, dass der Beitrag nicht gefunden wurde. Die URL zeigte einen korrekten Wert.
Da ich vorher ein Plugin gelöscht und entfernt sowie eine Optimierung der Datenbank für diese Blogs durchgeführt hatte, schwante mir böses. Das Leeren des verwendeten Caches half leider nicht.
Am Ende des Tages war die Lösung sehr einfach: Im Dashboard bin ich auf Einstellungen -> Permalinks und habe dort dann auf Einstellungen speichern geklickt. Das hat scheinbar gereicht, um einen fehlerhaften Eintrag in der Datenbank für den Blog zu korrigieren – die Artikel werden jedenfalls wieder angezeigt. Ist hier und hier auch erwähnt.
Seite mit guten Hinweisen
Es wurde nachfolgend auch erwähnt, ich habe natürlich als erstes, auf Grund der Fehlerbeschreibung, den Artikel Fehlermeldung: Invalid response document returned from XmlRpc server gelesen. Die Hinweise führten mich nicht sofort weiter – teilweise, weil ich mich selbst in die Falle geschubst habe und die Tests manchmal den Fehler zeigten, dann aber wieder durchliefen.
Ich hatte Plugins, die ich im Verdacht hatte, schon deaktiviert. Da ich aber den Blog hier, sowie eine Multisite-Installation für weitere Blogs habe, und die Deaktivierung macher Plugins zu Problemen führt, habe ich immer nur jeweils einen Blog mit deaktiviertem Plugin getestet.
Erst als ich das Plug-In WPS Hide Login, welches ich erst vor einer Woche installiert hatte (ein Plugin, welches Jahre störungsfrei lief, ist aus dem WP-Repository geflogen, weil es nicht mehr aktualisiert wurde) komplett in beiden Blogs deaktivierte, ergaben erste Tests, dass kein Fehler mehr auftrat.
Ich muss aber weiter testen – was schwierig ist. Der Hintergrund: Mein Provider überwacht die XML RPC-Schnittstelle. Poste ich binnen einer Minute mehrere Blog-Beiträge, wird dies als Brute-Force-Angriff gewertet und meine IP wird für einen Timeout gesperrt. Genau das ist mir gerade (23.6.) beim Testen wieder passiert. Danach schlug mein "Seiten werden nicht angezeigt Problem" in diverse Blogs zu. Ich muss also an vielen Fronten von Fehler zu Fehler hangeln.
Nachtrag: Das war es nicht – der Fehler ist schon wieder da.
Es gibt eine weitere Seite Windows Live Writer / WordPress – Invalid Server Response (XMLRPC) aus 2008 (und auch hier), die einen Eintrag in der .htaccess beschreiben, um die Prüfung auf dem Apache zu deaktivieren. Damit war mein Blog aber nicht mehr erreichbar – habe ich also verworfen.
Auf Anraten meines Providers habe ich im Frontend des WordPress-Hosting-Pakets auch den Speicher für PHP von 240 auf 480 MB hochgesetzt, hat aber nichts gebracht.
Windows Live Writer/Open Live Writer
Es kam der Hinweis, dass der Windows Live Writer (WLW) aus dem Support gefallen sei. Das ist mir bekannt, aber das Teil läuft astrein und ist das Beste seit Erfindung von "geschnitten Brot" zum Offline-Bloggen.
Beim Windows Live Writer gibt aber kleine Bugs, so existiert seit geraumer Zeit das im Artikel Live Writer – Blogdesign konnte nicht heruntergeladen werden beschriebene Problem – der dort genannte Fixer existiert aber nicht mehr. Kann ich mit leben.
Es gab den Hinweis auf den Open Live Writer (OLW) – war mir bekannt und das Tool ist hier auf meinem System sogar installiert. Ich bin der Leserschaft sehr dankbar, für solche Hinweise – auch wenn das bekannt ist. Oft liest man in Blogs, dass der OLW ein Ersatz für den WLW sei. Wird aber von Leuten behauptet, die nicht mit beiden Tools gearbeitet haben – denn andernfalls würden folgende Hinweise kommen.
Leider ist der OLW keine Alternative zum Windows Live Writer (WLW), weil:
– das ganze Projekt ist hoffnungvoll gestartet, it aber eine Weile schlicht tot (es findet seit Jahren keine Entwicklung mehr statt).
– Es wird die Rechtschreibprüfung von Windows 10 verwendet (nützt mir also aktuell nichts)
– es werten keine WLW-Plugins unterstützt (ich nutze zwei Stück, die mir das Bloggen erleichtern)
Im aktuellen Fall hilft es auch nicht, weil dort der gleiche Fehler auftrat.
Ich habe hier auch mal Blog-Desk installiert. Aber der Editor kann keine Designs laden (gibt einen Fehler), bietet keine Option für die Festlegung des Veröffentlichkeitsdatums (oder ich habe was übersehen) und ist auch sonst kein Ersatz für den WLW.
Alles in allem eine schwierige Kiste. Ich werde auch mal anhand der log-Dateien des WLW, die man gemäß dieser MS Answers-Angabe einsehen kann (danke an Thomas für den Hinweis), die Fehlerprotokolle analysieren – aktuell helfen die mir nicht weiter.
Anzeige
Mögliche Ursachen:
– Irgendein Wort/Link/o.ä. im Inhalt – https://core.trac.wordpress.org/ticket/9051
– PHP Warnung in der Antwort, siehe Open Live Writer log file – https://www.howtosolutions.net/2017/05/open-live-writer-connecting-wordpress-invalid-xml-rpc-server-response/
Könnte es an der spezifischen Länge des Textes liegen?
Das ausgerechnet das Wort " – from – " etwas auslösen soll, würde ja vorraussetzen, dass der Text durch irgendetwas interpretiert werden würde. Das wäre unschön.
Ich hatte vorhin eine Fehlermeldung, aber im Stress vergessen diese zu retten.
Die sah aus als sei der ganze Server down.
Hattest Du den neugestartet?
Ein Effekt wie mit "select – from" wie im o.g. trac Beispieltext ist möglicherweise ein SQL-Injection Fehlalarm irgendeines Schutzmechanismus des Servers. Mit der WordPress Plattform selbst hat das nichts zu tun, eine solche Validierung erfolgt darin nicht.
Klingt plausibel.
Hatte ich auch mal erleben dürfen.
Durfte in einem Fehlerbericht keine Zeichen wie $ ; etc verweden.
Irre.
heute vormittag bekam ich ein umrahmtes Kästchen mit "Keine Verbindung zur Datenbank" oder so ähnlich statt des Blogs mit den Artikeln, nach dem Mittag sahs wieder ok aus
Ja, der Server ächst, wenn ich die Datenbank reorganisieren lasse.
Windows Live Writer ist eine nicht mehr verfügbare Desktop-Blog-Publishing-Anwendung, die von Microsoft entwickelt und als Teil der Windows Live-App-Suite vertrieben wird. Die letzte Hauptversion von Windows Live Writer wurde 2012 veröffentlicht, und die Software wurde im Januar 2017 vollständig eingestellt. Quelle: Wikipedia
Und wie hilft dies jetzt weiter? Die Zusammenhänge sind mir da durchaus bekannt. Gibt schlicht aber nichts vernünftiges als Nachfolger. Ich muss schlicht herausfinden, was bei WordPress an der XML RPC-Schnittstelle klemmt. Aktuell lösche ich mal alte Blog-Beiträge die nicht mehr relevant sind – denn ich fürchte, mit über 20.000 Artikeln komme ich an einige Grenzen von WordPress und dessen Plugins (Export geht z.B. nicht mehr).
/blog/2022/06/22/trend-micro-beendet-support-fr-tm-wfbs-in-windows-7-server-2008-r2-zum-22-juni-2022/
Ist übrigens verschwunden/gelöscht
ja, habe ich gelöscht
Viel Erfolg!
+1
Woran lag es?
Ich weiß es noch nicht.
Hallo
wie sieht es mit der Alternative Open Live Writer aus.
Link zu der Seite https://openlivewriter.com/
Danke für den Hinweis. Der Open Live Writer (OLW) ist mir bekannt und hier auf meinem System sogar installiert. Leider ist der OLW keine Alternative zum Windows Live Writer (WLW), weil:
– das ganze Projekt nach kurzer Zeit tot war, und das Tool
– die Rechtschreibprüfung von Windows 10 verwendet
– keine Plugins unterstützt (ich nutze zwei Stück)
und weil dort der gleiche Fehler kommt. Ich muss in den sauren Apfel beißen und testen, bis ich hoffentlich die Ursache gefunden habe. Oder ich muss schauen, ob ich eine Online-Lösung für WordPress gefunden habe, die mir beim Bloggen den Komfort bietet, den der WLW an Bord hat.
Das ist auch bekannt?
https://itler.net/fehlermeldung-invalid-response-document-returned-from-xmlrpc-server/
"Ursache: Der Blog kann die Anfrage nicht vollständig verarbeiten, da sich das System am Limit befindet. Dies kann durch große Beiträge (z.B. Beiträge mit großen Bildern) der Fall sein, oder jedoch auch, wenn PlugIns nicht sauber arbeiten, oder schon zu viel Speicher in Anspruch nehmen. Letzterer Punkt ist einer der häufigsten Ursachen."
…
"Sollte dies noch nichts gebracht haben und der Fehler weiterhin auftauchen, kann die Variable memory_limit in der php.ini auf dem Server vergrößert werden. "
HTH
Hinweis dazu: Wenn man einfach in php.ini das memory_limit o.ä. erhöht, heisst das noch lange nicht, dass auf dem Server auch wirklich entspr. mehr Arbeitsspeicher zur Verfügung steht, selbst wenn phpinfo() oder WordPress das dann anzeigen sollten. Änderungen bei PHP memory_limit und auch bei z.B. WP_MEMORY_LIMIT sollten nur im direkten Kontakt mit dem Hoster vorgenommen werden. Sonst verschlimmbessert sich die Situation ggf. sogar, weil WordPress damit davon ausgeht, mehr Speicher zu haben als es gibt und es kommt noch öfters zu Meldungen im Browser oder Server Error Log wie "Fatal error: Allowed memory size of x bytes exhausted (tried to allocate x bytes…)". Die Angabe bei "tried to" lässt übrigens oft auf die tatsächlich verfügbare maximale Obergrenze schliessen.
Kleine Korrektur zum letzten Satz, gemeint ist natürlich: "Die Angabe bei "x bytes exhausted"…
Ich kenne diesen Beitrag – danke für den Link. Ich hoffe, den Fehler gefunden zu haben – vor gut einer Woche musste ich ein Plugin wechseln, weil das wegen fehlender Updates aus dem WordPress Repository rausgeflogen ist. Habe dann WP Hide Login als Ersatz-Platzebo verwendet.
Deaktivieren in einem Blog hat nicht geholfen. Habe es im Single-Side-Blog hier und im Multisite-Blog (englischer IT-Blog etc.) komplett gelöscht. Mein erster Test hat keine Fehler gebracht.
Allerdings leide ich noch unter einem Pferdefuß: Wenn ich zu schnell über XML RPC veröffentliche, meint mein Provider einen BruteForce-Angriff zu erkennen und sperrt den Zugriff für einige Zeit – gerade vor einer Stunde ich diese Falle gerauscht und dachte schon, den Blog durch Deinstallation des Plugin und einen Sicherheitsscan geschlachtet zu haben. An dieser Stelle kann ich leider nichts drehen – da winkt der Provider ab.
Zum nachfolgenden Hinweis von Anonymous: Hatte ich als Erstes schon auf Veranlassung meines Providers im Frontend meines Web-Hosting-Pakets gemacht. Hat aber gar nichts gebracht.
Es heißt für mich nun testen, testen, und nochmals testen. Gestern hatte ich die Situation, dass es kurzzeitig mit den Veröffentlichungen klappte und dann war der Fehler plötzlich wieder da. Daher bin ich auch noch nicht sicher, ob ich den Problembär wirklich gefangen habe.
Danke an Alle, die versuchen, mit Tipps zu helfen.
Im WordPress-Forum fragen?
Für interessierte Mitleser und WordPress Hobbyforscher hier ein kleiner Vergleich:
WordPress deutsch, frische Installation, PHP 7.4
Aktive Plugins: UsageDD, WP Downgrade
Aktives Theme: Twenty Twenty 2.0
Speicherverbrauch bei Aufruf der Admin Dashboard Startseite lt. UsageDD:
6.0.0 – 9.45 MB
5.9.3 – 9.05 MB
5.8.4 – 8.60 MB
5.7.6 – 8.04 MB
5.6.8 – 7.94 MB
5.5.9 – 7.87 MB
5.4.10 – 7.36 MB
5.3.12 – 7.28 MB
5.2.15 – 7.22 MB
5.1.13 – 6.94 MB
5.0.16 – 6.89 MB
4.9.20 – 6.67 MB
Durch das stetige Hinzufügen von Funktionalitäten für das Gutenberg Projekt ab WordPress 5.0 nimmt der Speicherverbrauch einfach für das Laden der Admin Dashboard Startseite also über die Versionen merklich zu.
Der Speicherhunger dürfte sich dann entspr. auch anderweitig jeweils stärker auswirken, je mehr Plugins und Daten vorhanden sind bzw. je mehr Filter und Hooks usw. für Gutenberg usw. durchlaufen werden.
Inwieweit der Vergleich im aktuellen Fall hier im Blog hilfreich ist, ist schwer zu sagen.
Man kann daran aber sehr gut ablesen, dass über die Zeit und Versionen hinweg eine Installation, die sich speicherbedarfsmässig immer schon unbemerkt knapp am Limit bewegt hat, alleine bei einem WordPress Update ohne sonstige Einflüsse einfach mal "umkippen" kann.
Viel Erfolg allen WordPress Bastlern, spannende Zeiten im Gutenberg Land…