• Hallo,

    erst einmal mein Lob für euer Plugin.

    Leider stellen wir in Verbindung mit diesem Plugin ein massives bzw. grunds?tzliches Problem fest:

    1.
    Migrationen auf ein neues WordPress sind kein Alltag, aber sehr wohl ein übliches Szenario vieler WordPress Projekte. Nun ist es so, dass euer Plugin die Z?hlermarken anhand der Post IDs der Datenbanktabellen ein Matching herstellt. Das ist denkbar schlecht und zugleich fatal: Denn bei einer Migration ?ndern sich selbstverst?ndlich alle Tabellen IDs der Posts. Selbst komplexe Import Plugins k?nnen IDs der Posts nicht übernehmen und das würde auch gegen den WordPress Codex arbeiten.

    Insofern stellt dieses Plugin den Kunden vor eine massive Hürde:
    F?ngt man einmal mit diesem Plugin an zu arbeiten, ist sp?ter eine Migration zu einem anderen WordPress nicht mehr m?glich. Gleichzeitig existiert bis heute keine Export M?glichkeit, dabei w?re die L?sung überschaubar:
    Die Z?hlermarken werden nicht per ID sondern über posttype_name + slugs gematcht.

    So arbeiten zumindest VGWort Drittanbieter Plugins und diverse Import/Export Plugins, wenn es sich nicht um z.B. WooCommerce Produkte handelt, bei denen über eine SKU ein Matching stattfinden kann.

    Nun stehen wir genau vor dieser Herausforderung.
    Wir stellen gleichzeitig fest, dass bereits diverse andere User nach einer L?sung suchen und auf diesen Beitrag verwiesen werden (mind. 2 Jahre alt):
    https://prosodia.de/prosodia-vgw-os/wordpress-migration-zaehlmarken-auf-neue-installation-uebertragen/

    Allerdings wird dort das ID Matching Verfahren angewendet, dass bei einer Migration auf ein neues WordPress nicht anwendbar ist.

    2.
    In dem von euch verlinkten Beitrag hei?t es:
    Wie arbeiten momentan daran, wie das Problem gel?st werden kann.
    Das ist mehr als zwei Jahre her. K?nnen wir mit einem Patch oder Upload/Export per Email rechnen?

    3.
    Der Export als CSV aus dem Quellsystem führt beim Import im Zielsystem zu folgender Fehlermeldung:
    Es wurden keine Z?hlmarken für den Import in den CSV-Daten gefunden. Stellen Sie bitte sicher, dass Sie die von der VG WORT erhaltenen CSV-Daten unver?ndert eingeben haben. Die Spalten der CSV-Daten müssen mit Semikolon (;) getrennt sein. Bei der VG WORT unterscheiden sich CSV-Daten von Autoren-Konten und Verlags-Konten, daher muss dies beim Import ausgew?hlt werden.

    4. Die manuelle Zuordnung bei mehreren knapp 2000 Posts ist ausgeschlossen. ??

    über ein zeitnahes Feedback würden wir uns sehr freuen, da wir gerade mit dem Rücken zur Wand stehen (wie viele andere auch). Der Export der Posts Tabelle ist ausgeschlossen, da im neuen Blog System diverse andere Plugins arbeiten und dadurch andere Metadaten abgelegt werden. Es ist daher üblich, dass die Migration über Export/Import Plugins erfolgt und nicht partiell Tabellen exportiert/importiert werden – das würde die gesamte Projekt- und Datenkonsistenz gef?hrden.

    Viele Grü?e,
    Tommy

    • This topic was modified 3 years, 6 months ago by tommy83.
Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Author Dr. Ronny Harbich

    (@raubvogel)

    Haben Sie Dank für die Hinweise.

    1. Die Spalte ID in der Post-Tabelle ist der Primary Key – mithin ist es korrekt, dass die Z?hlmarken-Tabelle darauf verweist. Sind slug und post_type wirklich unver?nderbar eindeutig?
    2. Eine L?sung ist m. E. nicht trivial. Für Vorschl?ge oder anderen Support w?re ich durchaus dankbar.
    3. Ist derart korrekt – beim Import handelt es sich um Z?hlmarken-Dateien, die direkt von der VG WORT kommen.
    4. Verst?ndlich und richtig.

    Mir ist das Problem durchaus bekannt. Eine gute L?sung habe ich bisher dennoch nicht gefunden. Allerdings werde ich die kommenden Tage nochmals recherchieren …

    Für ein kostenloses Plugin kann ich leider nur bedingt Entwicklungszeit einplanen. Wenn hier monet?re Unterstützung bereit gestellt werden m?chte, bitte gern melden.

    Sch?ne Grü?e!

    Thread Starter tommy83

    (@tommy83)

    Die Spalte ID in der Post-Tabelle ist der Primary Key – mithin ist es korrekt, dass die Z?hlmarken-Tabelle darauf verweist. Sind slug und post_type wirklich unver?nderbar eindeutig?

    Korrekt. Bereits das WP Datenmodel und die Eingabemaske von WordPress l?sst keine doppelten Slugs für den Beitrag zu. Wenn nun ein Export gefahren wird, sollte nicht die Post ID sondern der Post-Slug gew?hlt werden. Denn dieser bleibt nach dem Import im Zielsystem unver?ndert.

    Aktuell w?hlt das Plugin nicht den Postslug, sondern die Post ID:
    Das macht natürlich keinen Sinn, da diese sich nach dem Import im Zielsystem ?ndern wird.

    Nicht ohne Grund arbeitet WP ALL Import und jedes andere WordPress Plugin nach diesem Prinzip, wenn es um Export/Import Vorg?nge in ein anderes WordPress geht.

    Eine L?sung ist m. E. nicht trivial. Für Vorschl?ge oder anderen Support w?re ich durchaus dankbar.

    L?sung über trivalen sVerweis:
    Ich habe es mit einem sVerweis in Excel gel?st – und das ganze funktioniert analog über PHP in 60 Minuten. In Excel lade ich die Datenbanktabelle von vgwort aus dem Quellsystem. In einer zweiten Exceltabelle lade ich aus der selben Datenbank die Datenbanktabelle der Posts. Diese beinhaltet die Post ID und den Postslug.

    Nun schnappe ich mir die Post ID aus der ersten Tabelle und suche danach in der zweiten Post Tabelle. Wenn das Script einen Treffer hat, gibt es als Ergebnis den Titel zurück. Diesen Titel lasse ich notieren.

    Nun exportiere ich aus dem Zielsystem die Datenbank: Post ID und Titel.
    Ich suche nach dem Titel und lasse dieses mal die neue Post ID notieren. Diese ID lasse ich in meine CSV aus dem VGWort Plugin schreiben.

    Nun habe ich eine Import Datei, die gleich die richtigen Post IDs für das neue Zielsystem hat/kennt.

    Natürlich kann man sich diesen “Kindergarten” mit sVerweis sparen, wenn man gleich über Slugs arbeitet (siehe oben), so wie WP ALL Import, WordPress Imp/Exp und WordPress Export Advanced und viele andere Plugins.

    Frage:
    Das Plugin wird nicht von VG Wort supported?

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘fatales Export/Import Logik Problem’ is closed to new replies.