Drupal frissítés - a Drupal.hu tapasztalatai (2)

Hojtsy Gábor képe

Az előző rész hiányosságaként tomsolo rámutatott, hogy meg kell különböztetnünk kétféle frissítést is. A könnyebbik esetben biztonsági és/vagy hibajavító frissítést telepítünk (például Drupal 4.6.0-ról valamely későbbi 4.6.x-es kiadásra váltunk). Ez könnyebb a webhely gazdája számára, hiszen adatbázis változtatást szinte biztosan nem kell végrehajtani, csak a kódot kell cserélni, sőt a kiegészítő modulok kompatibilitása is biztosított. Emiatt ez a fajta frissítés mindenképpen javasolt.

Ebben a sorozatban viszont a nagyobb verzió ugrások végrehajtásához szeretnék tippeket adni, mint például a Drupal 4.6.x-ről 4.7.0-ra történő frissítés, vagy esetünkben a Drupal 4.5.x-es sorozatról a legújabb 4.7.0-ra. Itt garantált, hogy a korábban használt modul kódok nem lesznek kompatibilisek, új fordításokat kell telepítenünk és az adatbázis struktúra is szinte biztosan megváltozik.

Gondoljunk az adatbázisra és a fordításokra is

Az előző részben megbizonyosodtunk róla, hogy az új frissítendő kiadáshoz rendelkezésre állnak a számunkra szükséges kiegészítő modulok kódjai. Két dologról azonban még mindenképpen meg kell győződnünk a frissítés megkezdése előtt.

A Drupal 4.7.0 a korábbiaknál is felhasználóbarátabb adatbázis frissítő megoldással érkezik. Régebben a kiegészítő modulokhoz tartozó adatbázis táblák frissítését egyedileg kellett elvégeznünk, a modulonkénti leírások átolvasásával. A 4.7.0-hoz kiadott modulok esetén .install fájlokban leírhatóak a telepítésnél és frissítésnél végrehajtandó utasítások, és minden modulhoz saját adatbázis séma verziót tart nyilván a rendszer, ami alapján a szükséges frissítések kiterjesztésenként külön megállapíthatóak. Ha az általunk kívánt kiegészítő modulok esetében nem volt adatbázis változás, vagy rendelkeznek ilyen frissítést segítő fájllal, akkor szerencsénk van. Előfordulhat, hogy mégis egyedi leírások alapján kell a kiegészítő táblákat frissíteni, hiszen ez a telepítő alrendszer még friss, nem minden modul fejlesztőjének sikerült még áttérni rá.

Nem elhanyagolható szempont magyar (vagy más) nyelvű webhely karbantartásánál, hogy a kívánt modulokhoz elérhető-e már a kívánt fordítás. Ez az alapcsomag esetében semmiképpen nem gond, a kiegészítők már változatosabb mintát mutatnak az elérhető fordítások tekintetében. Ha véletlenül nincs letölthető fordítás a kívánt modulhoz, nem kell elkeseredni. A modul kódjának mappájából elindítva az extractor.php segítségével könnyen generálhatjuk a fordítási sablon fájlokat (.pot), melyekből kiindulva a modul fordítását magunk is elkészíthetjük, egy egyszerű szöveges fájlszerkesztő használatával. Bármilyen nyelvre is fordítunk, csak arra kell feltétlenül figyelnünk, hogy UTF-8 kódolást használva mentsük el a fordítást. Ezután érdemes a közösséggel megosztani a munkát, így erősítve az általunk használt rendszer képességeit, hozzájárulva jövőjének biztosításához. Bővebb információ a magyar fordításról.

A hivatalos verzió: frissítés adatbázis mentéssel

Nem érdemes feltételezni, hogy minden rögtön tökéletesen fog működni, ezért különösen veszélyes egy éles webhelyen frissítést végrehajtani. Könnyen lehet, hogy valami félrecsúszik, és ilyenkor mindenképpen jó, ha van egy biztonsági mentésünk a frissítés megkezdése előtti állapotról, amire könnyen visszaállhatunk. Valójában magán a mentésen, azaz a mentés alapján létrehozott teszt webhelyen érdemes a frissítést elindítani, biztonságos távolságra az éles környezettől.

