jogos
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.
A praktika annyi, hogy nagyon részletesen kommentezem a template.php-t. Rögtön látom, hogy 6 helyen volt módosítás, és még azt is, hogy pontosan micsoda.
De visszakanyarodva az eredeti problémára, nekem az volt a bajom, hogy egy figyelmeztetéseket dobó megoldást legszebbnek neveztünk.
Igen, ez jogos.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
hibaüzenetek?
Drupal naplót nézted? Szerver hibanaplóban van valami? Cron rendesen, hiba nélkül lefut?
Ha nem itt van a gond, akkor bemész az indexelést végző modulba, és részletesen kiíratod vele a watchdogba vagy fájlba, hogy mit csinál, hol akad el. Nálam egyszer fordult elő ilyen, és kiderült, hogy egy node törzsében volt hibás PHP-kód, azon hasalt el az indexelő.
Egyébként én is átírnám az importálót – node_save(), taxonomy_save_term(), stb. – és újra behúznám az adatokat. Kismókus koromban én is INSERT-elgettem, aztán a nagymókusok jól kiokosítottak, hogy azért van az API, hogy használjuk. És tényleg. :) Azóta sokkal egyszerűbb az életem, 30-40 CCK-mező, toronyóra lánccal, stb. és minden hibamentesen megy be az adatbázisba.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
hook rendszer
Mert nem hívod meg azokat a kódokat, amelyek a hook_nodeapi() $op == insert esetére vannak belőve. Ha van egy modul, ami mentéskor csinál ezt-azt, az nem fog értesülni arról, hogy neki most csinálnia kell valamit, ha nem az API használatával mentesz.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
jóval kisebb hibalehetőség
Mi a különbség hogy insert -el vagy api -val követem el ugyan azt az adatbázisban.
Elvileg semmi. Gyakorlatilag INSERT-tel akkor fog hibátlanul sikerülni, ha tökéletesen ismered a Drupalt és az összes installált kiegészítő modult, és pontosan tudod, hogy új node létrehozásakor mit kell a bekapcsolt – gondolom több tucatnyi – modulnak csinálnia az adatbázisban.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
bug?
a következő node sorban a created és changed mezőben eltérő értéknek kell lenni
Pontosan melyik függvény hasalt el a két azonos created/changed értékkel rendelkező egymást követő node-on? Mert ha ez tényleg így van, az egy bug, és be kellene küldeni a hibajegyet.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
kereső
2 perc keresés eredményeként a vonatkozó hibajegyek:
- http://drupal.org/node/139537 #36-tól kezdődően többen is jelzik, hogy tömeges import után tapasztalják a hibát
- http://drupal.org/node/146466 won't fix jelzéssel, bent van egy patch de már nem fog bekerülni az 5.x-be (6.x-ben javítva lett)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
ez a UI
Ez a UI kellene, pontosan ez a kérés. Amúgy pl. egy sima Taxonomy + Views + Nodequeue elég lenne.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
hol láttam már?
Igen! Ezen gondolkodtam, hogy láttam már valahol Drupalban ezt a kétpaneles selectet, csak nem emlékeztem, hogy hol. :) Közben utánanéztem önálló JQuery-s megoldásoknak, de megnézem majd ennek a kódját is, hátha könnyebben lehet copypaste-elni, köszi.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
megnézem
Az a gond, hogy ha nagyon messziről indulok, akkor több idő meglévő elemekre építeni, mintha nulláról megírnám. De belenézek alaposabban az OpenAtriumba, úgyis már egy ideje tervezem, hátha van benne valami instant hasznosítható okosság.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
akkor hol kell törölni?
De akkor hol törölsz változót? Ezért bemászol a hook_nodeapi()-ba matatni? Vagy egyáltalán nem törölsz, hanem üres stringre állítod a változót, és tpl.php-ben vizsgálod? De az mitől szebb, mint – sminkben, vagy modulban, vagy akárhol – unset()-elni? A szép azért itt nem csak esztétikai kategória, hanem gondolom van valami objektív ok: célszerűbb így és így csinálni, ezért és ezért.
Én sem vagyok híve annak, hogy a tartalmakat nagy tételben smink preprocesszben manipuláljuk. 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. 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.