- május 2012 (1)
- január 2012 (1)
- július 2011 (1)
- május 2011 (1)
- február 2011 (1)
- január 2011 (3)
- december 2010 (2)
- november 2010 (2)
- október 2010 (3)
- szeptember 2010 (2)
- 1 / 2
- ››
Hosszu Kálmán Drupal fejlesztő és tanácsadó szakmai blogja
A Drupal 7 states és a checkbox click esemény
Két napi önostorozás után jöttem rá erre a kis furfangra a states-szel kapsolatban, úgyhogy lehet néhány fejlesztő kollégámnak hasznos lehet.
Az történt, hogy a Drupal 7-be beépített states-et használtam arra, hogy a form bizonyos elemei megjelenjenjenek és bizonyos mezők kötelezőek legyenek különböző checkbox-ok állásától függően. Ez eddig rendben is volt, erre való a states. Aztán ezeket a checkbox-okat el kellett rejteni és más elemek eseményeinél kellett szimulálni a checkbox-ok bekapcsolását.
Ekkor az egész összeomolott. Olyan volt mintha nem csináltam volna semmit, aminek meg kellett jelennie nem jelent meg, aminek kötelezőnek kellett volna lenni az nem volt az. Próbálkoztam mindennel, click eseményt futtattam, checked attribútumut változtattam, states event-et triggereltem, behavior-t attach-eltem stb...de semmi. Végül ma reggel végre sikerült megoldani a problémát, mégpedig egy aprócska kiegészítővel: a click eseményen kívül a change eseményt is triggerelni kellett:
Egy sima form betöltése Chaos tool suite (ctools) modal ablakba
Már régóta kacérkodok a gondolattal, hogy jó lenne valamit írni a Chaos tool suite (ctools) modulról is, mert egyrészt egy nagyon jó kis API modul - ha már csak azt megnézzük, hogy milyen kaliberű modulok építenek rá akkor gondolhatjuk, hogy nem rossz - másrészt pedig amilyen jó annyira nincs ledokumentálva a használhatósága, amolyan fekete lyuk a Drupal világában, meg amúgy sem tudtam aludni, akkor meg már forgolódás helyett inkább valami értelmes dolgot csinálok.
Igazából nagyon sokat lehetne róla írni, de szerintem kezdjük az alapokkal, én se őrülök meg mire megírom, Te sem alszol el mire elolvasod :)
Magyar Git Cheat Sheet
Már egy ideje írogatom magamnak azokat a git parancsokat és beállításokat, amiket érdemes megjegyezni és ha véletlen elfelejtenénk akkor jó ha megvan valahol leírva, ne kelljen keresgélni. Én az svn-ről szoktam át a git-re, ezért úgy gondolom azoknak akik hasonlóan cselekedtek - vagy cselekednek - különösen hasznos lehet egy ilyen gyűjtemény.
A leírás folyamatosan bűvülni fog és hamarosan elkészül hozzá a letölthető formátum is, amit szintén rendszeresen frissítek majd, ezért akit érdekel annak érdemes követnie twitter-en, mert ott fogom kommunikálni a változásokat.
Drupal 6-os smink portolása 7-es verzióra
Egy ideje nem volt időm foglalkozni a blogommal, de most már összeszedtem magam és dedikáltam időt erre is.
A téma amiről írni szeretnék számomra éppen aktuális, ugyanis a közelmúltban vágtam bele egy új projektbe, aminek a célja az, hogy egy olyan webáruházat készítsek ami prémium kategóriás Drupal sminkeket árul. Ennek hozománya, hogy első körben a drupal.org-ról letölthető ingyenes témák (Gordon, Ellington) készültek el, ezeket pedig elérhetővé tettem 6-os és 7-es verzióban is.
Mindezek fényében igazából elég végigmenni az egyik smink 6-os és 7-es verzióján és megnézni a különbségeket, de úgy gondolom hasznos lehet, ha pár, szerintem lényeges elemet kiemelek a kódkavalkádból.
Drupal 7 telepítési profil írása
A héten nekiálltam átnézni hogyan is lehet telepítési profilt készíteni a Drupal 7-es verziójához. Átnéztem az alapokat, aztán gondoltam, hogy írok egy gyakorlati feladatot amiben elég sok része érintve van a lehetőségeknek.
Ezért aztán a következő példát találtam ki:
Készíts egy telepítési profilt Drupal 7-hez, amely elvégzi a standard telepítési műveleteket, és azon kívül a következőket:
- létrehoz egy új felhasználó csoportot editor néven
- az editor csoport törölhesse, módosíthassa a saját tartalmait
- az editor csoport láthassa a saját nem publikus tartalmait
- az editor csoport tudjon létrehozni tartalmat
- létrehoz egy új beviteli formát WYSIWYG néven
- a WYSIWYG beviteli forma legyen engedélyezett az administrator és az editor csoportnak
- az 1-es user kerüljön bele az editor csoportba
- létrehoz egy új beállítási képernyőt ahol meg lehet adni, hogy generáljon-e tartalmat
- legyen egy lépés amiben kiválaszthatod hogy megjelenjen-e a következő lépés
- a feltételesen megjelenő lépés egy linkkel térjen vissza, amire kattintva az utolsó lépésre ugrik a telepítő
- legyen feltelepítve az admin menu, devel generate és a wysiwyg modul
- a nyelvválasztó lépés legyen kihagyva
- az install beállítási képernyőn a következő mezők legyenek alapból kitöltve:
- site name = server name
- site mail = egy email cím
- admin name = admin
- admin email = egy email cím
- az ország legyen Magyarország
- az email értesítő a frissítésekről legyen kikapcsolva
Nos, a feladat adott, nézzük meg a megvalósítás menetét.
Hogyan készítsünk Drush kompatibilis modult, vagyis CLI-ből elérhető Drupal funkciókat
Egy korábbi RSS modult továbbfejlesztve gondoltam érdekes lehet, ha leírom hogyan kell a benne lévő funkciókat elérhetővé tenni CLI-ből a Drush segítségével. Először azt hiszem egy pár sorban összefoglalnám mi is az a Drush és mire jó.
A Drush-ról
A Drush egy olyan eszköz a Drupal-hoz ami megkönnyíti a fejlesztők és a rendszergazdák dolgát azzal, hogy rengeteg Drupal funkciót elérhetünk parancssorból. Ezzel a folyamatokat automatizálhatjuk és különböző kérésekhez nem kell a weboldalon ügyködnünk.
Többek között olyan funkciókat lehet vele elérni mint
- cache törlés
- cron lefuttatása
- kereső indexelése
- php parancs vagy script fájl futtatása a Drupal környezetben
- változók betöltése, beállítása és törlése
- napló listázása, törlése
- modulok és sminkek bekapcsolása, kikapcsolása
- modulok és sminkek letöltése és telepítése
- Drupal core és contrib modulok, sminkek frissítése
- adatbázis-műveleteket futtathatunk
- felhasználói adminisztrációt végezhetünk
- stb.
Én úgy gondolom nagyon hasznos kiegészítés már akkor is ha csak a core műveleteket biztosítaná, úgy meg hogy saját modulunkkal is kiegészíthetjük pedig kifejezetten érdemes odafigyelni rá.
Egy egyszerű modul portolása Drupal 7-re
Most, hogy megjelent a Drupal 7-es verziójának hivatalos kiadása elérkezett az ideje, hogy szépen fokozatosan frissítsem a moduljaimat. Úgy gondoltam először egy elég egyszerűvel kezdek, pár sorban leírom a lényegét:
A modul a user agent alapján megnézi, hogy a felhasználó milyen böngészőt, platformot és operációs rendszert használ, majd a kapott eredményeket beteszi a body osztályai közé. Tartalmaz egy beállítási felületet ahol ki lehet választani, hogy mindig JavaScript segítségével tegye ezt meg, vagy csak akkor ha be van kapcsolva a page cache. Ha a JavaScript nélküli opció fut le, akkor a page.tpl.php-ból elérhető $body_classes változót egészíti ki.
NetBeans beállítása Drupal fejlesztéshez
A NetBeans egy platformfüggetlen JAVA alapú opensource fejlesztőkörnyezet (IDE), melyet eleinte JAVA fejlesztésre optimalizáltak, majd a különböző nyelvek elterjedésével bővítették tudását és mára kiválóan alkalmas Drupal modul- és sminkfejlesztésre is.
Én gyorsasága és refactoring tuljdonságain kívül azért ajánlom, mert nagyon könnyen beállíthatóak rajta a következő dolgok:
- Drupal Coding Standars-re formázza a kódot
- Felismerje a Drupal specifikus fájl típusokat is (info, module, install stb)
- A tab-oka space-szel helyettesítse
- Az új sorokat unix formátumban tárolja
- A fájlok karakterkódolása UTF-8 legyen
- Ismerje a Drupal core fgv-eket és kiegészítse a gépelésünk alapján (auto complete)
- A Drupal hook rendszer könnyen integrálható template-ként
- A CVS és a Git verziókezelők támogatása
A hook_node_operations() használata
Amikor élesítettem a factory rss modult az oldalamon, előjött a lustaság miszerint nem akarok minden node szerkesztőfelületén egyesével végigmenni és kiválasztani, hogy megjelenjenek az RSS csatornában. Ekkor jutott eszembe a hook_node_operations() ami pont erre való és olyan gyakran felejtik el a fejlesztők - köztük én is - használni.
Pedig fontosnak tartom, hogy az admin felület is kényelmesen használható legyen, a Drupal kezelőfelülete első ránézésre anélkül is elég ijesztő, hogy ilyen kényelmi funkciókat felejtenénk el belőle.
Úgyhogy most már beveszem a standard-jaim közé azt is, hogyha valamilyen node műveletet írunk, akkor az elérhető legyen ebben a formában is, így az adminisztrátor tömegesen is tudja kezelni a node-okon.
Saját tábla integrálása Views-ba Drupal-ban
Úgy gondoltam írok erről is egy rövid példát, hátha hasznos lesz valakinek. Persze tudom, hogy ott van a CCK és ha azzal módosítjuk a tartalomtípust akkor ezzel nem kell tödőni, de van egy-két eset amikor ez jól jöhet.
Az én esetemben például megbeszéltem a munkahelyemen, hogy az ottani blogba is aggregálunk majd pár hírt az oldalamról RSS segítségével. Ez szép és jó, de nem akarok majd minden bejegyzést megosztani ott is, és nem is feltétlenül kategóriától függ majd az ottani publikálás. Nálam nincs fent a CCK, mert semmire se használnám és csak ezért nem is akarom felrakni, a Views viszont fent van. Ha views fent van, akkor már szívesen készíteném el annak a segítségével az RSS csatornát. Így kénytelen leszek egy olyan modult csinálni, ami a blog típust kiegészíti egy checkbox-al, amit views-ba lehet használni.
- 1
- 2
- 3
- 4
- következő ›
- utolsó »