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