Modul

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

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:

Nos, a feladat adott, nézzük meg a megvalósítás menetét.

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

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.

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.

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

Ez a bejegyzés egy korábbi cikk folytatása, melyben egy TinyMCE plugin alapjait írtam le. A Soundcloud filter modulban társfejlesztő vagyok, így úgy gondoltam azon megyek végig, így egy gyakorlati példát mutatok.

A kiegészítő létrehoz egy menüpontot ami a popup forrása lesz, és JavaScript-tel kezel textfield és checkbox input-okat. Az input-ok alapján legenerálja a filter forrást, illetve felülírja ha már létezik.

Nemrégiben a következő problémát kellett megoldanom: CCK mezővel kellett kiegészítenem egy tartalomtípust, de nem használhattam az admin felületet.
Erre azért volt szükség, mert egy elég nagy multisite felépítésű rendszerbe kellett bedolgozni, és olyan mezőtípusokra volt szükség, amit a CCK teljes egészében meg tud valósítani. Hozzátenném, hogy a views modul integrációt sem kell ebben az esetben magunknak elkészíteni, így azt is egyből lehet használni.

Kitaláltam egy leegyszerűsített feladatot, de szerintem a példával teljesen meg lehet érteni a működését, és rá lehet jönni miket is lehet még így beállítani:

A page tartalomtípust egészítsük ki egy autocomplete node referencia mezővel, amelynek segítségével korlátlan stroy típusú node-ot csatolhatunk page tartalomhoz. A label legyen elrejtve és teaser és teljes nézetben se jelenjen meg a node-on a kiválasztott tartalom.

Egyik jó barátom megkért, hogy segítsek neki a diplomamunkájában, aminek része lesz többek között egy Drupal filter, amihez tartozna egy WYSIWYG kiegészítő is. Ez a bejegyzás, nem teljesen fogja kielégíteni az igényeit, mert csak az alapjait mutatom meg, de később lesz egy olyan cikkem is, amivel már konkrétan az Ő problémáját is meg lehet oldani.

Csináljunk egy teljesen értelmetlen modult, a modul leírása a következő:

A modul készítsen el egy WYSIWYG kiegészítőt a TinyMCE editorhoz, aminek segítségével el lehet helyezni a szerkesztőn egy gombot ami a kijelölt szöveget H2 elemmé alakítja át.

Nos ahogy említettem ennek tényleg nincs igazából értelme, de az alapokat megmutatja.

Én a saját készítésű modulokat a sites/all/modules/custom könyvtárba szoktam elhelyezni, a contrib modulokat pedig a sites/all/modules/contrib-ba. Igazából ez nem kötelező, de szerintem jó így elkülöníteni a letöltött és a saját fejlesztésű modulokat.

A modulok ugye az info fájlal kezdődnek, úgyhogy hozzuk létre a wysiwyg_h2.info fájlt, állítsuk be a wysiwyg modult függőségnek:

name = WYSIWYG H2
description = WYSIWYG H2
version = VERSION
core = 6.x
 
dependencies[] = wysiwyg

Most nézzük meg a modul fájlt, hozzuk létre a wysiwyg_h2.module fájlt:

A WYSIWYG editorok lényege, hogy a felhasználó HTML tudás nélkül is tudjon webes felületen formázni. Ezt úgy érjük el, hogy a html szöveget tartalmazó textarea-ra egy JavaScript szerkesztőfelületet adunk, ami a begépelt és formázott szöveget HTML kódokká alakítja át.

Drupal alá is létezik sok közkedvelt WYSIWYG editor modul, pl: FCK Editor vagy a TinyMCE Editor, melyek mindig előkelő helyen vannak a leggyakrabban letöltött Drupal modulok között.