Összeakadó modulok?

Lejla képe

Létezik-e az, hogy összeakad a Path és a Gallery Assist modul, vagy én rontottam el valamit?

A weboldalon, amin a kérdéses probléma van (működő weboldal sajnos), a korábban beállított Path-os útvonal álnevekkel ellátott menüpontok és node-ok 500-as hibaoldalt dobnak (Internal Server Error) ha az újonnan telepített Gallery Assist modul és a hozzá tartozó bővítmények be vannak kapcsolva. Az útvonal álnév nélküli oldalak (mint a contact, vagy a meglévő másik galéria albumai) hibátlanul bejönnek, és az admin felület is. Próbáltam -kísérletképpen- utólag törölni a menükhöz felvett álneveket, de ez nem változtatott a helyzeten. Ellenben a Gallery Assistet kikapcsolva ismét működött a honlap, ahogy kell.

Az Album photos + dfgallery kombót szándékozom lecserélni a Gallery Assist megoldásaival, és egy próba-weboldalon már kipróbáltam, nagyjából hasonló beállítások mellett, és nem merült fel ilyen probléma... azért is mertem belevágni :-)

Megmutatni nem tudom sajnos, mert a weboldalnak működnie kell, így most kikapcsolva hagytam az új modult, de jó lenne, ha lecserélhetném erre a régi galériákat, így nagyon érdekelne, hogy mi okozhatja problémát, és hogyan oldható meg.

Nem tudom, hogy ezek alapján tud-e valaki segíteni?...

Melyik modulhoz, modulokhoz kapcsolódik a téma?: 
Drupal verzió: 
Lejla képe

Egy észrevétel még, mert közben próbálkozom...

Szóval: furcsa, de ha kikapcsolom a Path modult, akkor is megmaradnak a korábban megadott útvonal álnevek... ez normális?
Nem kéne ez esetben visszaváltaniuk a menü-linkeknek (és minden másnak) a "node/1234" formába?
(nem használtam Token-t vagy PathAuto-t, minden útvonal "kézzel" lett megadva)

0
0
pp képe

A path modul az csak egy szerkesztő felület az útvonal álnevekhez. Mint a Views UI, vagy az Imagecache UI. Ha kikapcsolod nem tudod szerkeszteni azokat, de attól még működnek. Az url_alias táblát ürítsd. (persze előtte adatbázis mentés nem árt :D)

pp

0
0
Lejla képe

Sajnos nem segített a helyzeten, hogy a táblát ürítettem, valószínűleg valami más a "konfliktus" oka :-(
Pedig kezdtem örülni, hogy csak ennyi, és minden rendbejön - de köszönöm az infókat, máskor még hasznát fogom venni, ha Path-al akarok gyorsan és egyszerűen boldogulni (tegnap a drupal admin felületen egyesével megszüntettem az összes url aliast, hátha... de most hogy az adatbázisba bele kellett nyúlnom, láttam, hogy attól még hogy nincs egyetlen url alias sem, a tábla nem üres... és számomra ez is egy hasznos infó volt).

0
0
chx képe

a) valaki belenyúlt közben az Apache konfigba és azért van ciki, a module-nak köze nincs

b) aliasolt oldalon a module végtelen rekurzióba esik v másmilyen módon segfaultolja a webszervert.

Akárhogy is, az Apache error log-ot kell sasolni félkilós (500-as) hibáknál.

0
0
Lejla képe

Ugye jól sejtem, hogy azt az error logot a szolgáltatóm látja csak?
Ha igen, mit kérdezzek tőle? Adjak meg olyan adatokat, mint hogy mikor próbáltam a modult működtetni, mikor kaptam a "félkilós" hibaüzit? (tetszik ez a becenév, csak kár, hogy elég gyakran látom mostanában a "tulajdonosát"... :-( )

0
0
chx képe

Amipta az eszemet tudom a legutolso havi otdollaros pinceszolgaltato is kepes volt az en vhost-om Apache logjait szepen hozzam letenni. Foleg azert mert igy a diszk quota-ba is szepen bele lehet suvasztani... de valoban meg lehet kerdezni a szolgaltatot hogy ekkor-es-ekkor mi tortent.

Eszembe jutott egy c) is, az a legjobb, mindenki imadja, igazan, amikor op code cache (altalaban APC) bugzik valamilyen kod lattan, elkepeszto hibauzenetek szuletnek belole az error logba es kb. csak ugy lehet rajonni ha az ember kikapcsolja az APC-t mondvan, hatha.

0
0