Anomália: Drush nem talál egy új modulkiadást

Robert Petras képe

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:

  1. ------- RELEASES FOR 'XMLSITEMAP' PROJECT -------
  2. Release Dátum Állapot
  3. 7.x-2.x-dev 2012-Dec-08 Development
  4. 7.x-2.0-rc2 2012-Dec-08 Supported, Recommended
  5. 7.x-2.0-rc1 2011-Dec-16 Telepített

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.")

Melyik modulhoz, modulokhoz kapcsolódik a téma?: 
Drupal verzió: 
Sk8erPeter képe

drush cc drush
ilyen 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 --select
ekkor 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 -y
parancsot, é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.

1
0
Robert Petras képe

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ési opciót Drush alatt manipulálni: http://mark.shropshires.net/blog/list-all-projects-available-updates-using-drush

0
0
Sk8erPeter képe

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. :)

1
0
Robert Petras képe

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.

0
0
Sk8erPeter képe

"A Drush "dl" és az "up" között pedig szerintem biztos van valami különbség bizonyos esetekben"

Igen, van különbség, példa:

drush dl xmlsitemap --select
megmondod, konkrétan melyik változatot szeretnéd letölteni, ami lehet akár dev is

drush dl xmlsitemap
simá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 xmlsitemap
sajnos - 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:
drush up xmlsitemap

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).

1
0
Robert Petras képe

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.

0
0
Sk8erPeter képe

Szívesen, örülök, ha segítettem!


"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."

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:

  1. Core drush commands: (core)
  2. [...]
  3. updatedb (updb) Apply any database updates required (as with running update.php).
  4. [...]
  5.  
  6. [...]
  7.  
  8. Project manager commands: (pm)
  9. pm-disable (dis) Disable one or more extensions (modules or themes).
  10. pm-download (dl) Download projects from drupal.org or other sources.
  11. pm-enable (en) Enable one or more extensions (modules or themes).
  12. pm-info (pmi) Show detailed info for one or more extensions (modules or themes).
  13. pm-list (pml) Show a list of available extensions (modules and themes).
  14. pm-refresh (rf) Refresh update status information.
  15. pm-releasenotes Print release notes for given projects.
  16. (rln)
  17. pm-releases (rl) Print release information for given projects.
  18. pm-uninstall Uninstall one or more modules.
  19. pm-update (up) Update Drupal core and contrib projects and apply any pending database updates (Same as pm-updatecode + updatedb).
  20. pm-updatecode (upc) Update Drupal core and contrib projects to latest recommended releases.

Szóval a lényeg, hogy

  • upc
    a core és kiegészítő modulok release-eit frissíted
  • up == pm-updatecode + updatedb
    a core és kiegészítő modulok release-eit frissíted ÉS végrehajtasz minden adatbázis-frissítést

tehát az up a 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.exe megfogja), 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. :)

1
0
Robert Petras képe

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...

  1. Code updates will be made to the following projects: XML sitemap [xmlsitemap-7.x-2.0-rc2]
  2. Note: A backup of your project will be stored to backups directory if it is not managed by a supported version control system.
  3. Note: If you have made any modifications to any file that belongs to one of these projects, you will have to migrate those modifications after updating.
  4. Do you really want to continue with the update process? (y/n): y
  5. Project xmlsitemap was updated successfully. Installed version is now 7.x-2.0-rc2.
  6. Backups were saved into the directory...

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.

0
0
Sk8erPeter képe

"Jó lenne tudni, hogy miképp lehetne ebből visszaállítani a modul korábbi állapotát [...] de ahogy megnéztem ezt a backup mappát, a modul fájlait látom itt, úgyhogy elég lenne csak visszamásolni."

Igazából Te magad írtad le a megoldást, mert ennyi a sztori. :D


"kaptam SSH használati engedélyt"

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).

1
0
segi képe

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.

1
0

Drupal developer at Cheppers

Robert Petras képe

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!

0
0
Sk8erPeter képe

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:

  1. All commands in features: (features)
  2. features-add (fa) Add a component to a feature module. (DEPRECATED: use features-export)
  3. features-components List features components.
  4. (fc)
  5. features-diff (fd) Show the difference between the default and overridden state of a feature.
  6. features-export (fe) Export a feature from your site into a module.
  7. features-list (fl, List all the available features for your site.
  8. features)
  9. features-revert (fr) Revert a feature module on your site.
  10. features-revert-all Revert all enabled feature module on your site.
  11. (fr-all, fra)
  12. features-update (fu) Update a feature module on your site.
  13. features-update-all Update all feature modules on your site.
  14. (fu-all, fua)

Tehát elvileg a drush fr ezt csinálja:

  1. features-revert (fr) Revert a feature module on your site.

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?

0
0
Robert Petras képe

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:

  1. pm-refresh
  2. Refresh update status information.
  3.  
  4. Aliases: rf

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.

0
0
Sk8erPeter képe

na az lehet, hogy felcserélte a betűket :D nekem ez nem jutott eszembe.
De akkor sem az én hibám! :D

0
0
segi képe

bocsi igen ezt benéztem, nyilván rf(pm-refresh). Még 1x bocs :)!

0
0

Drupal developer at Cheppers

Sk8erPeter képe

No para, így már tisztázódott :) Nekem meg hirtelen nem jutott eszembe, hogy van rf is, bár ezt nem is nagyon használom :)

0
0