drupal

Drupal 7 helyzetjelentés

Megjelent a Drupal 7 első kiadásra jelölt változata, azaz a Release Candidate 1. Úgy gondolom, érdemes alaposan megnézni, hogy is áll a D7 ökoszisztéma, azaz a közösségi modulok, sminkek és a fordítások.

Mikor fog megjelenni a végleges verzió?

Nos, bizonyos értelemben már megjelent. Micsoda?! Hogy merem én állítani, hogy megjelent a végleges verzió, hiszen még csak RC-ről beszélünk. Ezért:

Feature freeze, azaz új funkciók már nem kerülhetnek az Drupal 7-be. Aki az újdonságokra kíváncsi az nyugodtan próbálja ki az RC1-et, mert a végleges verzióban sem fog semmi újat találni a mostani állapothoz képest. Ez egyébként nem most történt, már elég rég óta így van.

API freeze, azaz a programozói felület is elérte a végleges állapotát. A függvény és metódus nevek már nem változnak meg, és a paraméter listájuk sem. Akik a saját moduljukat vagy sminkjüket szeretnék frissíteni az új verzióra, most már nyugodtan belevághatnak, nem kell attól tartaniuk, hogy mozgó célpontra vadásznak.

Akár közösségi modulról vagy sminkről beszélünk, akár egy éles rendszeren futó weboldalról, most már nincs több kifogás, el lehet kezdeni a frissítést. Ehhez segítséget nyújt a frissítési dokumentáció modulok és sminkek számára, illetve nagy segítség a Coder modul.

String freeze, azaz a Drupal 7-ben használt szövegek is elérték végleges formájukat, a fordítást is el lehet kezdeni, anélkül hogy kihúznák alólunk a talajt.

Felmerül a kérdés, hogy akkor mi a különbség az RC és a végleges változat között? Egyszerűen annyi, hogy a végleges változatba be fog kerülni még néhány hibajavítás. Ezek a hibák azonban nem kritikusak, az RC megjelenésének feltétele volt, hogy kritikus hiba nem lehet a rendszerben.

Akkor mi az, amire még nem használható az RC, de a végleges igen? Az egyetlen ilyen helyzet, az éles környezetben való bevetés. Új vagy régi weboldalunkat most még ne Drupal 7 alapokon futtassunk. De új oldal fejlesztésekor természetesen már választható a 7-es platform, mire kész leszünk az oldallal, már a Drupal 7.0 is meg fog jelenni.

Drupal 7 újdonságok

Túl sok szót most nem akarok pazarolni az újdonságokra, egyrészt mert már nagyon jól össze van foglalva itt (angolul), meg majd biztosan írok róla több bejegyzést is, ahogyan az eddigi Drupalokról is írtam.

Rögtön a legfontosabb változás, hogy több kulcsfontosságú Drupal 6 közösségi modul bekerült a magba. Persze, gondolok most többek között az ImageCache-re is, és a Token modulra is, de kétséget kizáróan, a legnagyobb horderejű változás a „Fields in Core” munkanevű projekt, azaz hogy a CCK modul most már a Drupal mag integráns része.

Most már nem csak a tartalom típusokat (node), hanem a hozzászólásokat (comment), a taxonómia szótárakat (taxonomy) és még a felhasználókat is (user) ugyanúgy testre szabhatjuk plusz mezőkkel, mint Drupal 6 alatt a node típusokkal tehettük. Ez félelmetes lehetőségeket szabadít fel, amire mindenképpen kitérek még később.

Egy teljesen újragondolt adminisztrációs felület fogad minket 4 új modul személyében: Overlay, Toolbar, Dashboard és Shortcuts. A nyílt forráskódú rendszereknél már jól bevált moduláris felépítést alkalmazza a Drupal 7, így külön-külön lehet ki és bekapcsolni ezeket a funkciókat, mindenkinek ízlése szerint. Szavakkal leírni hosszadalmasabb, mint kipróbálni, röviden annyit, hogy erős Javascript/AJAX támogatást kapott az admin felület.

Valódi időzóna támogatás is bekerült a D7-be, így már nem kell külön modult telepíteni, hogy ne csússzanak el 1 órával az elmentett dátumok a nyári időszámításra átálláskor és vissza.

Ez csak három kiragadott példa az újdonságokból, de közel sem teljes a lista. Az újdonságokról további a fent linkelt oldalon.

Drupal 7.0 követelmények

Van néhány komoly változás a követelményekben is. Íme:

  • HTTP szerver, ajánlott Apache 2.0 vagy nagyobb
  • PHP 5.2.4 vagy újabb verzió
  • SQL szerver: MySQL 5.0 vagy PostgreSQL 8.3 vagy SQLite 3.4.2, illetve újabb verziók

A PHP 5.2 és a MySQL 5.0 mint kötelező elem az igazi újdonság. Mindkét verzió az aktuális stabil főverziónál (PHP 5.3 és MySQL 5.1) eggyel régebbi verzió.

Sajnálatos hogy a RedHat, és az erre épülő kiszolgálók, nem fogják tudni futtatni a Drupal 7-et az ősrégi PHP 5.1.6 miatt, de valahol meg kellett húzni a határt. A nagyon régi architektúrák támogatása egyszerűen visszafogta volna a Drupal fejlődését.

