CONTENIDO Forum

Hallo zusammen,

ich habe heute nach einiger Zeit mal wieder eine (Unter-)Kategorie anlegen wollen. Wenn ich das tue, kann ich auch den entsprechenden Namen usw. in der Oberfläche eingeben, doch danach wird nur noch eine weiße Seite gezeigt.
Drücke ich dann reload, ist die Kategorie nicht vorhanden, und mein gesamter Kategoriebaum ist zerstört. Es finden sich nur noch die ersten zwei Kategorien, scheinbar vollkommen in Ordnung und bis in die gesamte vorhandene Navigationstiefe.
Dafür sind aber alle anderen angelegten Kategorien (es sind im Original 5) nicht mehr auffindbar, die Artikel dieser Kategorien, soweit direkt verknüpft und aufrufbar, sind aber noch vorhanden.

Ich habe ein wenig herumprobiert und festgestellt, daß die Kategorie sehr wohl mit der gewünschten Bezeichnung in der Datenbank angelegt wird, jedoch nur unter <Tabellename>_cat_lang, nicht in <Tabellenname>_cat_tree.
So kann ich mir sehr gut vorstellen, warum das Kategorien-Tool Amok läuft.
Ich habe hier die Suche benutzt und herausgefunden, daß das Problem wohl schon öfter aufgetreten ist, die zwei geschilderten Abhilfen sind
- <domain>/contenido/tools/updateseqruntime.php ausführen
--> das hat keinen sichtbaren Effekt

- Neuen Baum anlegen und wieder löschen
--> Ich kann zwar einen neuen Baum anlegen, auch ausserhalb der bestehenden Kategorien, aber auch dann kommt nur eine weiße Seite und bringt mich nicht weiter. Löschen kann ich den nicht angezeigten Baum dann natürlich nicht mehr.

Das Contenido Error-Log enthält keinen Fehler.
Ich verwende folgendes System :

MySQL Version 4.1.15-Debian_0.dotdeb.1-log
PHP Version 4.4.6
Contenido Version 4.6.8

Da ich das System eine Weile lang ohne Schwierigkeiten oder Änderungen am laufen hatte, kann ich nicht sagen, seit wann der Fehler besteht. Soweit sind von mir jedenfalls keine Änderungen vorgenommen worden, die sich irgendwie auf die Datenbank auswirken könnten (ich habe bei diesem System, rein im Sinne des Erfinders, Templates angepasst und ein paar Module zusätzlich installiert).

[edit]
- Der Provider hat am 11.4. die PHPversion geupdatet. Ich kann mir aber nicht vorstellen, daß die Probleme macht (und dann auch noch ohne Fehlermeldung oder Warning?). In jedem Fall ging das Anlegen von Ordnern vorher.
- Das Verhalten ist in mehreren getesteten Browsern gleich (Opera, IE7, Firefox).
- Die Tabellen an sich sind laut phpMyAdmin vollkommen okay, ich habe mal analyse / repair / optimize drüberlaufen lassen, ohne daß sich eine Änderung ergeben hat.
Dasselbe sagt phpMyAdmin aber auch über die nach dem Anlegen einer Kategorie "halbierte", kaputte Tabelle.
- Auch die Kategorien und Bäume meiner zwei anderen Mandanten in dieser Installation werden zerstört, wenn ich eine Kategorie bei meinem Haupt-Mandanten anlege.
- Kategorien und Bäume löschen geht ohne Probleme und macht die Tabelle nicht kaputt. Es hilft mir aber auch nicht - auch danach kann ich keine neuen Kategorien anlegen. Es ist auch kein Platzproblem in der MySQL erkennbar, und es liegen ausser den Contenido Tabellen in dieser DB keine anderen Tabellen.
- Ich habe etwa 400 Kategorien, wenn man der phpMyAdmin-Seitenanzeige Glauben schenken darf. Die IDs laufen von 234717 - 234313.
[/edit]

Kann mir jemand helfen?

lg,
Suse

ein netter provider...

das erste was ich machen würde ist ein db backup einspielen zu lassen, bevor du die aktionen mit den kategorien versucht hast... (der provider sollte ja ein backup haben, falls nicht ???)

