Forum

Hi mong,

hast du auch schon mal einen anderen Browser als IE probiert?

Ich habe so ein Zeit Problem mit dem Konqueror auf dem User-profil.


Arthur

hiho. ja: IE7, ie8 mit und ohne kompatibiltätsmodus, firefox usw... bei allen das gleiche

lg, mong

hmm.. ich hab nuna uch mit den modulen ein problem.

ich wollte 8 themes installieren. aber opn installierte immer nur eines und hängte sich auf. dh ich konnte die nur schrittweise installieren.

sowie ich die deinstallieren wollte hängte sich das ding auf. ich kann kein einziges modul mehr deinstallieren.

meine vermutung ist das der hoster ein problem hat aber - bei was? ich kenn mich im php zu wenig aus....

lg, mong

das hier bekomm ich als info vom php server falls das hilft:

PHP Version5.2.10PHP SAVE MODENOPHP Memory Limit40MMySQL Server Version5.0.32-Debian_7etch10-logMySQL Client Version5.0.32sqlite Server Version2.8.17 

• description ::=> 5.0.32-Debian_7etch10-log
• version ::=> 5.0.32

dbnamedb1102764-opnWebserver InterfaceAPACHE2HANDLERwget (GNU Wget 1.10.2)/usr/bin/wgetlynx (?)/usr/bin/lynxzip (Zip 2.32 (June 19th 2006). Usage:)/usr/bin/zipunzip (UnZip 5.52 of 28 February 2005, by Debian. Original by Info-ZIP.)/usr/bin/unzip

Vorschlag:

Mach mal einen Account OPN-Team und gib diesem Webmaster Rechte - Sende das entsprechende Passwort und die Url zum Portal per PM an mich.

Dann schauen wir auch mal

ist gesendet

Also mein erster Eindruck, ich glaub nicht das es an OPN an sich selbst liegt.

An Artikel auf keinen Fall - weil es auch andere Bereiche betrifft.

Datenbank - sieht auf den ersten Blick OK aus. Prüfung ob Felder fehlen geht und ist Fehler frei.

Datenbank Optimieren (Modul) - Geht auch aber evt. Größe der db. (Es gibt Hoster die diese beschränken)

Schwere Frage...

Denkbar irgendwein Timeout beim Inhalt aber das müsste dann eigentlich bei jedem Klick sein.

Sieht mehr so aus das beim Schreiben in die DB was passiert.

Ich wurde den Support bemühen vom Hoster - Datenbank soll er Prüfen, Festplatte usw. meiner Meinung stimmt da was nicht aus der ebene.

Zusätzlich einen Datenbank Sicherung erstellen, Dateien sichern. Und lokal das ganze mal probieren.

Da sich der Fehler verstärkt tippe ich stark auf ein Datenbank Problem.

Machbar wäre auch eine neue Datenbank erstellen die alte Sichern und die Sicherung in die neue einspielen. Kann helfen das es erstmal geht. Wenn es hilft ist es aber nur eine Kurzfristige Lösung

Gibt noch ein paar Sachen die man machen könnte aber ich würde erstmal das genannte tun.

lieben dank stefan

mittlerweile weiss ich was da is aber ka was ich dagegen machen kann.

in den logfiles bekomme ich folgende meldung wenn iche inen artikel freischalten will:
[Fri Aug 21 16:17:48 2009] [error] [client 80.80.248.199] ALERT - maximum execution depth reached - script terminated (attacker '80.80.248.199', file '/is/htdocs/wp1102764_4BHXLXPAPG/www/class/class.errorhandler.php', line 45), referer: http://www.mnsg.at/system/article/admin/index.php?opnparams=BTwGewJvABxWYlMgU1RWcgRoAidWI1Fw
[Fri Aug 21 16:54:42 2009] [error] [client 93.82.72.165] ALERT - maximum execution depth reached - script terminated (attacker '93.82.72.165', file '/is/htdocs/wp1102764_4BHXLXPAPG/www/class/class.errorhandler.php', line 45), referer: http://www.mnsg.at/system/article/admin/index.php?opnparams=Bz4EeV0wAh5TZwd0U1RXc1s3DCkCd1Fw

das war 2 mal ich - einmalö aus der firma und einmal von zu hause.

ich hab ein bisl gegoogled. anscheinend haben die HS europe eins kript installiert ;

suhosin.executor.max_depth=200


und damit verhidnert er, waruma uch immer, ein ausführen der artikel usw.

was kann ich dagegen machen?

lg

achja - den post hab ich hier gefunden.. soll ich das machen? wo muss ich das machen und wie ?

Stupid Hardened-PHP / Suhosin blocks generation of frontend output.

My hoster silently activated Hardened-PHP and TYPO3 failed perfectly - just a "page is being generated" message in the frontend and a nonspecial warning in the error.log (see additional information).
The problem was the ini declaration "suhosin.executor.max_depth" (see: http://www.hardened-php.net/suhosin/configuration.html#suhosin.executor.max_depth) [^] which was set to 50.
This blocks the character set conversion in tslib_cs (so it is a core problem).
Maybe it would be good to add a section to the install tool, which checks for the setting of this variable and puts out a warning if activated.

By the way: solution is (at least if the hoster allows this) to set:

php_value suhosin.executor.max_depth 0
php_flag suhosin.simulation On

in a .htaccess file
- The first one deactivates the maximum execution depth (at least needed).
- The second one sets Suhosin to simulation mode (not needed, but who knows what Suhosin might block in future...)

keiner ne idee ?

lg, mong