eFeS képe

..hogy mi volt az eredeti kérdés.

A 7-es drupal galéria készítése még mindig csak manuálisan megy rendesen, sajnos.

Amit ajánlani tudok:
- a fenti multiupload widgetek
- colorbox
- thumbnail és nagy nézetre kép sílus megadása a beállításokban
- egy dedikált (galéria) tartalomtipus külön indexkép és multipuload-os galéria, dátum és leírás mezőkkel, ha szeretnéd variálhatod tovább taxonómiákkal meg akármivel
- egy galéria tartalom beküldése lesz egy album, a tartalomtípusban lévő mezők alapján lehet még tovább csoportosítani (pl. taxonómiák)
- az "album" oldalt simán nézetekkel meg tudod csinálni az indexképek és a dátumok használatával
- egy album kifejtése lesz a tartalomtipus megjelnítése. Itt állítsd be, hogy a galéria mezőt a colorbox kezelje le (megjelenítési beállítások az adott tartalomtípusnál)
- kell egy field template a galéria mezőre az adott sablon könyvtárába a galéria mezőre (field--.tpl.php)
- és egy kis ízlés szerinti CSS

Itt egy működő példa:
http://www.vhf.hu/fomenu/bemutatkozas/foiskola-tortenete

4
0

---------------
Tátrai József
Drupler Kft.
http://www.drupler.hu

Darkstar képe

Szia!

Először is köszönöm a választ.
Miután néhány napot eltöltöttem a problémával, rájöttem hogy elég nagy butaságot kérdeztem.

Átrágtam magam a Views modulon. Nagyon jó! Szinte bármilyen listát tudok vele készíteni. Sőt blokkot is meg oldalt is tud, és még menübe is tudja rakni. Kész kánaán! Úgyhogy a Taxonomy -t ki is hagytam a dologból. Views mellett nem nagyon van rá szükség.

Token már megy a mezőknél, bár az autocomplete mezőnél még nem próbáltam. A megjelenés beállításainál, az "Alapértelmezés szerinti megjelenítési beállítások
" fül alatt ki kell pipálni a "Vezérjelek" pontot és működik. Telepítettem a Token filter modult és már a tartalomban is mennek a vezérjelek.

Jelenleg az Entity -vel ismerkedem. Remélhetően ezen is átrágom magam hamarosan. Ha tényleg olyan jó, mint ahogy írják, márpedig miért ne lenne, akkor felteszi a Views -re a koronát. A kettővel együtt szinte bármilyen tatalomszervezést meg lehet valósítani.

Még csak most kezdtem a Drupal -al komolyabban foglalkozni, ez az első oldalam, de már látom olyan mint egy svájci bicska. Meg kell tanulni, ez több idő, de aztán szinte bármit el tud készíteni benne az ember fia. Még akkor is ha nem programozó.

0
0
resi képe

Kedves DruTa!

Köszönjük a hasznos észrevételt és javaslatot a Drupal.hu adminisztrátor csapata mérlegelni fogja.

Kapcsolati témakörhöz: talán értesültél róla, hogy hosszas előzmények után az idei évben megalakult a Magyar Drupal Egyesület, mely időközben jogi személyként átvette többek között a Drupal.hu oldal működtetését, fenntartását és fejlesztését is, támaszkodva továbbra is a a drupalhu munkacsoport és a hazai közösség tagjainak megbecsült munkájára.

Számos folyamatban lévő feladatunk között dolgozunk már az Egyesület weboldalán is, mely természetesen tartalmazni fogja az elérhetőségeket is és kapcsolatban lesz a Drupal.hu oldallal is.

Javaslatod alapján hamarosan bevezetésre kerül egy Impresszum menüpont is az oldalon.

Addig is örömmel fogadjuk visszajelzéseidet, javaslataidat az alábbi kommunikációs csatornákon:

1) Drupal.hu Fórum
2) MDE központi e-mail címe: [email protected]
3) SLACK: https://drupalhu.slack.com/ ahova igény esetén meghívót örömmel küldünk e-mail címedre

Reisinger Gábor
Magyar Drupal Egyesület
elnök

0
0
pp képe

A kérdés nem egyszerű, hisz nem ismerjük a környezetet, sőt számomra az sem teljesen világos, hogy a "Ez mennyire érint engem biztonsági oldalról?" mondatban az engem, mit jelent. Vagyis Te milyen szerepben vagy?

Te üzemelteted a Drupalt és más fejleszti a mobil applikációt, és megint más a tulajdonos?

Mert akkor itt nem biztonsági kérdésekről van szó, hanem felelőségi és együttműködési körökről.