A Drupal.hu MySQL adatbázist használ, így most ezzel fogunk foglalkozni. Vegyük tehát a kedvenc adatbázis dump előállító programunkat (phpMyAdmin webes felületen vagy mysqldump a parancssorból), és egy .sql állományba mentsük el az adatbázisunk tartalmát. A mysqldump használatával a következőképpen juthatunk eredményre:


mysqldump --user=felhasznalonev --password=jelszo adatbazisneve > dumpfile.sql

Valójában eléggé nagy mentésünk lesz a cache, locales_target, locales_source és hasonló táblák miatt, amik tartalmára valószínű nem lesz szükségünk, a fordításokat úgyis újra kell importálnunk, a gyorstárat pedig a fordítás miatt úgyis űríti majd a rendszer. Ezeket a kivételeket azonban a mysqldump számára nem egyszerű megadni, ezért a magam részéről inkább együttélek a nagy fájl le- és feltöltésével járó nagyobb várakozással.

A következő lépés egy friss üres Drupal 4.7.0 telepítése, mely alá a gyárilag szállított MySQL adatbázis helyett a mentett adatbázisunkat töltsük fel. Ezután az index.php betöltése helyett az update.php oldalt hívjuk be. Itt kaphatunk egy hibaüzenetet, hogy nem vagyunk belépve, és így nem tudjuk elvégezni a frissítést. Ezesetben az update.php tetején található $access_check változót állítsuk FALSE értékre, így nem kell belépnünk. A frissítés után természetesen állítsuk vissza TRUE értékre, vagy töröljük az update.php fájlt teljesen.

Ha minden rendben megy, a frissítést elindíthatjuk, kiválasztva az összes felajánlott frissítési lehetőség közül azokat, amikre szükségünk van. Attól függően, hogy bekapcsolt vagy kikapcsolt JavaScript mellett futtatjuk a kódot, egy kicsit más felület fogad bennünket. Mindenképpen feltűnő a korábbiakhoz képest barátságosabb előrehaladást mutató sáv, mely a végére érve egy összefoglaló oldalra irányít bennünket, ahol áttekinthetjük a frissítés során végrehajtott adatbázis átalakító utasításokat, és az esetleges hibaüzenteket. Ezzel az összes frissítésre felkészített modulunk mögött álló adatbázist sikeresen az új verzióra állítottuk át, meglátogathatjuk az eseménynaplót a rögzített esetleges hibaüzeneteket áttekintendő, vagy rögtön a címlapunkra léphetünk.

A drupal.hu változat: párhuzamos tesztelés

Akik hozzánk hasonlóan saját modulokat is adtak a rendszerhez, esetleg még sminket is szeretnének változtatni, vagy már korán el szeretnék kezdeni a frissítés előkészítését, azok nem számíthatnak azonnal megfelelő eredményre. Könnyen lehet, hogy a teszteléshez használt rendszert folyamatosan a meglévő rendszer működtetése mellett kell előkészíteni. Ezt tettük a Drupal.hu esetében is.

Mivel a folyamatos párhuzamos üzemeltetés nem kényelmes kézi eszközökkel, egy kis segésszkriptet valósítottuk meg, mely veszi a meglévő drupal.hu adatbázist, és az azonos szerveren, de a világ szeme elől elrejtve karbantartott tesztelésre használt virtuális hosztnak megfelelő adatbázisba másolja azt. A PHP-beli megvalósítás lehetővé teszi, hogy speciális módosításokat is végrehajtsunk az adatbázison, mielőtt az update.php-t futtatjuk. Nézzük részleteiben a klónozásra használt szkript kódját:

// Kapcsolat felepitese
$conn = mysql_connect("localhost", "ujuser", "ujjelszo");
mysql_select_db("ujdrupalhu", $conn);
// Ujdrupalhu tablak eldobasa
$tables = mysql_list_tables("ujdrupalhu", $conn);
while ($r = mysql_fetch_row($tables)) {
mysql_query("DROP TABLE ujdrupalhu.$r[0]", $conn);
}
?>

