Problem nach Update auf 4.2

Dienstag, 03. November 2009 02:18:00

Hallo,

wir haben hier ein kleines Problem nach dem Update von 4.0.1 über 4.1 nach 4.2.
Die Seite wurde mit einigen Extensions erweitert.

Problem bei den Extension ist jetzt, dass nicht mal mehr der Administrator Zugriff auf die Module hat.
Es kommt immer der Fehler access denied.

Wenn wir jetzt allerdings für jedes Modul in der site.ini einen Eintrag wie folgt anlegen:
PolicyOmitList[]=<module>/<view>
dann funktioniert der Zugriff wieder. Allerdings greift dann ja bekanntermaßen das Rechtesystem von eZ Publish nicht mehr.

Die Änderungen in der module.ini mit [ModuleSettings] ModuleList[]=<module> sind berücksichtigt.

Hat irgend jemand eine Idee, wo wir noch suchen könnten?
Wir sind über jeden Tipp dankbar.

Dienstag, 03. November 2009 11:01:54

Hallo Felix,

danke für den Hinweis.
Jedoch haben wir mehrere Varianten der module.ini.append.php versucht.

Am exakten Beispiel: die Extension heißt "ccaccount"
und hat die Module "show" und "listla".

Wir haben folgendes versucht (jeweils ohne Erfolg):

[ModuleSettings]
ExtensionRepositories[]=ccaccount
ModuleList[]=ccaccount

[ModuleSettings]
ExtensionRepositories[]=ccaccount
ModuleList[]=ccaccount/show
ModuleList[]=ccaccount/listla

[ModuleSettings]
ExtensionRepositories[]=ccaccount
ModuleList[]=show
ModuleList[]=listla

Jeweils Cache gelöscht und versucht das Modul aufzurufen.

Welche Variante ist die richtige?

Dienstag, 03. November 2009 12:02:03

Hallo Felix,

ja, so habe ich das auch verstanden. Und die Struktur ist exakt so.
Ich werde jetzt mal eine "nakte" Instanz von eZ Publish aufsetzen und mein Modul damit testen.

Vielleicht ist ja irgendwie was beim Update schief gegangen.

Trotzdem mal vielen Dank soweit.
Oder hast du gleich eine Idee, was eventuell beim Update schief gelaufen sein könnte?

Gruß
Michael

Dienstag, 03. November 2009 14:22:07

Hallo Felix,

vielen Dank schonmal für die Hilfe bisher.

Ich habe folgendes getestet:
Komplette Instanz von eZ Publish neu aufgesetzt. Dann meine Extension rein kopiert und aktivert.
Danach den Cache gelöscht. Konnte aber nicht auf die Extension zugreifen.
Dann nochmals den ini-Cache gelöscht und irgendwann dann nochmals den gesamten Cache.
Und dann hat es auf einmal funktioniert - seltsam.

Bei der alten "produktiven" Instanz habe ich zur Sicherheit die module.ini.append.php ins override Verzeichnis umgesiedelt, wie du empfohlen hast.
Leider auch ohne sichtbaren Erfolg.

Wie kann ich denn diesen Zugriff debuggen?
Welche Kernel-files sind denn dafür zuständig?

Wir sind kurz davor, das komplette Update wieder rückgängig zu machen....aber so wirklich helfen für die Zukunft tut das auch nicht.

Dienstag, 03. November 2009 14:51:03

Sowohl als auch.

Warum? Gibt es da Unterschiede?

Dienstag, 03. November 2009 15:23:41

Hallo Felix,

gut zu wissen.
Allerdings wird es jetzt noch komischer:

Ich habe jetzt die Extension jacextension von dir bei ez.no heruntergeladen und installiert.
Dann habe ich Stück für Stück, das entfernt was ich bei dem Beispielmodul nicht benötige.

In der Zwischenzeit ist die Extension umbenannt und auch die Module.
Und es geht immer noch. Dann habe ich von meinem eigenen Modulen eines reinkopiert und es geht immer noch.

Wenn ich die neue Extension (umgebaute Version von jacextension) mit meiner alten Vergleiche,
dann sind die exakt gleich - bis auf den Namen.
Die eine Erweiterung tut, die andere nicht.

Das ist doch weit weg von logisch!
Oder nicht?

Mittwoch, 18. November 2009 14:37:00

Hab ihr den mal geprüft, ob es die Klasse mit gleichem Namen bereits vorher gab. Doppelte Klassen können zu Konflikten führen.

Dipl. Ing. (FH) M. Sc. Thomas Köhn

http://www.jac-systeme.de - Individuelle WEB-Lösungen
--
http://www.CJW-NETWORK.com/de - Developers united in eZ Publish
http://projects.ez.no/cjw_newsletter - eZ Publish Newsletter Lösung

Mittwoch, 18. November 2009 19:34:33

Hallo,

beides ist nicht das Problem - Module mit dem Namen gibt's bei mir nicht mehrfach, und auch die autoload-Infos stimmen.

Wie gesagt, einige Views des Moduls funktionieren, andere nicht.

Für mich riecht das entweder nach
- Probleme mit den Zugriffsrechten, was ich allerdings nicht nachvollziehen kann. Die entsprechenden Roles erlauben den vollen Zugriff auf alle Views des Moduls. In den Konfigurationsdateien taucht der Name der Moduls ansonsten nur im Zusammenhang mit ModuleViewAccessMode[...]=ssl auf.
- Caches. Allerdings habe ich alle Caches, alle Caches einzeln, und alle Caches von der Shell per bin/php/ezcache.php gelöscht.
- Bug. Ich hab' nur keine Lust und Zeit stundenlang durch den Quellcode zu ackern.

Noch mehr Ideen auf Lager?

Danke,

Arno