Author Topic: Großes Lob - die Updatefunktion ist genial  (Read 98 times)

Offline joey19

  • Posts: 93
Großes Lob - die Updatefunktion ist genial
« on: March 28, 2019, 07:09:21 PM »
Hallo liebe Entwickler,

ich will heute erst mal ein großes Lob loswerden:

Seit etwa 10 Jahren betreue ich die Homepage eines Sportvereins, die regelmäßig gepflegt werden will. Ich habe von daher schon einige Updates installieren dürfen. Diese Woche nun bin ich (endlich) von der Version 2.8.3 auf 2.12.1 umgestiegen - mit der genialen unzip-Methode einfach wie nie. Da macht selbst ein Update Spaß. Habe dann auch gleich die beiden weiteren Seiten, die ich betreuen darf, aktualisiert.

Deshalb vielen Dank mal an dieser Stelle und natürlich auch für die immer hilfreiche Unterstützung hier im Forum.

Mein Umlautproblem (teilweise in latin gespeichert, Umstellung auf UTF-8) habe ich auch relativ gut händeln können, nachdem ich die wichtigsten Seite mit Suchen und Ersetzen bearbeitet hatte (was miri dann doch zu aufwändig war). Da ich php ja nicht kann und auf meine alten Tage auch nicht mehr lernen will, habe ich ein SQL-Statement genutzt und habe die relevanten Tabelle mit einem Replace-Update beglückt. Ich weiß zwar nicht was Jacobi dazu sagen wird, aber es scheint funktioniert zu haben Ist zwar ein bisschen Handarbeit (Spaltennamen anpassen, geht aber mit Notepad++ einfach), flutscht aber dann sehr schnell über die DB:
Update t_mod_wysiwyg set
    `content`= REPLACE(`content`,"ß", "ß"),
    `content`= REPLACE(`content`, "ä", "ä"),
    `content`= REPLACE(`content`, "ü", "ü"),
    `content`= REPLACE(`content`, "ö", "ö"),
    `content`= REPLACE(`content`, 'Ä', 'Ä'),
    `content`= REPLACE(`content`, "Ãœ", "Ü"),
    `content`= REPLACE(`content`, "Ö", "Ö"),
    `content`= REPLACE(`content`, '€', '€'),
     `content`= REPLACE(`content`, '–', '-')

Liebe Grüße und natürlich weiter so  :-D (Y)

Joey

Offline dbs

  • Betatester
  • **
  • Posts: 7846
  • Gender: Male
  • tioz4ever
    • WebsiteBaker - jQuery-Plugins - Module - Droplets - Tests
Re: Großes Lob - die Updatefunktion ist genial
« Reply #1 on: March 28, 2019, 07:16:13 PM »
Quote
Da macht selbst ein Update Spaß.

Danke an dich auch.  (Y)

Offline jacobi22

  • Posts: 5738
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Großes Lob - die Updatefunktion ist genial
« Reply #2 on: March 28, 2019, 11:41:32 PM »
Quote
Ich weiß zwar nicht was Jacobi dazu sagen wird

ich hab hier nix zu sagen, die Zeiten sind vorbei   :wink:

zum Thema zurück: in der Tat ist es immer eine umfangreichere, aber auch einmalige Sache, wenn es denn richtig gemacht wird.
Und es geht beim Umstieg natürlich auch darum, die Optik und Lesbarkeit wieder herzustellen, aber fast schon wichtiger ist es, zu vermeiden, das es wieder passiert. Und dazu muß neben den Zeichen auch die sog Collation und das Charset angepasst werden. Die Collation bestimmt unter anderem die Sortierreihenfolgen beim Einlesen von Daten. Wird ein Ä nach A behandelt oder als AE usw. Das Charset bestimmt dagegen den Zeichensatz
Schaut man sich mal solch Backup-Datei an, z.b. eben im Notepad++ oder besser, ist es oft leicht erkennbar.
Stellvertretend mal einen Ausschnitt einer solchen Tabelle mit farblicher Markierung