Üljetek le hárman, a másik fejlesztőcéggel és a tulajdonossal, és beszéjétek meg, hogy mi lesz akkor amikor baj van. Hogyan fogjátok felderíteni a hiba okát, ki fogja elhárítani, hogyan fogjátok tesztelni stb. Mert itt a tulajdonosnak kell megérteni, hogy ha gond van, és ti elkezditek focizni ide-oda, akkor az neki nem jó. Nem csak azért fogjátok focizni, mert nem akarjátok, hanem mert nem, vagy csak nagyon körülményesen fogjátok tudni megoldani a problémát. Hisz a problémát csak akkor lehet megoldani, ha az felderíthető (tesztelés, logolás), egy megoldás csak akkor működik majd megbízhatóan, ha az aki csinálja érti, hogy mi történik, és akkor nem fognak elmérgesedni a viszonyok, ha egyértelmű lesz, hogy ki, mikor, mit és miért csinált. (verziókezelés, közös workflow)

pp

3
0
aboros képe

a hideg futkos a hátamon az artisztirtől, de végülis nagy nehezen meglett a probléma. a style.css 468. sorában kezdődő selectorral van a gáz, rögtön kettő is:

.art-slidecontainerheader .art-slide-item valamiért kapott display: none; és opacity: 0; direktívákat is, mindkettő azt eredményezi, hogy nem láthatóak ezek az elemek.

fogalmam sincs, hogy az artisztiren belül mi okozta ezt vagy hogyan lehet az artisztirben megoldani, esetleg kérdezd meg az artisztir supporttól ezt.

amint kiiktatom ezt a két tulajdonságot, egyből megjelenik a kép, amint ezen a screenshoton is látható: https://cdn.pbrd.co/images/weleRbPpe.jpg

0
0

-
clear: both;

Illyés Edit képe

Szia csonti,

szétnéztem a portálodon, és pontosan erre gondoltam, ilyeneket kell nekem is gyártani nagy tételben.

Van a Firefoxhoz egy Screengrab nevű kiterjesztés, bár nincs még meg az FF 2 verzió. Korábban dolgoztam vele és nagyon kényelmes volt, jpeg fájlként rögtön lementette a böngészőablak képét, nem kellett ide-oda lépegetni a böngésző és a grafikai program között.

A power-kézikönyv az ügyfél szempontjából valószínűleg sokkal jobb, mint a sima weblap leírás. De a saját szempontjainkat is figyelembe kell venni: egy-egy leírást, képernyőképet gyorsan megtalálni, jobb egérgombbal kijelölni-másolni-lementeni, node-okat, egész könyvet exportálni-importálni, nyomtatóbarát verzió, PDF verzió, stb. Szerintem ezt a rugalmasságot csak a hagyományos Drupal könyvlap adja.

Végül is az egészhez csak annyi kellene, hogy aki be akar kapcsolódni, az kapjon .jpg, .gif, .png csatolási jogosítványt, meg legyen egy könyvlap, ami alá elkezdhetjük feltölteni a dolgokat. A többi meg majd kialakul... Én szívesen csinálnám, nekem most édes mindegy, hogy 1 vagy 2 helyre töltöm fel lényegében ugyanazt az anyagot...

Ui.: Ja, és persze kellenének a kép paraméterek. Elég szűk itt a hely a fő tartalmi blokkban.

0
0
Illyés Edit képe

  1. Létrehozol egy tartalomtípust, mondjuk "rovatoldal" néven.
  2. Kiegészíted a rovatoldal tartalomtípust a kívánt view reference és node reference mezőkkel (cikklistákhoz és node-ok behívásához, igény szerint).
  3. Elkészíted Views modullal a nézeteket, amelyek kilistázzák a blokkokba a cikkeket. Elkészíted az önálló node-okat, amelyeket be szeretnél hívni a rovatoldalon.
  4. A Tartalom beküldés -> rovatoldal menüpont alatt beküldesz egy rovatoldalt. A beküldő űrlapon ott lesznek a view reference és node reference mezőid, egyszerűen kiválasztod, hogy az adott rovatoldalon az adott mező melyik nézetet/node-ot hívja be.
  5. Ha nem tetszik az elkészült rovatoldal típusú tartalom megjelenése, akkor Contemplate modullal, ill. a nézetek sminkelésével (lásd a Views Theme Wizard szolgáltatását) tudod a HTML-t kedvedre alakítani.

Ennél egyszerűbb megoldás, hogy a rovatoldal egy egyszerű page, amibe Insert View és Insert Node modullal beszúrod a kívánt Views blokkokat és node-okat. Ennek hátránya, hogy ha laikus szerkesztőség van, akkor változtatásnál bele kell javítani a page kódjába, ami ugye HTML kódból és az Insert modulok szűrőiből áll, míg a fenti bonyolultabb megoldásnál legördülő listákból választhatnak, ami barátságosabb felületet kínál a szerkesztőségi munkához (viszont jóval memóriaigényesebb).

