Kategorie anlegen / Baum anlegen nicht mehr möglich
Kategorie anlegen / Baum anlegen nicht mehr möglich
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
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...
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...
*** make your own tools (wishlist :: thx)
-
- Beiträge: 103
- Registriert: Fr 28. Jan 2005, 15:15
- Wohnort: Unna
- Kontaktdaten:
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.
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:
Code: Alles auswählen
[Tue Apr 17 09:58:30 2007] [notice] Parent: child process exited with status 3221225477 -- Restarting.
[Tue Apr 17 09:58:30 2007] [notice] Apache/2.0.59 (Win32) PHP/4.4.4 configured -- resuming normal operations
[Tue Apr 17 09:58:30 2007] [notice] Server built: Jul 27 2006 15:55:03
[Tue Apr 17 09:58:30 2007] [notice] Parent: Created child process 2504
[Tue Apr 17 09:58:31 2007] [notice] Child 2504: Child process is running
[Tue Apr 17 09:58:31 2007] [notice] Child 2504: Acquired the start mutex.
[Tue Apr 17 09:58:31 2007] [notice] Child 2504: Starting 250 worker threads.
[Tue Apr 17 09:58:32 2007] [notice] Parent: child process exited with status 3221225477 -- Restarting.
[Tue Apr 17 09:58:32 2007] [notice] Apache/2.0.59 (Win32) PHP/4.4.4 configured -- resuming normal operations
[Tue Apr 17 09:58:32 2007] [notice] Server built: Jul 27 2006 15:55:03
[Tue Apr 17 09:58:32 2007] [notice] Parent: Created child process 1864
[Tue Apr 17 09:58:33 2007] [notice] Child 1864: Child process is running
[Tue Apr 17 09:58:33 2007] [notice] Child 1864: Acquired the start mutex.
[Tue Apr 17 09:58:33 2007] [notice] Child 1864: Starting 250 worker threads.
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 :
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
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 :
Code: Alles auswählen
PHP-Errors Im Browser ausgeben ändern
PHP-RegisterGlobals On ändern
PHP-Magic-Quotes-GPC On ändern
PHP-Zend-ZE1-Kompatibilität Serverstandard ändern
PHP-Register-Long-Arrays On ändern
PHP-Session-Use-Trans-SID On ändern
PHP-Allow-Call-Time-Pass-Reference On ändern
PHP-MySQL-Secure-Login Serverstandard ändern
PHP Suhosin Session Encryption Serverstandard ändern
PHP Suhosin Mail Protection 1 ändern
PHP4-Extensions einstellen php4 php3 php ändern
PHP5-Extensions einstellen phtml php5 ändern
CGI-Extensions einstellen cgi pl py sh rb ändern
Directoryindex einstellen index.html index.htm index.shtml index.php index.php4 index.php5
Ich hole mir jetzt aber noch das gesamte Log des Providers und gucke, ob da irgendwas drin steht. Das hier :
aha.... ich schreib mal an Hosteurope und frage, was das ist.(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
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 :
Heisst das also, daß ich mir bei der Grösse meines Projektes ein anderes CMS-system suchen muss?
lg,
Suse
So, also, Antwort von HostEurope liegt vor :
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.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
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
lediglich verhindern das mal ein php-Script Amok läuft.
Default ist 0 (disable)
http://www.hardened-php.net/suhosin/configuration.html
Vielleicht doch. In der .htaccess fileZuMe hat geschrieben:jau, nur ausstellen kann ich diese funktion wohl nicht.
http://bugs.typo3.org/view.php?id=4930
-
- Beiträge: 112
- Registriert: Mi 21. Jun 2006, 07:00
- Wohnort: Nordhausen
- Kontaktdaten:
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
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
-
- Beiträge: 103
- Registriert: Fr 28. Jan 2005, 15:15
- Wohnort: Unna
- Kontaktdaten:
-
- Beiträge: 112
- Registriert: Mi 21. Jun 2006, 07:00
- Wohnort: Nordhausen
- Kontaktdaten:
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 ?
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 ?
*** make your own tools (wishlist :: thx)
-
- Beiträge: 103
- Registriert: Fr 28. Jan 2005, 15:15
- Wohnort: Unna
- Kontaktdaten:
-
- Beiträge: 472
- Registriert: Di 15. Apr 2008, 15:57
- Wohnort: Michelstadt
- Kontaktdaten: