Borsa Péter Planet Drupal.hu hírcsatornája
Borsa Péter Planet Drupal.hu hírcsatornája
Keresés
Red Hat Cloud azaz OpenShift és a Drupal
A napokban a Red Hat is bejelentette saját alkalmazásplatformját felhőben, amely az OpenShift nevet kapta. 3 fajta verziót találunk ha ellátogatunk a főoldalra, Express, Flex és Power. A Power jelenleg nem elérhető, kapott egy "coming soon" címkét. Az Express szolgáltatás csupán alapvető platformokat tartalmaz, PHP, Ruby, Python. A Flex ennél jóval több, ott már megtalálható MySQL, MongoDB adatbázis is, vagy JBoss AS, Tomcat alkalmazásszerverek. Bővebben az OpenShiftről az alábbi linken kapható információ.
Most pedig nézzük hogyan telepíthetük Drupal 7.0-t a Red Hat féle felhőbe.
Először is, regisztrálnunk kell vagy használhatjuk a redhat.com-os felhasználónév/jelszó párosunkat, azonban mint magam is tapasztaltam, jelentettem, van hiba a SSO megoldásban, de dolgoznak a javításon. Ha ezzel megvagyunk akkor egy hozzáférést kell kérnünk("Try it now" gomb) a kiválasztott platformhoz, én az Expresshez kértem.
Szükségünk lesz egy Red Hat Enterprise Linux vagy Fedora disztribúcióra. Ha ez rendelkezésünkre áll akkor letölthetjük az Express repo fájlt a /etc/yum.repos.d/ könyvtárba.
yum clean all && yum update
Frissítjük a csomagadatbázisunkat.
yum install rhc
Kliens program telepítése.
rhc-create-domain -n asrob -l email@címem
Létrehozzuk a domaint, mivel nem adtuk meg argumentumként a jelszavunkat így a parancs kiadása után kérni fogja tőlunk.
rhc-create-app -a drupal -t php-5.3.2 -l email@címem
Elkészítjük az első alkalmazásunkat illetve megmondjuk melyik platformot használjuk, jelen esetben a PHP-ra van szükségünk. Ezután ismét kérni fogja tőlünk a rendszer a jelszavunkat.
A következő címen fogjuk elérni weboldalunkat, http://drupal-asrob.rhcloud.com, azonban előtte még be kell szereznünk egy drupalt és fel kell töltenünk a szerverre.
cd drupal/php
Könyvtárat váltunk, ide fogjuk kicsomagolni a drupalt, ez a drupal webrootja.
wget http://ftp.drupal.org/files/projects/drupal-7.0.tar.gz
Letöltünk...
tar zxf drupal-7.0.tar.gz
Kicsomagolunk...
mv drupal-7.0/* .
mv drupal-7.0/.htaccess .
Átmozgatunk mindent a webrootba. Frissítés: NeverGone jelezte hogy a .htaccess ott marad, valóban, azt nem mozgatja át, így azt külön meg kell tennünk.
rm -rf drupal-7.0 drupal-7.0.tar.gz
Töröljük ami már nem kell.
$base_url=http://drupal-asrob.rhcloud.com
Módosítanunk kell a "default.settings.php" fájlt mielőtt belefognánk a telepítésbe. A base_url értékét a fentebb látható értékre módosítjuk. A "default.settings.php" egyébként a "sites/default/" alatt érhető el.
git add -A
Hozzáadjuk a drupalt a helyi git repohoz.
git commit -a -m “drupal hozzaadva”
A változtatásokat "elmentjük".
git push
Végül feltöltjük a szerverre.
Készen is vagyunk, ezután megnyitjuk kedvenc böngészőnket, beírjuk a honlapunk címét, jelen esetben a http://drupal.asrob.rhcloud.com címet és telepíthetünk.
Azonban mint tudjuk, az Express platform nem biztosít számunkra *SQL adatbázist, így az SQLite-t kell kiválasztanunk az adatbázis konfigurációs oldalon. Egy fontos beállítást kell még végrehajtanunk itt, mégpedig az SQLite fájl elérési útját módosítanunk kell a következőre, természetesen idézőjelek nélkül, "../../data/.ht.sqlite"
Folytathatjuk a telepítést, más fontos módosítást már nem kell elvégeznünk.
Telepítés után ellátogatva az állapot jelentés oldalra láthatunk egy-két figyelmeztetést, konkrétan az "Upload progress" nincs engedélyezve valamint a "Unicode library" miatt is problémázik, azt egy "PHP mbstring" kiterjesztés telepítése megoldaná. Továbbá mintha a tiszta webcímek sem lennének elérhetőek, ennek ellenére azt hiszem kijelenthetem, hogy ismerkedésre, tesztelésre alkalmas rendszert kapunk az Openshift Express személyében. Ajánlani tudom csak mindenkinek, jó szórakozást hozzá. :)
Címkék
Tömeges file feltöltő
Sziasztok,
keresek egy egyszerű (kevés többlet modult igénylő) tömeges file feltöltőt D7 alá.
Előre is köszi!
KALMI
Drupal verzió:
Fórum:
Megjelnés calendar modulban a beküldéstől az adott dátumig minden nap
Adott egy node, benne egy date field. Sikerült a calendar blokk-ban a date-nek megfelelő nap alatt megjeleníteni a node-ot.
Azt szeretném elérni, hogy ne csak a date napon, hanem a beküldés és a date közt minden nap alatt megjelenjen a node!
Hogyan lehet rávenni a views-t, hogy ilyen megjelenítést produkáljon ?
Drupal verzió:
Fórum:
fb_social comment megjelenítés a linkek alatt
Alapesetben a comment rész a linkek fölött jelenik meg. Én azt szeretném ha alatta jelenne meg !?
1. vagy törölni kellene a content részből ( ez esetben bekapcsolom a fb_comment blokkot a tartalom részben, így legalul jelenik meg)
2. vagy a content részből át kellene tenni a linkek alá
Azt sikerült kiderítenem, hogy a fb_social_comments_nodeapi() view ágában adja hozzá a $node-hoz a comment részt, de azt már nem tudom, hol tudnám megfogni azt, törölni vagy áthelyezni, hogy úgy jelenjen meg ahogy fent leírtam!?
Próbálkoztam a phptemplate_preprocess_node()-al de rossz helyen keresgéltem, mert ott nem sikerült megoldanom...
Alapvetően nem is kifejezetten a fb_social modul a problémás, hanem ez inkább egy általánosabb kérdés...
Melyik modulhoz, modulokhoz kapcsolódik a téma?:
Drupal verzió:
Fórum:
Calendar nem látja a létrehozott dátum mezőt
Sziasztok!
Végigböngésztem az angol/magyar fórumokat, megnéztem a screencastet is, de valami miatt D7 alatt (az alá elérhető 7.x-2.0-alpha1-es Calendarral) szívok az esemény dátum szerinti listázásával.
Többször végigcsináltam ezt: http://drupal.hu/kezikonyv/tippektrukkok/calendar-modul-listazas-az-esem... , de valami miatt a "CONTEXTUAL FILTERS" - ha jól gondolom, akkor a korábbi verziókban Arguments volt- alatt kitörlöm a Dátum: Date (node) (Tartalom: Updated date)-t, és felveszem újra Date (node)- ot, de sajnos nem látom a leírás sorrendjének megfelelően létrehozott mezőt.
Bármi ötlet, hogy mi változhatott meg, ami miatt a leírt metódus nem oldja meg a gondot?
Nagy köszönet!
Üdv
M
Melyik modulhoz, modulokhoz kapcsolódik a téma?:
Drupal verzió:
Fórum:
szűrt tartalmak exportja
egy nézethez tartozik xls export (data export nézet, csatolva az oldalhoz), ez viszont az összes tartalmat exportálja, szűrés után is. hogy lehetne beállítani, hogy csak a találatokat küldje ki xls-be?
előre is köszönöm
Melyik modulhoz, modulokhoz kapcsolódik a téma?:
Drupal verzió:
Fórum:
Egy hét Drupal 7: Az entitásról
A Drupalban eddig mindenki tudta, hogy ha tartalom kezelésről volt szó, akkor azt a legkönnyebben a nodeok segítségével tudta megoldani. Az elgondolás lényege az volt, hogy adott a node, melyet a különböző modulok adatelemekkel és funkciókkal tudnak bővíteni. Ez nagyszerű volt, hisz ha volt egy oldal típusú tartalmam, vagy egy hír típusú, akkor ha az egyikhez megírtam a hozzászólás funkciót akkor az a másikkal is működött. Csak arra kellett figyelnem, hogy ezt úgy tegyem meg, hogy azt a típus nélküli nodehoz írjam meg. Ettől fogva a hírhez is és az oldalhoz is hozzá tudtam szólni, hisz mindkettő node volt. Sőt, amennyiben létrehoztam egy új tartalom típust, mondjuk képet, vagy képgalériát, akkor már azokhoz is igénybe vehettem ezt a nagyszerű szolgáltatást.
Azonban, maradt számos olyan tartalmi elemem, melyek nem voltak nodeok. Ilyenek voltak a kategóriák, a hozzászólások, felhasználók stb. Amennyiben ezekhez is igénybe kívántam venni azokat a szolgáltatásokat amiket a nodeokhoz kidolgoztak, trükköznöm kellett.
(Ilyen szolgáltatás volt például az, hogy az adott tartalmi elemhez újabb mezőket adjak hozzá, vagy megjelenítsem egy listában. Vagyis a CCK és Views modul)
A legalapabb trükk az volt, hogy az adott adatelemből nodeot gyártottunk. Ezzel aztán meg is oldottuk a problémánkat. Amennyiben társkereső oldalt akartunk készíteni, semmi más dolgunk nem volt, mint feltenni a Usernode(4.7.x, 5.x), vagy Content Profile(6.x) modulok egyikét. Ekkor minden egyes felhasználóhoz létrejött egy megfelelő típusú node. Semmi mást nem kellett tennünk, mint felvenni egy újabb CCK választó mezőt, melyben bejelölhették a delikvensek, hogy ők a focit szeretik vagy a baseballt és egy ügyes views lista segítségével már egymásra is találtak.
Azonban bármilyen szépen működött is ez a dolog, volt pár árnyoldal.
Először is, mivel két külön adattáblába, két külön modul írogatta azokat az adatokat amelyeket egy táblában kellett volna tárolnunk, igen magasra szökött az inkonzisztencia veszélye. Keletkeztek olyan felhasználók, akikhez nem tartozott node és keletkeztek olyan user nodeok, amikhez nem tartozott felhasználó. Amennyiben nem figyeltünk oda, könnyedén létrehozhattunk egy felhasználóhoz több tartalmat is. Egyszóval, volt egy olyan szuper bárhogyan konfigurálható rendszerünk amihez igazából jobb volt, ha nem nyúltunk hozzá.
A másik probléma ezzel a megoldással, hogy ha kevés hírünk volt, de sok felhasználónk, akkor is keményen dolgozott az adatbázisunk, hisz a hírek megjelenítéséhez először ki kellett szűrnie a felhasználókat az adattáblából és csak utána tudta rendezni és kilistázni a híreinket. Amint egyre több és több felhasználónk lett, úgy lett egyre nehezebb és nehezebb kilistázni a híreinket.
A „Csináljunk mindenből nodeot” megoldásnak ezen felül még volt egy árnyoldala. A node számos olyan frankó funkcióval rendelkezett, amire nem minden esetben lett volna igényünk. Ilyen szolgáltatások voltak azok, hogy egy node az verziókezelt, lehetett tudni melyik tartalmat melyik felhasználó látta már, lehetett szabályozni különböző szempontrendszerek szerint, hogy mely tartalmat mely felhasználó nézhess stb. Egyszóval számos olyan, ami egy tartalom kezelésekor jól jött de nem igazán volt szükségünk akkor erre, ha mondjuk felhasználókról, vagy csoportokról volt szó.
Drupal hetesben bevezetésre került az entitás fogalma, melyet egy node feletti egységként kéne elképzelni. Így lehetővé vált az, hogy a megvalósítani kívánt funkcióknál eldönthessük, hogy az melyik tartalmi szinten lesz számunkra érdekes. Ezek egy részét ráadásul az entitás létrehozásakor mi magunk is szabályozhatjuk. Pl. azt, hogy lehessen-e hozzá mezőket kapcsolni vagy legyen-e verziókezelt.
Minden entitásnak vannak olyan altípusai – úgynevezett bundle –, melyekhez a FieldAPI segítségével különböző mezőcsokrokat kapcsolhatunk. A node-nál ez a node típus, a kategóriáknál a szótár a felhasználóknál meg a ... hopp és itt a rés a pajzson, mert nincsenek a felhasználónak altípusai. Természetesen, nem lenne Drupal a Drupal, ha nem lenne egy alter hook amivel ne lehetne ezen a szörnyű helyzeten is változtatni.
De ne szaladjunk ennyire előre, ezt majd a workshopon. Készítsünk egy olyan Drupal 7 modult, ami egy olyan pehelysúlyú tartalmi elemet – egy entitást – valósít meg, mely semmi más mint egy darab táblában egy darab mező. Nézzük az én megoldásomat!
Hierarchikus jogosultságok a Drupal 8-ban
Hamarosan elkezdek dolgozni a Google Summer of Code projektemen, melynek célja a Drupal jogosultsági rendszerének újragondolása, majd ennek implementálása a Drupal 8 magba. Izgalmas hónapoknak nézek elébe, először leginkább az API-ra fogok fókuszálni, aztán amikor minden rendelkezésre áll, a UX-Teammel együttműködve új felhasználói felületet valósítok meg a jogosultságok kezelésére.
A Google Summer of Code programról
A Summer of Code 2005-ös indulása óta a Google évről-évre nyílt forráskódú szoftvereket támogat azzal, hogy projekteket finanszíroz részükre, melyeken egyetemi hallgatók dolgozhatnak világszerte. A Drupal közösség idén is 20 projektre kapott lehetőséget, és kiválasztotta a résztvevőket.
Hogyan kerültem be?
Lugosi Kornélnak tartozom köszönettel, aki megadta az első igazi lökést, mikor egy szegedi DUG alkalmával beszélgettünk. Kornél hallgatóként és mentorként is szerzett tapasztalatokat, motiválóan hatott rám élménybeszámolója, a bíztatása pedig bátorságot adott ahhoz, hogy pár nappal később már a lehetséges projektemen gondolkozzak. Végül Képes Viktor ötletét továbbgondolva kialakult, hogy mivel szeretnék foglalkozni, nagy-nagy köszönet érte.
Abban a megtiszteltetésben részesülök, hogy Négyesi Károly, alias chx lesz a mentorom, ő fogja segíteni és felügyelni a munkámat. Talán elárulhatom, hogy mivel chx az egyik GSoC adminisztrátor, egyáltalán nem tervezte, hogy idén mentorként is tevékenykedni fog, azonban mikor először meséltem neki terveimről, megváltoztatta álláspontját. Felhívta a figyelmemet Larry Garfield bejegyzésére, aki két évvel ezelőtt hasonló tervekről vízionált. Egy-két nap múlva már Larry-vel és chx-szel beszélgettünk a lehetséges megvalósításról, és Bojhan Sommers, a UX-Team egyik vezetője is felajánlotta segítségét az új felhasználói felület kidolgozásában. Jókora gombóccal a torkomban készültem erre a megbeszélésre, de Boros Ádám bíztatása rengeteget segített abban, hogy úrrá legyek izgalmamon, köszönöm neki.
Amit jobbá szeretnék tenni
A jelenlegi jogosultsági rendszer használata sok esetben kényelmetlen; magas fokú koncentrációt és magabiztos ismereteket követel a megfelelő konfiguráció. Már az alaprendszer részét képező Node modul esetében sem egyértelmű első olvasásra, hogy pontosan mit takar például a tartalom adminisztrációja, ugyanez igaz a User modul felhasználók adminisztrációja jogosultságra, ami ezt figyelembevéve, kisebb sarkítással egyenesen biztonsági résnek tekinthető. Egy tapasztalatlan felhasználó ugyanis nincs tisztában azzal, hogy mivel jár egy csoport számára ennek a jogosultságnak az engedélyezése. Nem beszélve arról, hogy ezek a jogosultságok lefednek másokat, viszont ez szintén nem derül ki előzetes ismeretek nélkül. A felület nem támogatja ennek felismerését, az elnevezés persze sokatmondó lehet, de csupán erre hagyatkozni nem feltétlenül jó döntés hosszú távon.
A tervek
A projektem során egy olyan API-t fogok biztosítani a modulok számára, melynek használatával hierarchikusan szervezhetik az általuk definiált jogosultságokat. A hierarchikus rendszer segítséget nyújthat abban, hogy egyértelművé tegyük a Drupal adminisztrátorok számára, hogy a jogosultságok milyen funkciókhoz való hozzáférést fednek le pontosan. Szeretném a beállításokra szolgáló felületet átláthatóvá, egyszerűvé, jól kezelhetővé tenni.
A modulok jogosultsági fákat definiálhatnak majd, akár többet is. A felületen ezek megjelenítése a modulok szerinti csoportosítás helyett (esetleg mellett) logikai csoportok szerint történhet. Ezzel a lépéssel is segíthetjük a jobb megértést. Figyelmet fordítok majd azokra az esetekre is, amikor egy-egy modulhoz tartozó lehetőségeket nem szeretnénk pontosan testreszabni, hanem elegendő számunkra, ha pl. a modul jogosultsági fájának gyökerében található hozzáférést engedélyezzük csak az adminisztrátor csoport számára. A felület terveiről pontosabban korai lenne még írnom, ez később fog tisztázódni. Bár nem vagyok sem dizájner, sem UX-szakértő, mégis remek kihívásnak tekintem ezt a feladatot, és természetesen ebben a részben sok segítséget fogok kapni a UX-Teamtől és a közösségtől is.
Inspiráló feladatokon fogok dolgozni az elkövetkezendő hónapokban. Természetesen a Summer of Code végeztével sem szeretném ezt abbahagyni, aktívan részt veszek majd a Drupal 8 fejlesztésében. Szerencsésnek mondhatom magam amiatt, hogy átélhettem egy olyan közösségi élményt, amit a magyar Drupal közösségtől kaptam e projekt kapcsán - pedig még el sem kezdtem a munkát. Ebben a bejegyzésben nem készítettem teljes körű listát azokról a személyekről, akik támogattak, de hihetetlen pluszt kaptam, nagyon köszönöm mindenkinek!
Galéria feltöltése tartalomba
Sziasztok,
Drupal 6 alatt csináltam egy tartalomtípust, ahol kb. 20 szöveg és számmezővel kérem be az adatokat. Ezzel nincs is baj, de kellene minden tartalomba 1 nagy és alatta 6 kis kép is.
Megmutatom
Ezeket a képeket most ImageField-el tettem be, de ez így nem jó, mert a megrendelő azt szeretné, hogy ezekre a képekre rákattintva (a nagyra és a kicsikre is) ugorjon fel a kép nagyban, és fontos, hogy a képeket ne külön egy galériába kelljen feltölteni, hanem együtt a szöveges tartalommal.
Eddig próbálkoztam lightbox2, gallery assist, image, flash gallery, node gallery modulokkal, de nem találtam a megoldást, vagy csak folyamatosan elszúrok valamit :(
Kérlek benneteket segítsetek...
Drupal verzió:
Fórum:
