Hello!
Drupal 6 alatt egyetlen felhasználó van, az admin. Eddig minden jól ment, de most se új tartalmat nem tudok hozzáadni, se meglévőt nem tudok módosítani, a tartalmakról a fordítás opció is eltűnt és folyton "user admin does not exist" hibát kapok.
Holott az adminnal be tudok jelentkezni és az adatbázisban is rendesen benne van a név.
Jogosultságokat már próbáltam újraépíteni, nem segített. Mit nézzek még meg?
Drupal verzió:
Update: Mivel egy menüpont
Update: Mivel egy menüpont hozzáadása után jött elő a hiba, töröltem (egy másik) menüpontot a menüfából és rendbejött a probléma.
Elég nagy menüfa van, lévén soknyelvű az oldal, de mi ez a limitáció?
Összesen 1418 entry van a menu_links táblába, ezzel még működik. Ha hozzáadok még egyet, a fenti hiba jön elő...
O.o?
Keresgéltem és úgy olvastam,
Keresgéltem és úgy olvastam, hogy másnak ezt a problémát megoldotta a memória limit emelése. Nos, most fölvettem a PHP memória limitet 128MB-ról 256MB-ra, de sajnos a hiba továbbra is fennáll. Nincs valakinek ötlete még?
Hogy működik pontosan a menü rendszer?
Alaposan beleástam magam a hibába és a következő furcsaságra jutottam:
Elég tanácstalan vagyok. Azt hiszem, legjobb volna újraépíteni a menüfát, de hogy lehet ezt megcsinálni, anélkül, hogy egyessével, kézzel újra felvinném a kb. 1500 menüpontot?
Asszem feladom...
Mindenhonnan próbáltam infót és segítséget szerezni, sikertelenül.
Most
A probléma mégis fennáll. Valami a menü modulban lehet, de hogy mi, arról selytelmem sincs. Ha a menü modult is letiltottam, akkor a probléma megszűnt... a menü szerkesztéssel együtt ugyebár.
Van bármi, amit még ki tudok jelen helyzetben próbálni?
Pár gondolat:
Pár gondolat:
1. Lehet, hogy valami ötletet adna, ha megmondanád a site linkjét.
2. Cache törlést csináltál, ugye? Csak mert azt nem írtad.
3. Jól értettem, hogy 3-án az adatbázisba írogattál? Ha nagyon rá vagy erre szokva, akkor ne csodálkozz, ha összeomlik az oldalad (talán most nem ez a helyzet, de ez nagyon veszélyes: lehet, hogy ha változtatsz valamit, még másik három táblában is kéne változzon valami stb.)
4. Itt egy hasonló hiba, itt ez volt a kulcsszó: suhosin
5. És egy OFF: megnéztem egy összetettebb D6-os oldalt: abban nekem 1000 rekord volt a menu_links táblában. Hogy lehet neked ennyire baromi sok benne? Kicsit túlzásnak tűnik...
Védd az állatokat! ;)
"Hogy lehet neked ennyire
"Hogy lehet neked ennyire baromi sok benne?"
Akármitől. Pl egy bekapcsolt book modul. Vagy og. De még tán a forum is megcsinálja, vagy egy többnyelvű oldal és szép mennyiségben csinál menu linket.
Amúgy tartok tőle, hogy ez veszett fejsze nyele, ahhoz, hogy ezt rendbe szedd, baromira át kell látnod, mi mitől van úgy a drupalban ahogy, és még így is soksok óra debugolás.
Mintha derengene régről egy workaround, de simán lehet, hogy álmodtam: ürítsd ki a menu_links táblát úgy, hogy meg van nyitva az az oldal, ahol a rebuild cache van. Utána nyomd meg a rebuild cachet, és rendbe jön a táblád (vagy nem, szóval legyen backup). A drupalod működni fog, viszont az összes custom linked el fog tűnni a menükből, mire visszapakolgatod, tutira elmegy a kedved a kézzel adatbázisban turiról.
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
A hiba jelentkezéséig nem
A hiba jelentkezéséig nem túrkáltam az adatbázisban. Utána is csak azért, hátha sikerül megoldanom (backup van). Cache ürítést természetesen minden alkalommal csináltam, mikor pl. kikapcsoltam egy modult vagy változtattam a configon.
Azóta egyébként csináltam egy helyi másolatot az oldalból, amin szintén jelentkezett a probléma. Frissítettem 6.19-ről 6.26-ra a Drupal-t, plusz az összes használt modult, amiből volt frissítés, de a hiba nem jött rendbe. Kipróbáltam a helyi tesztkörnyezetben, hogy a menu modulon kívül minden mást letiltottam, de ez sem hatotta meg. Menü modul letiltása után egyből rendben (de ilyenkor ugye nem lehet a menüt szerkeszteni), tehát valahol a menü modulban vagy a menüfa adatokban lehet a hiba.
Arra gondoltam még, hogy anno balga módon csináltam egy custom page-t, aminek a nevében alulvonás volt (ezt nem kellett volna) és így keletkezett egy törölhetetlen menüpontom a navigation menüben. A teszt verzióban kiürítettem a navigation menüt és úraépíttettem, de nem ez volt a hiba.
Az meg, hogy miért van ennyi menü, elég egyszerű: 11 nyelvű az oldal, minden nyelvből van egy felső menü (csak a galéria nyelvenként legalább 8-10 menüpont), plusz egy alsó gyűjtő menü, plusz még a navigation, amivel együtt elég sok menüpont jön össze.
Mivel itt eléggé elakadtam, arra gondoltam, hogy nekilátok és átdolgozom az egész oldalt Drupal 7-re. Először megpróbálom frissítéssel, ha az nem megy, akkor marad a kézi átvitel...
miért törölhetetlen
Ezt nem egészen értettem. Miért is lenne attól törölhetetlen, hogy van a nevében alsóvonás?
Még megpróbálhatnád megkérdezni a Drupal Answers-ön, ott elég lelkesen szoktak válaszolgatni (vagy legalább próbálkozni) az emberkék a "kreditekért" cserébe. :)
"Ezt nem egészen értettem.
- ezt úgy értem, hogy a custom page modul csak alfanumerikus karaktereket kezel a névben, alulvonást nem, de ez csak akkor derült ki számomra, miután már létrehoztam.
Ezután akár a kérdéses custom page-et akartam törölni, akár a menüpontot, 500-as hibába futottam.
Drupal Aswers-ön feltettem a kérdést. Egyelőre csak olyan választ kaptam, hogy "clearly this falls into the "broken" category" :(
Közben próbáltam drupal7-re migrálni a teszt példányomat, de egyelőre ott még sok teendő lenne (pl. a theme átdolgozása), hogy menjen rendesen. Pl. valamiért egyelőre a migrált verzióban nem tudok menüpontot sem hozzáadni.
Gyanítom, hogy a vége az lesz, hogy csinálok egy friss Drupal7 telepítést, átdolgozom a sminket, aztán manuálisan átpakolom a tartalmat... T.T
Probléma megoldva
Tovább vizsgálva a hibát, sikerült megoldani. Nem a Drupal-nál és nem is a PHP-ben volt a gond.
A nagy menüfa miatt az alapból max 1MB-os Mysql csomagot túlléptem és emiatt a Mysql eldobta a kapcsolatot (és pesze utána egy rakás szükséges query nem futott le).
Hozzáadtam a Mysql confighoz az alábbi sort:
Utána egy Mysql restart és a probléma megszűnt.
Mindenesetre köszönöm a segítséget!
max_allowed_packet
Na igen, a szokásos max_allowed_packet...
Nekem meg az AB Plusz rendszergIzdái képtelenek voltak elhinni, hogy a Drupalnak ez a korlát nagyon alacsony, és gyakran okoz problémát. Menjek a fenébe, másnak nincs ilyen gondja (pl. aki nem Drupalozik, vagy használ valami erőforrás-igényesebb CMS-t), akkor nekem se legyen Drupallal.
Mindenesetre jó, hogy megosztottad, hogy ez volt a megoldás. Újabb megerősítése annak, hogy a max_allowed_packet túl kicsi, ha 1 MB-ra van állítva.