[Gelöst] Exportieren der Daten in MySQL und anschließender Import - Fehler im Encoding
Dies ist das technische Support-Forum für WPML – das mehrsprachige WordPress-Plugin.
Mitlesen können alle, doch nur WPML-Kunden können hier Fragen veröffentlichen. Das WPML-Team antwortet im Forum an 6 Tagen pro Woche, 22 Stunden am Tag.
Heute stehen keine Supporter zur Arbeit im German-Forum zur Verfügung. Sie können gern Tickets erstellen, die wir bearbeiten werden, sobald wir online sind. Vielen Dank für Ihr Verständnis.
wir möchten gerade unsere Webseite auf einen neuen Server umziehen.
Hierbei haben wir die DB Daten (MySql - Maria DB) exportiert. Leider werden hierbei die Übersetzungen aber mit ?????? exportiert.
Ich denke, dass es sich hierbei um einen Codierungsfehler handelt.
Die Codierung der DB ist UTF8. Es wird auf der Webseite (produktiv) bei uns auch korrekt angezeigt. Lediglich beim Export via PHPMYADMIN wird die Codierung falsch übernommen.
Können Sie mir mitteilen wie wir die Daten der DB exportieren müssen, dass es für unsere 13 Übersetzeungen (bspw. Russisch, Japanisch, Chinesisch etc) dann von der Codierung stimmt?
eine andere herangehensweise wäre den Export und Import zu vermeiden und den Umzug auf einen anderen Server abzubrechen.
Dieser ist nämlich nur nötig weil auf dem derzeitigem Webspace ein File iNode Limit von 164.000 Dateien gesetzt ist.
Leider wurden aber durch die 13 Sprachen die übersetzt wurden soviele Files erzeugt, dass nun das Limit erreicht ist und ein Umzug nötig wäre.
Gibt es eine Möglichkeit Sprachen wie bspw. Irisch wieder zu entfernen (und alle Files die dazu existieren) zu löschen?
-> wichtig wäre aber dann, dass ich diese vorab noch sichern kann, da ja die Übersetzung ca. 1.000€ gekostet hat und ich sonst buchstäblich das Geld in den Papierkorb schiebe.
Dies wäre eine temporäre Lösung, da ich derzeit keine neuen Seiten / Produkte mehr einstellen kann, und auch keine Plugins mehr updaten kann, da die Übersetzungen soviele Files generiert haben.
-> Aber dieser Topic ist durchaus noch wichtig und sollte gelöst werden, da auf kurz oder lang ein Umzug nicht ausbleiben wird, da ich ja die Übersetzungen bezahlt habe und auch verwenden möchte 🙂
Vielen Dank für eine kurze Rückmeldung (vermutlich würde diese Frage dann aber in einem separaten Ticket beantwortet/verschoben werden)
LG,
Johannes
eine andere Frage wäre um den Export und Import zu umgehen
welche Files meinen Sie? Die Übersetzungen liegen als .MO/.PO Files unter /wp-content/languages/wpml. Meinen Sie diese Files? Die .MO Files dort sollten kein Server-Limit ausreizen. Könnten Sie mir bitte ein Beispiel dazu anhängen.
Ich habe es gerade mit unserem DB-Experten geprüft und er meinte, dass Sie es vom aktuellen Host konvertieren sollten, z.B.: damit: https://stackoverflow.com/a/69919753.
Alternativ können Sie die Migration mit einem Plugin wie Duplicator oder All In One Migration. starten.
1. Files / Ablage
Ja das war die Frage in welchen Ordner Files generiert werden. Denn das "Problem" ist durch die Übersetzungen entstanden, da dadurch die Fileanzahl angestiegen ist.
Werden also durch Sie nur die .MO/.PO im languages Ordner generiert?
Wenn ich diese downloaden und anschließend löschen würde wären könnte ich dann noch die Seiten im Backend ausblenden? Bzw. Gegenfrage wenn die Files anschließend wieder hochgeladen werden und dann die Sprache im Backend wieder aktiviert wird -> funktioniert dann wieder alles?
----
2.
Beide DBs liegen beim selben Provider (Ionos). Unterschied ist
derzeit läuft die
Produktiv Seite auf einem WordPress Webspace. Hier ist allerdings die iNode Fileanzahl limitiert
nun soll auf einen VPS Server umgezogen werden (ebenfalls Ionos)
ich werde ihren Vorschlag bzgl. Export ohne charset und anschließende replacen (lt. Link) testen und Ihnen dann Rückmeldung geben.
ich habe mir gerade nochmal per FTP den Ordner angesehen.
generell wurden nicht allzuviele Files erzeugt. also im language Ordner befinden sich unter plugins ~ 4.000.
Diese könnte ich temporär löschen oder? Denn ich gehe davon aus, dass diese für das Backend notwendig sind?
-> wird pro produkt / Seite / Beitrag wahrscheinlich auch immer ein neues File erzeugt, oder?
Weil wir haben ca. 500 Produkte und 13 Sprachen -> d.h rund 6500 files sind erzeugt worden.
daher könnte es dann sein das das limit vorher schon ausgereizt war und nun durch die generierung von 10.000-15.000 Files durch die Übersetzungen nun das Limit voll ist ^^
Danke für eine kurze Auskunft welche Files temporär entfernt werden könnten.
Dann wäre es möglich per WP-All in one migration zu migrieren.
die Files unter /wp-content/languages/wpml sollten Sie nicht löschen. Die String Translation werden von dort geladen.
-> wird pro produkt / Seite / Beitrag wahrscheinlich auch immer ein neues File erzeugt, oder?
Nein, alle Übersetzungen sind in der DB, außer die oben genannten Strings. Daher wundert mich, ob hier überhaupt WPML in der hohen Anzahl involviert ist bzw. die Übersetzung hier involviert sein soll. Wir erstellen keine Files für Pages, Produkte etc.
Rechnet Ihr Hosting auch die Mails mit? Sonst löschen Sie am besten WP Caching Dateien etc. Ich bin ehrlich gesagt überrascht, dass IONOS überhaupt noch ein File Limit hat.
danke für Ihre Rückmeldung.
Ja ich bin auch verwundert und ja ein File Limit finde ich heutzutage auch nicht mehr "state of the art..."
Aber es ist so wie es ist.
Ich habe gestern Ihren Tipp einmal umgesetzt und den Export der original DB ohne spezifische char collate gemacht und danach wieder in utf8 importiert.
Sieht nun gut aus.
Zumindest die Export Datei beinhaltet die Kyrilischen und chinesischen Zeichen.
Auch in der DB wurden diese wieder importiert.
Auch bei den Produkten wurde die Umlaute etc. korrekt übernommen.
Nur leider bei den Kategorie Beschreibungen sowie bei den Menü Verlinkungen gibt es nun ein Problem bei den Umlauten bzw. "ß".
Wird das durch Ihre Plugins irgendwie beeinflusst?
Weil ich vermute, dass es mit der WPML String Translation zusammenhängt?
Dieses kann nämlich nicht aktiviert werden
WPML String Translation versucht, .mo-Dateien mit Übersetzungen in folgenden Ordner zu schreiben:
/var/www/vhosts/silly-wu.85-215-173-5.plesk.page/httpdocs/wp-content/languages
Welche Rechte müssten auf den Ordner gesetzt werden?
Evtl. werden diese per FTP nicht übernommen bzw. im Normalfall durch Ihr Import/Install Plugin gesetzt.
Link zur Seite die importiert wurde am VPS Server versteckter Link
Hier werden die Menü Einträge nicht korrekt angezeigt
Bspw. Epoxidharzm?bel anstelle von Epoxidharzmöbel
oder auch beim Kategorietext sind die Umlaute und "ß" nicht korrekt.
Hängt das damit zusammen, dass Ihre Plugins noch nicht aktiviert sind (ich kann sie derzeit nicht aktivieren aufgrund des geschilderten permission Problems)
dies sollte nicht durch ein deaktiviertes WPML ausgelöst werden. Sie werden sich hier an Ihr Hostingunternehmen wenden müssen, es betrifft hier Ihre Defaultsprache, welche nicht von WPML verwaltet wird. Dies wird auch ohne WPML der Fall sein.
Am Provider liegt es sicher nicht, da es ja ein VPS Server ist. Wenn dann am Import des DB Dumps (charset)
Ich werde mir hierzu die DB Import Datei nochmals Näher ansehen.
Zu Frage 2.
Habe es nun überprüft. Die Rechte für den languages Ordner sind im Produktiv sowie im Test System gleich.
-> Siehe Screenshot
Aber im Testsystem erhalte ich folgende Meldung:
WPML String Translation versucht, .mo-Dateien mit Übersetzungen in folgenden Ordner zu schreiben:
/var/www/vhosts/silly-wu.85-215-173-5.plesk.page/httpdocs/wp-content/languages
Dieser Ordner scheint nicht beschreibbar zu sein. Dies blockiert das Erscheinen der String-Übersetzungen auf der Website.
Um dies zu lösen, kontaktieren Sie bitte Ihr Hosting-Unternehmen und bitten Sie darum, diesen Ordner beschreibbar zu machen.
Weitere Details siehe WPMLs Dokumentation zur Fehlerbehebung in der Erstellung von .mo-Dateien..
-----------------------
Woran liegt das?
Danke im Voraus für Ihre Mühe.
Neue Threads, die von Marcel erstellt wurden und mit diesem verbunden sind, sind unten aufgeführt:
