A mai napon, (vagy még a tegnapin?) megjelentek a Drupal 4.7.x és 5.x újabb, biztonsági hiba javításokat tartalmazó verziói. A frissítés erősen ajánlott. Mivel fordítandó karaktersorok nem változtak, ezért az előző verziók fordításai használhatóak.
A csomagok letölthetőek a Drupal nemzetközi webhelyéről.
Hozzászólások
lehetőleg ne a patch -et használjuk
Ezt is tegyük hozzá, szerintem érdemes:
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Köszi
Eszembe se jutott, hogy valaki nem a teljes upgrade-t fogja választani.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
Mely elemeket nem kell ..
Illetve, nem szabad frisíteni. Légyszíves írjátok le. Nehogy szétüssem a rendszeremet.
Köszi előre is.
ML
A sites könyvtár
A sites könyvtár tartalmán kívül csak másold fel a fájlokat, a mostani javításhoz nem kell adatbázist sem frissteni, legalábbis 5.3 esetén. Bővebben lásd a megjegyzéseket itt: http://drupal.hu/hirek/20070727/drupal-5.2
Aries
http://aries.mindworks.hu
Modulok?
Az általad megadott linken az van, hogy a kikapcsolható modulokat ki kell kapcsolni - ez most is igaz? (Kicsit macerás lenne újraindíteni és ismét beállítani őket...)
nem kell ismét beállítani
Bekapcsolás után megtalálják az adatbázisban a korábbi beállításaikat (hacsak nem törölted őket).
Köszönöm!
Ez így már jobban hangzik :-)
kivéve
az olyan modulokat amik frankón letörlik az addigi dolgaikat az adatbázisból kikapcsolás során...
Az alap modulokkal nincs gond
Megcsináltam a frissítést és első ránézésre az általam használt modulok beállításai egyáltalán nem sérültek.
igen, de
de vad kikapcsolgatás előtt nem árt nézegetni a modulok .install filejaiban a hook_uninstall megvalósítást...
pl van egy már jó sok anyaggal feltöltött oldalad, jön az update, aztán kapcsold csak ki a jelenleg elég sokat használt és felkapott imagecache modult (igaz, ez contrib, de sose tudhatod)...
(drop table imagecache_preset, drop table imagecache_action, delete from sequences ...)
Ahhoz nem volt szerencsém
Illeve ezek szerint szerencsém volt, hogy azt a modult nem használom...
De a blokk modul, amitől a legjobban féltem, gond nélkül magához tért.
nem akkor fut le
A hook_uninstall() nem akkor fut le, amikor *kikapcsolod* (disable) a modult, hanem amikor *letelepíted* (uninstall). Előbbi a modul listában lévő jelölőnégyzetek állítgatásával könnyen működik. Utóbbihoz azonban külön leteletpítő oldalra kell menni, és kifejezetten kérni kell modulonként az adatok törlését. Szóval érdemes tudni, hogy itt mi hogyan működik, és máris kevesebb dolog miatt kell aggódni... (Ettől még készíteni kell biztonsági mentést frissítés előtt).
valóban
és tényleg...
hát akkor sorry a fölösleges pánik hangulat keltésért :), nem tudom miért így emlékeztem rá...
Ments az upgrade előtt!!
Mentsd el a fájlrendszert és az adatbázist mint mindig. így ha szétütöd a rendszert vissza tudsz álni.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
szép világ, jó világ
Egyre többször tapasztalom sajnos, hogy ez a "frissítés előtt mentsd le a fájlrendszert és az adatbázist" dolgot elég nehézkes megvalósítani. Nem tudom, kinek milyenek a technikai lehetőségei otthon/munkahelyén, de én itt egy elég "keskeny széles sávú" internetelérést használok. Ha frissítés előtt ftp -vel letöltöm a szolgáltatótól a fájlokat (mivel nincs mód a tömörítésre, ezért egyenként a sok kicsi fájl töltése amúgy sem leányálom), majd lementem a phpmyadmin -ból az adatbázist, az legalább húsz perc. Nos, ha ezek után valami gond van a frissítés során, akkor törlés után vissza kell tölteni mindent, ami a kimenő adatfolyam szűkösebb sávszélessége miatt nem áll meg háromnegyed óra alatt, de inkább több. És abbe még bele sem gondoltam, hogy mi van, ha a frissítéskor jelentkező probléma összetettebb (mondjuk valamelyik külső modul miatt), és ezért többször is szükséges az eredeti állapot visszatöltése a szerverre.
Vagy csak én látom úgy, hogy ez macera?
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
szegény ember vízzel főz.
Egy adatbázis dump és egy file mentés nem ilyen hosszadalmas ám, ha van egy normális szervered shell és backup szerver eléréssel ;)
Amíg nincs addig marad ez a macera. (esetleg megfűzni a szolgáltatót, hogy egy napi mentést tar.gz-vel tegyen számodra elérhetővé, hogy gyorsan tudj menteni, és akkor csak a visszaállítás lesz lassú ;)
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
szerver akadna
Távolról elérhető, mentéshez használható szerver-hozzáférésem van, shell és ftp eléréssel. Viszont a legtöbb szolgáltató phpmyadmin -t használ az adatbázis felhasználói kezeléséhez, és azt szinte lehetetlen links, lynx, és egyéb szöveges böngészőkkel használni (pl. most kipróbáltam, hogy importálok vele egy adatbázist, de bármilyen beállításokat próbáltam, és bármilyen formában kértem a mentést, mindenképpen megmutatta a tartalmát, és nem mentette le.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
man
man mysqldump
Aries
http://aries.mindworks.hu
nem mindig jó
Nem járható út, ha a szolgáltató nem adja meg az sql-szerver címét, hanem csak egy álnevet, amely "kívülről" természetesen már nem érvényes.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Akkor ideje
Akkor ideje váltani...
Aries
http://aries.mindworks.hu
Szerintem bőven elég az
Szerintem bőven elég az adatbázist menteni. Ez valóban hosszadalmas lehet, de írhatsz egy kis modult (lehet, hogy van is ilyen), amivel ezt lemented a files mappába és gond esetén visszatöltöd, így nem kell ftp-zgetned. Ugyanezt a fájlokkal is megteheted.
Aries
http://aries.mindworks.hu
http://drupal.org/project/bac
http://drupal.org/project/backup_migrate
Aries
http://aries.mindworks.hu