Az első fontos pont, hogy nem a Drupal rendszer adatbázis műveleteit használjuk, hiszen ahhoz be kellene tölteni a Drupal alaprendszert, ami viszont egy aktuális adatbázis sémát feltételez, és éppen ez az, ami még nem áll rendelkezésünkre. Így magunkra vagyunk utalva. Annyit teszünk, hogy az új adatbázishoz csatlakozva eldobjuk annak minden tábláját (egy korábbi klónozás eredményét), és felkészülünk az újabb klónozásra.

// Drupalhu klonozas
$tables = mysql_list_tables("drupalhu", $conn);
while ($r = mysql_fetch_row($tables)) {
$c = mysql_fetch_row(mysql_query("SHOW CREATE TABLE drupalhu.$r[0]", $conn));
mysql_query(preg_replace("!CREATE TABLE `([^`]+)`!", "CREATE TABLE ujdrupalhu.\\1", $c[1]), $conn);
mysql_query("INSERT INTO ujdrupalhu.$r[0] SELECT * FROM drupalhu.$r[0]", $conn);
}
?>

Ezekután nincs mit tenni, mint egyenként venni a drupalhu adatbázis tábláit, a CREATE TABLE utasításukat lemásolni, az ujdrupalhu adatbázisban felhasználva lefutattni, majd az adatokat átmenteni. Ez természetesen azért lehetséges, mert olvasási jogot kapott az ujuser felhasználó a korábbi drupalhu adatbázisra. Ott más jogosultságra nincs szüksége, és nem is szabad adni neki, nehogy a frissítés negatívan érintse a meglévő rendszert.

Mivel elkészült a korábbi adatbázis másolata, akár rögtön neki is állhatunk az update.php futtatásának, mi azonban kihasználva a PHP nyújtotta lehetőségeket, még a fent említett adat eldobásokról is gondoskodunk, elmozgatva a felesleges adatokat, amik csak meghosszabbítanák a frissítést.