Quote
CREATE TABLE `wb_addons` (
  `addon_id` int(11) NOT NULL,
  `type` varchar(255) COLLATE latin1_german1_ci NOT NULL DEFAULT '',
  `directory` varchar(255) COLLATE latin1_german1_ci NOT NULL DEFAULT '',
.........
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci;

möglich sind im deutschen Sprachraum auch andere Kombinationen wie z.b.
- DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci
- DEFAULT CHARSET=latin1 COLLATE=latin1_german2_ci

die rot markierte Kombination steht grundsätzlich an jedem Feld-Typ, der Text verarbeitet, also ein CHAR, ein VARCHAR, ein TEXT usw. Die blaue und grüne Markierung steht einzeln oder zusammen immer am Ende der Tabellenstruktur.

blau = z.b. DEFAULT CHARSET=latin1 sollte immer auf DEFAULT CHARSET=utf8 stehen
grün und rot - z.b.  COLLATE=latin1_german1_ci oder COLLATE latin1_general_ci sollte immer auf COLLATE=utf8_unicode_ci stehen

Das Wichtigste ist wohl, das man dabei nicht die Übersicht verliert.
Zuerst natürlich ein Backup der Datenbank erstellen. Die gelieferte Datei kopieren und sicher irgendwo ablegen und höchstens zum erneuten Kopieren wieder anfassen.
Alles weitere läuft dann nur über die Kopie der Sicherung oder eine Kopie der Kopie.

Als Editoren eignen sich viele Programme, z.b. Notepad++, das simple Notepad
Absolut ungeeignet wäre Wordpad oder gar Word. Diese fügen für dieses Programm unsichtbare Steuerzeichen ein, ggf auch Zeilensprünge und vermurksen das Backup.

Die meisten westeuropäischen Schriftzeichen beginnen in UTF8 mit à oder â. Wer noch etwas anderes findet, immer mit rein schreiben in solche Threads. Ist das Werk getan, lohnt es sich oft, nach genau diesen einzelnen Zeichen im Backup zu suchen. Dies steht immer mit einem zweiten Zeichen, das  â auch mit zwei weiteren Zeichen wie z.b. , das für ein Anführungszeichen aus Word steht - . Die für uns Deutsch-Sprachige gebräuchlichsten Kombinationen hat Joey oben aufgezeigt, in meiner Liste habe ich aktuell 91 solcher Kombinationen. Neben den deutschen Umlauten sind da auch französische, tschechische oder spanische Umlaute enthalten, aber, mangels bisheriger Nachfrage, z.b. keine aus Skandinavien und schon garnichts kyrillisches oder asiatisches/arabisches. Diese haben aber seit je her schon mit UTF8 gearbeitet, wenn sie irgendwo international auftreten wollten.

Was nicht ersetzt werden muß, sind die sog HTMLSpecialChars wie & ä usw. Diese treten meist in Wysiwyg-Sectionen auf, aber auch in Einzelfeldern vieler Module. Diese Zeichen werden vom Browser übersetzt in die entsprechenden Sonderzeichen. Zu kontrollieren wäre aber eventuelle EMails, Kontaktformular, Gästebuch u.ä. Oft liegt das aber auch an den Mail-Clients oder den Mailservern. GMX war früher mal solch Spezialist, wo es immer recht schwierig war, ordentliche Mails zu versenden.

Nach Anschluß der Arbeiten empfiehlt sich ein Test-Import. Dafür eigenen sich die portablen Server wie WBPortable oder Uwamp, lokale Server wie Xampp oder man nutzt einen kostenlosen Account z.b. bei BPlaced.net. Funktioniert der Import dort, wird er auch auf dem Webserver eurer Domain funktionieren.
Wirft er Fehler, heißt es suchen und vergleichen, oft liegt es nur an Kleinigkeiten, aber mit großen Auswirkungen, z.b. ein Semikolon mit entfernt. Hängt an den Dateinamen des konvertierten Backups immer auch Datum und Uhrzeit mit dran und scheut euch nicht, auch mal von vorn zu beginnen statt ein Backup mit Fehlern zu reparieren.

Und wer sich nicht ran traut oder nicht klar kommt, immer fragen, hier oder per EMail. Für  kleine bzw die meist verwendeten Projekte mit 10 - 20 Seiten reicht mir das SQL-Backup, dann kann ich mir das nachbauen, sofern die verwendeten Module verfügbar sind. Bei komplexeren Sachen sollte es dann aber schon auch ein Backup der Dateien sein, das ich mir irgendwo herunterladen kann. Nach den Negativ-Erfahrungen der letzten zwei Upgrades verschicke ich aber keine konvertierten Backups mehr ohne vorherigen Test's und "Abnahme" - gern auch auf einem internen, geschützten Server, so das man zusammen schauen kann.
Manch einer kann dann solch Import-Beschreibung nicht lesen, ein anderer will es nicht und der nächste fragt zwar an, traut aber dem Ergebnis oder mir nicht, auch, wenn er das Ergebnis live gesehen hat. Mir müßt wirklich ein Huf fehlen, wenn ich eine 20.000 Zeilen Datei Zeile für Zeile durchgehe und die vom Uwe konvertierten Zeichen aus dessen Datei in meine eigene rein kopiere und dabei die selbst vorher getestete Datei vermurkse, egal, vorbei....

Sofern es nicht zur Lebensaufgabe wird, gibt es nach Abschluß der Arbeiten ein ZIP mit den Projektdateien und eins mit dem SQL-Import als Download zurück, was man dann nur noch auf den Server übertragen muß, natürlich in der aktuellsten Version
« Last Edit: March 28, 2019, 11:47:59 PM by jacobi22 »
Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.