Illyés Edit képe

Nyomtatás: Printer Friendly modul
Továbbküldés: Send vagy Forward modul
Betűméret: biztos van rá valami, én sminkben szoktam megoldani

0
0
Illyés Edit képe

Írd be a következő sort a settings.php-be:

ini_set('error_reporting', 'E_ALL & ~E_NOTICE');
0
0
Illyés Edit képe

Kb. egy éve volt egy beszélgetés az admin levlistán arról, hogy hogyan kellene továbblépni. Ott alapvetően azon akadt el a dolog, hogy nem tudtuk eldönteni, kik a Drupal.hu felhasználói, ill. kiket szeretnénk a jövőben bevonni. Mivel már a kiindulópont sem volt fix, nem volt olyan szempontrendszer, amire fel lehetett volna építeni az egész projektet, színekről meg margókról folyó vitába torkollt az egész, aztán pár hét után elhalt a dolog. Utána Gábor frissítette a design-t a mostanira, aminek a legnagyobb érdeme, hogy senki nem utálja, mindenki együtt tud vele élni.

Az egy érdekes kérdés, hogy akik már itt vannak, mit csinálnak a honlapon, ezt lehet egy kicsit kutatni is. De a vita lényege az volt, hogy hogyan tovább. Egyik sarkos álláspont szerint elsősorban az üzleti élet felé kell mutatnunk magunkat, tehát a Drupal.hu a profi fejlesztőket segítené abban, hogy komoly megrendeléseket szerezzenek – ennek megfelelően a showcase lenne a hangsúlyos, a gittegylet benyomást keltő, fésületlen fórumot ("SEGÍTSETEK PLS!!!!") pedig el kell rejteni a potenciális megrendelők szeme elől (nem értik, mi ez, elriasztja őket).

Másik sarkos álláspont szerint a közösség mozgatja az egész projektet, a kezdő végfelhasználót kell kiszolgálnunk címkézéssel, kézikönyvvel, fórummal, okos keresővel, stb. aztán a nagy számok törvénye alapján a tömegből mindig kiválik pár ember, akik komoly drupalosok lesznek, kóddal vagy más módon hozzájárulnak a projekt sikeréhez. (Ezt láttuk is mostanában, sok az új aktív tag akik 1 éve még nem voltak itt.)

Ugyanezek a problémák jelentkeznek a drupal.org-on is, érdekes lesz majd figyelni, hogy merre megy el a dolog. Érzékelhető, hogy az egyre több profinak igénye van arra, hogy a Drupal üzletileg eladható legyen ("ügyfelek nem értik az ufófej logót, cseréljük le", stb.), másrészt ott a masszív végfelhasználói tábor, a hátország amit bővíteni kell, mert az elitista open source projektek hajlamosak a kifulladásra. Érdekes lesz majd látni, hogy merre billen a mérleg nyelve – vagy esetleg a redesign team elő tud-e állni egy olyan megoldással, ami minden igényt ki tud szolgálni.

0
0
Illyés Edit képe

Oszinten az egesz drupal kodbol az a resz erdekel amely a HTML kodot nyomja ki, es amit sminkelni lehet.

A 6-os kiadáshoz tartozó Devel modul szépen megmutatja, hogy egy adott HTML kódrészlet honnan, melyik sminkfüggvényből jön. Másik tanulási módszer, hogy itt-ott belenyúlsz a kódba (page.tpl.php, node.tpl.php, phptemplate.engine, modulokban lévő theme függvények, kész sminkhez kapott template.php), és megnézed, mi történik. Sminkeléshez elég ennyi, modulfejlesztéshez vagy sminkmotor írásához (miért nem jó a PHPTemplate?) ott a Pro Drupal Development könyv.

0
0
Illyés Edit képe

taxonomy meg dísznek van? :)

Nem, de egy term-nek csak neve, leírása, szinonímái, szülői/gyermekei vannak, a node típus pedig tetszés szerint bővíthető.

hogy magát az üzletet hogyan kötöd a term -hez, arra tucatnyi ötletet tudok elképzelni

Hallhatnánk ebből a tucatból egy párat?

nekem eddig az tűnt praktikusnak, hogy magát az 'üzlet' típusú tartalmat is beleteszem a saját maga term -jébe az 'üzletek' szótárban.

Nekem meg pont nem tűnt annak, elég szerencsétlenül jön ki, hogy a 45. sz. csemegebolt benne van a 45. sz. csemegebolt nevű kategóriában (az üzlet által árult termékek mellett). Sminkben ezt a kategóriát el kell rejteni, és ha több száz üzleted van, amelyeknek sok a tulajdonsága, akkor nagyon könnyen egy kezelhetetlen taxonómia-dzsungellel kell dolgoznod. Mondjuk listázd ki az 50 és 100 m2 közötti alapterületű, 5 alkalmazottnál többet foglalkozató üzleteket, stb. Minden tulajdonságra, ami alapján később le akarsz kérdezni, kategóriákat kell létrehoznod, míg node típus esetén van egy alapterület meződ és kész.

