Problem mit Contenido 4.3.2beta

[emergence]

seit dem ich die aktuelle version verwende habe ich bei meinem lokal apache server (opensa 1.0.4) ein geschwindigkeits problem. sobald ich mich angemeldet habe, scheint es fast so als ob das php script in einer endlosschleife hängen würde. erst nach 20 sekunden erscheint die eigentlich admin oberfläche. der rechner reagiert innerhalb dieser zeitspanne entweder überhaupt nicht oder sehr träge. auslastung der cpu liegt bei 100%.

hier ein auszug aus dem apache access.log
127.0.0.1 - - [28/Jul/2003:12:38:04 +0200] "POST /contenido/index.php?contenido=5e2daef9c355eeb3b3fe8d37619c1747 HTTP/1.1" 200 280
127.0.0.1 - - [28/Jul/2003:12:38:22 +0200] "GET /contenido/main.php?area=login&frame=1&changelang=&lang=1&client=1&contenido=5e2daef9c355eeb3b3fe8d37619c1747 HTTP/1.1" 200 913

ähm irgendeine idee woran es liegen könnte ?

die vorgänger version (4.3.1b) lief hingegen wirklich problemlos.

[Renkert]

Komisch, da würden mal ein paar Details zu Deiner Serverumgebung nützen. Ich hab Contenido gerade mal im Debugg-Modus laufen lassen in meinem Editor, das ist das Ergebnis:

Debugger_Logfile_BoxMaxx_Webstudios:
"Action", "navigating: http://localhost:8080/file:/H:/test/cms ... /index.php", "14:26:58", ""
"Action", "debug session started", "14:27:00", ""
"Action", "debug session finished", "14:27:21", ""
"Action", "navigating: http://localhost:8080/file:/H:/test/cms ... /index.php", "14:27:30", ""
"Client", "POST:", "14:27:30", ""
"Client", "username=sysadmin", "14:27:30", ""
"Client", "password=sysadmin", "14:27:30", ""
"Client", "vaction=login", "14:27:30", ""
"Client", "formtimestamp=1059395241", "14:27:30", ""
"Client", "belang=de_DE", "14:27:30", ""
"Client", "x=8", "14:27:30", ""
"Client", "y=11 ", "14:27:30", ""
"Action", "debug session started", "14:27:30", ""
"Action", "debug session finished", "14:27:42", ""
"Action", "navigating: http://localhost:8080/file:/H:/test/cms ... header.php", "14:27:42", ""
"Client", "GET:", "14:27:42", ""
"Client", "changelang=1", "14:27:42", ""
"Client", "changeclient=1", "14:27:42", ""
"Client", "contenido=f3c1cf64489512bfd3166fadcf0ec507", "14:27:42", ""
"Client", "target frame: header", "14:27:42", ""
"Action", "navigating: http://localhost:8080/file:/H:/test/cms ... o/main.php", "14:27:42", ""
"Client", "GET:", "14:27:42", ""
"Client", "area=login", "14:27:42", ""
"Client", "frame=1", "14:27:42", ""
"Client", "changelang=", "14:27:42", ""
"Client", "lang=1", "14:27:42", ""
"Client", "client=1", "14:27:42", ""
"Client", "contenido=f3c1cf64489512bfd3166fadcf0ec507", "14:27:42", ""
"Client", "target frame: content", "14:27:42", ""
"Action", "debug session started", "14:27:42", ""
"Action", "debug session finished", "14:28:34", ""

Wie Du siehst (anhand der Zeitangaben hinter jeder Aktion) gibt es bis auf die Breakpoints (die werden vom Debugger bzw. von mir bestimmt) keinerlei Verzögerungen mit folgendem Server

WinXP_SP1 / Apache 2.0.46 / PHP 4.32

Also, das liegt nicht an Contenido, irgendwas schleift da Deinen Server...

[kypta]

Ich muss leider zustimmen. Habe auf NT4.0 / IIS4.0 mit PHP4.3.2 auch festgestellt: Contenido 4.3.2.1b ist wesentlich langsamer als Contenido 4.3.1b.
Im errorlog.txt steht:

