drupal 7

Drupal 7 privát fájlok letöltése csak bejelentkezett felhasználóknak

A Google maps-es példákat hamarosan folytatom, de ezt most muszáj kiírnom magamból.

Ma órákon át téptem a hajam egy egyszerűnek tűnő probléma felett: mindössze annyit szerettem volna elérni, hogy egy Drupal 7 weboldalnál a privát tárolóba feltöltött fájlokat csak bejelentkezett felhasználók tölthessék le.

Az első ötlet, hogy erre lesz egy kis pipa a jogosultságok beállítási oldalán. Hát nincs. Némi utánajárás után kiderült, hogy a Drupal nem így működik. A fájlokhoz akkor enged hozzáférni egy felhasználót, ha az adott node-hoz van hozzáférése a felhasználónak.

Nekem nem ez kellett, a node-ot mindenkinek látni kellett, csak a fájl letöltéshez kell bejelentkezni.

Jó, gondoltam, akkor majd mező (Field) szinten kezeljük a jogosultságokat.

Meg is találtam a Field permissions modult, amivel nagyszerűen be lehet állítgani minden egyes mezőre mindenféle jogot (megtekintés, létrehozás, módosítás). Szépen beállítottam amit szerettem volna, és mint aki jól végezte dolgát, léptem is a következő feladatra.

Véletlenül vettem csak észre, hogy a weboldalról a mezőt ugyan elrejti a Field Permissions modul, de a konkrét fájlt továbbra is le lehet tölteni a megfelelő webcím (URL) ismeretében.

Ezután következett egy órákon át tartó, vad és elkeseredett kattintgatás hadjárat, mindenféle tutorial és issue olvasgatás, néhány modul kipróbálása és mindenféle mágikus varázsigék mormolása. Persze minden hiába, csak nem tudtam célt érni.

És akkor itt jön az Open Source ereje.

Nem volt más hátra, meg kellett nézni a forráskódot, hogy mégis mi a fene történik a háttérben. A megoldást, nem több mint 1 perc után megtaláltam:

  • A fájl pathból (/system/files/) sejteni lehetett, hogy a system.module-ban kell keresgéljek.
  • A system_menu függvényben meg is találtam, hogy a file_download függvény szolgálja ki ezeket a kéréseket.
  • A file.inc-ben meg is találtam a függvényt, bőséges dokumentációval. Mint kiderült létezik egy hook_file_downloads hurok, amivel szabályozható a hozzáférés.

Újabb 1 teljes percet vett igénybe a megfelelő kód megírása:

<?php
modulom_file_download
($uri) {
  if (
user_is_anonymous()) {
    return -
1;
  }
}
?>

Hát ennyi volt. Több óra kattintgatás vs. 1+1 perc kódolás. De sokszor hallottam már, hogy amit lehet, saját kód helyett érdemesebb letölthető modulokkal megoldani. Egy jó darabig még nehéz lesz engem meggyőzni erről.

A Drupal kereső adatok használata saját modulban.

Ez is egy olyan bejegyzés, amit leginkább magamnak írok. Nem egy bejegyzést írtam már, amit újra meg újra visszakeresek, hogy kimásoljam a benne lévő kódrészletet. Bár a logfájlok alapján, úgy tűnik másokat is érdekelnek ezek a bejegyzések.

Szóval, többször előfordult már, hogy a Drupal kereső funkciójának az adatait integrálni akartam egy saját megoldásba, és mindig elég nehezen sikerült megtalálni a jó megoldást, ezért most leírom egyet, ami nekem bevált.

Mikor is van erre szükség? Legutóbb egy meglehetősen összetette kereső funkciót kellett kivitelezni, aminek a kulcsszavas kereső funkció csak egy kis része volt. Máskor pedig a hírekhez rendelt címkéket használtam kereső kifejezésnek, így implementáltam hasonló tartalom ajánló funkciót a oldalra, mert a meglévő megoldások nem váltak be.

Ezeknek az eseteknek közös eleme, hogy a Drupal keresővel egy keresést kell végeztetni, de az eredményeket nem megjeleníteni kell, ehelyett további feldolgozás vár az adatokra.

Az első ötlet, hogy közvetlenül a search_* adatbázis táblákon végzünk keresést. Bár ez is egy lehetőség, meglehetősen összetettek ezek a táblák, nem arra vannak kitalálva, hogy egyetlen SELECT utasítással hozzájussunk az eredményhez. Ennél sokkal egyszerűbben, egyetlen függvény hívással is el lehet intézni a dolgot.

Drupal 6-ban:

<?php
 $talalatok
= node_search('search', 'kereső kifejezés');
?>

Drupal 7-ben:

<?php
 $talalatok
= node_search_execute('kereső kifejezés');
?>

A Drupal a node-okon kívül a felhasználókban és potenciálisan még ezer másik dologban is tud keresni, de nekünk most elég lesz a node-okban keresni. Általában úgyis ez érdekel minket. Ráadásul ha más objektumban akarunk keresni, akkor elég a node_search helyett pl. a user_search függvényt használni.

De nézzük egy kicsit tovább a dolgot, mi van ha csak egy node típust várunk eredményként? Ezt az információt a kereséséi kifejezéshez kell hozzáadni, így:

Drupal 6-ban:

<?php
 $talalatok
= node_search('search', 'kereső kifejezés type:nodetipus');
?>

Drupal 7-ben:

<?php
 $talalatok
= node_search_execute('kereső kifejezés type:nodetipus');
?>

A Drupal mag összetett keresője több más szűrő paramétert is ismer, nem csak a típust. Ezek használatát a legegyszerűbben úgy deríthetjük ki, ha a /search oldalon használjuk az összetett keresőt és megnézzük, hogy mi kerül a keresési kifejezés mezőbe.

Ahhoz hogy, a fenti megoldás működjön természetesen szükséges az, hogy a Drupal mag kereső modulja be legyen kapcsolva és a tartalmakat folyamatosan indexelje, azaz hogy az ütemezett feladatok (cron) be legyen állítva.

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.

Feliratkozás RSS - drupal 7 csatornájára