Innhold

Dette er et arbeids dokument og veiledning for oppgradering av eZ publish fra 3.6 til 3.8. Det er mulig dette dokumentet også kan brukes til oppgradering fra 3.7 til 3.8. Oppgraderingen ble gjort på Høgskolen i Lillehammer i perioden 1 til 17 November 2006.

Dokumentet er gjort i samarbeid med webdeal.no v/ Morten Tvenge og Jørn Skjerven) og Høgskolen i Lillehammer v/ Pål Messenlien

Vedlegg

Vedlagt til dokumentet følger det to sql filer som skal hjelpe til med konverteringen til utf-8.

• utf8convert.sql
• iso_to_utf8.sql

De kan hentes her

Grunnlag

Tre eZ publish siter bygd på nesten samme kilde kode. Disse kjørte ez publish versjon 3.6.7.

de skulle oppgraderes til siste versjon av eZ publish (3.8.5)

Teknisk oppsett

Vi valgte å sette opp en midlertidig server i oppgraderings perioden. Dette var en server som var likt konfigurert som den gamle hoved serveren. Denne fungerte som hoved server i oppgraderings perioden, slik at vi da kunne jobbe på oppgraderingen uten at dette skulle gå ut over tilgangen til websidene våre. Det ble satt opp en tidsplan for publiserings stopp i perioden slik at vi kunne fortløpende kopiere over endringer fra den midlertidige serveren. Dette fungerte veldig bra og vi endte opp med nedetid på ca 7 minutter av hoved websidene gjennom hele oppgraderingen.

Teknisk oppgradering

Før eZ publish oppgraderingen kunne starte måtte følgende være klart:

• Database server oppgradering til MySQL 5.*
• Php oppgradering med extensions til versjon 4.4.*
• Tegnsett på dataser fra iso 8859-1 til utf-8

Programvare (webdeal.no)

PHP

eZ publish før versjon 3.7 er kun kompatibel med PHP 4.3.4 eller nyere av 4.3.X serien. For eZ publish versjon 3.7 til 3.9 må man benytte seg av PHP 4.4.X. Dette innebærer at dersom man har hatt et system med en eldre versjon av eZ publish, må du oppgradere PHP til siste versjon av PHP 4.4.X. Avhengig av operativsystem og versjonene du har tilgjengelig i pakkesystemet, vil det mest sannsynlig være nødvendig å manuelt oppgradere PHP. Enten i form av kompilering, eller ta i bruk oppdaterte pakker (f.eks rpm) som ikke følger med standard i pakkesystemet. Spesielt Enterprise versjoner av Linux har låste versjoner av programvaren som støttes, og man må derfor være klar over at man mister både oppdateringer, garantier og support fra distributør når man går utenom pakkesystemet.

Man bør også ta et valg om man vil oppgradere operativsystem dersom man sitter på ett noe eldre system og låste versjoner. Man risikerer å måtte kjøre manuelle oppdateringer også på libraries som PHP benytter. Jo dypere man må «grave» og endre i pakkesystemet, jo større er sannsynligheten for at noe går galt.

Dersom PHP kompileres, følg henvisningene på http://www.php.net og sørg for å få med de extensions som er nødvendige for eZ Publish og dine andre PHP scripts. Mange av PHP extensions er avhengig av headerfiler og libraries til 3. part programvare, og disse må være på plass før man får kompilert PHP. Dette gjelder såkalte devel pakker, eller bruk kildekoden. Sørg også for å få med database extension til enten PostgreSQL eller MySQL. Under configure før kompilering, henvis til riktig versjon som skal brukes. Dersom pakker brukes, er det vanligvis en pakke for hver extension.

MySQL

eZ publish støtter Unicode, men dette avhenger av å ha en database som også støtter Unicode. PostgreSQL har støtte for Unicode, og MySQL 4.1.X. Mange bruker MySQL med eZ publish, og dersom du sitter på en versjon fra før 4.1.X, må MySQL oppgraderes. Men mindre pakkesystemet støtter 4.1.X er det ikke mange gode argumenter for å holde seg på 4.1.X, så her bør man gå opp til versjon 5.0.X når man først skal oppgradere. MySQL anbefales ikke å kompilere selv. Så sant det er mulig, bruk ferdig kompilerte pakker for din arkitektur og operativsystem.

Husk å ta oppdatert backup av alle databaser før oppgradering! (SQL dump)

Det er også nødvendig å konvertere databasene for Unicode. Noen erfaringer rundt dette kommer i den neste seksjonen.

Konvertering av data i databaser ISO 8859-1 til UTF-8 (webdeal.no)

Filkoding av databasedump