// Felesleges dolgok az adatbazisban
mysql_query("DELETE FROM ujdrupalhu.cache", $conn);
mysql_query("DELETE FROM ujdrupalhu.locales_source", $conn);
mysql_query("DELETE FROM ujdrupalhu.locales_target", $conn);
// Korabban hasznalt, de mar nem alkalmazott modulok torlese
mysql_query("DELETE FROM ujdrupalhu.system WHERE name in ('weblink', 'trstatus')", $conn);
// A simplelinks a weblink helyettesitoje
mysql_query("INSERT INTO ujdrupalhu.system (filename, name, type, status)
VALUES ('modules/simplelinks/simplelinks.module', 'simplelinks', 'module', 1)", $conn);
?>

Ugyanitt lehetőségünk van azoknak a módosításoknak a végrehajtására is, amiket a frissítés után a webes felületen amúgyis végrehajtottunk volna. Például az előző részben leírtak szerint új saját fejlesztésű simplelinks.module helyettesíti a korábbi weblink modul funkcionalitását, így a weblink bejegyzését töröljük, a simplelinks bejegyzését viszont hozzáadjuk az adatbázishoz. Ehhez hasonlóan bármilyen előkészítő lépést megtehetünk.

Mindez természetesen nem lenne szükségszerű, ha a folyamatosan alakított és frissített Drupal illetve modul forráskódok miatt nem kellene rendszeresen újra futtatnunk a frissítést. Így viszont a folyamat automatizálása jelentősen könnyítette az életünket. Maga a frissítés természetesen már az update.php betöltésével kényelmesen elvégezhető.

Drupal.hu specialitás: a kódolások visszavágnak

Még egy momentum okozott számunkra fejfájást. A drupal.hu mögött álló adatbázis tábláinak szöveges mezői történelmi okok miatt (eléggé helytelenül) iso-8859-2 kódolásúra vannak állítva a MySQL számára. Ez nem okoz különösebben gondot a napi működésben, ilyen adatbázisban is tud a MySQL UTF-8-as adatokat tárolni. A 4.7.0 frissítése azonban a szöveges mezők típusát kifejezetten UTF-8 beállításúra próbálja állítani. Ez nem is lenne gond, ha a kapcsolat kódolását már a konverzió előtt az első pillanattól nem UTF-8-ra állítaná a rendszer. Így viszont az iso-8859-2 kódolású mezőket átvezetve ezen a kapcsolaton olyan karaktersorozatokat kap a PHP, melyeket a Drupal által előszeretettel használt unserialize() nem tud kibontani (nem annyi karakter van ugyanis a kódolás váltás miatt a karaktersorozatban, mint amit az unserialize() elvárna). Ez nem teszi lehetővé a frissítés lefutását, menetközben végtelen ciklusba kerül (körülbelül 70%-os frissítettségnél).

A probléma megoldása egyszerűbb, mint amilyennek a gond leírása hangzott. Egyszerűen nem alkalmazunk UTF-8 alapú kapcsolatot addig, amíg nem olyan formában állnak rendelkezésre az adatok. Ehhez a database.mysql.inc fájlban a 84-86. sorban a következő módosított változatot használjuk:

if (version_compare(mysql_get_server_info(), '4.1.0', '>=') && !function_exists('update_sql')) {
mysql_query('SET NAMES "utf8"', $connection);
}
?>

Az update_sql csak az update.php által betöltött oldalon létezik, így a frissítés során nem lesz aktív ez a kapcsolat kódolás beállítás, csak később. Ehhez még hozzá kell vennünk egy cache tábla eldobást a frissítési oldalak végén, különben előfordulhat, hogy olyan gyorsítótár állapot marad meg az adatbázisunkban, ami az új kódolásnak nem megfelelő (az unserialize() által használt formátum miatt). Ezért beillesztettük még az alábbi sort a Drupal update.php kódjának végére:

db_query("DELETE FROM {cache}");
?>

Hogy erre a két módosításra szüksége van-e más magyar Drupal webhely működtetőknek, az azon múlik, hogy a frissítés enélkül is sikeresen lefut-e, azaz hogy milyen adatbázis struktúra volt a korábbi adatbázisban. Az mindenesetre fontos, hogy a majdani későbbi frissítések már helyes kódolással fussanak le, tehát az első kis változtatást a későbbiekben már nem szabad a rendszerben hagyni.

Frissíteni könnyű

Akár a hivatalos verziót követjük, akár a klónozásos párhuzamos tesztelést, a megfelelő előkészítő lépések megtétele után a frissítés könnyedén le tud futni. Ha mégis probléma lenne a frissítéssel, akkor a drupal.org hibajelentőjében lehet részletes hibajelentéssel élni, mely javítása esetén egy remélhetőleg még jobban használható frissítési folyamathoz vezet a jövőben.

Hozzászólások

ninja képe

nálam az adatbázis tábláinak szöveges mezői latin1-re voltak állítva, a 4.6-os drupal hiba nélkül megjelenítette a karaktereket. az update script lefuttatása után viszont szétestek a karakterek, kb így nézett ki az oldal.

ha nálad is hasonló a probléma akkor itt van egy megoldás az adatbázis konvertálásához.

http://alleycat.hu

müzso képe

Nálam is hasonló eredményt produkált a 4.6-ról 4.7-re frissítés, viszont a drupal.org-on keresgélve nem találtam meg az említett megoldást (valójában a fórumon kb. minden ember valami mást javasolt :-(). Ehelyett egy nagyon béna és tákolós/favágós módszerhez folyamodtam: készítettem az adatbázisról egy dump-ot, majd ezt OpenOffice-ban (ami képes az UTF8-as kódolású fájlokat kezelni) megnyitottam és a kriksz-krakszokat search&replace módszerrel kicseréltem a megfelelő ékezetes karakterekre. Nincs olyan sok ékezetes karakterünk, szóval ez viszonylag értelmes időn belül végrehajtható. Ezután eldobtam az összes táblát és beimportáltam a módosított dumpot. Voálá ... ismét minden karakter szép és jó lett. :-) Persze nem ment elsőre ... kb. harmadik nekifutásra sikerült a dump-ot megfelelően kijavítani, mivel a kriksz-krakszok között voltak olyan párok, ahol az egyik prefixe a másiknak ... :->

yaanno képe

Nos, ő mondta, hogy egy bonyolult problémára nincs egyszerű megoldás. Mindenesetre találtam egy jó írást ezügyben itt.

yaanno képe

Jómagam is elbénáztam a drupal telepítésekor egy ízben a karakterkódolást, így most 2 napomba tellt, amíg rá tudtam venni a rendszert az utf8-ra. 4.6-os lévén különösen hasznos volt egy mentőötlet, vagyis az e sorozathoz "rendszeresített", Jeremy Andrews által jegyzett Database Administration modul, amely nem igényel önálló adatbázistáblákat, viszont lehet vele dumpolni stb.
Ez utóbbira volt nekem szükségem, ugyanis a db-om latin1 kódolású volt, ami önmagában nem zavarta a drupalt, csak éppen dump esetén összekavarodott a latin1 és az utf8 kódolás. Ezzel a kis modullal sikerült megfelelő dumpot készíteni.

A fejlesztő maga is felhívja a figyelmet egy (a modultól független) biztonsági résre, tehát hosszú távra más megoldás javallott.

yaanno képe

ingola kérdezte mailban, hogy nálam hogyan működött a DBA modullal jelzett megoldás, de leírom ide lépésenként, hátha valaki tudja hasznosítani.

Mivel localhoston (php5 és mysql5) akartam fejleszteni, plusz meg akartam tartani mindent (indexek stb., bár erre alapesetben nincs szükség) ezért:

1. létrehoztam két db-t: site_backup és site_backup_clone néven, utóbbit csak azért hogy ne kelljen újraimportálni a teljes backupot, ha valami félresikerülne; fontos, hogy a localhoston létrehozott db-ok alap kódolása megegyezzen a szerveren lévővel, különben már ezen a ponton bekavarunk a kódolásnak! a SET NAMES később úgyis 'konvertálja' a táblákat.

pl:

CREATE DATABASE site_backup DEFAULT CHARACTER SET latin1;
CREATE DATABASE site_backup_clone DEFAULT CHARACTER SET latin1;

2. a modullal csináltam egy full backupot, indexekkel stb., de ez opcionális

3. nyers drupal install (4.7.3 pillanatnyilag)

4. settings.php -> site_backup

$db_url = 'mysql://user:jelszo@localhost/site_backup';
$db_prefix = '';

5. database.mysql.inc -> 85. sor kommentelése

  if (version_compare(mysql_get_server_info(), '4.1.0', '>=')) {
   // mysql_query('SET NAMES "utf8"', $connection);
  }

6. update.php -> check_access() = FALSE, majd az update futtatása
(Megj: az update során nálam mindig hibát dob ki a node-ok esetén, ugyanis két darab primary keyt akar létrehozni, ez manuálisan orvosolható.)

7. update után a database.mysql.inc kommentjét ki kell venni.

8. ha esetleg karakterkódolási zűrzavar látszódik, érdemes ellenőrizni, hogy nem maradt-e a cache-ban valami - ürítsük ki, vagy amint a cikkben is volt, eleve hagyjuk ki a játékból.

eMeLA képe

Nagyon szép és jó ez a leírás, de lehetne egy kicsit szájbarágósabb is a biztonsági frissítés leírása.
Ha jól gondolom akkor egyszerüen a régi fájlokat kell az újakkal felülírni (esetemben 4.7.1->4.7.2).
Ezt csak azért írom le mert egy kezdő számára nem biztos, hogy egyértelmű, hogy mit is kellene tenni.
Kérek visszajelzést, hogy jól gondolom-e !

...mit tudok: http://web.termuves.hu

Hojtsy Gábor képe

Ez egy konkrét leírás a Drupal.hu 4.5-ről 4.7-re frissítéséről, és ennek tapasztalatairól. A biztonsági frissítést illetően viszont ugyanúgy irányadó lehet. Ezt írtam:

A következő lépés egy friss üres Drupal 4.7.0 telepítése, mely alá a gyárilag szállított MySQL adatbázis helyett a mentett adatbázisunkat töltsük fel. Ezután az index.php betöltése helyett az update.php oldalt hívjuk be.

Én nem felülírom a fájlokat, hanem telepítek egy új Drupal-t (bemásolom a fájlokat egy mappába, beállítom a settings.php-t a webhelyhez), és az adatbázis mentés után vagy az eredeti adatbázist állítom be az új kódnak, vagy egy új másolatot. A "felülírom a fájlokat" elképzeléssel az a probléma, hogy közte bentmaradhat valami szemét, ami már nem kell.

ingola képe

van egy 4.6 -os oldal http://okoturizmus.hu amit szeretnék 4.7-re "frissíteni". a gond az, hogy egy szerveroldali "elszállás" után az adatbázist visszarakó szolgáltató kavart valamit, úgyhogy jelenleg olvashatatlan karaktereket és latin1-swedish egybevetést látok aza adatbázisban

egy kis részlet az adatbázisból: ross-motoros rend??rj??r??r??k kezdt??k meg a szolg??latukat szerd??n a
Bakonyban: els??sorban Zirc, Olaszfalu, Epl??ny, Veszpr??m ??s V??rpalota

amúgy az oldal ehlyesen jelenik meg most, de frisstíésnél nem. kértem a szolgáltatót csináljon valamit, és valamit csinált is mert vannak jól megjelenő dolgok a tesztoldalon, de általában nem jók a karakterek (pl külső rss csatornák tartalmai a blokkban) és az adatbázis továbbra is olvashatatlan: http://eco.okoturizmus.hu

sajnos nem értek hozzá (bocs ha rossz kifejezéseket használtam) ha tud valaki segíteni, kérem tegye meg. köszi

http://magosfa.hu

yaanno képe

Nem működött? Kiürítetted a cachet? Regeltem nálad és láttam hogy a menük és a rendszerüzenetek jól jelennek meg, viszont nem lehet tartalmat elérni. Próbáld meg a cache ürítését mindenképpen! ha van phpmyadminod, azzal igen egyszerűen meg tudod tenni.

ingola képe

nekem belépettként bejön a tartalom, vendégként semmi (pedig be kéne) a kézikönyvek menü (ha bejön) ugyancsak rossz karakterekkel jön be. valószeg van jóbnéhány hiba az oldalon, de amíg rossz karakterekkel van meg az adatbázis addig nem akarom pofozgatni
lehet hogy a tákolgatós megoldás lesz:

ingola képe

rossz karaktereket kicseréltem (find-change), feltöltöttem az adatbázist, update, ha be vagyok lépve minden látszik és ok, de ha más lép be vagy vendég látogat nem jelenik meg a tartalom
nem tudom mi lehet?

ja és a cache-t is ürítgetem

ingola képe

a vendég és regisztrált felhasználók.
de ugye ezt én nem akarom : )

