Drupal

Már meglévő tartalomtípus kiegészítése CCK field-el modulból

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.

El sem hiszem, Drupal CVS account

Kb. fél évvel ezelőtt eldöntöttem, hogy jó lenne nekem is egy cvs account a Drupal-hoz, mert hát akkor csak fel tudnám én is rakni amiket gondolok, esetleg beszállhatok egy-két modulba társfejlesztőnek meg na ... már éppen elég ideje foglalkozok a dologgal, hogy nekem is legyen.

Igen ám, de nem gondoltam volna, hogy ilyen kemény lesz megszerezni! Júniusban adtam be a kérelmemet és csak most fogadták el. Azért ezt kicsit túlzásnak érzem, biztos van valami baj a rendszerrel.
Na mindegy, most nem ez a lényeg hanem, hogy megvan és most már így is tudok segíteni a Drupal közösségnek, remélem mások számára hasznos modulokat (esetleg sminkeket) fogok készíteni.

Az első modul amiben segédkezek a Soundcloud filter, de tervbe van még pár saját és társ fejlesztés is. Ha úgy gondolod, hogy a Te modulod fejlesztésében is segítsek, akkor nyugodtan vedd fel velem a kapcsolatot!

Megismerkedésem a Drupal-lal, az Open Source-al és egyáltalán a webfejlesztéssel

Gondoltam eleget teszek pp kérésének miszerint osszuk meg rövid történetünket, hogyan is kerültünk bele ebbe az egész rendszerbe.

Az ősidők

Mivel már kicsinek is kocka voltam, érdekeltek a kütyük és a legjobb kütyü a számítógép volt. Persze eleinte nem sokat tudtam rajta csinálni, örültem ha elindult rajta a játék viszont arra gyorsan ráuntam...nem tudom, engem jobban felidegesített mint kikapcsolt, úgyhogy a játékokról viszonylag gyorsan lemondtam, elkezdett érdekelni hogyan is működik ez az egész, mit lehetne belőle kihozni. Kézenfekvő volt a Turbo Pascal, majd a Delphi...szép volt, jó volt, próbálgattam miket lehet csinálni, remek alap volt.

A kísérletezések kora

Ezt az időszakot kb a középiskola végére, egyetem elejére teszem. Itt már megismerkedtem a JAVA-val ami nagyon nagy hatással volt rám, teljesen beleszerettem és a mai napig az egyik (ha nem a) legjobb programozási nyelvnek tartom.
Ebben az időszakban már tudtam, hogy a webfejlesztés érdekel, tudtam hogy nem akarok optimalizáló algoritmusokat csinálni gyártósoroknak, nem akarok asztali alkalmazásokat írni és a mobilok sem fogtak meg annyira - bár a JAVA mind a három dologra tökéletesen alkalmas lett volna - engem a J2EE érdekelt, vagyis a webes- hálózati programozás.

Elkezdtem bújni az online tudásbázist, vettem a könyveket, próbálgattam mit és hogyan, aztán jött egy meló...

Én és a Drupal

Az én megismerkedésem sajnos korántsem volt olyan idilli, mint másoknak.

Hogyan készítsünk egy alap TinyMCE plugint beépülve a WYSIWYG Drupal modulba?

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:

Megújítottam az oldalam

Végre sikerült olyan állapotába hoznom az új oldalamat, hogy kitehessem másoknak is. Még nincs teljesen kész, de már lényeges funkcióvesztés nincs rajta.
A nyitólap fog még eltérő kinézetet kapni, valamint szükség van még egy alsó layer-re is, ahogyan eddig is volt.

Tudom, hogy régen írtam már, de az utóbbi időben egy csomó témám lett volna amit szívesen megosztanék másokkal is, viszont a szabadidőmben inkább az oldal felújításán dolgoztam, mint hogy cikkeket írjak. Most már viszont eljutottam odáig, hogy nem azért dolgoztam vele ennyit, hogy egy éves bejegyzések legyen rajta, hanem hogy megpróbáljak minél sűrűbben írni.

Két lényeges változás történt az előző verzióhoz képest:

  1. lecseréltem az arculatot
  2. lecseréltem a motort

Az arculatváltásra szükség volt, mert szerencsére megérett a vállalkozásom arra, hogy egyedi kinézettel rendelkezzen, a motor csere alatt pedig azt értem, hogy Drupal lett az eddigi Wordpress helyett.

Felmerül a kérdés, hogy a Kálmánnak a weboldala miért Wordpress-ben volt?
Ennek a megválaszolásához leírok egy rendszeresen lezajló párbeszédet, ami kb leírja a véleményem:

Ügyfél: Figyeljé má Kálmán! Nekem Drupal oldal kell, lehessen rajta blogolni és olyan legyen mint a Wordpress!

Én: Akkor miért ne legyen Wordpress?

Mivel az előző oldalamat a blogon kívül semmire se használtam, teljesen feleslegesnek tartottam Drupal-ban megcsinálni, hiszen egy csomó plusz modul kellett ahhoz, hogy azt a működést elérjük ami a Wordpress-ben az alaprendszert képezni, ezen kívül a Drupal contrib sminkek sem győztek meg túlzottan a WP által felkínált több ezer opensource dizájnnal szemben.
Nade mindegy is, ami volt elmúlt, most már más belső funkciókra is szükségem van, amiket nem akarok WP-ben megvalósítani, úgyhogy végre Drupal-os embernek Drupal oldala van :)

Egyedi smink készítésének alapjai Drupal 6 alatt

Rendszeresen megkeresnek azzal a kéréssel, hogy hogyan kell egyedi Drupal sminket készíteni, mert nem akrarnyak egy már elkészített contrib fejlesztést használni.
Én is általában azt szoktam javasolni, hogy inkább készítsük el saját magunk a meglévő psd alapján a sminkünket, mert igaz az esetek legtöbbségében meg lehetne oldani valamely már meglévő fejlesztés css-ének módosításával, de az mégsem az igazi. Egyrészt azért, mert a contrib sminkek több dologra vannak felkészítve mint amire nekünk szükségünk van, másrészt a végeredményben úgyis egy 3000 soros css-t kapunk amiben egy rakás osztály, vagy id több helyen van definiálva. Másrészt ahogy a contrib modulokba se szokás beleirkálni, szerintem a sminkeket se kell piszkálni.

Ha saját sminket készítünk, saját tpl és css fájlokkal akkor ezek a problémák kiküszöbölhetőek, és nem egy ördöngös feladat.

Leszögezném, hogy ez a bejegyzés csak az alapokról szól, nagyon sok egyéb dologra felkészíthetjük a sminkünket, pl: $logo, $site_slogan, $mission, $search_box stb. Az elérhető változókat itt lehet megnézni.

A Drupal 6, a Wysiwyg API, a TinyMCE 3 és a Drupal teaser megadása és különválasztása a teljes tartalomtól

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.

Drupal-ban az elsődleges linkek (primary links) helyére képek a themes_links() fgv. kifejtésével

Nekem már többször előfordult olyan problémám, hogy a Drupal elsődleges menüjének (primary links) egyedi kinézete miatt, kizárólag képekből álló menüt kellett készítenem. Ezalatt azt értem, hogy nincs a háttérkép felett semmilyen szöveg, a menü címe is a képen szerepel.

A háttérképeket egyszerűen megadhatjuk, a menüpontok egyedi azonosítója miatt (pl. menu-130 stb.), viszont a rajta lévő szöveget el kell tüntetni valahogy.

CSS-ben ha levesszük a betűméretet 0px-re sajnos nem a megfelelő megoldás, mert IE-ben, Chrome-ban és Operában kicsiben, de látszik.

Egy megoldás, ha a hyperlinkek szövegét span elemek közé tesszük, és a span elemeket tüntetjük el CSS-ben a display: none; definícióval, tehát a cél az lenne, hogy így nézzen ki egy menüelem:

<li class="menu-129"><a class="menu-129" href="/"><span class="primary-title">Nyitólap</span></a></li>

Ekkor minden további nélkül megadhatjuk CSS-ben a következőt:

ul.primary-links span.primary-title {
display: none;
}

Igenám, de hogy érjük el, hogy a Drupal span elemek közé tegye a linkek címét?

A megoldás az, hogy a sminkünk template.php fájljába kifejtjük a theme_links() fgv-t.

Íme a kód:

/**
 * Csak kepekbol allo menu elkeszitesenek alapjai
 *
 * @param unknown_type $links
 * @param unknown_type $attributes
 * @return HTML
 */
function phptemplate_links($links, $attributes = array('class' => 'links')) {
  global $language;
  $output = '';
 
  if (count($links) > 0) {

Az fgvtcsv beépített php fgv iso-8859-2 -es karakterkódolásban elhagyja az ékezetes kezdőbetűket

Az egyik általam készített Drupal alapú webáruház termékeinek adminisztrálása CSV alapon működik. Ez annyit jelent, hogy van egy exportáló felület, ahol a site admin lementheti a termékeit egy csv fájlba, amit aztán valamilyen csv-t kezelő programban (általában Microsoft Excel) átszerkeszt, és egy importáló felületen feltölt. Ezután az oldal feldolgozza és érvénybe lépnek a változtatások.

Ez így mind szép és jó, csak egy gond van vele. A windows felhasználók nagy része, ISO-8859-2-es karakterkódolást használ, míg a Drupal UTF-8-at. Hogy a címek és egyéb karakterkódolástól függő érték problémáját kiküszöböljük, szükség van az mb_convert_encoding() fgv-re, amely segítségével az ISO-8859-2 karakterkódolású részeket, át tudjuk konvertálni a Drupal-nak is használható UTF-8-as karakterkódolásba.

Egyszercsak jelentkezett egy probléma. Azon kezdőbetűk amelyek ékezetesek egyszerűen elvesztek. Tehát például az "Öntapadó" szóból, "ntapadó" lett.

Druplal 5-ben a $node->path, azaz a url alias érétke üres? A megoldás

A Drupal 5-ben van egy hiba amiről a programozók sokszor elfelejtkeznek.

A $node objektumnak van egy path attribútuma:

<?php
$node->path;
?>

Ez a node-hoz tartozó url alias, tehát a megadott elérési címet tartalmazza. Sokszor használjuk különböző tartalmak dinamikus gyűjtőoldalán, ezért fontos tisztában lennünk ezzel a hibával.

A probléma az, hogy amikor admin-ként vagyunk bejelentkezve a path érték megfelelő, ám ha nem akkor üres, így minden link a kezdőoldalra mutat. Ez annyit takar, hogy nem lehet elérni a kívánt bejegyzéseket, és ha nem elég körültekintő a tesztelés, akkor fel sem tűnik, mivel a session-be bentmaradunk mint bejelentkezett admin-ok, így nem is érzékeljük a hibát.

A megoldás egy egyszerű beépített Drupal fgv használata

<?php
$node->path = drupal_get_path_alias("node/$node->nid");
?>

Ez egy nagyon egyszerű megoldás, mégis ha nem vagyunk vele tisztába komoly gondot okozhat a weboldalon, de hangsúlyozom: megfelelő tesztelés esetén ki kell hogy derüljön még az élesítés előtt.