Jelenlegi hely
Új hozzászólás
Aki magas színvonalon dolgozik Drupallal, az megtanulta: használd újra, amit csak lehet! Hogyan lehet olyan jellemzőket (a Features modullal létrehozott feature modulokat) létrehozni, amelyek tartalmaznak mindent az újrahasznosíthatósághoz, és csak azt tartalmazzák?
Értem, ha látom: vegyünk egy konkrét példát! Adott egy „Page”/„Oldal” (gépi/emberi) nevű tartalomtípusunk, melyet szeretnénk egy másik webhelyen is felhasználni. Természetesen vigyük át az összes vonatkozó beállítást: a mezőket, azok megjelenítési módját, a hozzászólás-beállításokat, a szövegformátumokat, a képstílusokat, a jogosultságokat, a Pathauto beállításait – egyszóval a mindent.
A feature létrehozásakor megadtuk a kötelező elemeket: nevet és a programok által használt (gépi) nevet. Célszerű kitölteni a „Változat” mezőt is, hogy a feature esetleges későbbi frissítésekor tudjuk mihez tartani magunkat – ehhez mi a következő formát szoktuk használni: „7.x-1.0-20120420rc10”, ahol a „7.x” a mag főverziójával való kompatibilitást jelenti (mint általában a moduloknál mindig); az „1.0” arra utal, hogy ez a feature már használatban van olyan oldalon, amihez a megrendelő is hozzáfér (magyarán kvázi „éles”); a „20120420” az utolsó exportálás dátuma; az „rc10” pedig „kiadásra jelölt” állapotot jelent (bár a megrendelő már látja az eredményt egy fejlesztés alatt álló oldalon, de a nagyközönség számára még nem került ki az oldal – merthogy vannak még finomítanivalók rajta, amit az „rc” utáni szám is mutat).
So far so good, ahogy a művelt német senior drupal fejlesztő mondaná, de pontosan mit pakoljak bele a feature-be? Lássuk komponensenként.
Tartalomtípusok: node
Kezdjük logikusan az elején: tartalomtípust exportálunk, tegyük hát bele a feature-be – és reménykedjünk, hogy minden függőséget és beállítást automatikusan beletesz a rendszer. Nos, nem így történik: egy kis kézimunka még kell hozzá.
Mezők: field
Ideális esetben a feature-be pakolandó tartalomtípus mezőit a rendszer automatikusan felismeri a tartalomtípus kijelölésekor – előfordulhat azonban (pl. a feature, azaz a tartalomtípus későbbi újabb mezőkkel való bővítésekor), hogy néhány mező kimarad. A mezők listájában meglehetősen könnyen felismerhető „szemre”, mi tartozik hova: vegyük a „node-page-field_page_illustrations” mezőt: itt a „node” arra utal, hogy tartalomtípus-mezővel van dolgunk (és nem mondjuk taxonómiaszótár-mezővel, mert az „taxonomy_term” lenne; vagy tartalomtípus hozzászólásának mezőjével, mert az „comment” lenne); a „page” a tartalomtípus (gépi) neve; a „field_page_illustrations” pedig magának a mezőnek a neve. Általánosságban tehát elmondható, hogy entitástípus-mezőcsoport-mező (entity_type-bundle-field) alakú a mező itt felsorolt neve (kivéve persze a comment.module
esetén, mint annyi egyéb helyen is).
Teendő: az összes, az exportálni kívánt tartalomtípusunkhoz tartozó mezőnél ellenőrizzük, hogy a jobb oldali mezőlistában szerepel-e, s ha nem, akkor itt jelöljük be!
Képstílusok: image
Ideális esetben a rendszer felismeri, ha a tartalomtípusunk által szállított valamelyik mező kép típusú, és a használt képstílusokat is automatikusan hozzáadja a feature-höz. Természetesen előfordulhat itt is, hogy valami homokszem kerül a gépezetbe, ilyenkor a használt képstílusokat kézzel hozzá kell adnunk a feature-höz.
Mi a teendő, ha nem találom a képstílust, melyet valamely képmezőnél használni szeretnék? Valószínűleg újrahasznosítottál egy másik feature-ben, vagy az alaprendszerbeli image.module
-ban definiált képstílusokat. Erre csak az a megoldás, ha saját képstílusokat hozol létre.
Strongarm: variable
Bár lehet készíteni feature-t a Strongarm modul használata nélkül is, de nem érdemes: a Drupal hajlamos ugyanis változókban tárolni egy csomó beállítást – ezen változókat pedig a Strongarm teszi exportálhatóvá. A „page” tartalomtípus esetén mely változókat exportáljam? Az én trükköm az, hogy mivel ez a lista meglehetősen hosszú, a böngészőmbe épített keresővel kiemeltetem a „page” szöveget – így minden olyan változóval találkozni fogok, amely számomra érdekes lehet, és egyet sem hagyok ki. Nos, majdnem – lássunk tehát egy tipikus listát, az egyes változónevek jelentésével.
- additional_settings__active_tab_page: a tartalomtípus szerkesztésekor utoljára nyitva hagyott fül neve;
- comment_anonymous_page: névtelen látogató hozzászóláskor megadjon-e kapcsolati adatokat (hiszen a jogosultságok beállítására szolgáló oldalon ezt nem lehet tartalomtípusonként beállítani);
- comment_page: új tartalmak alapértelmezés szerinti hozzászólási beállítása;
- comment_default_mode_page: a hozzászólás válaszainak megjelenítése beágyazott listában beágyazott-e;
- comment_default_per_page_page: oldalankénti hozzászólások száma;
- comment_form_location_page: hozzászólás-űrlap elhelyezkedése;
- comment_preview_page: hozzászóláskor kell-e előnézet;
- comment_subject_field_page: legyen-e cím mezője a hozzászólásnak;
- language_content_type_page: több nyelv támogatott-e;
- menu_options_page: a tartalomszerkesztő űrlapon mely menükhöz lehessen a tartalmat menüpontként hozzáadni;
- menu_parent_page: alapértelmezett szülő-elem a tartalomszerkesztő űrlapon;
- node_options_page: alapértelmezett tartalomjellemzők;
- node_preview_page: kell-e előnézet a tartalom beküldésekor;
- node_submitted_page: szerző és beküldési dátum megjelenítendő-e;
- pathauto_node_page_pattern: a Pathauto modullal létrehozott alapértelmezés szerinti útvonal mintája.
Bonyolultabb webhelyek és/vagy tartalomtípusok esetén (mikor a más webhelyen való újrafelhasználhatóság esélye alacsony) a gyakorlatban célszerűnek tűnik az összes tartalomtípust egyetlen feature-be exportálni, mert van néhány beállítás (főleg itt a változók között), amelyeket nem lehet tartalomtípusonként exportálni. (A szakirodalom megosztott ebben a kérdésben; van, aki azt mondja, hogy ilyen esetekben hozzunk létre egy bázis feature-t, ami csak és kizárólag azon beállításokat tartalmazza, amelyek a többi feature esetében közösek, és a tartalomtípusokat, miegyebet tessék önálló feature-ökbe exportálni, amelyeknél már csak ezt a bázis feature-t kell megadni függőségként.) Lássuk tehát a tipikus változókat, melyeket ilyen bázis feature-be exportálnánk:
- default_nodes_main: alapértelmezett főoldali tartalmak száma;
- field_bundle_settings: megjelenítési módok beállításai;
- pathauto_case, pathauto_ignore_words, pathauto_max_component_length, pathauto_max_length, pathauto_punctuation_*, pathauto_reduce_ascii, pathauto_separator, pathauto_transliterate, pathauto_update_action, pathauto_user_pattern, pathauto_verbose: Pathauto modul (tartalomtípus-független) alapbeállításai;
- transliteration_file_lowercase, transliteration_file_uploads: Transliteration modul beállításai.
Van néhány változó, amit semmi esetre se tegyünk feature-be:
- clean_url: rövid webcímeket használjon-e a rendszer;
- cron_last: az utolsó cron (időzítő) futás időpontja;
- css_js_query_string: a webhelyre és annak állapotára jellemző kulcs, a CSS/JS fájlok gyorsítótárazásánál használatos;
- ctools_last_cron: a Chaos Tools modul időzítője;
- features_*: a Features modul saját változói;
- install_*: a telepítési profilra jellemző adatok;
- javascript_parsed: a feldolgozott JS fájlok listája;
- language_count, language_default, language_negotiation_*, language_types: többnyelvű webhelyek esetében használatosak elsősorban, a nyelvi változat kiválasztására, stb.;
- maintenance_mode: karbantartási módban van-e a webhely;
- site_mail, site_name, site_slogan: a telepítés során megadott értékek (ha a telepítési profil bekapcsol olyan feature-t, melyben szerepelnek ezek, akkor bizonyos telepítési lépéseket átugrik a rendszer);
- update_last_check: az elérhető frissítések ellenőrzésének utolsó időpontja.
Taxonómia: taxonomy
Ha a tartalomtípusunk tartalmaz kifejezés-hivatkozás mezőt (vagy bármi egyebet, amihez valamely taxonómia-szótárra van szükség), akkor exportáljuk az adott szótárat is.
Szövegformátumok: filter
A szöveges mezők legnagyobb részének megjelenítéséhez szükség van a megjelenítés módjára vonatkozó információkra, azaz a szövegformátumokra is. (Ha a fentebb már említett bázis feature megközelítést használjuk, akkor ezeknek is a bázis feature-ben van a helye.)
Függőségek: dependencies
A rendszer a legtöbb esetben felismeri, ha egy adott tulajdonság vagy beállítás exportálásához valamilyen további modult is be kell kapcsolni. Ha ez a felismerés mégsem volna sikeres (pl. a Pathauto modul változóinak esetében), akkor a hiányzó modulfüggőségeket kézzel kell megadnunk.
Jogosultságok: user_permission
Általánosságban elmondható, hogy amely modul beállításait belerakjuk egy feature-be, azon modullal kapcsolatos jogosultságokat is ugyanazon feature-be rakjuk. Szem előtt kell tartani, hogy ezek a jogosultság-beállítások csak olyan webhelyen fognak maradéktalanul érvényesülni, amelyen léteznek a feature exportálására használt webhelyen meglevő szerepkörök! Természetesen ha minden tartalomtípust és a velük kapcsolatos egyéb beállításokat egyazon feature-be gyűjtünk össze (tipikusan a bonyolultabb webhelyek esetében, ugyebár), akkor célszerű a következő jogosultságokat is ugyanezen feature-be exportálni:
- Filter*: a szövegformátumokkal kapcsolatos jogosultságok;
- Node*: a tartalomtípusokkal kapcsolatos jogosultságok;
- Path*: az útvonal-álnevekkel kapcsolatos jogosultságok;
- Pathauto*: az automatikus útvonal-álnevekkel kapcsolatos jogosultságok;
- Taxonomy*: a taxonómia-rendszerrel kapcsolatos jogosultságok.
Fenti modulok, illetve jogosultságok gyakorlatilag minden Drupal-alapú webhely esetében kezelendőek. Lássunk néhány ritkábban használtat:
- Book*: a
book.module
használatakor annak jogosultságai; - CKEditor*: a CKEditor modul használatakor annak jogosultságai;
- Comment*: a
comment.module
használatakor annak jogosultságai; - Image*: az
image.module
használatakor annak jogosultságai; - JW Player*: a JW Player modul használatakor annak jogosultságai.
Egyebek
További kiegészítő (contrib) modulok használata esetén további komponensek közül választhatunk. Néhány példa:
- CKEditor modul: CKEditor profiles: ckeditor_profile (azért szeretjük, mert a beállításait kényelmesen lehet exportálni – a Wysiwyg modullal szemben);
- JW Player modul: JW Player: jwplayer_preset;
- Linkit modul: linkit_profiles;
- Views modul: views_view (kár is rá több szót vesztegetni: mivel az egész „exportáljunk beállításokat kódba” kezdeményezés a Views felől indult, ezért nem meglepő, hogy ennek a működése a legmegbízhatóbb);
- stb.
Néhány dologra a Features-alapú exportálás nem megoldás. Például:
- Nem tudok használható és kellően általános megoldásról, amivel tartalmat lehetne exportálni.
- Ennek egy speciális esete, hogy míg a taxonómia-szótárak exportálhatóak, addig a taxonómia-kifejezések már nem azok.
- Szintén a tartalom exportálhatóságával, illetve annak megoldatlanságával függ össze, hogy ha egy Field collection modul segítségével készült mezőnek van alapértelmezett értéke, akkor azt a Features nem tudja hasznáhatóan exportálni (lásd a vonatkozó issue-t).
Zárszó
A Features egy apró, de annál idegesítőbb tulajdonsága még említésre méltó: ha egy adott komponensből több tulajdonságot szeretnénk hozzáadni a feature-höz, akkor minden esetben várjuk meg, míg az elem mellől eltűnik a folyamatjelző (pörgettyű)! Ellenkező esetben (ha túl gyorsak vagyunk) bizonyos tulajdonságok kimaradhatnak a feature-ünkből.