CMS Made Simple Forums

Ich habe im Backend ein (memory-exhausted) Problem, wenn ich eine AdvancedContent Seite bearbeite (sporadisch, nicht immer). Ich verwende die neueste AdvancedContent Version (0.4.1) auf dem SVN-Repository (heute morgen ausgecheckt) und CMSms 1.8.1. Mein PHP-Speicherlimit ist bei 32MB.

Haben das Problem auch andere bzw. konnte das schon mal jemand nachstellen?

Wie mir Georg mitteilte, ist einer der größeren Speicherfresser die Dropdown-Liste für die übergeordnete Seite - die bei Adv.Content ja nochmal für FEU geladen wird. Kann man die zweite Liste nicht abschaltbar machen - FEU wird ja nur auf einigen Seiten verwendet?

kann ich leider nicht bestätigen, eventuell sind 32MB doch zu wenig.
Ich habe v0.4 in Verwendung und 64MB ohne solche Probleme soweit.

Ich habe jetzt gerade noch einmal getestet, das Problem tritt auch bereits auf, wenn ich bei der Seitenbearbeitung unter Optionen den WYSIWYG-Editor versuche abzuschalten. Wenn ich die Seite als normale Content-Seite abspeichere, tritt das Problem nicht auf.

Vielleicht liegt es mit 1.8.1 zusammen ich sitz immer noch auf 1.7.1 

Na vielleicht ist es das?

http://forum.cmsmadesimple.org/index.ph ... w.html#new

hlf wrote: Na vielleicht ist es das?

http://forum.cmsmadesimple.org/index.ph ... w.html#new

Könnte sein.
Kann das aber gerade nicht testen. Mach ich viell. heute nacht...
Aber so oft werden keine Regulären Ausdrücke bei AdvancedContent verwendet bzw. hängt das von der Anzahl der Inhaltsblöcke und der verwendeten Parameter zusammen.
Andis Template ist aber ein ganz einfaches mit 6 Inhaltsblöcken.
Ich hatte schon zu Testzwecken ca. 60 Blöcke im Template und keinen Fehler.
(zumindest nicht serverseitig )

Nun ja es ist Smarty wo mit regulären Ausdrücken intensiv gearbeitet wird und das ist keine eigene direkte Verwendung.

Wenn man mal sehen könnte (Meldung) wo es absemmelt hätte man vielleicht einen Ansatzpunkt.

Andiministrator wrote:
Ich habe jetzt gerade noch einmal getestet, das Problem tritt auch bereits auf, wenn ich bei der Seitenbearbeitung unter Optionen den WYSIWYG-Editor versuche abzuschalten.

Ich kann zumindest bestätigen, dass sich der Speicherverbrauch tatsächlich beinahe verdoppelt (springt von ca. 24MB auf bis zu ca. 50MB)
Das kann aber unmöglich nur am Modul liegen, denn schon in der ersten Zeile, wenn SMARTY geladen wird, erhöht sich der Speicher von ca. 102840 Bytes auf sage und schreibe 892208 Bytes !!! Und an dieser Stelle ist noch kein einziges Modul geladen! Daher glaube ich nicht, dass es an meinen Scripten liegt.

Edit:

Und ich glaube auch zu wissen warum.  ::)

Wenn mir irgendjemand erklären kann, warum zum Teufel CMSms das komplette Inhaltsobjekt (die Klasse des Inhaltstypen) mit der Funktion serialize als verstecktes Inputfeld mit ins formular packt, wäre ich der Lösung einen wichtigen Schritt weiter.

Wenn ich das Feld im Firefox mit Hilfe von Firebug entferne und dann die WYSIWYG Option ändere, bleibt der Speicherverbrauch gleich.
Ich habe sogar den Eindruck, dass es etwas schneller geht.

CMSms serialisiert das Inhaltsobjekt und bezieht beim Neuladen der Seite (ohne ohne den Inhalt zu speichern - d.h. nur beim Ändern des Templates oder der WYSIWYG Editor-Einstellung) alle Informationen aus diesem Objekt welches mit dem Formular gesendet wird. Dummerweise gehen beim Serialisieren von Objekten alle anderen Referenzen verloren. So auch die Referenz auf das Modul selbst. Ich brauche aber eine Referenz auf das Modul, da ich Funktionen des Modul API benötige. Durch einen häßlichen Trick erstelle ich einfach eine neue Referenz. Möglicherweise liegt hier der Hase im Pfeffer und irgendwas belegt dadurch doppelt Speicher.

Ich bin mir noch nicht ganz sicher ob und wie ich das lösen kann.
Aber es scheint an der Schnittstelle Inhaltstyp/Modul zu liegen.

EDIT 2:

Ich glaube ich habs (ich Idiot )
Anstatt das Modul mit mir herumzutragen wird einfach über das $gCms Objekt auf das Modul zugegriffen.
Werde morgen im Laufe des Tages noch ein paar Tests machen.
Aber jetzt gehe ich jetzt erstmal schlafen.

Also eine Erhöhung des Speicher-Limits von 32MB auf 64MB beseitigt das Problem. Wenn ich das Speicher-Limit bei 32MB belasse und pcre.backtrack_limit von 100000 auf 250000 setze, tritt das Problem weiterhin auf.

Andiministrator wrote:
Also eine Erhöhung des Speicher-Limits von 32MB auf 64MB beseitigt das Problem.

Aber auch nicht dauerhaft.
Wenn Du einfach mal nur die Seite immer wieder neu laden lässt indem Du den WYSIWYG Editor für diese Seite immer mal ein und wieder abschaltest, wirst Du irgendwann auch bei 128MB Probleme bekommen.

Andiministrator wrote:
Wenn ich das Speicher-Limit bei 32MB belasse und pcre.backtrack_limit von 100000 auf 250000 setze, tritt das Problem weiterhin auf.

Weil es damit offenbar auch nichts zu tun hat.
Ich denke ich habe beim Progrmmieren einfach aus Unwissenheit über die Arbeitsweise von PHP einen kleinen Denkfehler gemacht.
Wie gesagt, das Problem ist schon so gut wie behoben.

EDIT:

Erste Testversion steht via SVN bereit.
Wer mit SVN nichts anfangen kann, der wird hier fündig.

Super, dann werde ich heute abend oder morgen früh das Modul nochmal auschecken und testen

Also mit der aktuellen Version aus dem SVN Repository funktioniert nun alles ohne Probleme. Danke NaN!