Sziasztok!
Azt szeretném megoldani, hogy legyen egy olyan blokk, ami minden oldalon megjelenik, de a tartalma attól függően változik, hogy épp milyen oldalon vagyunk: vagy URL-től, vagy kontextustól függően dőlne el (pl. node id, tartalomtípus, ilyenek), melyik tartalom jelenne meg. Egyelőre mondjuk az első a fontosabb, hogy legalább URL-től függővé lehessen tenni.
Például van egy "Küldetésünk" nevű blokk, aminek a tartalma minden aloldalon más és más: a blabla/akarmi/* útvonalon (vagyis az összes blabla/akarmi/-vel kezdődő URL esetén!) az, hogy "Mi vagyunk a legjobbak", de a masikblabla/asdasd oldalon az, hogy "Bizony", a harmadikblabla/qwe oldalon az, hogy "Nem", és így tovább...
Van ilyenhez vajon valami normális, átlagjúzer által is kezelhető felület?
A Header image modul, amit itt korábban bemutattam, az egy egész használható megoldást alkalmaz, csak nem tudom, ezt átlagjúzer mennyire tudná kezelni, vajon van-e egyszerűbb felület, ahol pl. kattintásokkal ki lehet választani, melyik aloldalra szeretné az adott tartalmat... Meg tudja szerkeszteni is azt.
Mit javasoltok?
Előre is köszönöm!
hányféle tartalom van?
Én ezt úgy csinálnám, hogy létrehoznék annyi blokkot, ahány féle tartalom van, a Block felületet pedig általában tudja használni az átlagjúzer, ha megmutatom neki, hogyan tud útvonalakat megadni.
Persze ha 100 féle tartalom van, akkor ez nem megoldás.
Előre nem tudom, mennyi tartalmat akar majd hozzáadni a júzer
Na ez az, hogy egyelőre megjósolni nem tudom, a jövőben hányféle ilyen jellegű tartalmat akar létrehozni. Az is lehet, hogy lesz 4-5 darab, az is lehet, hogy 20. Húsz külön blokkot definiálni, az admin-felületen áthúzgálni meg hát egy kicsit már ronda lenne. Ráadásul akkor azt is el kéne magyarázni, hogy a blokkok átrendezésénél hova húzogassa, és hogy a többi blokkot ne bántsa... szóval ez a megoldás igen sok veszélyt rejtene magában.
Pont ezért gondoltam arra, hogy egy külön tartalomtípust hozok létre, és biztosítok egy mezőt, amivel meghatározhatja, hogy melyik oldalakon jelenjen meg a blokk (ha nem jelenik meg, akkor vmit elrontott az URL-nél).
Ilyenre nincs megoldás?
Egyelőre arra gondoltam, hogy megoldom a "Header image" modullal. :) Ott az
admin/structure/headerimageoldalon meg tudok határozni különböző blokkokat, "Header image" tartalomtípusbeli tartalom hozzáadásakor pedig azt, hogy melyik blokkba kerüljön. Aztán ott van az a felület, amit mutattam, ahol meghatározhatom az URL-t, esetleg node id-t, tartalomtípust, taxonómiakifejezést.Már ha nincs erre jobb megoldás... :\ Mert azért majd ezt is testre kell szabni kódból, hogy ne vezessem félre a júzert, hogy mi köze ennek a fejlécképhez. (Igazából amúgy magát a modult szerintem sokkal általánosabb névvel is elláthatták volna :) )
Egyre inkább alkalmasnak tűnik a Header image modul a célra.
Egyre inkább alkalmasnak tűnik a Header image modul az említett célra. Ráadásul úgy tűnik, mégsem kell kódolnom hozzá.
Most nézem, hogy az
admin/structure/headerimage/settingsoldalon az összes tartalomtípusra (nem csak a defaultként meghatározott Header image content type-ra) meg lehet határozni, hogy megjelenjen a Header image modul "Display conditions" füle, aztán ott meg lehessen határozni, melyik blokkban jelenjen meg az adott tartalomtípus bármely node-ja.Magyarul ez azt jelenti, hogy létrehozhatnék egy "Our mission" tartalomtípust, majd ezt bepipálnám az említett settings-oldalon, és a felhasználónak megmondanám, hogy a "Display conditions" fülön tudja begépelni, hol jelenjen meg az adott blokk. A blokk elrendezésével pedig csak nekem kell foglalkoznom.
Szóval jónak tűnik, tényleg elnevezhették volna általánosabban is a modult, mert ilyesmire is alkalmasnak tűnik, egy sor kódolás nélkül. :)
hát én ebben semmi nehézséget nem látok
simán felveszel egy entity reference mezőt amivel aztán a user meg tudja adni hogy adott nodenál melyik másik nodeot akarja megjeleníteni a "blokkba" és erre kell egy nézet aztán viszont látásra.
azt is el tudom képzelni, hogy ezek a "tartalmak" amiket a blokkba lehet kérni, valójában termek egy taxonómia szótárban. amikor beküldök egy node, csak berakom abba a taxoba amelyiknek a 'leírását' vagy akármilyét meg szintén egy nézettel kiteszem a node mellé.
nálunk például van egy 'spotlight' nevű feature, ami nagyjából ez csak fordítva, egy ilyen "banner rendszer" szerűség. nem a nodeba adom meg, hogy melyik banner jelenjen meg, hanem a bannerba adom meg, hogy hol akarom látni. a 'spotlight' tartalom típusban van egy 'display at' entity reference mező, ahol page, article, event, egyéb típusú nodeokra lehet hivatkozni, itt lehet megadni hogy adott "banner" hol jelenjen meg. erre van egy nézet, ami contextual filterként használja ezt a mezőt és kész is, ha a node/42 oldalon állok, egy blokkban megjelenik az a "banner" amelyik a negyvenkettes nodera hivatkozik a 'display at' mezőben. persze lehet cifrázni, hogy a display at mellet van még esetleg egy 'position' mező is, top, bottom, left, right, ilyen értékekkel, és akkor nem csak egy nézet van, hanem ahány position, annyi nézet (illetve csak egy nézet, az van újrahasznosítva page managerben a négy külön pozícióba) és akkor a user mikor beküld egy új "bannert" megadja hogy node/42 meg node/69 oldalakon akarja, 'left' pozícióba. slusz. az egészhez tartozik egy "admin" felület ami listázza az összes spotlight -ot meg exposed filterekkel lehet közöttük keresni és ámen. tökre szeretik.
-
clear: both;
De ezzel csak egyféle entitástípusra lehet hivatkozni... :(
A probléma az, hogy az entity reference mezővel csak EGY adott entitástípusra (content, taxonomy term, comment, file, user, stb.) tudok hivatkozni, amit az elején, az első tartalom hozzáadásáig megadok, azonbelül a bundle-öket is be kell jelölni (igaz, be lehet jelölni az összeset, de mi van, ha időközben új content type-ot adok hozzá? Akkor lehet visszajönni ide mindig, és nem elfelejteni a pipát, különben anyázni fog a júzer, hogy miért nem működik a reference, de ez most mellékes, mert erre még lehetne írni automatizált kódot, lásd hook_node_type_insert :) ), és egyáltalán nem biztos, hogy csak NODE-OKNÁL (vagy épp csak taxonomy termnél, stb.) szeretném csak megjeleníttetni az adott blokkot, elképzelhető, hogy egy Views-zal létrehozott oldalon, Panels page-en, taxonomy term oldalon kell látszania a blokknak, mittudomén (akár ha az a kérés, admin-oldalon is, miért ne), tehát jóval általánosabban kell működnie annál, mint hogy csakis node-hoz legyen kötve.
De azt hittem, egyértelmű :P Azért is írtam "Küldetésünk" blokkot, mert az elég általános, több helyen is megjelenhet (ez az ukáz).
Amit mondtál, azzal nem látom be, hogyan jelenne meg a blokk a szokásos helyén egy Views-oldalon, ahol mondjuk a híreket (mindegyik egy külön node ugye) listázom ki.
Sajnos itt pont jelen van a kulcsszó, hogy ezzel csak node-ra lehet hivatkozni (vagy olyan entitástípusra, amit az elején, az első tartalom hozzáadásáig megadtál), aztán kész, más típust (akár Views-gyűjtőoldalt) innentől kezdve nem.
Nem ismerek olyan fieldet, ahol bármilyen típusú entitásra lehet hivatkozni (legyen az Panels-oldal, Views-oldal, node, taxonomy term, stb.), de ha van, ne tartsátok magatokban :)
====
A képen, amit linkeltem, jól látszik, hogy a megjelenési feltételeket az általam többször emlegetett Header image modul "Display conditions" elég általánosan meg lehet adni:
Szóval eddig még mindig ez tűnik a legjobb megoldásnak. Még ha fancy autocomplete felülete nincs is.
akkor nem reference hanem link
legyen akkor a bannerban a 'display at' mező egy link. itt urlt adok meg, hogy hol szeretném látni a bannert. akár többet is persze. és akkor ez a link field a contextual filter. így megjelenhet bárhol. persze nekem igazából teljesen mindegy ám, hogyan csinálod, csak ötletet próbáltam adni.
-
clear: both;
Köszönöm szépen, hogy
Köszönöm szépen, hogy foglalkozol a dologgal, remélem, nem tűntem hálátlan rohadéknak amiatt, hogy visszakérdezgetek, vagy felvázolom a potenciális problémákat, nem kötekszem, csak a megvalósítás számomra nem igazán világos egyelőre, meg az, hogy mi a gond az általam felvázolt megoldási lehetőséggel (teszteltem, működik, ahogy a feltételektől függő banner-megjelenítés is, de nyitott vagyok a jobb megoldásra).
Menjünk még bele picit plíz, ha nem gond!
Ez a link fieldes megoldás már járhatóbb útnak tűnik (habár az említett Header image modulban is ott van a linkelt képen az URL-mező, ami hasonlóan működik, mint a blokkoknál, ezenkívül van még a node id-s mező, meg a taxonomy termes is, így bővebb lehetőségeket kínál a feltételek megszabására), DE: OK, Views-ban megadom ezt a mezőt contextual filterként, de hogyan validálom ezt, mint a jelenlegi path kontra link fieldben megadott URL? A "When the filter value is available or a default is provided" részben van egy "Specify validation criteria", ott nem tudok ilyenről, hogy lehetne egyeztetni a jelenlegi URL-lel a kapott értéket, legalábbis külső modul nélkül (pl. ha jól értem, ez a modul ilyesmire használható, de akkor az plusz egy modul csak erre a feladatra) - legfeljebb PHP-kódot tudnék beírni ide, ami meg nem túl szép, mert PHP-kódot nem tárolunk adatbázisban. Vagy milyen megoldási lehetőségre gondoltál?
Köszi az eddigieket, meg az ezutániakat. :P
általában nem szeretem az ilyen modulokat
nem linkelted, de gondolom erről van a modulról van szó: https://drupal.org/project/headerimage
első mondat:
an _image_ érted..
általában nem vagyok híve az ilyen "egy dolgot csinálok" moduloknak. azokat a modulokat szeretem, amik absztraktak, általános funkciókat adnak, amikkel én legozom össze az éppen szükséges speciális funkciót. ez a drupal és kontribjai erőssége, más elterjed OS CMSekkel szemben. használhatod ezt a modult, de hajlítgatnod kell, hogy azt csinálja amit akarsz. általában próbálok közel maradni a maghoz, amennyire lehet, plusz olyan modulokat használni amik már szinte magnak számítanak és ezekkel összelegózni a kívánt működést. (ctools, views, panels, ilyen-olyan reference esetleg relations, flag, rules, ilyesmi modulokra gondolok)
inkább írok php kódot egy contextual filter kezelésébe (kb return $GET['q']), minthogy használjak egy "speciális" dolgot megvalósító modult, ami egyébként tökre nem azt csinálja amit akarok, tehát erősen hajlítgatnom kell. nem _headear image_ akarsz megjeleníteni, hanem valami mást, tehát a headerimage modult erősen alterezned kéne, hogy az történjen amit szeretnél. ennél _szerintem_ nagyságrendekkel "future proof" -abb, ha megépíted "kvázi-core" modulokból a funkciót. még akkor is, ha ehhez esetleg php kódot kell írnom egy nézet contextual filterének kezelésébe.
-
clear: both;
"ha ehhez esetleg php kódot
"ha ehhez esetleg php kódot kell írnom egy nézet contextual filterének kezelésébe."
Hiijj, na itt ledobtam a láncot, most mondd lécci, hogy nem a views ui contextual filter részébe akarsz php kódot írni, hanem mondjuk egy _pre_execute vagy hasonló hookra gondoltál..
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
De,a modul absztrakt, általános célokat szolgál, a neve ellenére
A nyitó hsz.-ben, az "itt korábban bemutattam" link alatti hsz.-emben ott szerepelt a link a modulra. :)
Igen, arról van szó.
Őőő, igen, "értem", ahogy a modul nevét is "értem". De úgy tűnik, épp számodra nem jött át, amit írtam: "Igazából amúgy magát a modult szerintem sokkal általánosabb névvel is elláthatták volna", és pontosan azért, mert sokkal általánosabb célt szolgál, mint az _image_ érted.. Lehet, hogy nem volt egyértelmű, amit magyaráztam, de pont azért jó ez a modul, mert annál jóval absztraktabb, mint hogy csak képet jelenítsen meg - nem is értem, miért nem gondolt a szerző arra, hogy kicsit szélesebb körnek is lehetőséget villantson valami találóbb névvel, mert a megoldás maga tök jó. Mondjuk nyilván ez csak akkor derül ki, ha vki kipróbálja. Szerintem fel is fogom vetni az ötletet az issue queue-ban, hogy tegye magát a nevet és a leírást is absztraktabbá, hátha lát benne lehetőséget a fejlesztő.
A lényeg: teljesen mindegy, milyen mezőt akarsz megjeleníteni a blokkban, ugyanúgy jelenik meg, ahogy egyébként szokásos (pl. egy node megtekintésekor), csak az az extra benne, hogy bizonyos tartalomtípusoknál (pl. "Banner", "Our mission", stb., épp aminél szerkeszthetővé akarod tenni a tartalmakat, és nem hatmillió blokkot akarsz létrehozni, hanem node-okként akarod kezelni) megjeleníttetheted a "display conditions" fület (amiről már mutattam egy párszor a screenshotot), ahol kiválaszthatod, a tartalom melyik előre definiált blokkba kerüljön (ahol majd a feltételek súlyozásától (!) fog eldőlni, melyik tartalom fog bekerülni épp az adott blokkba, melyik jut érvényre az adott URL-en/node id-nál/taxonomy termnél/megadott tartalomtípusnál; lehet egy default tartalom is, ami mindenhol megjelenik, ha a többi feltétel nem áll épp fenn), aztán a blokkot oda húzod, ahova akarod, lehet állandó helye, úgyis majd a feltételektől fog eldőlni, épp lesz-e ott tartalom, és ha igen, akkor melyik az előre beküldöttek közül.
Szóval inkább azért írod, hogy "nem szeretem az ilyen modulokat", mert nem ismered, meg valszeg nem volt teljesen egyértelmű a leírásom, de majd ha egyszer ráérsz, szánd rá azt a 10 percet, hátha neked is jól jön vmikor.
Én pont úgy vagyok vele, hogy inkább addig keresem az alternatívát, akár modulfejlesztgetéssel együtt, amíg nem kell PHP-kódot beokádnom az adatbázisba. Mert annál kevés rondább dolog van szerintem, mint UI-on - akár rövid - PHP-kódot írni. A potenciális problémákat gondolom nem kell sorolni.
Szerencsére ennél a modulnál nincs szükség ilyenre, egész általános célú, már amúgy is használom az oldalon dinamikusan változó banner céljára, amit a júzer is tud kezelni (úgy, ahogy, nyilván ez sem a legjúzerfrendlibb interfész, ezért vártam alternatívát, hátha ezt az ötletet hasznosították valahogy már egy fancy GUI-val), és teljesen az elvártak szerint működik, valamint kipróbáltam az általam felvázolt célra is, arra is megfelelő volt, így nem érzem, hogy ezzel a modullal csak feleslegesen terhelném a rendszert.
Ráadásul ugye alternatív megoldást sem találtunk eddig, egy olyan javaslat sem érkezett eddig sajnos, amivel különösebb tákolás nélkül megoldható lenne a teljesen általános megjelenítési feltételszabás.
De szívesen várom az ötleteket, ha van még! :)
És természetesen köszönöm az eddigi ötleteléseket.
sakk :)
lehet most már ki is kéne próbálnom ezt a modult mielőtt tovább ötletelek? :)
-
clear: both;