Szintén ide tartozik, hogy a Drupal 7 kifogástalanul fut PHP 5.3 környezetben is. Így az egyre népszerűbb Ubuntu szerverek friss verzióin, közöttük az utolsó LTS-en, a Lucid Lynx-en is, gond nélkül futtatható az új Drupal.

Modulok

Egy Drupal kiadás féllábú óriás a közösségi modulok nélkül. Így különösen jó hír, hogy ezen a téren sokkal-sokkal jobban állunk mint annak idején, a Drupal 6 megjelenésekor. Szinte minden fontos modulnak van már valamilyen többé-kevésbé használható verziója, van ahol már egészen stabil állapotokról beszélhetünk.

Devel: mindvégig zászlóshajóként viselkedve, ez a modul járt legelöl a Drupal 7-re portolás állapotában, így most egészen használható állapotban van. Aktuális verzió: 7.x-1.0-beta2

CCK: a legfontosabb részei bekerültek a Drupal core-ba, néhány kevésbé fontos dolog továbbra is a contrib modul része, amelyből jelenleg csak egy fejlesztői változat létezik. A kapcsolódó FileField és ImageField is a mag része, egyúttal kiváltva a régi Upload modult.

Views: Igaz ugyan, hogy a 7-es verzióra nincs semmilyen alpha, beta vagy egyéb címke aggatva, pusztán csak egy fejlesztő dev változat létezik, de egy rövid próba alatt teljesen stabilnak tűnt, egyetlen hibát sem sikerült kicsikarni belőle.

Panels és Ctools modulokból már készen állnak az alpha1-es verziók, bár egy gyors teszt alatt nekem nem sikerült működésre bírni a Panels-t.

Admin Menu: kisebb hiányosságok vannak ugyan, de alapvetően használható a jelenlegi fejlesztői változat.

A Token és ImageCache is bekerült a Drupal magba.

A PathAuto is készen áll egy 7.x-1.0-alpha2 verzióval, de sajnos ezzel sem volt szerencsém.

A Rules is készen áll egy 7.x-2.0-alpha2 verzióval, sajnos a Flag modulnál még nincs 7-es verzió.

Kezdő sminkek

Itt már nem olyan jó a helyzet, a fontosabb kiindulási alapnak szánt sminkek is többnyire csak dev verzióban érhetőek el:

  • Zen: Fejlesztői (dev) változat áll rendelkezésre
  • Fusion: szintén egy fejlesztői változat.
  • Framework: se híre, se hamva 7-es verziónak
  • Basic: 7.x-2.0-rc2
  • Genesis: fejlesztői változat
  • Blueprint: 2.x fejlesztői változat
  • Adaptive Theme: Beta 2
  • 960: fejlesztői változat

Két meglehetősen elterjedt, azonnali felhasználásra szánt smink viszont igen jól áll az új verziót tekintve: Corolla 7.x-1.17 és Pixture Reloaded 7.x-1.0-beta2

Fordítások

A Drupal mag és az egyes modulok különböző nyelvű fordítási állapotáról itt található részletes információ: http://localize.drupal.org/

A Drupal 7 magyar nyelvű fordítási állapota az átlagosnál sokkal jobb.

Összegzés

A Drupal 7 mag és a közösségi bővítmények egyértelműen olyan állapotban vannak, hogy mindenki nyugodtan belevetheti magát az új rendszer megismerésébe. Elvégre már több mint 20.000 éles Drupal 7 weboldal működik.

Drupal keresőoptimalizálás előadás

A Drupal Hétvége 2010 konferencián (2010. november 13-14.) előadást tartok Drupal keresőoptimalizálás témában. Érdemes eljönni, mert az én előadásomon kívül is igen sok érdekes téma lesz.

Aki a webes világban dolgozik, legyen akár döntéshozó, reklámszakember vagy honlapkészítő, annak érdemes eljönnie.

A konferencia ingyenes, de előzetes regisztráció szükséges. Jelentkezési határidő: november 7. (vasárnap)

Ha eljössz, keress meg, és igyunk meg egy pohár sört üdítőt.

Update: Az előadás fóliái a slideshare-en:

Volt egy másik, 5 perces előadásom is. Ott az Állás.IT indulásáról beszéltem:

Állás.IT - Informatikai állás és munka ajánlatok

Az Állás.IT egy informatikai állás és munkakereső weboldal. Úgy gondolom van igény egy olyan oldalra, ahol a munkavállalók elmondhatják a véleményüket az egyes cégekről, és ahol kérdéseket tehetnek fel az álláshirdető cégnek még mielőtt jelentkeznének a pozícióra.

Egy másik fontos szempont az oldal kialakításánál az egyszerű és letisztult kezelőfelület volt. Én nagyon nem szeretem a kilométer hosszú formokat, és szerintem más sem. Ezért a hirdetésfeladás űrlap csak a legeslegfontosabb mezőket tartalmazza. Minden másra ott a hirdetés szövege.

