code und code2: Ausführung gestört

[evaki]

Genauer:
Fatal error: Maximum execution time of 30 seconds exceeded in
/www/framework/frontend.functions.php on line 657

Einfache Textausgaben per echo oder ein phpversion(); stellen kein Problem dar
phpinfo(); zum Beispiel hinterläßt die Bremsspur: Fatal error: Maximum execution.........

Installiert ist v2.8.2 SP2 ohne Hotfix

Hat jemand einen Verdacht?

Komme leider nicht an die Serverlogfiles.

MfG. Evaki

[kweitzel]

Dazu brauchst Du die Serverlogs nicht ... die Nachricht ist eindeutig: Ein Script muss zur Abarbeitung länger als 30 Sekunden laufen ... und das draf es nicht. Warum ein gegebenes Script so lange benötigt kann ich Dir allerdings nicht sagen. Vielleicht ist der Server einfach überlastet ...

Gruß

Klaus

[evaki]

Ein phpinfo(); außerhalb vom CMS gestartet läuft sofort und schnell.
Deshalb bin ich so irritiert.
MfG. Evaki

[kweitzel]

OK, dann muss es was mit WB zu tun haben ... ich hatte es noch nicht ernsthaft probiert, da ich selten Code ausserhalb von Templates verwende.

Ich hab mal bei den Entwicklern angefragt.

Gruß

Klaus

[einteik]

Kannst du denn einmal das eingegebene Script hierher kopieren?

Die entsprechende Zeile

Code:

$content = str_replace($insert, '', $content);

(ich hoffe, dies ist auch deine Zeile 657) führt nichts wildes durch. Wenn Fehler auftreten, sollte dies schon vorher geschehen.

[evaki]

Sieht gleich aus.
Da die Dateien nochmals übertragen wurden, ist ein Dateifehler eher weniger wahrscheinlich -morgen gucke ich trotzdem nochmal. Ob eventuell ein Datenbankfehler in Frage kommt, kann ich nicht beurteilen.

Habe es soeben noch auf der zweiten Domain getestet, wo es es störungsfrei  läuft.
Da es unterschiedlich ausgestattete Pakete sind, kann man es sicher nicht vergleichen.
Habe im Moment auch keinen Schimmer davon, ob eventuell open_basedir aktiviert ist und ob dies in diesem Zusammenhang überhaupt eine Bedeutung haben kann.
MfG. Evaki

[Luisehahne]

Das Hotfix sollte auf jedenfall auch eingespielt werden. Ich selber hatte letztens das Problem des Timeout und festgestellt das bei Aktulisierungen seitens des Hosters, die DB Tabellen als engine "innoDB" erstellte werden, statt mit MyIsam. Und hatte dan nein Mix von beiden.

Bitte mal kontrollieren. Das Hotfix enthält für den Installer ein Fix der die richtige engine einträgt.

Auch gibt es Ändeurngen in der class.admin und class.wb. Die WB Homepage läuft ebenfalls mit 2.8.2 SP2 allerdings mit Hotfix. und nutzt sehr intensiv das CodeModul

Dietmar

P.S. WIr stellen leider immer wieder fest das die Hotfixes nicht ernst genommen werden, warum auch immer. Ist doch ein guter Weg um schnell ein bekanntes Problem zu fixen, statt bis zur nächsten Stable zu warten zu müssen

[evaki]

HotFix überspielt, upgrade-script gestartet: Ergebnis: Script ohne Fehlermeldung

Wechsel zum Backend

Test mit phpinfo() bringt weiterhin Timeout

Soeben auch Zugang zum Serverlog bekommen.
<OT>
Schön, daß auch SM_2-Fehler drinstehen:
show_menu2 error: $aOptions is invalid. No flags from group 1 supplied!
Was das wohl sein mag, da schaue ich später rein.
</OT>
Ein Wechsel zu ALL CSS bringt weiterhin Timeout

Werde einen Test laufen lassen, der mir etwas über die Sicherheitseinstell ungen erzählt,
auch wenn das nichts mit WebsiteBaker zu tun haben mag. (ist ok)

Hoffentlich wird das keine Weihnachtsbeschäftigung.

MfG. Evaki

1. Ergebnis: DB
MyISAM und InnoDB "gemischt"
utf8_general_ci und utf8_unicode_ci "gemischt"

2. Ergebnis: DB
a.) Export und ersetzt (MyISAM und InnoDB)
b.) Import bringt Fehlermeldung:

Code:

SQL-Befehl:

\ r \ n value = page_title

