Sziasztok!
A segítségeteket szeretném kérni a következőben.
A főoldalt úgy szeretném kialakítani, hogy a középső (tartalom) hasábban felül van egy slideshow, ami a kiemelt híreket tartalmazza, majd alatta egymás mellett 2 blokk, az egyik a hírek, a másik a programok 5-5 elemét jeleníti meg.
Addig eljutottam, hogy a slideshow megvan és működik rendesen, valamint készítettem 2 blokkot, ami a 2 kategória cikkeit tartalmazza.
2 kérdésem lenne jelenleg.
Hogyan tudom megoldani, hogy a főoldalon csak ez a 3 blokk legyen? Most van egy 1 nevű cikk is, mert a az nincs, akkor kiírja, hogy még nincs tartalom létrehozva a főoldalra. Viszont én nem szeretnék tartalmat, csak a 3 blokkot.
Másik kérdésem, hogy lehet 2 blokkot egymás mellé tenni? Jelenleg a 3 blokk egymás alatt van, de azt szeretném, hogy a slideshow alatt a 2 kategória blokk egymás mellett legyen.
Előre is köszi a segítségeteket.
pikk, pakk
Legkönnyebben:
Panels és Page manager modul endélyezése, majd menj a admin/structure/pages/import oldalra és illeszt be ezt http://paste2.org/VC7vWjwy
Majd itt tudsz hozzaadni tartalmat: https://www.evernote.com/shard/s13/sh/e08dae2f-6c88-4951-9687-10170adde4...
Drupal full-stack developer at Wunderman Thompson Budapest
vagy manuál a sminkedben
tudsz készíteni egyedi tpl.php a címlapnak, ha lemásolod a page.tpl.php -t page--front.tpl.php néven. egyszerűen kiveszed belőle a render($content) sort és máris nem lesz 'content' a címlapon, így nem jelenik meg az üzenet se, hogy nincs címlapos tartalom. :)
vagy a template.php -ban megvalósítasz egy template_preprocess_page függvényt, amiben vizsgálod, hogy a $variables['is_front'] értéke true e és ha igen, akkor a $variables['content'] legyen NULL vagy FALSE.
a blokkokat pedig cssel rendezed egymás mellé.
-
clear: both;
akkó' má' mé'
Fúj! :D Nekem erről a gányolás szó jut eszembe :D
Vagy használja az API-t, amiről sokszor megfeledkeznek a zzemberkék: drupal_is_front_page(). (Igaz, ez a függvényhívás minimális overheadjével terheli a futást, de mivel static változóba van tárolva az értéke, ezért az első hívás után már nem is lesz olyan költséges a törzsben lefutó kód, ráadásul sztem szebb és beszédesebb kódot eredményez.)
Amúgy az egész macera helyett nem lenne már értelmesebb tényleg átállítani a site_frontpage változó értékét az admin-felületen keresztül olyan útvonalra, ami a másik megjelenítést mutatja? Pont mint amit csakiistvan javasolt, én inkább arra szavaznék. Főleg így, hogy importálható, copy-paste kódot is mellékelt. :)
kb annyi írni egy saját
kb annyi írni egy saját modult emi megvalósít egy hook_menu -t és beletenni 3 változót, meg a saját tpl-be a diveket amíg az első hozzászólásomat megírtam... tisztább és szebb lenne az egész, nem kellene hozzá 2-3 másik benga modul... de hát gyorsabb volt összekattintgatni és exportálni a panelt mint elmagyarázni hogy is kellene szerintem jól.
Drupal full-stack developer at Wunderman Thompson Budapest
kellhet amúgy is
Jaja, egyértelmű, meg hát úgy tűnt, a kérdező még nem merült bele a modulfejlesztés gyötrelmeibe. Ezenkívül még hasznát veheti a Panels+Page manager párosnak.
nincs olyan, hogy az egyetlen univerzális igaz út
fúúúj hát, persze! de ha például meg vagy áldva egy 64 megabájtos memória korláttal, akkor sok sikert a page manager + panels kombóhoz :) ami egyszer gányolás, másszor lehet, hogy okos körüldolgozás. a csodálatos sminkréteg többek között azért is olyan csodálatos, mert pofon egyszerűen lehet benne ilyesmi dolgokat elkövetni, batár mammutmodulok nyakunkba vétele és aztán egy életen át cipelése nélkül. persze elismerem, with great power, comes great responsibility ;)
ha nekem kellene ilyet csinálnom, úgy csinálnám, ahogy szoktam, panels és page manager kombinációjával. ettől függetlenül gondoltam nem árt, ha ideírom, hogy egyébként amúgy is lehet. meg még lehet máshogy is, azokra majd kitérek, ha ez a kettő nem lenne elegendő.
ha már így belemászunk, a drupal_is_front_page() hívásnak pedig semmi overheadje nem lesz a template_preprocess_page -ben, mert mire ideértünk, már többször is meghívtuk. igazából azt is mondhatjuk sosincs overheadje, mert például a system modul hook_initje is hív egyet :)
-
clear: both;
van overhead
A fújt arra írtam, hogy először összepakoltatod egy tömb tartalmát (még ha abban kevés tartalom is van, vagy konkrétan nincs), aztán egyszerűen kiszeded a kiíratását - ugyanúgy dolgozik vele a Drupal, csak tök feleslegesen (jó, igen, a Panels még sokkal jobban megdolgoztatja, úgyhogy erre a témára pont nem jó alternatíva, spórolásra a saját modulos útvonal-definiálás hook_menu-ben jó, amit csakiistvan ki is fejtett, annak beállítása az új frontpage-ként, majd egy kis CSS), ráadásul amikor később meggondolja magát, mégis akarja a szokásos frontpage-et, és elfelejti, hogy hoppá, itt mit is csinált, és mégis akar tartalmat belerakni, akkor majd szívhat vele, hogy ja basszus, de a
render($content)sort kiszedte, így aztán várhatja a végtelenségig, hogy ott össze legyen állítva a tartalom... szóval sztem az ilyen hibalehetőségek elkerülhetők egy másik útvonal definiálásával (főleg, ha mondjuk a $contentben lenne érdemi tartalom is, csak ide nem kéne neki, akkor gány kitörölni a kiíratós sort sztem). Na de amúgy sem kell magadra venni, ha valaki vitatkozik az általad javasolt módszerrel, nem bántásként írtam, hanem csak szakmai vita kibontakoztatására. :) Nyilván nincs egyetlen igaz út, többféle megoldás is van, csak van, ami ésszerűbb lehet, mert mondjuk hosszú távon nem kínál akkora tévedési lehetőséget.Mindenesetre bocs, ha sértőn vagy fölényesen hangzott, tényleg nem az volt a szándékom.
Igen, magának a függvénytörzsnek nyilvánvalóan nem lesz overheadje, mivel eddigre már "ötezerszer" meghívódott (mondjuk azt hittem, egyértelmű abból, amit írtam, hogy eddigre már nem lesz "költséges" a meghívása), de létezik olyan, hogy függvényhívás-overhead... ha találkoztál kismértékben is spórolós környezettel, akkor vágod... (amúgy assembly-kódolásnál sokszor előjöhet olyan feladat, hogy kerüljük el az ide-oda ugrálást, stack-mentéseket, felesleges plusz időket, beágyazott rendszernél pl. nem mindegy)
Nyilván itt nem beágyazott rendszerről beszélünk, de sokszor látom Drupal-modulok kódjában, hogy a fejlesztőjük szeret nagyon pazarolni, ezt már többször említettem - tipikus hiba például, hogy azonos függvényen belül többször meghívják ugyanazt a függvényt, ahelyett, hogy letárolnák az értékét egy változóba. És akkor ez csak egy a sok közül. Overhead jelentkezhet függvényhíváskor, és költségesebb lehet, mint egy változó értékének felhasználása. De igazából itt az overheadet inkább mellékes infóként jegyeztem meg.
nem hangzott sértőn, szívesen eltrécselgetek bármiről bármikor
tulajdonképpen én nem vagyok képzett programozó, úgyhogy "spórolós környezettel" még sose találkoztam, középiskolába láttam ugyan assembly kódot, de nem igazán villanyozott fel :) elhiszem, hogy szakmailag úgy precíz ahogy mondod/mondjátok, de az elmélet gyakran más, néha egészen más, mint a gyakorlat.
arra vonatkozólag semmilyen mérés nincs, bár megnéznék egyet, hogy melyik a pazarlóbb, ha direkt ezér csinálok egy külön modult aminek van egy hook_menuje, vagy ha egyszerűen kivágom a preprocessbe a kontentet mint macskát, aztán viszlát. az "én preprocessem" semmi pluszba nem kerül, egyszerűen kidobok valamit ami már amúgy is ott van. értem én, hogy ez pazarlás, mint amikor kipiszkálgatom a túrós rétesből a mazsolákat, de egy plusz modul viszont tuti plusz memória, ha tippelnem kéne. sőt, plusz egy sor a system táblába! overhead!! betelllikk a vincsesszter! ;)
arra akarok csak finoman kilyukadni, hogy _szerintem_ úgy általában a drupalban ilyen "nullra vágom a $content" megoldások overheadjéről túl sokat vitázni nemigen érdemes, ha úgy nézzük az esetek nem kis részében az egész drupal maga egy büdösnagy overhead :) persze nem azt akarom ezzel mondani, hogy nem is kell foglalkozni semennyit azzal, hogy valami mennyire erőforrás igényes, de azért a címlap ilyen formájú meghajlítgatása nem kimondottan az a tett amiért nagyon kéne, hogy fájjon a fejem. a függvényhívás-overhead meg pláne nem. viszont ahogy szépen leírtad, akkor inkább a $vars['is_front'] a jobb és nem a drupal_is_front_page() mer' annak akkor nincs függvényhívás-overheadje, hanem pont egy drupal_is_front_page visszatérési értékének letárolása, ahogy azt te is felvázoltad. :)
például hogy egy képgaléria borítókép megoldáshoz ;) használjak e field collection modult, na az már olyan amin érdemes gondolkodni, bár azon is inkább csak nagy forgalmú nagy site esetén. de hogy most nullra vágom a címlapon a kontentet, hát ez kábé akkor se érdekes, ha amúgy a bcc.co.uk -ről beszélünk. bár lehet ezér nem én építem azt :D
hogy kinek mi a fenntartható, megjegyezhető megoldás, az meg már nagyon szubjektív. ilyen szempontból a preprocesszem legalább kódba van, nem egy nyomi szetting ;)
szívesen elvitatkozgatok ám még ezen, de szerintem több, mint jól értjük egymást és a kérdező se jut ezekkel sokkal többre.
-
clear: both;
Kicsit jobban átgondolva
Kicsit jobban átgondolva igazából tényleg már szinte kötekedésszagúnak tűnik, amit írtam, pedig nem annak indult :D Az is egy jogos szempont, amit felvetettél, hogy a külön erre létrehozott modul akkor már jobban hozzájárulhat az overheadhez, de külön modul a contrib modulokon kívül úgyis mindig kell, legalábbis nekem még nem volt olyan, hogy ne kellett volna pluszban belenyúlnom akár valami apróságért :)
De amúgy ha már, akkor már a template_preprocess_page()-megoldásod tűnik nekem a legjobbnak, hogy még ott vágod ki a tartalmat NULL-ba, ha ilyen kell, bár az is igaz, hogy magának a tömbnek a passzolgatása tudtommal nem para, mert referencia szerint adódik át PHP-ban, amíg nem történik rajta módosulás, tehát nem lesz mindig másolgatva a tömb tartalma (nem növeli a memóriaigényt) - de az is igaz, hogy útközben simán belenyúlhat mégis valaki :D Na, ezt jól átrágtuk, végül is sztem nem volt kártékony a szakmai dumálgatás, nekem jólesett :D
Köszönöm
Sziasztok!
Köszönöm mindenkinek a segítséget, a kiírást sikerült eltüntetni a főoldalról, hogy nincs még tartalom, a 2 modult egymás mellé helyezni pedig este próbálom meg.