CCK + Viewfield
A tartalomtípushoz adj hozzá egy Viewfield típusú CCK mezőt. A mező default értékénél megadhatod, hogy melyik view-t építse be a tartalomba.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
devel
Tedd fel a Devel modult, és írasd ki vele a memóriafelhasználást. Aztán egyenként kezdd el kikapcsolni a modulokat, és meglátod, melyik eszik ilyen sokat.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
mi a kérdés?
Ha a Pathauto a korábban importált kifejezésekhez "egyszerre" készíti az útvonalakat és sokat kell dolgoznia, akkor legfeljebb "Fatal error: Maximum execution time of x seconds exceeded" hibaüzenet jelentkezne, nem memóriaprobléma.
kifejezes bevitelnel a korabban felsorolt modulok kozul mi koze lenne ehez barmelyiknek?
Te magad írod, hogy a Notifications eszi a sok memóriát. Akkor mi a kérdés? (Notifications problémáknak nyiss új témát.)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
HTML forrás?
Az oldal HTML forrásában mi jelenik meg?
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
tárolás CCK táblákban
Azt írják a projekt oldalán, hogy választhatsz, a Taxonomy-t vagy a CCK-t használod a kifejezések tárolására, és a CCK hatékonyabb:
it's possible, that the storage is done in CCK tables (which might be more efficient)
%d?
Nem tudom, ez a %d honnan jött, URL-ekben rendes változókat használunk, pl. $user_id, $nid, stb. Ezek értékét pedig a szokásos módon tudod lekérdezni:
<?php global $user; $user_id = $user->uid; ?>
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
devel
már megnéztem el is indultam egy úton
Pont ezt mondjuk, hogy nem jó felé ;) Drupal 5 alatt a %d csak SQL lekérdezéseknél használatos, a menürendszer nem tud vele mit kezdeni. Rendes változókkal dolgozz.
a gyorsító tár ürítése okoz gondot és nem látszódik a hatás azonnal amikor valamit változtattam
Ürítsd a cache_menu táblát, vagy tedd fel a Devel modult, engedélyezd a Devel blokkot és kattints az Empty cache linkre.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
beállításoknál
Nem ismerem a modult, csak a projektoldalt olvastam. Arra tippelnék, hogy vagy globális beállításként adhatod meg a mentés módját – ebben az esetben valahol az Adminisztráció -> Webhely beállítása környékén lesz egy settings oldal – vagy akkor, amikor a tartalomtípushoz hozzáadod a mezőt. README.txt-nél kezdeném az olvasást...
megnézted egyáltalán, amit írtam?
tessek?
gondoltam feltudsz vilagositani es nem is tudsz az egesz mukodeserol semmit!?
Nem, de ez bevett szokás ezen a fórumon, hogy ha nincs idő valaminek utánanézni, modult letölteni, installálni, debuggolni, kódrészletet tesztelni stb. attól még érdemes pár mondatban leírni, hogy én (a válaszoló) merre indulnék el. Sokan megfogadják a tanácsot, és a problémájuk megoldódik, mások kiverik a hisztit, hogy miért nincs a szájukba adagolva a bébipapi.
cck -s dolog gondolom az akar lenni ahogy jelenleg hasznalom a taxonomy field -et.
Korábban ezt írtad:
a tartalom tipushoz mezo hozzaadasanal pedig Taxonomy Field->ActiveSelect mentes beallitasnak a both -ot jelolom meg
Erre idéztem neked a projekt ismertetőjét, ami teljesítmény szempontjából a CCK-s mentést ajánlja. Tehát nem mindkettőt (both), hanem a CCK táblában történő mentést. Csak abban nem voltam biztos, hogy külön Settings oldalon kell beállítani, vagy a mező hozzáadásakor – de most installáltam, utánanéztem, sőt, még képernyőképet is készítettem neked, hogy lásd, a mező hozzáadásakor lehet beállítani a "Save in CCK table" opció kiválasztásával:
Ezen felül ajánlottam a README.txt elolvasását – és láss csodát, bár rossz angolsággal de teljesen korrektül le van írva a lényeg:
Additional you can choose whether the term is saved as a real tag in the term_node table (standard)
or the term is only saved in a cck-table (so not a real term - node connection)
Szerk.: Kis fogyasztású modulok. Bár én core modulok lecserélése helyett inkább másképp szervezném a tartalmakat (a Taxonomy&CCK öszvér megoldást teljesen lecserélném egyszerű CCK mezőkre).
session tábla mérete
Mekkora a session táblád? Arányos a honlap forgalmával? Pl. ha 10.000 rekord van a táblában, és van napi 100 látogatód, akkor egyértelmű, hogy nem fut le cronnnal a PHP garbage collector. (Ilyet Debian alapú szervereknél gyakran látok, szólni kell a tárhelyszolgáltatónak, hogy állítsa be rendesen a rendszert.) Az sem biztos, hogy pont az a lekérdezés a lassú, amit a szolgáltató jelzett, csak ez fut leggyakrabban, ezért az adatbázis tartós túlterhelése esetén ez kerül be legnagyobb valószínűséggel a slow query log-ba.