MySQL meldet:  
 #1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\r\n value=page_title' at line 1

c.) Nun das DB-Backup von gestern eingespielt und anschließend upgrade-script (HotFix) gestartet

d.) Ergebnis: Nach wie vor Timeout

e.) ratlos, nein doch nicht: InnoDB per Hand korrigiert (nach MyISAM )

f.) open_basedir restriction in effect
Der Hoster wird benachrichtigt. Vielleicht hatte ich ja den "richtigen Riecher"

g.) Der Hoster ist benachrichtigt. Die Hotline versteht aber das Problem mit "open_basedir restriction" offensichtlich nicht. Das kann ja noch lustig werden, wenn das Ticket nicht weiter gereicht wird.

[DarkViper]

Sorry, in der Weihnachtszeit dauert es eben etwas länger, da so ganz nebenbei auch noch geringfügige private, familiäre Dinge zu erledigen sind.

Ich hab mir das Code/code2 + phpinfo - Problem mal kurz zu Gemüte geführt.
Dass hier Probleme auftreten müssen ist völlig logisch und es ist nur ein Zufall, dass es teilweise funktioniert hat.

Zerlegen wir das Problem doch mal kurz in seine Bestandteile:

• die Funktion phpinfo() gibt bei Aufruf alle möglichen Systeminformationen direkt zum Browser aus. Nicht als Datenfeld zur Weiterverarbeitung, sondern als vollständige, komplette, HTML-Formatierte Website.
• Eine Section, basierend auf einem Code/Code2 - Modul baut alle direkten Ausgaben (echo(), print() und eben auch phpinfo()) am definierten Platz des Seiten-Templates, irgendwo zwischen <body> und </body> ein.

Wie sieht jetzt eine zum Browser gesendete Website aus, bei der in einer Section ein phpinfo() - Funktionsaufruf erfolgte?
Solch ein Ergebnis (schematisiert) sieht etwa SO aus:

Code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd">
<html>
    <head>


    </head>
    <body>
        <!-- oberer Bereich des Seitentemplates... -->
        ...
<!-- Beginn Ausgabe von phpinfo() -->
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd">
        <html>
            <head>
                <style type="text/css">
                ...
                </style>
            </head>
            <body>
                ...
            </body>
        </html>
<!-- Ende Ausgabe von phpinfo() -->
        ...
        <!-- unterer Bereich des Seitentemplates... -->
    </body>
</html>

Kurz gesagt, ist es absoluter Unfug, eine komplette HTML-Seite innerhalb einer anderen HTML-Seite auszugeben.
Dass bei derartig ungültigem Schrottcode zum Beispiel (was im aktuellen Fall auch passiert) die RegExpressions der Ausgabefilter - die sich auf wenigstens halbwegs validen HTML-Code verlassen -  hoffnungslos überfordert sind und daher versagen, ist völlig normal.

[evaki]

Mag ja alles zutreffen, aber bei anderen Domains funktionierts (Heute auch noch ein paar andere laufende ausprobiert), und auf einem Lokalen Server auch. Bis v.2.8.1 gab es überhaupt keine Probleme dieser Art.

Dazu kommt auch noch:

Code:

Warning: file_exists(): open_basedir restriction in effect. File(/home) is not within the allowed path(s): (/home/www:/usr/phpbin:/tmp:/usr/local/php:/usr/local/php5:/usr/local/php53:/usr/local/php5.3:/usr/local/php-5.3) in /home/www/doc/12345/domain.de/www/account/login_form.php on line 40

Eine Fehlermeldung, die nur auf diesem beanstandeten Host ausgegeben wird.

Bisher meinte ich eine Section php dort zu sehen, wo es per Module eingefügt wird. Bei Code2 erst recht, weil hier auch html und anderes eingefügt werden kann.
Zum phpinfo(): Den Browser interessiert es nicht, das Template auch nicht, und ja, natürlich sieht es dann "nicht mehr schön aus". Kann für einen kurzen Einblick aber auch völlig egal sein. Letztendlich muß es m.E. den Anwendern überlassen bleiben, was sie dort an Code einfügen und sollte durch das CMS nicht eingeschränkt werden. Wenn es zukünftig restriktiv ausgelegt wird, dürften auch keine Zugriffe mehr auf die DB und anderes erfolgen dürfen. Nur geht dann eine der wichtigsten Vorteile des CMS verloren, so zumindest meine Ansicht.
MfG. Evaki

[kweitzel]