das nächste wäre zu kontrollieren ob dein db user das recht lock table hat...

das andere keine einträge im errorlog -> durch das update haben sich sicherlich alle dateiberechtigungen geändert -> hab ich auch schon des öfteren gesehen...
also sämtlich ordner und dateiberechtigungen kontrollieren und ggf. richtig stellen...
zb:
contenido/logs/
contenido/cronjobs/
mandant/cache/
usw..

ohne eine fehlermeldung wird ein erraten worans nun wirklich liegt etwas schwierig...

ich hatte die Tage das gleiche Problem.

Ich wollte eine neue Kategorie anlegen und fast der ganze Kategoriebaum war weg.
Ich hab mich dann mal ein wenig durch die Sourcen gequält :) und herrausgefunden das es an der Funktion liegt, die den Kategoriebaum komplett neu anlegt (ganz abgesehen davon das ich nicht verstehe warum der immer komplett neu angelegt wird.. für ALLE Mandanten)
bei mir hört er fast immer nach genau 200 Einträgen in cat_tree auf
es sind aber über alle Mandanten über 500 Kategorien.

Ne Abhilfe habe ich nicht gefunden.

Gott sei Dank passierte das bis jetzt nur auf einem Testserver und nicht auf dem Echtserver.
Was ich wohl noch rausgefunden habe, ist das PHP dann irgendwie schafft den Apache zum abstürzen bringt:
Habe dazu aber auch nichts im Netz gefunden. Nur das dieser Fehlercode wohl häufiger auftritt und niemand ne universelle Lösung hat.

Hmmm...

ja, HostEurope hat/hatte ein Backup und hat es mir auch super schnell zur Verfügung gestellt (ein Fax, eine Stunde Bearbeitungszeit... ich mag die Jungs. )

Die Ordner-Berechtigungen haben sich durch das PHP-update nicht geändert. Ein Error oder Warning taucht im contenido-Log nach wie vor nicht auf. Es könnte aber sein, daß das merkwürdige Verhalten an einer neuen PHP-Komponente liegt, die Hosteurope bei dem Update mit installiert hat. Sie nennt sich "PHP Suhosin Session Encryption" und sagt mir mal gar nichts, scheint aber irgendein Sicherheits-Feature zu sein. Sagt die einem von euch was?

