Hallo Eric.
Mit der 3er Version habe ich es noch nicht probiert, da mit dieses Update gar nicht angezeigt wird. Gehe ich recht in der Annahme, dass es WordPress mindestens ab Version 5 voraussetzt?
Wenn ja, dann bin ich jetzt in einer ganz blöden Situation denn meine Seite läuft noch unter 4.9.15 und ein Update wollte ich zwingend vermeiden um mir damit nicht meine Seite zu zerschießen.
Bzw wollte ich zur Sicherheit vor dem Update halt ein Backup machen um im Fall der Fälle meine Daten noch zu haben.
Genau diese Beschäftigung wollte ich mir eigentlich ersparen aber vielleicht komme ich doch nicht drumherum.
Mal sehen, was Eric jetzt noch zur Problematik sagt.
Nimm dir https://wordpress.org/plugins/duplicator/ und installiere damit irgendwo eine Kopie deines WordPress. Gerne auch lokal bei dir auf dem Computer. Dann kannst du in der Kopie gefahrlos WordPress und Publisher aktualisieren und sogar den Export von dort gefahrlos ausführen.
2 „Gefällt mir“
Danke, das probier ich gleich mal aus.
Auch wenn schon einige Zeit ins Land gegangen ist, ich hatte bisher leider keinen Erfolg.
Der Duplicator funktioniert nicht, da scheinbar der Verbindungsaufbau zum Server immer wieder zusammenbricht. Es wäre ja aber eh nur ein Behelf gewesen.
Mittlerweile ist ne neuer PHP Version auf dem Server drauf, sodass ich den Publisher in der Version 3.4.1 verwenden kann.
Bekannte Problematik bleibt aber. Beim Einspielen der Daten kommt folgende Fehlermeldung:
Ein Fehler vom Typ E_ERROR wurde in der Zeile 21 der Datei /hp/cu/ab/nf/www/podential/wp-content/plugins/podlove-podcasting-plugin-for-wordpress/lib/modules/import_export/import/podcast_import_job_trait.php verursacht. Fehlermeldung: Uncaught Error: Call to a member function registerXPathNamespace() on boolean in /hp/cu/ab/nf/www/podential/wp-content/plugins/podlove-podcasting-plugin-for-wordpress/lib/modules/import_export/import/podcast_import_job_trait.php:21
Stack trace:
#0 /hp/cu/ab/nf/www/podential/wp-content/plugins/podlove-podcasting-plugin-for-wordpress/lib/modules/import_export/import/podcast_import_episodes_job.php(16): Podlove\Modules\ImportExport\Import\PodcastImportEpisodesJob->setupXml()
#1 /hp/cu/ab/nf/www/podential/wp-content/plugins/podlove-podcasting-plugin-for-wordpress/lib/jobs/job_trait.php(20): Podlove\Modules\ImportExport\Import\PodcastImportEpisodesJob->setup()
#2 /hp/cu/ab/nf/www/podential/wp-content/plugins/podlove-podcasting-plugin-for-wordpress/lib/jobs/cron_job_runner.php(63): Podlove\Modules\ImportExport\Import\PodcastImportEpisodesJob->__construct(Array)
#3 /hp/cu/ab/nf/www/podential/wp-content/plugins/podlove-podcasting-plugin-for-wordpress/lib/modules/import_export/import/podcast_importer.php(83): Podlove\
Wie @ericteubert vorgeschlagen hatte die Daten vorab zu entpacken, habe ich es auch versucht. Auch hier wieder gleiche Problematik: Das Archiv lässt sich gar nicht öffnen.
Moin zusammen,
ich kann gerade nicht recht glauben, dass in den letzten Jahren offenbar niemand drüber gestolpert ist, ein Podcast von Podlove in ein anderes Wordpress umzuziehen. Aber ich renne gerade drei Jahre später wieder in den gleichen Bug 
Podcast Episoden Export – Das .gz kann nicht importiert werden, die darin enthaltene XML ebenfalls nicht, die sieht so aus:
Tracking Export lässt sich das .gz nicht mal auspacken.
Oder gibt es irgendwo ein funktionierendes howto/ workaround / … ?
Ich denk mal schon, dass da viele drüber gestolpert sind aber es scheint nun mal keine Lösung da zu sein.
Letztendlich habe ich es auch aufgegeben und alles manuell gemacht.
Ich hatte es auch Manuel gemacht ,… War nicht lustig, aber machbar.
hmmm… danke für die Rückmeldungen. Dann ist es zumindest geteiltes Leid 
1 „Gefällt mir“
Hast Du schon eine Idee, wie Du den Umzug ansonsten machen willst?
Moin, ich habe mir das gestern abend mal genauer angesehen und einen Workaround zusammengebaut. Bin gerade beim Import. Scheint mit einigen minimalen Änderungen am Code des Plugins zu klappen. Das ist kein Fix, nur ein Workaround. Ich verhindere einfach nur, das überhaupt irgendwas komprimiert wird. Ich schreibe das gerade zusammen, damit die Nachwelt auch was davon hat.
Man soll ja ein neues Blog immer gleich mit einem kleinen Rant beginnen
Für mich hat dieser Workaround auf den ersten Blick funktioniert. Ich fürchte bei größeren Podcasts könnten unkomprimierte Ex- und Imports aber wegen der Dateigrößen zu Problemen führen.
1 „Gefällt mir“
Wenn ich jetzt noch ein bissel mehr Ahnung von der Materie hätte, würde ich das auch in die Reihe bekommen. 
Konntest Du denn ansatzweise die Programmierung im Original nachvollziehen? Irgendwie scheint es mir ja so, als ob das noch nich so funktioniert hat, wie es funktionieren sollte oder lag das in unseren Fällen lediglich daran, dass sich mit der Zeit eine gewisse Menga an Daten angesammelt hat, die das Plugin dann nicht mehr verarbeiten konnte?
BTW
Es wäre auch echt super, wenn @ericteubert hier mal kurz etwas dazu sagen und aus der gewonnenen Erfahrung das Plugin anpassen könnte.
Ich glaube mein Problem war hier immer, dass es bei meinen Tests funktioniert hat.
Ich habe den Blogpost gelesen und vermute hier als Ursache die zwei Leerzeilen, die da noch hin gehören. Die könnten auch dafür sorgen, dass das gzipping nur Datensalat erzeugt. Da die Ursache zu finden ist kein Spaß: kann am Publisher liegen, aber auch an jedem anderen Plugin oder Theme.
Man könnte mal ansetzen zu schauen, ob es mittlerweile verlässlichere Methoden gibt komprimierte Downloads zu erzeugen.
Optional gzip im Im und Export zu deaktivieren geht natürlich auch, führt aber je nach Podcast Größe schnell zu anderen Problemen (Upload Limits, Timeouts, …)
Perspektivisch könnte man auch erwägen das auf die API umzubauen, die in der beta schon ziemlich vollumfänglich ist. Dann könnte sich die neue Installation die Daten direkt aus der Alten rausziehen, ohne Umweg von Exportdateien.
Danke auf jeden Fall für das Teilen von Erkenntnissen 
2 „Gefällt mir“
Ich denke nicht, dass der Bug an der Menge der Daten hängt. Out of the box hatte es ja bei mir auch nicht geklappt. – Ich bin da auch noch etwas dran. Leider auch, weil die erzeugten Urls in der neuen Instanz doch nicht überall passen. Da werden Pfade für eine Single Site installation angelegt, und die passen nicht zur Multisite hier, aber das ist ja auch ein bisschen ein Spezialfall.
@ericteubert Als ich die beiden Leerzeilen gesehen hatte, dachte ich auch kurz darüber nach, ob alles damit seinen Anfang genommen hatte und der Stream beim Wegschreiben dadurch hinüber war.
Der API Ansatz wäre sicher eine schöne Idee für einen Umzug in eine neue Domain. Wer aber mit neuem Wordpress in einem neuen Webspace unter gleicher Domain weitermachen will, ist auf den XML Export angewiesen.
1 „Gefällt mir“
Also ich habe noch mal reingeschaut, aber wenn da zwei Leerzeilen sind, ist in der Instanz was grundlegend krumm, und eine Ursachensuche könnte sich lohnen, auch um an anderen Stellen Seiteneffekte zu vermeiden. Methode: Auf Standardtheme wechseln, testen. Einzeln Plugins abschalten und nach jedem Abschalten testen.
Ich habe noch Ideen das Problem zu umgehen (derzeit wird der Download on-the-fly generiert, da kann externer Code reingrätschen. Ich könnte aber auch tatsächlich eine Datei schreiben und anschließend auf diese Datei weiterleiten. Das dürfte robuster sein.) Aber das ist jetzt nicht „mal schnell“ gemacht. Ich behalte es im Hinterkopf.
1 „Gefällt mir“