Die "open_basedir restriction in effect" Fehlermeldung hat allerdings nichts mit WebsiteBaker zu tun, sondern mit der PHP Configuration auf dem Server. Aus der Serverkonfiguration heraus wird entschieden, dass versucht wird auf einen nicht erlaubten Ordner (siehe die Pfadliste) zuzugreifen. Das wird vom Server unterbunden.

Das ist etwas, was Dein Hoster übernehmen muss, da können wir nichts machen.

Gruß

Klaus

[evaki]

Morgen gibt es dann hoffentlich Anwort vom Hoster.
Zur Zeit glaube ich nämlich, daß dort "der Hund begraben ist"
Gut ist in jedem Falle Eure Unterstützung, weil damit ein Problem von mehreren Seiten betrachtet werden kann.
MfG. Evaki

[evaki]

Abschluß:
Trotz Deaktivierung von open_basedir blieb das Problem.
Weitere Untersuchungen melden Fehler in den Datenbankeinträgen.
Zukünftig wird hierauf mehr geachtet werden müssen.
Die Werkzeuge hierfür sind vorhanden, leider jedoch nur wenige Fachleute.

Bei der bestehenden Installation kann aktuell wohl niemand mehr feststellen wo "der Wurm drinsteckt".
Ein Admin-Tool für die Prüfung der WebsiteBaker-Datenbankeinträge wäre nicht schlecht.
Fehler treten nämlich besonders dann auf, wenn "alte" Einträge in neue SQL-Versionen "reingezwungen" werden.
Einige Module tragen anscheinend auch die falsche Engine ein.
MfG. Evaki

[evaki]

Habe es nochmal begutachten lassen
Fatal error: Maximum execution time of 30 seconds exceeded in
/www/framework/frontend.functions.php on line 657

Dort wurde von unserem Ex-Admin eine Änderung vorgenommen, und nun geht es wie gewünscht.
Es liegt also an v2.8.2. Vordem gab es das Problem nicht.

Damit nun keine ungewollten Änderungen (bei Update-Versuch etc) passieren, wurde der Kern gegen Zugriff gesperrt.
Wenn es nun ungestört funktioniert, soll es mir recht sein.

MfG. Evaki

[badknight]

Habe es nochmal begutachten lassen
Fatal error: Maximum execution time of 30 seconds exceeded in
/www/framework/frontend.functions.php on line 657

Dort wurde von unserem Ex-Admin eine Änderung vorgenommen, und nun geht es wie gewünscht.
Es liegt also an v2.8.2. Vordem gab es das Problem nicht.

Damit nun keine ungewollten Änderungen (bei Update-Versuch etc) passieren, wurde der Kern gegen Zugriff gesperrt.
Wenn es nun ungestört funktioniert, soll es mir recht sein.

MfG. Evaki

schön, dass es nun funktioniert. Doch leider muss ich dir sagen das die von dir genannte Datei nur 662/663 Zeilen hat..

Welcher code war denn bei dieser Stelle?

[evaki]

line 657
Irgendwas soll da gefiltert werden -keine Ahnung.
Habe wegen Wechsel des FTP-Users keinen Zugriff mehr auf den Code.
MfG. Evaki

[DarkViper]

Ich hab das weiter oben schon ausführlich zu erklären versucht.
Ich könnte wetten, dass die Seite, die hier Probleme macht, garantiert keinen validen HTML-Code enthält. Und zwar nicht nur ein nicht geschlossenes DIV, sondern wesentlich gravierender.

Dass wir bei Ausgabefiltern etc. nicht jeden möglichen, hausgemachten HTML-Fehler berücksichtigen können und auch nicht wollen, sollte einleuchten. Die Filter sind auf halbwegs sauberen Code ausgelegt und da funktionieren sie auch.
(wer sein Auto abweichend vom Plan zusammenbaut, sollte sich auch nicht wundern, wenn es anschließend nicht fährt)

[evaki]

Bisher gibt es keine fehlerhafte Ausgabe.
Alles funktioniert wie von v2.8.1 her gewohnt.
Da HTML-strict gefordert wurde, wird hier schon sehr früh auf validen Code geachtet.
Daß bei phpinfo() nichts valides herauskommt ist natürlich klar. Hier sollte nur die Ausführung nicht verhindert werden.
Freuen wir uns, v2.8.2 läuft, und mittlerweile zur Zufriedenheit, da keine weiteren Probleme mehr zu sehen sind.
MfG. Evaki

[NorHei]

Wenn ein Simpler HTML Fehler das ganze System(CMS) zum Absturz bringen kann, ist das etwas wo man doch eventuell ein wenig drüber nachdenken solle ??