mai cikk
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
node.tpl.php
Aries alighanem arra gondolt, hogy a node-ok megjelenítését a node.tpl.php sablon segítségével ajánlott végezni, az ugyanis pont erre van kitalálva...;)
Miért akarnád mondjuk egy admin oldalon megvizsgálni, hogy van-e az (éppen nem létező) $node-ban csatolt fájl?
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
hogyan használjuk a tpl fájlt
Az állandó elemek egyike egy, a képernyő jobb oldalán megjelenő terület, ami minden oldalon jelen van, de bizonyos esetekben kell, hogy tartalmazza a node-hoz csatolt képeket.
Gondolom, csak node oldalakon kell, hogy a csatolt képek megjelenjenek. Nekem ez logikailag egy blokk a jobb oszlopban, aminek a megjelenítését a block.tpl.php-ben szabályozom.
Egyelőre számomra továbbra sem világos, ez most hogy függ össze a kérdésemmel.
Nagyon könnyű a tpl.php fájlokban kódolási hibát, biztonsági rést hagyni. Érdemes mindig arra gondolni, hogy a template fájlok lényegében HTML fájlok, amelyekben PHP változókat íratunk ki – és nem PHP fájlok, amelyekbe itt-ott bedobunk egy kis HTML-t.
Rossz gyakorlat:
<?php foreach($node->files as $file) { $imagePath = $file->filepath; $imageTitle = $file->description; if($imagePath != "") { print '<div class="image-attach-body"><img src="'.base_path().'/'.$imagePath.'" alt="" title="'.$imageTitle.'" class="image image-thumbnail "/></div>'; } } ?>
Helyes gyakorlat:
<div class="image-attach-body"> <img src="<?php print $base_path; ?>/<?php print $imagepath; ?>" alt="" title="<?php print $imagetitle; ?>" class="image image-thumbnail "/> </div>
...ahol az $imagepath, $imagetitle változókat a template.php-n keresztül adod át át a tpl.php fájlnak. Tehát template fájlban nem programozunk, csak változókat íratunk ki, aztán örülünk, hogy minden biztonságos, szépen működik, tiszta, száraz érzés...:)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
admin/settings/error-reporting
Az admin/settings/error-reporting oldalon megadhatsz saját 403-as oldalt, ami lehet a /user is. Login után szerintem magától visszavisz az előző címre, de ezt le kell csekkolni. Ha nem, akkor a login formot beteszed egy node-ba, megbuherálod (drupal_goto()), és beállítod 403-asként.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
több kép megjelenítése
legrosszabb esetben a template.php-ban kell ezt a tartalmat előállítanom
A template.php azért van, hogy ott programozzunk. Például ott deklarálok saját változókat és töltöm fel őket értékekkel, aztán átadom őket a template fájlok számára (a tpl.php nevű fájlok a sminkmappában), ahol ki tudom őket íratni HTML címkék közé. Ez nem "legrosszabb eset", hanem így van a rendszer kitalálva.
template.php:
<?php function _phptemplate_variables($hook, $vars) { switch($hook) { case 'sajatsablon' : $vars['egyikvaltozo'] = 'izé'; $vars['masikvaltozo'] = 'valami'; break; } return $vars; } ?>
sajatsablon.tpl.php:
<h1><?php print $egyikvaltozo; ?></h1> <p><?php print $masikvaltozo; ?></p>
HTML végeredmény:
<h1>izé</h1> <p>valami</p>
Ha nem tudom a kívánt változókat a template.php segítségével átadni a template fájloknak – mert mondjuk az az érték, amivel a változómat feltölteném a $node objektumban van, ami nem érhető el a template.php-ből – akkor nem a tpl.php fájlokat kezdem el összekuszálni, hanem modult írok a feladatra.
Nem értjük, miért nem megy az általad megadott PHP kód, és el lehet kezdeni debuggolni, de szerintem gyorsabban el lehet jutni a működő megoldáshoz, ha szabályosan használjuk a Drupal template-ező rendszerét.
a "Helyes gyakorlat" alatti rész továbbra is csak egy kép megjelenítésére alkalmas...
A template fájlok többször meghívhatók. Például a node.tpl.php, block.tpl.php is annyiszor fog meghívódni, ahány node/blokk van az oldalon.
Készítesz egy kis modult, ami lekéri az aktuális node-hoz csatolt képeket, végigmegy rajtuk egy ciklussal, theme_image függvény segítségével elkészíti a HTML kimenetet, amit végül betesz egy blokkba. A blokkot pedig beteszed a jobb oszlop régiódba.
A theme_image függvényt a template.php-ben, a blokk megjelenést a block.tpl.php-ben (vagy ennek valamelyik alváltozatában) kedvedre alakíthatod. Mindkettő pont annyiszor fog meghívódni, ahányszor szükséged van rá – és ha betartod az elnevezési konvenciókat, akkor teljesen magától.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
admin/content/node
Tudtok-e olyan kiegészítő modulról, amelyel megoldható az, hogy a viewban (node listában) bepipált (kiválasztott) node-okon egyetlen kattintással tudja a felhasználó átállítani a feldolgozttságot nem feldolgozotról, feldolgozás alattira például. Tehát csoportosan megváltoztatni a kijelölt node-ok kategóriáját?
Az /admin/content/node oldalon van egy ilyen jellegű interfész, onnan tudsz kódot/ötleteket lopni egy saját modul számára.
Frissítés: Lásd Thamas fenti linkjét (Views Bulk Operations) – pontosan ezt csinálja:
As an example, the module comes with a re-implementation of the Content admin page. To access it, just go to the URL admin/content/node2.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
nem ftp?
csak ftp-n keresztül egy könyvtárba és kézi importálás, ezt nem akarom a felhasználókra bízni :-)
A mass upload nem azt jelenti, hogy ftp-n keresztül töltenek fel? Ha nem ftp, akkor hogyan szeretnéd?
Egyébként galériára a legrugalmasabb megoldás a CCK + Imagefield + Imagecache.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
alakul...
A Drupal 6-ban végre lehetővé vállt, hogy mindenféle PHP smink tudás nélkül, csupán CSS sminkeket készíthessünk a Drupal alap HTML kódjára építve.
Erre eddig is volt lehetőség, bármelyik meglévő smink CSS fájljainak módosításával. A CSS designereket az riasztja el – és a profi themereket az idegesíti –, hogy nem kapnak szabad kezet a CSS struktúra kialakításakor. Mindenkinek megvan a kedvenc módszere arra, hogy hogyan rétegezze egymásra a stíluslapokat úgy, hogy a kód egyszerűen fejleszthető és karbantartható legyen:
- browser-reset.css (böngésző alapbeállítások lenullázása)
- layout.css
- typography.css
- colors.css
- ... stb.
Én a következő módszert használom:
- browser-reset.css
- basic.css (általános stílusok HTML elemekre – p, a, blockquote, fieldset, stb.)
- tpl.css (stílusok a .tpl.php fájlokban szereplő HTML elemekre – időnként tpl.php fájlonként szétbontva, hogy könnyebben átlátható legyen, főleg CCK-Views sminkelése esetén)
- drupal.css (CMS funkciókhoz – admin interfész – szükséges stílusok)
- sminkneve.css (a maradék, azaz egyéni blokkok és az összes alsóbb szintű, specifikus stílus)
Ezzel szemben a Drupal rákényszerít arra, hogy modulok szerint szervezzük a stíluslapokat:
- system.css
- aggregator.css
- book.css
- ... stb.
Első ránézésre van benne logika, csak aki napi 8 órában CSS-szel foglalkozik, az tudja, hogy egy ilyen módon szervezett CSS megírása és karbantartása dupla munkát jelent.
Az egyetlen ésszerű munkamódszer az, hogy első körben lenullázzuk a böngészőket, utána pedig valamilyen logika szerint az általánostól (p, a, blockquote) haladunk a specifikus (#wrapper #container .sidebar .block p) felé.
Az pedig, hogy ki milyen logika szerint szeret dolgozni, egyénileg eltérő. A lényeg, hogy a fenti, általános -> specifikus irányba menjen, akkor 5 perc alatt kiigazodom egy másik tervező fájljaiban.
Ha jól értem, a Drupal 6-ban annyival lesz jobb a helyzet a mostaninál, hogy például a Drupal által adott system.css-t lecserélhetem a sajátomra, nem kell a felülírni. Ez egy félmegoldás, én biztos nem fogom használni. Maradok a régi jól bevált gányolásnál, és a page.tpl.php-ben kikapcsolom az összes beépített stíluslapot.
Az egyébként nagyszerű, hogy a template fájlok (.tpl.php) nagyobb figyelmet kapnak és könnyebben kezelhetővé válnak.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
korrekt megoldás
Szerintem nem írja tele
Tényleg nem írja. :) Régebben, talán még a 4.7-es, 4.6-os időkben volt olyan, hogy ha nem találta a style.css-t, akkor hagyott egy hibaüzenetet a logban.
Akkor ez így egy teljesen korrekt megoldásnak tűnik – mindenesetre sokkal szebb, mint láncfűrésszel hadonászni a page.tpl.php-ben. Köszi az infót. :)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
szerintem is
Igen, szerintem is ebben kellene gondolkodnia a Szakdolgozónak. Még lehet, hogy üzletileg is életképes lenne egy ilyen önkormányzatokra specializálódott Bryght-szerű szolgáltató.