böngészek a drupal.org-on is de nam találoma megoldást

ingola képe

és egyszerűbb, mint azt gondolnánk:

http://drupal.org/node/59080#comment-168578

magyarul og-t be kell kapcsolni ha van!

Atyla képe

Nem tudom mennyien használnak még 4-es verziót, de a többség biztos, hogy már 6-ost használ. Na most ha idejön egy kezdő, aki tényleg azt se tudja mi merre, akkor egy régi, sok szempontból butább verzió frissítését olvassa el, miközben ő biztos a 6-os verzióval kezd, amiben rengeteg minden máshogy van.

Én szívesen megírnám a 6-os verzióval kapcsolatos tudnivalókat, de annyira még nem vagyok jó Drupalban, hogy bevállalhatnám.

Egy szó mint száz: a Drupal 4-es verziója ha jól tudom már vagy 5 évvel ezelőtt készült. Azért az már nem ma volt...

aboros képe

Én szívesen megírnám a 6-os verzióval kapcsolatos tudnivalókat,

ha nagyon ráérnék én is megírnám, elhiheted. meg vannak még páran akik így vannak ezzel. mindazonáltal minden lépés hibátlanul le van írva minden verzióban megtalálható UPGRADE.TXT állományban.

de annyira még nem vagyok jó Drupalban, hogy bevállalhatnám.

ne légy ilyen kishitű. frissíts, írd meg hogy ment. ha véletlenül valamit nem jól csináltál, majd úgyis kijavítja aki tudja, hol hibáztál. mindenki nyer. lesz egy új leírásunk és te is bizonyosságot nyerhetsz, hogy mennyire jó vagy.

hajrá.

-
clear: both;

Atyla képe

Rendben, most a 6.19-es verziót használom, a következő frissítés amikor megcsinálom, le fogom írni, hogyan, de ez csak egy egyszerű felhasználói leírás lesz, semmi extra, mivel még nem tudok programozni, éppen egy jó könyvet keresek, ami alapról indul...

Nagy Gusztáv képe

Esetleg ez megfelel?

http://drupal.hu/node/11046

Nagy Gusztáv