Akkor még egyszer.
Egy:
Nekem az volt a problémám, hogy töröltük magát a változót. Ha megnézed a sminket akkor abba ott le van írva, hogy ha nincs tartalma a címnek, vagyis a cím üres, vagyis nincs cím akkor nem rak ki div-et. Az az if nem azt vizsgálja, hogy létezik-e a változó, hanem azt, hogy a változó üres-e. (HF: Próbáljuk meg a 0 szöveget adni egy node címének). Képzeljük el a szituációt, hogy tesztelni szeretnénk valami egész mást az oldalon, mert van egy hibánk. Szépen beállítunk mindent, hogy még a figyelmeztetéseket is mutassa nekünk a rendszer, hátha abból több infonk lesz. Ezután nézzük az error logot és már zsibbad is az ujjunk a sok lefelé tekeréstől. ;))
Kettő:
Én azt mondtam ez a megoldás egyből következően nem a legszebb, hisz szebb lenne, ha a tartalmát törölné és nem magát a változót. Senki nem mondta, hogy ez ebben az esetben nem jó megoldás.

Talán nem árt azonban rámutatni arra, hogy ez a fajta megoldás nem jó. Miért műxik ez a "preprocessben unsettelem a változót" ebben az esetben?
1. a smink, vagyis a template fel van készülve arra, hogy üres sztring esetén a burkoló htmlt se írja ki.
2. a Drupal hibakezelője lenyeli a figyelmeztetéseket.

A Bálint által bemutatott megoldás viszont a fenti két feltételtől függetlenül is jól működik. Még akkor is amikor mondjuk a name_and_slogan div-et akarod törölni. Itt ugyanis hiába unsetteled a változókat és hiába is törlöd az értéküket.

De ha csak pár egyszerű eset van – mint itt, hogy egy bizonyos node-nál ki kell lőni egy változót – akkor a legjobban kezelhető módszer a preprocessz.
Helyes használat és a fenti egyes feltétel esetén igen. Tehát lehet a preprocesst erre használni, sőt jó is, csak megfelelően használjuk. Nekem a preprocessel nincs bajom.

Ha több tpl.php fájl van a sminkben, én attól mindig depressziós leszek. Például szeretnék egy plusz divet a page.tpl.php-be, akkor annyi fájlt kell módosítani, ahány page(-xxx).tpl.php fájlom van.
Akkor Te ne használd ezt a fantasztikus lehetőséget. Azért érdemes itt is belegondolni, mi lesz egy fél év múlva. Mi van, ha akkor kell beszúrni azt a div-et. Ott van az egy darab tpl.php-d beletolod megnézed egy helyen és hátradőlve mosolyogsz: ez műxik. Aztán egy nap múlva szólnak, hogy ja itt szétesett. Azt javítod, eltelik még egy nap, megint szólnak, ja itt is szétesik. Aztán szépen ritkulnak az időpontok, és közben keverednek a módosításaid. Ezzel szemben, ha már eleve látod, hogy 6 különböző .tpl.php-t kell módosítanod, akkor 6 különböző helyet is fogsz tesztelni. Ekkor szerintem jóval nagyobb az esélye annak, hogy jó munkát adsz ki a kezeid közül. Nyilván megvannak a praktikáid, hogy ezeket a problémákat kikerüld. Nekem ez segít, lehet neked nem.
De visszakanyarodva az eredeti problémára, nekem az volt a bajom, hogy egy figyelmeztetéseket dobó megoldást legszebbnek neveztünk. Nem több.

pp

Az én oldalam CJB-n van, ott gond nélkül fut a Drupal (igaz, itt is felső frame-es reklám van, de nincs annyi gond, mint pl. UW-n). Az Extra.hu nagy előnye, hogy reklámmentes, de a LOCK TABLES hiánya érezhető (nagyon is; pl. nekem egyes beállítások átírása után ugyanúegy az alapból beállított érték maradt, vagyis nem módosult a beállítás)...
Egyébként most 2 hónapig a CJB is reklámmentes...