Der Rest an Einstellungsmöglichkeiten sieht so aus : Denke das ist in Ordnung... ? (http://www.doogle.de/info.php für weitere Informationen... )

Ich hole mir jetzt aber noch das gesamte Log des Providers und gucke, ob da irgendwas drin steht. Das hier :

(Log)
217.86.35.78 - - [18/Apr/2007:16:14:48 +0200] "GET /contenido/scripts/messageBox.js.php?contenido=8bafa7a4d21914f42dd5a26422f53bb2 HTTP/1.1" 200 8070 "http://www.doogle.de/contenido/main.php ... 6422f53bb2" "Opera/9.20 (Windows NT 5.1; U; de)" "www.doogle.de"
217.86.35.78 - - [18/Apr/2007:16:14:47 +0200] "GET /contenido/main.php?area=str&action=str_newcat&frame=4&idcat=9&contenido=8bafa7a4d21914f42dd5a26422f53bb2 HTTP/1.1" 200 176596 "http://www.doogle.de/contenido/main.php ... 6422f53bb2" "Opera/9.20 (Windows NT 5.1; U; de)" "www.doogle.de"
217.86.35.78 - - [18/Apr/2007:16:14:49 +0200] "GET /contenido/images/but_cancel.gif HTTP/1.1" 200 760 "http://www.doogle.de/contenido/main.php ... 6422f53bb2" "Opera/9.20 (Windows NT 5.1; U; de)" "www.doogle.de"
217.86.35.78 - - [18/Apr/2007:16:14:53 +0200] "POST /contenido/main.php?frame=4&contenido=8bafa7a4d21914f42dd5a26422f53bb2 HTTP/1.1" 200 408 "http://www.doogle.de/contenido/main.php ... 6422f53bb2" "Opera/9.20 (Windows NT 5.1; U; de)" "www.doogle.de"

(Errorlog)
[Wed Apr 18 16:14:53 2007] [error] [client 217.86.35.78] ALERT - maximum execution depth reached - script terminated (attacker '217.86.35.78', file '/is/htdocs/wp1057135_5M6UGK7OUT/doogle/conlib/db_mysql.inc', line 112), referer: http://www.doogle.de/contenido/main.php ... 6422f53bb2

aha.... ich schreib mal an Hosteurope und frage, was das ist.

Die DB-User-Rechte habe ich noch einmal neu gesetzt, LOCK TABLE ist da dabei. Ich probiere gleich nochmal, ob das etwas an dem Verhalten ändert. [edit] -- nö. [/edit]

lg,
Suse

hm.

So, also, Antwort von HostEurope liegt vor :

das Problem liegt scheinbar an der Suhosin Einschränkung:

suhosin.executor.max_depth=200

das sollten die Programmierer lösen können.

Mit freundlichen Grüßen

Sascha Ritzer
Hosting & Services - Support & Vertrieb Host Europe

Ich muss ehrlich sagen, ich sehe diese Contenido Funktion, jede Kategorie einzeln in die Datenbank einzufügen wenn nur eine einzige geändert wurde, auch als nicht gerade sinnvoll an, aber für mich mit lückenhaften PHP- und nicht vorhandenen SQL-Kenntnissen ist es nicht zu lösen, ganz zu schweigen davon, daß dann "mein" Contenido ja wohl von allen zukünftigen Upgrades ausgeschlossen werden müsste.
Heisst das also, daß ich mir bei der Grösse meines Projektes ein anderes CMS-system suchen muss?

lg,
Suse

Wenn ich das richtig interpretiere soll suhosin.executor.max_depth
lediglich verhindern das mal ein php-Script Amok läuft.

Default ist 0 (disable)

http://www.hardened-php.net/suhosin/configuration.html

jau, nur ausstellen kann ich diese funktion wohl nicht.

ZuMe hat geschrieben:jau, nur ausstellen kann ich diese funktion wohl nicht.

Vielleicht doch. In der .htaccess file

http://bugs.typo3.org/view.php?id=4930

Suhosin

ich vermute sie legen den baum komplett neu an, um programmier einfach die Konsistenz zu erhalten. abhilfe schafft nur umschreiben. vielleicht kann Brazo Alkher mal den sourcecode poschten

maveric2001 hat geschrieben:vielleicht kann Brazo Alkher mal den sourcecode poschten

von was soll ich den SourceCode posten?

Brazo Alkher hat geschrieben:von was soll ich den SourceCode posten?

von dem dicken kaefer, der den ganzen baum neu anlegt

ich probiers gleich mal aus mit der .htaccess ... hoffentlich darf ich das... YEAH

Wosch - ich könnt dich knutschen... ach was ich tus einfach *knutsch* you saved me!

DANKE !!

lg,
Suse

meine meinung -> die einschränkung ist schwachsinnig...

sobald etwas in einer (?rekursiven?) schleife 200 mal aufrufen wird, bricht das script ab ?

das zu einem default setting zu machen... ??? bzw die default vorgabe von 0 auf 200 zu setzen ist schon sehr riskant...
sie führt unter anderem ja zu datenverlust...

würd mich intressieren ob der provider für die zeit aufkommt, die andere verschwenden um die einschränkung zu umgehen... bzw die db wieder zu reparieren ?

maveric2001 hat geschrieben:

Brazo Alkher hat geschrieben:von was soll ich den SourceCode posten?

von dem dicken kaefer, der den ganzen baum neu anlegt

also das ist alles in der Datei functions.str.php im includes Ordner
und dort die Funktion strRemakeTreeTable()

Ein ähnliches Problem hatten wir auch bei einem Kunden. Wir haben bei Hosteurope nachgefragt:

leider kann dies im moment weder per .htaccess noch per KIS eingestellt werden.

Solange dies nicht geändert wurde ist dieser Hoster leider nicht für Contenido geeignet.