Amióta végignéztem a Bevezetés a Drush használatába videósorozatot (kudos: zionduc) és aktívan elkezdtem használni a Drush-t cli környezetben, sokkal hatékonyabban és gyorsabban tudom karbantartani az általam üzemeltetett Drupal weblapokat. Ma belefutottam azonban egy bosszantó kis dologba, amiért a segítségeteket kérem.
A ma reggeli postaládában több értesítőt kaptam arról, hogy megjelent az XML Sitemap modul egy új kiadása. Ahogy szoktam nekiálltam frissíteni a weblapkat a Drush-t használva. A teljesség igénye nélkül a következő frissítési folyamatokat használom weblapról-weblapra a teljesség igénye nélkül:
1. "drush upc" első használata csak azért, hogy lássam, hogy milyen frissítések érhetőek el. magát a folyamatot nem engedélyezem egyenlőre.
2. "drush rl xmlsitemap" illetve a "drush rln xmlsitemap" alapján megnézem, hogy mit tartalmaz az új modul kiadás és hogy mire kell ügyelnem a telepítés során
3. "drush vset drush vset maintenance_mode 1/0" használatával karbantartó módba vagy ismét aktív állapotba pakolom a weblapot mikor mi kell.
4. "drush bb" -vel készítek egy biztonsági mentést az adatbázisról
5. "drush upc -y" és elindítom a kombinált modul és adatbázis frissítést
6. ha kell cache törlés, cron futtatás, stb.
Habár hosszúnak tűnik a lista, a valóságban azonban 3-4 perc alatt végig tudtam menni az összes weblapon elérhető modul frissítésen anélkül, hogy használnám a böngészőt és ki/be kellene jelentkeznem a weblapok admin felületén és kattintgatással kellene a fentieket egyenkét elvégeznem.
Most is így tettem és pikk-pakk végeztem a modulfrissítéssel az összes weblapon egyet kivéve. Itt az történt ugyanis, hogy a "drush upc" szerint nem volt elérhető frissítés ("No code updates available.").
Teljesen kibuktam, mert ugyanazon a szerver környezetben, ugyanazt a legfrissebb Drupal core kiadást és majdhogynem teljesen megegyező modul infrastruktúrával rendelkező több weblapon korábban már sikeresen frissítettem a XML Sitemap modult percekkel megelőzően.
A "drush rl xmlsitemap" a következőket dobta ki ezután:
A "drush upc" mégsem látta és a "drush up xmlsitemap" sem reagált semmit, mikor irányítottan szerettem volna frissíteni a modult?
Eztután nem tehettem más, minthogy megnéztem a weblap admin panelján, hogy megtalálja-e a frissítés az új modulkiadást. És igen, csak ezen keresztül sikerült frissítenem a modult, de miért?
Miért nem találta meg a Drush project manager az új kiadást és miért nem működött a "drush up xmlsitemap" közvetlen parancs?
Valakinek van valamilyen ötlete erre vonatkozóan? Belefutottatok már hasonló esetbe és ha igen, akkor milyen megoldást találatok?
Tudom, hogy a topik cím nem pontos, mert végtére is a Drush látta az új kiadást a Drupal.org fájlszerveren, de mégsem hívta le magának ezt a "pm-updatecode".
Kicsit furcsa kiegészítés az egészhez, hogy ettől a weblaptól még nem kaptam frissítési értesítőt, nem tudom, hogy ennek van-e valamilyen jelentősége, mert általában nem egyszerre érkeznek a levelek. Ebben az esetben pedig úgy voltam, hogy elébe megyek a modulfrissítésnek és nem várom meg az értesítőt.
Segítsetek ha tudtok! Köszönöm!
Ui: közben belefutottam a Drush dokumentum oldalán a "drush pm-refresh" parancsba, de csak miután már a böngésző ablakban frissítettem a modult + nem is nagyon tudom, hogy a kurtafarkú leírás után segített-e volna ez egyáltalán vagy sem ("Refresh update status information.")
drush dl xmlsitemap --select
drush cc drushilyen is van, ha a Drush cache-ét szeretnéd törölni. De lehet, hogy semmi köze hozzá. :D
Amúgy én simán ezzel szoktam mindent update-elni (core-t is viszi, ha megjelent új):
drush up -yŐszintén szólva fogalmam sincs, miért jött elő, hogy épp ez a modul nem frissült, de annyira nem tragikus a dolog, akkor manuálisan is letöltheted a megfelelő változatot:
drush dl xmlsitemap --selectekkor megkérdezi, melyik változatot akarod letölteni, bepötyögöd a megfelelő számot, aztán megkérdezi, felülírod-e az aktuális telepített változatot, azt mondod, igen, majd nyomatsz egy
drush updatedb -yparancsot, és kész.
Az értesítést pedig ki lehet kapcsolni itt:
admin/reports/updates/settings☑ Check for updates of disabled modules and themes
nézd meg, nincs-e itt kiszedve a pipa az említett oldaladnál.
Köszönöm a válaszod!
Számos hasznos ötletet kaptam tőled, olyat is amit már ismertem, de van köztük olyan is amit eddig nem használtam. Egyszerűbb moduloknál szerintem sem lehet gond ha mondjuk felülírjuk a meglévő modul fájlokat. Komplexebb moduloknál azonban nem tudom, hogy jó ötlet ez. Ezt még le szeretném tesztelni lokális környezetben, mielőtt ehhez folyamodnék.
Mint a bors az orrom alatt, annyira bosszantott ez a kis dolog, hogy időközben teljesen áttanulmányoztam a Drush project manager parancssorok dokumentációját.
Amúgy a modul aktív volt, ezért mindenképpen meg kellett volna találni a Drush-nak az új kiadást. Képzeld, közben azt is megtaláltam, hogy miként lehet ezt az
értesítésiopciót Drush alatt manipulálni: http://mark.shropshires.net/blog/list-all-projects-available-updates-using-drushEzt az update_check_disabled
Ezt az update_check_disabled variable-t még nem ismertem, de ennek nem sok köze van az e-mailes update-értesítésekhez :)
idézem:
"I especially need to see ALL projects, both enabled and disabled, since a distribution user may decide to turn on a project which isn’t enabled by default."
szóval a lényeg röviden, hogy a letiltott modulokra is csekkolja a frissítést, pedig alapból nem tenné (csak enabled állapotban lévőkre)
"Egyszerűbb moduloknál szerintem sem lehet gond ha mondjuk felülírjuk a meglévő modul fájlokat. Komplexebb moduloknál azonban nem tudom, hogy jó ötlet ez."
Ezt igazából nem értettem. Ugyanezt csinálja az a módszer is, amit eddig csináltál, hogy admin-felületen kattintgattad össze, hogy frissítse a modult. :) Letölti tmp-be a modul cuccait, aztán ha rámész, hogy frissítse, akkor kicseréli a korábbiakat az új fájlokra! Éppen ezért, ha eme folyamat során hiba történik (például jogosultsági probléma vagy lock, amibe én már belefutottam IIS esetén), akkor akár inkonzisztens állapotba is kerülhet ez a könyvtár, tehát lehet, hogy nem töltődik le minden fájl, vagy épp üres marad, mert nem sikerült kicserélni a fájlokat... már volt sajnos ilyenben részem, ekkor manuálisan kell felmásolni a fájlokat, a hibát javítandó.
Tehát amit javasoltam, ugyanazt csinálja Drush-on keresztül, mint ami történik amúgy is. :)
A drush up -y használatakor is az történik, hogy készít egy backupot a modulok korábbi állapotáról, hogy azért a régi is meglegyen, és egyszerűen az új példányt bemásolja a régi helyére, aztán nyomat még egy adatbázis-update-et is. Szóval semmi mágikus dolog nem történik, csak manuálisan kényelmetlen folyamatokat automatizál a Drush. :)
Mea culpa: nagyon elírtam valamit
Igazad van, nem az levélbeni értesítésről szól a változó, hanam az inaktív modulok frissítésének vagy a frissítés mellőzésének figyeléséről. Egy kicsit fáradt vagyok val'szeg, mert ettől föggetlenül pontosan tudtam, hogy mit csinál ez a dolog.
A Drush "dl" és az "up" között pedig szerintem biztos van valami különbség bizonyos esetekben, bár ennyire nem vágom ezt a dolgot. Ha egy mód van rá, akkor inkább ragaszkodnék az "up" használatához. Amikor le kell tölteni valami új modult akkor a "dl", amikor frissíteni kell egy már meglévő modult, akkor az "up" parancsokat használom. Ilyen egyszerű vagyok én is... :D
Nem tudom pontosan megmondani, hogy ez most miért jobb, de pl. amikor klikkelgetve intéztem anno az ehhez hasonló ügyeket a weblapon, akkor is kerültem valamiért a "nyers" SFTP-n keresztül történő modul frissítést vagy manipulálást. Csak egyszer kellett így hozzányulnom egy modulhoz, akkor sem szivesen tettem valamiért.
Pont azért kérdeztelek meg, hogy mit tennél a helyemben, ha a Drush update nem talál egy létező új modul verziót.
Amúgy jó, hogy írsz, mert így legalább lehetőségem van mások workflow-ját megismerni, ebből tudok tanulni + a hiba megoldásán keresztül.
"A Drush "dl" és az "up"
Igen, van különbség, példa:
drush dl xmlsitemap --selectmegmondod, konkrétan melyik változatot szeretnéd letölteni, ami lehet akár dev is
drush dl xmlsitemapsimán letölti az xmlsitemap aktuális legfrissebb, lehetőleg stable (!!) változatát (ha van; ha nincs, akkor rc-re vagy beta-ra próbál; dev-et csak legutolsó esetben (ha csak az van) próbálja meg letölteni)
drush up xmlsitemapsajnos - eddigi próbáim alapján - ez működik az adott modulra, DE mégis az összes engedélyezett modulra végigfuttatja az update check-et, tök feleslegesen, DE csak a kijelölt modult (itt xmlsitemap) frissíti; most próbáltam konkrétan ezzel, és tényleg ez történt.
De hogy ne csak a szám járjon, itt a bizonyíték, nem ígéret:
amit fontos tudni erről, hogy ez csak az aktuális legfrissebb, lehetőleg stable változatra próbál frissíteni (aztán ha csak az van, rc, beta, dev).
Ezek az igazán lényeges különbségek, egyébként a Drupal sem csinál semmiféle mágiát a háttérben, a modulok definiálnak bizonyos update-változatokat, a Drupal pedig attól függően update-el, hogy egy adott modul éppen melyik változatnál tart; ennek megfelelően hívja meg a megfelelő hook_update_N-t:
http://api.drupal.org/api/drupal/modules!system!system.api.php/function/...
ebben megtörténik a megfelelő változatra történő frissítés, ha ezt kezdeményezi a júzer, amíg a szükséges adatbázis-frissítéseket az aktuális változatig el nem érte.
Itt egy példa:
file_entity_update_7002()
http://api.drupalhelp.net/api/media/file_entity--file_entity.install/fun...
Kérdezz, ha még valami felmerült, hátha tudok rá még válaszolni.
Mindenesetre a lényeg, hogy a drush dl használatával is nyugodtan frissíthetsz, amennyiben odafigyelsz, hogy valóban a jelenleg fent lévőhöz képest újabb változatot tölts le, aztán updatedb-vel frissíted az adatbázist, majd cache-t törölsz (drush cc all).
Nagyon alapos vagy
Köszi, most már kezdem érteni az azonosságot és a kölönbséget a két dolog között, mégha az parányi is. Tényleg jó a szemléltető képernyőkép amit küldtél. Hasznos!
Azt tudtam eddig is, hogy az "up" a modulok legfrissebb változatát húzza le, azt is, hogy az "upc" ennél továbbmegy és az adatbázist is frissíti + biztonsági mentést készít az adatbázisról.
Eddig még nem kellett éles környezetben használnom a "--select" verzió választót, de el tudom képzelni, hogy bizonyos esetekben ez nagyon hasznos lehet. Nagyjából 1 hónappal ezelőtt amikor a Drush használatát elkezdtem tanulni (vele együtt a parancssori felület használatát, terminal, ssh, stb) akkor használtam először és utoljára a " dl --select" kombót azért, hogy direkt egy-egy korábbi modul verziót töltsek le, hogy aztán frissíthessem a "up" parancs kiadásával.
Igazából igyekszem idafigyelni, hogy megnézzem a "rl" infót és a "rln" kiadási jegyzetet, mert nem akarok belefutni egy olyan dologba, hogy hirtelen egy modul "1.x" kiadásáról a "2.x" kiadásra telepítek úgy, hogy csak rutinból kiadom a "up" vagy most már az "dl" parancsokat és nem figyelek oda.
Köszi még 1x a segítségedet.
épp az "up" csinál többet, mint az "upc"! :)
Szívesen, örülök, ha segítettem!
Na várj, ezt rosszul tudod, most azért mielőtt blődséget kezdtem volna itt nagy hévvel terjeszteni, direkt beírtam a
drush help-et, és itt egyértelműen kiderül:Szóval a lényeg, hogy
upca core és kiegészítő modulok release-eit frissíted
up==pm-updatecode + updatedba core és kiegészítő modulok release-eit frissíted ÉS végrehajtasz minden adatbázis-frissítést
tehát az
upa bővebb kategória :)Éles környezetben amúgy én sem használom a Drush-t, csak osztott tárhelyen vannak Drupal-oldalaim, ott meg ugye nem kapok shell-t általában (csak pl. VPS-nél vagy saját szerveren). Amikor localhoston fejlesztek, akkor szinte már élni sem tudok Drush nélkül, iszonyatosan felgyorsítja a munkát.
Ez már kicsit OFF, de ha már localhost+Windows: annyira kell figyelnem nagyon, hogy IIS esetén lock-olódnak egy darabig a könyvtárak és fájlok (a
php-cgi.exemegfogja), amit az Unlocker progival kell feloldanom, és erre a problémára a mai napig nem érkezett megoldás Drupal Answers-ön, ahol még áprilisban tettem fel ezt a kérdést:http://drupal.stackexchange.com/questions/28093/iis-problem-with-drupal-...
IIS-sel igazából ez volt csak a lényeges problémám localhoston, más nem igazán zavart (mondjuk még annyi, hogy nincs rendesen konfigurálva, mert webszerverparák miatt sajnos pl. jPlayerrel bizonyos videók nem működnek, asszem request filterre hivatkozva, ezzel még nem volt kedvem szenvedni; plusz defaultból pl. a + karaktert tiltja az URL-ben, ami keresésnél para (pl. szóköz-helyettesítő, Views operátorok is használhatják), de ezt egy beállítással meg lehet változtatni).
Azt szoktam csinálni, hogy localhoston kipróbálok változtatásokat, a Drush-t aktívan használva, és update-elem az éles oldal fájljait, ha szükség van rá, és működnek is a módosításaim. Éles környezetben ugye nem tesztelgetünk. :)
Igazad van ezt csúnyán benéztem ;-(
Nálad a pont a "up" és az "upc" kapcsán, ezt nagyon benéztem, mikor azt írtam, hogy az "upc" adatbázist is ment. Úgy látszik, hogy lusta voltam elolvasni, hogy valójában milyen feedbak-et kapok a frissítés után...
Ahogy korábban már írtad nekem, tényleg készít egy backup-ot a modulról, amit a drush-backup mappába ment el alapértelmezett beállítással. Jó lenne tudni, hogy miképp lehetne ebből visszaállítani a modul korábbi állapotát hátha egyszer erre is sor kerül, de ez már egy másik sztori. Most nincs sok időm ezzel játszani, de ahogy megnéztem ezt a backup mappát, a modul fájlait látom itt, úgyhogy elég lenne csak visszamásolni.
Egyébként én éles környezetben is használom a Drush, mert kaptam SSH használati engedélyt. Szóval egy Drush hűbérúr igazgat több kissebb brossúra méretű weblapot. Az Ügyfeleim nem engedhetik meg, hogy saját szervert üzemeltessenek vagy virtuális szervert béreljenek ezért beérik az osztott tárhellyel. Gondolom, hogy sokan vannak ezzel így, a Sysadminok pegid a fejüket csóválják emiatt, mert tudják, hogy ez mennyie nem kóser.
"Jó lenne tudni, hogy miképp
Igazából Te magad írtad le a megoldást, mert ennyi a sztori. :D
na, az nem rossz, pedig osztott tárhelyen ez kevésbé jellemző :)
Én is használnám egyébként a Drush-t éles környezetben is, ha lenne rá lehetőségem, főleg core update-nél kissé kényelmesebb, mint aztán az éles oldal teljes kódját kicserélni az újra... ja, és mindezt backup után természetesen (hiszen backup mindenekelőtt, fájlokról és adatbázisról egyaránt).
Valószínűleg,
a drush fr parancs megoldotta volna a problémád, nekem múltkor az egyik oldal frissítésekor, konkrétan az újabb Drupal verziót nem látta.
Drupal developer at Cheppers
Legközelebb frissíteni fogom az állapotot ha szükséges
Köszönöm neked is a jótanácsot! Legközelebb élni fogok a "drush fr" parancs használatával. Azóta újabb más weblapkon futó modulokat kellett frissítenem és minden gond nélkül lezajlott a dolog.
Azért megjegyzem ezt a konkrét weblapot magamnak és figyelni fogom, hogy legközelebb is makrancoskodik a Drush alatta vagy sem.
Köszi még 1x!
Ez miért jó?
Ezt még sosem használtam, ezért megnéztem, mire jó ez, és megtaláltam a Features által biztosított Drush-parancsok között:
Tehát elvileg a drush fr ezt csinálja:
Ez miért oldotta volna meg Petrás Róbert problémáját, hogy az XML Sitemap modul frissebb változatát nem találta? Már a kapcsolódási pontot sem értem, de feltételezem, én nézek el valamit, meg tudod indokolni?
Huh, a Features-nek semmi köze ehhez
Ez nekem most nagyon új amit írtál. Én ezt a leírást találtam a Drush dokumentáció oldalán a "pm-refresh" alias "rf" parancsról:
Ennyire benéztem volna, hogy ez a parancs a Features-t támogatja? A parancs leírása nagyon kurtafarkú, ebből én nem ezt következtettem. Nekem az jött le, hogy ez a parancs szimplán frissíti egy-egy modul frissítési állapotát. A Features modult abszolút nem ismerem még.
Szerintem "segi" egyszerűen csak felcserélte a betüket, de én sem vettem egészen eddig észre, mert tudtam, hogy mire gondolt (a pm-refresh parancs rövidítésére). Szóval nem nagy ügy.
na az lehet, hogy felcserélte a betűket :D
na az lehet, hogy felcserélte a betűket :D nekem ez nem jutott eszembe.
De akkor sem az én hibám! :D
Yep,
bocsi igen ezt benéztem, nyilván rf(pm-refresh). Még 1x bocs :)!
Drupal developer at Cheppers
Nó para, nó fír
No para, így már tisztázódott :) Nekem meg hirtelen nem jutott eszembe, hogy van
rfis, bár ezt nem is nagyon használom :)