0
0
Illyés Edit képe

Az egyik legfontosabb dolog amit végig kell gondolni, az a felhasználók menedzselése. A nem regisztrált felhasználó cache-ből kapja a tartalmakat, a regisztráltnak minden egyes oldalt frissen rak össze a Drupal. Nagyot lehet hasraesni identitás-zavaros projektekkel, amikor pl. nem tudjuk eldönteni, hogy most hírportált üzemeltetünk, vagy közösségi portált. Bonyolult hírportálos listázó blokkokat teszünk ki nagyszámú regisztrált felhasználónak, akiket aztán élesben kell kiszolgálni. Láttunk erre példákat az utóbbi időben.

Vannak technikák, amelyekkel meg lehet próbálni menedzselni az ilyen helyzeteket is (Block Cache, felhasználói aktivitást igénylő oldalak elkülönítése-kiszervezése, stb. ) De ezek már kényszermegoldások.

A Views-t is lehet okosan használni (listázó nézet), meg nem okosan (teaser nézet). Mérlegelni is kell olykor, pl. a sima filteres view-kat betárazza, az argumentumosakat futtatáskor élesben rakja össze – másrészt viszont könnyen előfordulhat, hogy 5-6 jól átgondolt argumentumos nézetre fel lehet húzni egy egész portált, toronyórával, lánccal. Egy összetettebb webhely kézzel írt lekérdezésekkel olyan, mint a nagymama konyhaszekrénye – minden zugban van valami finomság – ezt aztán tartsa karban akinek két anyja van.

Napi többszáz-ezer oldalletöltésnél viszont már a cache sincs ingyen, ott már nagyon kell számolni.

0
0
Illyés Edit képe

Az index karbantartása okoz nehézséget. Ha nagyobb mennyiségű tartalom van a webhelyen, könnyen lehet, hogy több millió rekordos táblákat kell kezelnie a MySQL-nek. Ez már komoly rendszerüzemeltetési feladat, egy szokásos osztott tárhelyen előbb kivág a szolgáltató, minthogy eljutnál a millió rekordig. :)

Google beágyazása: fizetni kell azért, hogy a saját felületeden jelenjenek meg a találatok. Egyes webhelytulajdonosok idegenkednek attól, hogy a felhasználó átkerül a Google felületére.

Szerintem meg ez jó, mert azt a felületet már jól ismeri a látogató, otthon érzi magát. A találati lista is jobb, azért a Google súlyozó algoritmusa kicsit fejlettebb, mint a Drupalé. :) Amikor elindult az Apache Solr projekt, akkor volt Robert Douglass-nek egy vicces előadása: megpróbálta megtalálni egy nagyon konkrét kifejezésre keresve az egyik cikkét egy Drupal oldalon. A Google az első helyen dobta ki, a Drupal keresője meg valahol a 10. oldalon. :D (A Drupal kereső finomhangolásával ezen lehet valamennyit javítani, azt hiszem, az előadásban elmondja, vagy valahol leírja, hogy hogyan.)…

És van, aki egyszerűen sznob, ugyanúgy elutasítja a Google kereső beépítését, mint ahogy lenézi azt, akinek Gmail-es email címe van sajátdomaines helyett. Számomra ez érthetetlen, de vannak ilyen népek, akik ez alapján ítélnek.

0
0
Illyés Edit képe

Ahogy írtam, a Context-et nem ismerem, nincs összehasonlítási alapom.

A Panels tökéletesen megfelel arra, amit írtál. Hogy megéri-e, az csak utólag fog kiderülni. :) De legrosszabb esetben majd a következő projektnél fogod hasznosítani a megismerésére fordított időt.

A Mini panels arra jó, hogy több blokkot összefoghatsz egy csokorba, és a csokrot teszed ki egyik vagy másik panelbe egy meghatározott helyre. Egy-egy blokk tetszőleges számú csokorba bekerülhet. De nem muszáj a Mini panels-t használni, ez is csak egy kényelmi szolgáltatás, hogy kevesebbet kelljen kattintgatni. Például ha A, B, és C útvonalon külön-külön paneljeid vannak, de mindhárom esetben ki kell tenni az Aktív fórumtémák és az Új munkaajánlatok blokkot, akkor ezekből csinálsz egy minipanelt, és a minipanelt teszed ki a három panelbe.

A súlyokat az áthúzós felületen áthúzással állítjuk. :) Ha X útvonalon a blokknak z helyen kell lennie, Y útvonalon pedig w helyen, akkor két külön panelt készítünk, felvesszük a blokkot a megfelelő helyekre, és beállítjuk, hogy az első panel X útvonalon jelenjen meg, a második pedig Y útvonalon. (De persze lehet PHP kóddal és még sokféle megoldással operálni. Tényleg csak kávét nem...)

1
0