Másik témában le kéne írnod, hogy mit próbáltál, mi megy, mi nem, és pontosan leírni mit is szeretnél. A legnehezebb, hogy az olyat, mert Te mást látsz benne fontosnak és más meg megint mást.

pp

Mostmar csak sminkelned kell. Szoval fogod azt a minimalis css tudast es a leggyorsabban elkezded boviteni. Ha mar az oldaladon a kepeket tudja valotgatni es ott vannak azok a kis kockak is ahol te gyalog is tudod a kepeket valtogatni akkor mar csak a sminkelese van hatra. En pl. azzal a firebuggal modositgatnam a megfelelo div-ek es egyebek parametereit, mig csak a nekem nem megfelelo kinezetet kapom. Kozben amit csinalok azt szepen bejegyzem a style.css fajlba a sminkemben. Vagy egy kulon fajlba is lehet gondolom de en a tudasommal a style.css ben csinaltam meg ami nekem kellett.

Nem olvastam az előző iderángatásokat, de ha jól értem, akkor a dolgozatok mind ugyanolyan típusú node-ok, amikhez a bírálati mezők cck-val vannak hozzáadva, de a cck mezők egy részét el szeretnéd mindig rejteni a dolgozat típusától függően, mert nem kell mindegyikhez az összes.

Ha így van, akkor miért nem használsz külön tartalomtípust a különböző dolgozatokhoz? Ebben az esetben mindegyikhez azokat a mezőket tehetnéd hozzá, ami ott kell, és nem kéne saját modult írnod (mert máskülönben szerintem nem úszod meg).

Ezen kívül nem világos, hogy technikailag hogyan vannak megvalósítva a szekciók, de ha egy taxonomia kifejezés, vagy cck mező alapján sorolod be a dolgozatokat, akkor ezt az információt nem kell átadni, a node eleve tudja magáról.

A rendszeresen frissített és karbantartott Drupal oldalakkal nincs gond. Mondom ezt úgy, hogy több olyan oldallal is volt dolgom mostanság, ami Drupal 4.6 vagy 4.7 alatt működött, hibátlanul. A dolog titka annyi volt nekik, hogy letiltották a regisztrációt. :)
Itt jön a lényeg, az egyik legfontosabb védelmi vonal! Mert beszéltek szerverről, tárhelyről, de nem említitek a jogosultságokat! Mit tud egy bejelentkezés nélkül felhasználó elérni, megtenni az oldalon? És abból biztosan minden kell neki? Különösen igaz ez olyan pontokon, ahol adatbevitel van: tartalmak, hozzászólások, keresés, kapcsolat űrlap, stb.
A regisztrációt védi valami? A Mollom nagyon sokat segít, de amúgy is elég sok CAPTCHA megoldás érhető a Drupalhoz.
A szükséges hozzáférések megfontolása után érdemes végigmenni a jogosultság-oldalon és megvonni az egyes szerepköröktől (különös tekintettel a bejelentkezés nélküli látogatókra) azokat a jogosultságokat, amelyek nem szükségesek a tevékenységükhöz. Új modul bekapcsolásakor pedig megnézni, hogy milyen új jogosultásokat hozott a rendszerbe és azokról is dönteni. Ajánlatos követni a "whitelist" elvet, vagyis alapértelmezetten mindent tiltunk, és csak a szükséges szerepkörnek engedélyezzük a kívánt jogosultságot, lehetőleg minél szűkebben értelmezve.
Következő kör a modulok: Milyen modulok vannak használatban az oldalon? És azokból minden kell? Pl. ha fent már a Views, akkor azzal és egy kis kattintgatással nem lehet kiváltani valamit? Ha egy modult fejlesztésnél használunk, biztosan kell az az éles oldalra is? Találkoztam már éles oldalon bekapcsolva felejtett Devel modullal és főoldalra kitett PHP beviteli formmal is… Modulválasztásnál érdemes megnézni, hogy mikor volt az utolsó kommit a modulban, hány oldalon használják és milyen státusz van megjelölve, mennyi hibajegy van hozzá, abból mennyi a nyitott. Ebből fel tudod mérni, hogy mennyire „él” az adott fejlesztés és aszerint alapozhatsz rá.
Érdemes lehet megfontolni biztonsági modulok pl. Sentry Client használatát is.

Aztán ott van az a rész, ami a Drupalon túl mutat: nyilvánosan elérhető phpMyAdmin, Total Commanderbe elmentett FTP-jelszó, stb. Ezeket a támadási kísérleteket botok végzik, jól felparaméterezve. Sok sebezhetőség a phpMyAdminra épít, ezért a Drupaltól független külső szolgáltatásokat érdemes alaposan megszűrni, elpakolni az alapértelmezett útvonalról és levédeni htpasswd-vel.