[28-Jul-2003 13:45:40] PHP Warning: fopen(e:/av_cms/4321/contenido/locale//LC_MESSAGES/contenido.po): failed to open stream: No such file or directory in e:\av_cms\4321\contenido\includes\functions.i18n.php on line 73
[28-Jul-2003 13:45:40] PHP Warning: fopen(e:/av_cms/4321/contenido/locale//LC_MESSAGES/contenido.po): failed to open stream: No such file or directory in e:\av_cms\4321\contenido\includes\functions.i18n.php on line 73
[28-Jul-2003 13:45:40] PHP Warning:
usw. usw.

Im upgradeerrorlog.txt steht:

2003-Jul-Mon 13:33:21: error 1064 (You have an error in your SQL syntax near 'FROM acon431_phplib_active_sessions ORDER BY DESC' at line 1) - Invalid SQL: SELECT FROM acon431_phplib_active_sessions ORDER BY DESC<br><br>
2003-Jul-Mon 13:33:21: error 1064 (You have an error in your SQL syntax near 'FROM acon431_phplib_active_sessions ORDER BY DESC' at line 1) - next_record called with no query pending.
2003-Jul-Mon 13:33:21: error 1064 (You have an error in your SQL syntax near 'FROM acon431_sessions ORDER BY DESC' at line 1)
usw. usw.

Beim Setup-Schritt Nr. 6 kam:

PHP-Warning: fopen(/LC_MESSAGES/contenido.po): failed to open stream: No such file or directory in e:\av_cms\4321\contenido\includes\functions.i18n.php on line 73
usw. usw.

Gruss
Thomas

[kypta]

Um genauer zu sein: Langsam ist das Backend. Das Frontend ist so schnell wie von 4.3.1b gewohnt.

Gruss
Thomas

[krell]

Im errorlog.txt steht:

[28-Jul-2003 13:45:40] PHP Warning: fopen(e:/av_cms/4321/contenido/locale//LC_MESSAGES/contenido.po): failed to open stream: No such file or directory in e:\av_cms\4321\contenido\includes\functions.i18n.php on line 73
[28-Jul-2003 13:45:40] PHP Warning: fopen(e:/av_cms/4321/contenido/locale//LC_MESSAGES/contenido.po): failed to open stream: No such file or directory in e:\av_cms\4321\contenido\includes\functions.i18n.php on line 73
Thomas

Hi,

da sind zwei "/" Zeichen in ..."locale//LC_MESSAGES". Hatte auch bei der Installation Fehlermeldungen bezüglich dieser Datei.

[Renkert]

Hmmm, die Einträge im Errorlog habe ich auch, seltsam, kam noch nie auf die Idee dort nachzusehen, weil meine Debugger nie anschlugen und Contenido bei mir eigentlich sehr schnell läuft....komisch

Aber irgendwie doch nicht verwunderlich. Contenido bekommt langsam ne ordentliche Grösse....Typo3 verwendet für sein Backend sogar einen eigenen Cache-Mechanismus....

[axxxcel]

Bis jetzt lief das Backend der 4.3.1b von der Geschwindigkeit her anstandslos. Nach der (Neu)Installation der 4.3.2 treten bei mir die gleichen Symptome auf.

Hier der Auszug aus Datei Errorlog.txt von Contenido:

[26-Jul-2003 18:31:15] PHP Warning: fopen(C:/Program Files/BigApache/Apache/htdocs/sites/contenido/v43/contenido/locale//LC_MESSAGES/contenido.po) [<a href='http://www.php.net/function.fopen'>function.fopen</a>]: failed to create stream: No such file or directory in C:\Program Files\BigApache\Apache\htdocs\sites\contenido\v43\contenido\includes\functions.i18n.php on line 73

Im Apache Errorlog ist folgender Eintrag zu finden:

[Sat Jul 26 18:31:37 2003] [error] [client 192.168.5.5] Premature end of script headers: php.exe, referer: http://www.auvorstadt.local/sites/conte ... a33cc76a66

Und hier noch meine Systemkonfiguration

PHP Version 4.3.1
Apache/2.0.44
MySQL 3.23.52-nt
Window Server 2003

Bei der eigentlichen Installation bekam ich (im gegensatz zu "Krell") keine Fehlermeldung. Auch die Prüfroutinen am Anfang der Installation verliefen erfolgreich. Wie gesagt, die 4.3.1b läuft nach wie vor auf dem gleichen System (natürlich mit eigener DB ) von der Geschwindigkeit her ganz problemlos und ohne derartige Fehlermeldungen.

Hoffe das hilft, dass Problem weiter einzugrenzen.
lg
Alexander

[Renkert]

Sieht so aus als hätte TIMO da unter Linux mit POEDIT gearbeitet, angeblich crossplattform fähig, da ist wohl was schief gelaufen.....auf jeden Fall verursacht die Datei i18n die Fehler in Apache....

[timo]

Sieht so aus als hätte TIMO da unter Linux mit POEDIT gearbeitet, angeblich crossplattform fähig, da ist wohl was schief gelaufen.....auf jeden Fall verursacht die Datei i18n die Fehler in Apache....

Mit poEdit an sich hat das herzlich wenig zu tun. poEdit erzeugt nur Catalog-Files (.po und .mo), die weder Pfadangaben noch sonstige systemspezifische Dinge enthalten. Doch soweit ist das richtig, ja, wir verwenden (und empfehlen) poEdit für die Übersetzung - übrigens die Win32-Variante.

Da jedoch die meisten Win32-Benutzer von Contenido ihre WAMP(P) nicht mit gettext konfiguriert haben (wozu auch - bei (fast) allen Linux-Distributionen ist gettext fester Bestandteil der Distribution und wird beim PHP-kompilieren automatisch integriert), haben wir einen gettext-Emulator eingebaut. Daß dieser langsamer ist als eine Library-basierte Methode, kann man sich an dieser Stelle bereits denken

Was mich allerdings an der Sache wundert: Zum einen dauert das einloggen auf meiner Test-WAMP auf einem P3-500 nur ca. 5 Sekunden, und zum anderen kann ich mir den Fehler nicht erklären (zwischen den doppelten Backslashes sollte normalerweise der Sprachcode stehen, was aber auch nicht schlimm ist, denn wenn er das File nicht öffnen kann, übergibt er den Default-String (englisch)). Welche WAMP verwendest du? In unserer Contenido-WAMP (auch jeweils aktuellste PHP- und MySQL-Versionen) funktioniert es tadellos. Kannst du uns mal deine php.ini schicken?

Grüße,
Timo

[Renkert]

Hmmm, also um ehrlich zu sein, versteh ich nicht ganz was Ihr da macht, anstatt die bestehenden Bugs (und da gibts ja genug) rauszuschreiben, implementiert Ihr mit jeder Beta neue Scripte...und neue Bugs!

Ich möchte nicht unverschämt sein, aber wie wollt Ihr denn in 2 Monaten noch in der Lage sein Eure Fehlerquellen zu finden ????

[timo]

Gegenfrage: Wie soll es anders gehen? Jeder Bug, der in dieser Version auftritt, wird in der nächsten gefixt. Damit sehe ich überhaupt kein Problem.

Wenn das bei KDE der Fall wäre, wie du ihn beschreibst, wären wir immer noch bei KDE 0.9.1.2.5.1.2.3.1.2.3.3beta. Ein bugfreies System gibt es nicht, außer als Illusion.

Die meisten Bugs sind keine Bugs an sich, sondern Probleme, die mit verschiedenen PHP-Versionen und/oder Konfigurationen entstehen. Im Prinzip fixen wir in diesem Sinne keine Bugs, sondern bauen Workarounds für Probleme, die die Systemadministratoren mit Ihren unüblichen Konfigurationen verursachen. Wenn jemand in seiner php.ini das ausführen von dem Befehl "echo" verbietet, kann er nicht von uns erwarten, daß dann PHP-Scripte auf seiner Website trotzdem etwas zum erscheinen bringen - als triviales Beispiel.

[Renkert]

Das Thema wurde hier neulich denke ich in einem Thread zur Genüge diskutiert, da hatte ich das Gefühl Ihr würdet über das ein oder andere nachdenken.

Aber dem ist wohl nicht so. Deine Affinität zu KDE habe ich ja mittlerweile begriffen, dennoch solltest Du KDE nicht als Standardbeispiel für alles hier nehmen, denn dass es auch anderst geht, zeigt OpenOffice.

Die php.ini Einstellungen sind eine Sache. Du weisst aber selbst, dass Du fast jede einzelne Variable dort abfragen kannst. Es ist zwar schön, dass Ihr beim Setup die php Version abfragt, aber das alleine kanns ja wohl nicht sein, wenn, wie Du selbst sagst, die php.ini Einstellungen verändert wurden. Was ist also das Problem diese Einstellungen abzugleichen?

Wo ist das Problem diese Variablen in einer separaten Datei zu speichern, zusammen mit allen Contenido Einstellungen, damit der User dieser per sendmail oder als einfache eMail an Euch senden kann. Wo ist das Problem diese Daten bei Euch auszulesen und dann festzustellen wo´s klemmt ?

Das wären für mich grundlegende Dinge um Fehlern auf die Spur zu kommen....

Aber wie gesagt, ich muss ja nicht alles verstehen.

Trotzdem sieht es so aus als würdet Ihr hier Euer Ding durchziehen ohne auf das Urteil oder Anregungen der Community Wert zu legen.....was ja Euer gutes Recht ist !

Da jedoch die grundlegenden Dinge, die von verschiedenen "Interessenten" hier im Board angesprochen wurden, anscheindend nicht machbar sind, macht es für mich keinen Sinn hier irgendetwas zu bewegen....

Da liegt es nahe ein Zitat eines User hier anzubringen: "Schade Contenido..."

[axxxcel]

Also ergänzend zu dem Problem möchte Ich noch wie von timo gewünscht folgendes hinzufügen. Ich arbeite mit dem WAMP Paket Bigapache (http://www.bigapache.org) und habe damit eigentlich nur gute Erfahrungen gemacht. In meiner Testumgebung laufen Postnuke, Xoops, Conpresso, Der Dirigent damit ohne Probleme.

Das Verhalten von Contenido hat sich erst mit der Version 4.3.2b entsprechend verschlechtert, ohne das an der PHP-Konfig, unter der die 4.3.1b sehr performant lief, etwas geändert wurde.

Der Check des Installationsprogramms wirft ja auch lauter grüne Häckchen aus und sagt das die PHP-Konfig und die Schreibrechte ok sind.

Ich stelle gerne meine php.ini bei, wenn mir jemand sagt, wohin ich Sie mailen soll.

Weiters funktioniert das Login bei mir zumeist auch recht schnell, das Backend wird erst beim Arbeiten merklich langsamer. Insbesondere wenn man Artikel bearbeitet füllt sich das Errorlog von Contenido und Apache recht schnell.

Falls Ihr sonst noch Angaben benötigt gebt bescheid.

[ConCon]

Das kann durchaus an der neuen lang-function liegen, ist ja auch ne ungewöhnliche Art sowas zu realisieren...

Aber ich sehs auch so, ich würd mal aufhören ständig neue Sachen einzubauen bevor das Ding nicht fehlerfrei läuft....

[timo]

Wo ist das Problem diese Variablen in einer separaten Datei zu speichern, zusammen mit allen Contenido Einstellungen, damit der User dieser per sendmail oder als einfache eMail an Euch senden kann. Wo ist das Problem diese Daten bei Euch auszulesen und dann festzustellen wo´s klemmt ?

Weil das Zeit kostet. Wenn in den nächsten Tagen etwas Zeit bleibt, wird so etwas sicher kommen. Wie auch bereits diskutiert, haben wir die derzeit nicht. Übrigens ist die 4.3.2b nicht erst seit der großen Diskussion vor ein paar Tagen entstanden.

Trotzdem sieht es so aus als würdet Ihr hier Euer Ding durchziehen ohne auf das Urteil oder Anregungen der Community Wert zu legen.....was ja Euer gutes Recht ist !

Sei versichert, daß jedes Thema, jedes Problem und jeder Bug vom Forum bei uns im Team durchgesprochen wird - was nicht heißen muß, daß der Bug/das Problem sofort in der nächsten Version gefixt wird.