Az egyszerűség ellenére az oldalon használt címke rendszer igen erőteljes eszköz, nagyon jól kereshetővé válik ezáltal az oldal.

Bevezető reklámkampánynak indítottam egy nyereményjátékot, ahol lehet nyerni akár egy iPhone 4 telefont egy twitter üzenetért és egy regisztrációért cserébe. Szerencsére nagyon népszerű a játék, a yamm.hu trendben többször első pozícióban volt a játék.

Az oldal természetesen Drupalban készült, ezt mondanom sem kell. A bejelentkezésénél és üzenet küldésnél használt modális felugró ablakot elég nehezen sikerült megvalósítani, azt hittem erre létezik kész modul. Sajnos a létező modulok, itt használhatatlanok voltak. Később tervezek erről egy plusz bejegyzést, volt néhány érdekes dolog amit megtanultam ezzel kapcsolatban.

Az oldal és a játék külalakja bVisual munkáját dicséri, aki ilyen szép logókat is tud csinálni:

Nagyon bízom az oldal sikerében, eddig minden jól alakul :)

Debian és Ubuntu szervereken a Drupal sessions tábla túl nagyra nő

Probléma: Ha Debian vagy Ubuntu szerveren futtatsz Drupal-t és a session kezeléssel kapcsolatos beállításokat nem állítottad át a php.ini-ben, akkor a Drupal sessions tábla soha nem lesz ürítve, ezért túl nagyra fog duzzadni, napról napra egyre jobban lelassítva a weboldaladat.

Megoldás: A Drupal settings.php-be szúrd be ezt a két sort:

<?php
ini_set
('session.gc_probability',   5);
ini_set('session.gc_divisor',       100);
?>

és esetleg finomhangold ezt a sort:
<?php
ini_set
('session.gc_maxlifetime',   200000);
?>

Egy másik megoldás, ha a .htaccess fájlba vagy az Apache virtualhost definícióba szúrod be ezt a két sort:
php_value 'session.gc_probability' 5
php_value 'session.gc_divisor' 100

Miért csak Debian alapú szervereken?

Nade mit is csinál ez a két sor és miért kell ezzel külön foglalkozni a Debian alapú szervereken?

Ahhoz, hogy megértsük a problémát, bele kell kicsit mélyednünk a Drupal lelkivilágába.

Nem csak az asztali gépemen fut Ubuntu, hanem szervernek is szívesen használom. Így vettem észre, hogy az f1vilag.hu oldalon, ami egy elég forgalmas site, a session táblában nagyon sok bejegyzés van. Hamar kiderült, hogy a táblából soha nem kerülnek ki a régi sorok, mindig csak az újak kerülnek beszúrásra.

Utánanéztem, hogy ez hogyan lehetséges, és egy kis keresgélés után kiderült, hogy a Drupal a sess_gc nevű függvényében ürítené a táblát. Az is hamar kiderült, hogy ezt a függvényt nem közvetlenül hívja meg a Drupal, hanem indirekt módon, a PHP-t kéri meg, hogy néha hívogassa ezt a függvényt, amikor a PHP azt jónak látja. Ezt egyébként úgy éri el a Drupal, hogy a session_set_save_handler függvény 6. paramétereként megadja visszahívandó callback függvényként a 'sess_gc'-t.

A PHP egy véletlen sorsolással dönt arról, hogy mikor kell meghívni a munkamenet szemétgyűjtőt, ismertebb nevén a session garbage collectort. A fent beállított értékek esetén, minden 100 oldalletöltés esetén átlagosan 5 alkalommal fog végrehajtódni a takarítás.

Ez mint szép és jó, de miért nem teszi ezt meg magától a PHP Debian alatt és miért teszi meg más rendszerek alatt? A választ megkapjuk, ha bepillantunk a php.ini ide vonatkozó részébe egy Ubuntu vagy Debian alatt:

; Define the probability that the 'garbage collection' process is started
; on every session initialization.
; The probability is calculated by using gc_probability/gc_divisor,
; e.g. 1/100 means there is a 1% chance that the GC process starts
; on each request.

; This is disabled in the Debian packages, due to the strict permissions
; on /var/lib/php5.  Instead of setting this here, see the cronjob at
; /etc/cron.d/php5, which uses the session.gc_maxlifetime setting below.
; php scripts using their own session.save_path should make sure garbage
; collection is enabled by setting session.gc_probability
;session.gc_probability = 0
session.gc_divisor     = 100

Debian alatt tehát ki van kapcsolva a php beépített session garbage collection funkciója, és helyettesítve van egy ütemezett feladattal (cronjob). Ami viszont csak annyit tesz, hogy a php session fájljait törölgeti félóránként. Ezért nem lesz soha meghívva a drupal sess_gc függvénye és ezért nő a sessions tábla a végtelenségig. A php.ini-ben, mint fent olvashattuk, nem is érdemes visszakapcsolni ezt a funkciót. Inkább a Drupal-ban állítsuk vissza ezt a funkciót, amelynek hatására már rendszeresen meg fog hívódni a sess_gc függvény és nem nő a végtelenségig a sessions tábla.

Oldalak

Feliratkozás RSS - drupal csatornájára