ezek után sokkkkkal könnyebb dolgod lesz a szűrésekkel, ugyanis a taxonomyt pontosan erre találták ki.

Egyszerű szűrőfeltételek esetén valóban. A világ viszont gyakran elég bonyolult.

a mezők alapján szűrögetés enyhén szólva macerás,

Miért is? Eddig nekem semmiféle nehézséget nem okozott.

szerintem a node_reference mezőnek akkor van értelme, ha egy node -ból egy max 2-3 másik node -ra akarsz hivatkozni, azt se túl gyakran.

Miért ne lehetne 1 node-ból több százra, vagy több ezerre hivatkozni node reference-szel? Miért jobb ebben az esetben több ezer term, mint több ezer node? (Egyáltalán: be tudod tölteni azt a sok kategóriát a memóriába?)

Taxonómiát érdemes használni, ha a kategóriának csak neve van, esetleg leírása:

  • Piros (term name)
  • #ff0000 (description)

(Megjegyezném, hogy ha meg is akarjuk valahol jeleníteni a description mezőt, akkor az már bonyolultabb, mintha egyszerűen egy node mezője lenne.)

Ha több dolgot is el tudunk a kategóriáról mondani, főleg, ha ott változó értékek lehetnek (alapterület, alkalmazottak száma) akkor már node típust érdemes csinálni. Továbbá node-ot érdemes használni akkor, ha a webhelyen a munkafolyamat ezt megkívánja – jogosultságkezelés, verziókezelés, időzítés, csatolmányok és még egy csomó szolgáltatás a Drupalban könnyebben megoldható node-okkal mint term-ekkel.

Mivel nem tudjuk, miféle webhelyet, alkalmazást fejleszt a kérdező, ezért nem is lehet egyértelműen kijelenteni, hogy számára a CCK vagy a Taxonomy a jobb megoldás.

Hogy a kérdésre is válaszoljunk, az adott node-ra node reference útján hivatkozó node-okat Views modullal tudod kilistázni, és Viewfield modullal beilleszteni a szülő node-ba. Egyszer csináltam is erről egy videót, csak most a honlapom költözése miatt nem elérhető, ha küldesz egy üzenetet a kapcsolati űrlapomon, akkor átküldöm.

Szerk.: Sajnos sikerült a költözés közben úgy elpakolni a fájlokat, hogy most nem találom őket. :( Viszont közben már a Drupal.org kézikönyvbe is bekerült a téma.

0
0
Illyés Edit képe

Nem írtál butaságot, csak a hozzászólásod címe az volt, hogy "hibás megközelítés". Nem tudjuk, hogy mi a feladat, ezért azt sem tudjuk eldönteni, hogy mi a helyes megközelítés. Az egyik legsúlyosabb döntés, amit a munka kezdetén meg kell hozni az az, hogy CCK vagy Taxonomy vagy valami saját fejlesztés. Ezután ha már jó sok minden elkészült a webhelyen, és/vagy jó sok tartalmat feltöltöttek, akkor utána már nehéz váltani (bár nem lehetetlen).

0
0
Illyés Edit képe

Akkor miért nem a nyitó oldalon jelennek meg ezek az aggregált hírek? Mert azért valljuk meg ott lenne a helyük.

A FeedAPI modul rendes node-okat készít az aggregált hírekből, tehát semmi akadálya, hogy az arra érdemes blogbejegyzéseket a szerkesztők esetenként kiemeljék a címlapra. Automatikus kiemelés meg nem lenne szerencsés – az egyik ok, amiért szívesebben írnak a fejlesztők a saját blogjukra, hogy ott nem kell a "hivatalos" Drupal.hu követelményeinek megfelelni, az írás lehet szubjektívebb, lehet csak egy pár sor, stb.

Illyés Edit képe

A másikon egyszerűen meg se jelenjen (pl. a tartalombeküldési lehetőségek között).

Nem kapcsolod be a modult ;)

(Valószínűleg nem értem a kérdést.)

0
0
Illyés Edit képe

Nice Menu modul, de azt hiszem szülő menüpont ott sem lehet üres, meg kell nézni.

0
0
Illyés Edit képe

Tudtommal ez egy egyéni fejlesztés itt a Drupal.hu-n. Egyébként akár sminkből is egyszerűen megvalósítható, készítesz egy tartalomtípust, aminek az egyik mezője egy link, másik mezője egy kép, a sminket (node-tipusneve.tpl.php) pedig úgy alakítod ki, hogy a kép elemet linkesíted, ahol a href azonos a link elem értékével.

0
0