Et av problemene ved konverteringen av databaser, er tegnsettproblemer. Dette gjelder både på selve datasettet i tillegg til filkodingen på serveren. Databasedumpen man får ut er UTF8, og da denne ble leses inn igjen via kommandolinje, blir denne lest som ASCII-tekst. Dette gjør at ØÆÅ og andre spesialtegn ikke nødvendigvis blir lagt inn igjen riktig. Hvilken filkoding som databasedumper lagres i avhenger av tegnsettet i shell på server. I dette tilfelle UTF-8.

En løsning på dette er å kjøre rådumpen av databasen gjennom en enkel editor som gjøre om filkodingen til standard ASCII. Dette kan f.eks. gjøres i programmet UltraEdit, ellers kan dette også gjøres lokalt på serveren vha iconv.

Tegnsett

Lagringsmotoren (storage engine) må også defineres i MySQL5. Fra databasedump, vil denne mest sannsynlig være spesifisert med ISO 8859-1 (latin). Dette må endres til UTF-8 før databasedump importeres i ny UTF-8 klar database. Dette kan gjøres ved å endre på hver enkelt tabell i databasedumpen:

"engine=MyISAM;" endres til "engine=MyISAM collate utf8_danish_ci CHARATER SET utf8_danish_ci";

Dette er greit beskrevet i CREATE TABLE dokumentasjonen til MySQL:

http://dev.mysql.com/doc/refman/5.0/en/create-table.html

Tegnsett og eZ publish

En annet problem med tegnsett relatert til eZ publish, er alle xml-feltene i databasen. Disse er definert som ASCII, men dette kan endres i etterkant av dumpen med en enkel UPDATE spørring. Dette gjelder flere av tabellene, for full oversikt referer til eZ publish dokumentasjon.

Dette kan løses ved å kjøre denne sql stringen på basen:

UPDATE ezcontentobject_attribute SET data_text = REPLACE(data_text, 'encoding="iso-8859-1"?>', 'encoding="utf-8"?>')

Det er skrevet mye om dette i forumet til eZ, og en tråd å anbefale er denne:

http://ez.no/community/forum/install_configuration/update_to_3_8_and_codepage_problems

Konverterings eksempel

Iconv eksempel gjort med lokal server i Ubuntu linux
Dump ut databasen

Jeg prøvde mye frem og tilbake med iconv konvertering og snodig nok så var det denne settingen som fungerte best for min konvertering.

« iconv -f UTF-8 -t UTF-8 ezpublish.sql > ezpublish_utf8.sql»

NB! Hvis du bruker den gamle databasen så drop alle tables og kjør «Collation» på basen slik at den står som default «utf_8_danish_ci»

« mysql -u root -p --default-character-set=utf8 ezpublish2 < ezpublish_utf8.sql»

Endre gamle tables til utf-8

« mysql -u root -p ezpublish2 < utf8convert.sql»

Sjekk om alle tables i databasen er «utf8_danish_ci»

Rydd opp i basen og endre XML felt tegnsett

« mysql -u root -p ezpublish2 < iso_to_utf8.sql»

Tips: Jeg velger å bruke phpMyAdmin til å kjøre små sql scripts.

Ez Publish oppgradering

Bakgrunn for denne oppgraderingen hentet jeg her:

http://ez.no/doc/ez_publish/upgrading/upgrading_to_3_8/from_3_6_x_or_3_7_x_to_3_8_0

Last ned og pakk ut siste 3.8.* versjon fra her: http://ez.no/download/ez_publish

Kopier med deg var, settings/override, settings/siteaccses, design foldere og eventuelle extensions til den nye installasjonen.

Database oppgradering

Kjør MySQL oppgraderings skriptene enten via phpMyAdmin eller via et shell:

mysql -u root -p ezpublish < update/database/mysql/3.8/dbupdate-3.6.0-to-3.8.0.sql

Ini instillinger

Endre site.ini.append.php i «settings/override» og «settings/siteaccess» tilpasset din site.

Skru på utf-8 som tegnsett for siten med å endre settings/override/i18n.ini.append.php

<?php /* #?ini charset="utf-8"?

[CharacterSettings]

Charset=utf-8

*/ ?>

Sjekk om du har flere i18n.ini.append.php filer under de andre siteaccess mappene du bruker. Du trenger kun 1 av denne filen.

For ryddighetens skyld så endret jeg også alle ini filer i «settings/override» og «settings/siteaccess» til <?php /* #?ini charset="utf-8"?

Hint: Under [DatabaseSettings] måtte jeg sette «Charset=» for at utf-8 skulle fungere riktig

Kjør « bin/shell/clearcache.sh –clear-all» og sjekk om oppgraderingen fungerte.

Til toppen