Neuigkeiten
  • Die modified eCommerce Shopsoftware ist kostenlos, aber nicht umsonst.
    Spenden
  • Damit wir die modified eCommerce Shopsoftware auch zukünftig kostenlos anbieten können:
    Spenden
  • Thema: modified eCommerce Shopsoftware 2.0.5.1 rev 12725 veröffentlicht

    Rabek1200

    • Neu im Forum
    • Beiträge: 5
    • Geschlecht:
    Klasse Leistung! Wird sicher sehr nützlich sein!
    Modulshop - Eine große Auswahl an neuen und hilfreichen Modulen für die modified eCommerce Shopsoftware

    borwerbung

    • Neu im Forum
    • Beiträge: 9
    Hallo fleißiges Modified-Team,
    ich habe Probleme mit der "start.php Darstellung" nach Shop-Umstellung von latin1 auf utf8.

    Testshop-Version: 2.0.5.1
    Datenbank: MOD_2.0.5.1
    PHP Version: 7.3.20
    MySQL: 5.6.42
    bei Strato gehostet

    Ich habe meinen Testshop auf utf8 umgestellt gem. toller Anleitung und Skript (convert_to_utf8.php) von noRiddle ("Umlautprobleme nach Umstellung auf utf8"), ebenfalls habe ist die "includes/configure.php" und die "root/.htaccess" bearbeitet. Im Shop noch schnell die Sprache von iso-8859-15 auf utf8 abgeändert. Alles hat bestens ohne Fehlermeldung funktioniert und die Zeichensätze werden richtig angezeigt, jedoch in der "start.php - Ansicht" wird jetzt die rechte Spalte (Modified-News) ganz nach links über die linke Spalte angezeigt und deckt ca. 50% der linken Spalte ab (Online seit / Name / letzter Klick / Infos). 
    Nach Rückstellung (Shop und Datenbank) aller Änderungen (ohne utf8) wird wieder alles korrekt angezeigt.
    Mache ich etwas falsch oder ist das Skript für die aktuelle Shopversion nicht geeignet oder, oder ...???

    noRiddle (revilonetz)

    • Experte
    • Beiträge: 13.707
    • Geschlecht:
    Leere mal testweise die beiden DB-Tabellen newsfeed und whos_online (keine Angst, die werden neu gefüllt).

    Gruß,
    noRiddle

    borwerbung

    • Neu im Forum
    • Beiträge: 9
    @noRiddle
    Vielen Dank für deine schnelle Rückmeldung und Tipps.
    Heute habe ich noch einmal meinen Testshop auf utf8 umgestellt und erhielt diesmal keine Probleme mit der "start.php Darstellung",
    obwohl ich exakt alles nach gleichem Schema erstellt habe. Aus diesem Grund habe ich deine Tipps leider nicht ausprobieren können und entschuldige mich hierfür für die Zeitverschwendung meinerseits. Ebenfalls habe ich noch einmal Schrittweise die alte includes/configure.php und auch die root/.htaccess eingefügt, ebenso die Sprachumstellung, jedoch war der Fehler nicht mehr herzustellen.
    Ergebnis: Das etwas ältere Skript und die Dateiänderungen sind für die aktuelle Shopversion 2.0.5.1 weiterhin bestens geeignet +++.

    Tomcraft

    • modified Team
    • Gravatar
    • Beiträge: 46.161
    • Geschlecht:
    Der Datenbank Manager ist doch aber auch in der Lage die Datenbank von Latin-1 nach UTF-8 zu konvertieren.

    Grüße

    Torsten

    Timm

    • Fördermitglied
    • Beiträge: 6.318
    Der Datenbank Manager ist doch aber auch in der Lage die Datenbank von Latin-1 nach UTF-8 zu konvertieren.
    [...]

    War das für die Allgemeinheit? So ganz ohne Erklärung kann man sich das schlecht vorstellen, da es im Datenbank-Manager mehr oder weniger nur Backup- und Wiederherstellungsbuttons gibt.

    Vermute es geht darum eine Datei in den Backupordner zu schieben und dann durch wiederherstellen auszuführen. Aber selbst dann wüsste ich nicht welche Datei.

    Grüße Timm

    EDIT: Vielleicht könnte man das auch hier schreiben: Wiki: Datenbank von latin1 (iso-8859-1) auf utf8 umstellen

    snocer

    • Fördermitglied
    • Beiträge: 312
    Ich gehe mal davon aus, Torsten meint dieses Feld. Dann wird der Inhalt so übernommen wie er in der DB steht.
    Machst ein Backup mit der Auswahl, stellst Deinen DB Server um und sicherst das Backup zurück fertig.

    cu snocer

    noRiddle (revilonetz)

    • Experte
    • Beiträge: 13.707
    • Geschlecht:
    Und was soll das mit der Checkbox bringen ?

    [...] Dann wird der Inhalt so übernommen wie er in der DB steht.
    [...]

    Das sagt es doch schon aus.
    Die Frage ist doch in welcher Kodierung exportiert wird, und nachher importiert, egal ob Charset und Collation beim CREATE TABLE und/oder bei Text-Feldern dabei steht. Wenn ein Sonderzeichen wie ein Umlaut in latin1 der irgendeinem iso-... in die *.sql-Datei exportiert wird, wie soll daraus dann beim Import z.B. UTF8 werden ?

    Oder macht MySQL im Hintergrund etwas von dem ich nichts weiß ?
    Genauer an einem Beispiel:
    Man exportiert ohne Charset und Collation Commands als latin1, weil die DB in latin1 ist.
    Man importiert den Export in eine neue DB mit Default Charset utf8 (oder utf8mb4) und Collation entsprechend.
    Erkennt MySQL das dann und konvertiert automatisch alle Daten zu utf8 ?
    Habe ich, so weit ich mich erinnere, noch nicht erlebt.

    Gruß,
    noRiddle

    Tomcraft

    • modified Team
    • Gravatar
    • Beiträge: 46.161
    • Geschlecht:
    Bitte ignoriert
    Der Datenbank Manager ist doch aber auch in der Lage die Datenbank von Latin-1 nach UTF-8 zu konvertieren.
    [...]

    Bitte ignoriert die Aussage erst einmal, da scheint was noch nicht ganz rund zu laufen.
    Ich habe das in Ticket #1880 festgehalten.

    Grüße

    Torsten

    snocer

    • Fördermitglied
    • Beiträge: 312
    Und was soll das mit der Checkbox bringen ?

    [...] Dann wird der Inhalt so übernommen wie er in der DB steht.
    [...]

    Das sagt es doch schon aus.
    Die Frage ist doch in welcher Kodierung exportiert wird, und nachher importiert, egal ob Charset und Collation beim CREATE TABLE und/oder bei Text-Feldern dabei steht. Wenn ein Sonderzeichen wie ein Umlaut in latin1 der irgendeinem iso-... in die *.sql-Datei exportiert wird, wie soll daraus dann beim Import z.B. UTF8 werden ?

    Ich muss gestehen, habe die Funktion nicht getestet, bin einfach auf die Aussage von Torsten eingegangen.
    Bin davon ausgegangen das beim Export der DB die Textfelder bei nicht Angabe des Charset und der Collation die Felder eben so übergeben werden wie der Inhalt momentan ist. Beim Import in eine neue DB mit UTF8 müssen danach natürlich noch eventuell Anpassungen vorgenommen werden. Die aber schnell in einer UTF8 DB durch "suchen und ersetzen" machbar sein sollten. Meine Tools können auch per Auswahl alle Entitäten und oder Umlaute mit einem Rutsch auf das gewünschte Format umstellen auf DB Ebene für alle Tabellen durchführen. Daher empfand ich den Ansatz ohne Charset und Collation zu exportieren einfach als einfach und praktikabel. Der bisherige Lösungsansatz beinhaltet natürlich nicht eine automatische Konvertierung. Welche man aber per Import Script auch lösen könnte. Und Torsten sucht jetzt bestimmt nach dem Import Script für die automatische Konvertierung, für die es aber auch noch keinen Schalter gibt. :-)

    Eine automatische Konvertierung der Feldinhalte seitens MySQL gibt es nicht.

    cu snocer

    snocer

    • Fördermitglied
    • Beiträge: 312
    oder vor dem Import des DB Dumps im SQL Script folgenden Parameter --skip-character-set mitgeben.

    cu snocer

    borwerbung

    • Neu im Forum
    • Beiträge: 9
    Re: modified eCommerce Shopsoftware 2.0.5.1 rev 12725 veröffentlicht
    Antwort #191 am: 02. September 2020, 09:46:40
    @noRiddle
    Rückmeldung zum Problem aus Antwort #181 und Lösungsvorschlag aus Antwort #182:

    [...]
    Ich habe meinen Testshop auf utf8 umgestellt gem. toller Anleitung und Skript (convert_to_utf8.php) von noRiddle ("Umlautprobleme nach Umstellung auf utf8"), ebenfalls habe ist die "includes/configure.php" und die "root/.htaccess" bearbeitet. Im Shop noch schnell die Sprache von iso-8859-15 auf utf8 abgeändert. Alles hat bestens ohne Fehlermeldung funktioniert und die Zeichensätze werden richtig angezeigt, jedoch in der "start.php - Ansicht" wird jetzt die rechte Spalte (Modified-News) ganz nach links über die linke Spalte angezeigt und deckt ca. 50% der linken Spalte ab (Online seit / Name / letzter Klick / Infos). 
    [...]

    Habe dann den Vorschlag von noRiddle aus Antwort #182 befolgt:

    Leere mal testweise die beiden DB-Tabellen newsfeed und whos_online (keine Angst, die werden neu gefüllt).
    [...]

    Nach dem Leeren der zwei DB-Inhalte ist die Ansicht der start.php wie gewünscht, somit war der Tipp sehr hilfreich +++
    Herzlichen Dank an noRiddle !

    Grüße
    Günther

    [EDIT Tomcraft 02.09.2020: Zitate korrigiert.]

    Timm

    • Fördermitglied
    • Beiträge: 6.318
    Re: modified eCommerce Shopsoftware 2.0.5.1 rev 12725 veröffentlicht
    Antwort #192 am: 04. September 2020, 11:12:51
    Moin

    Ist es normal, dass die Zeit für das löschen des Caches im Backend extrem hochgegangen ist im Vergleich zur 2.0.4.2?

    Bei mir läuft das öfter in einen 504 Serverfehler, da die max_execution_time von 30s nicht ausreicht. Er löscht dann nur die Hälfte an Dateien zb und ich muss das nochmal anstoßen und dann löscht er auch den Rest. Die Ausführungszeit dauert also irgendwas zwischen 30s und 60s. Das kommt mir ziemlich lang vor. Ist das normal?

    Gruss Timm

    Tomcraft

    • modified Team
    • Gravatar
    • Beiträge: 46.161
    • Geschlecht:
    Re: modified eCommerce Shopsoftware 2.0.5.1 rev 12725 veröffentlicht
    Antwort #193 am: 04. September 2020, 11:41:21
    Reden wir vom Cache oder vom Template-Cache?
    Ab Shopversion 2.0.5.0 funktioniert der Cache überhaupt erst richtig und wird daher sicherlich wesentlich mehr Dateien anlegen, als in früheren Shopversionen.

    Grüße

    Torsten

    Andre Kern

    • Fördermitglied
    • Beiträge: 426
    Re: modified eCommerce Shopsoftware 2.0.5.1 rev 12725 veröffentlicht
    Antwort #194 am: 04. September 2020, 11:47:44
    Huhu,

    gerade in 2 Shops getestet. Einer (v2.0.5.1) mit 600 Artikeln und einer (v2.0.5.0) mit 2000 Artikeln. Bei beiden brauchen Cache und Template-Cache weniger als 2 Sekunden zum leeren.

    LG
    Andre