Bug bei der Contentsicherung von Tiny...

MediaMuchacho · Beitrag von **MediaMuchacho** » Fr 18. Nov 2005, 20:06

Hallo

Ich habe es in einem anderen Thread http://www.contenido.org/forum/viewtopic.php?t=10225schon angesprochen. Jetzt kann ich es konkret reproduzieren und hoffe auch hinreichend erklären, dass es als Bug anerkannt wird.

Es gibt ein Problem beim speichern der Daten von Tiny und Daten die schon vorhanden sind.

Ich habe aus Testgründen den Validatorlink auf meiner Seite eingebaut (w3c.org) diesen habe ich nach jedem Update der Daten auf einer Testseite ausgeführt um die Fehleranzahl zu messen.

Ich hab die Seite vorher 100% valide programmiert. Vom Validator geprüft.

Meine Testseite hat 2 Header und einen HTML Content.
Ich habe alle 3 gefüllt. In einem der Header kommt ein <p> Tag vor. Dieser gibt via Tiny normalerweise keine Probleme...sprich er ist valide gecodet. Über das insite edititing ist es nicht valide....soweit so bekannt.

Editiere ich also den 2. Head via Tiny erhalte ich validen Code...Validator geprüft!

Editiere ich jetzt den Content...gebe dort zum Beispiel einige Bilder ein oder ebenfalls <p> tags...so werden diese von Tiny wieder wunderbar valide dargestellt und gespeichert. Validator geprüft.

Dummerweise wird jetzt der vorher valide Code vom Head...der ebenfalls ein <p> enthielt nun von der insite editing Speicherung nochmal gesichert. ( Vermutung ) Jedenfalls ist der einstmals valide code jetzt nicht mehr valide.

Ändere ich Head2 wieder via tiny in validen Code so ist mein Content nicht mehr valide usw...

Ich habe also niemals eine Chance validen Code zu erzeugen egal ob mit oder ohne Tiny.

Einzige Lösung : Ein einziges Content Feld und sonst nichts. Denn dann übernimmt Tiny die Datensicherung und diese ist valide. In jedem anderen Fall...sobald mehr als 1 Datenfeld vorhanden ist für Content...wird der jeweils nicht in Tiny bearbeitete Inhalt sofort als nicht valider Code gespeichert.

Ein sehr sehr ärgerlicher Bug....vor allem wenn man auf der eigenen Seite die Vorteile von Contenido, dessen validen Code etc pp anpreisen möchte.

Ich denke auch nicht, dass das ein Tiny Bug ist. Tiny funktioniert einwandfrei...aber die Datensicherung funktioniert nicht gescheit....

Ich hoffe das kann jetzt auch jemand anders reproduzieren.

grüße

Beitrag von **emergence** » Sa 19. Nov 2005, 12:38

ich kenne momentan nur zwei möglichkeiten

entweder firefox verwenden...
oder die inside editing funktionalität komplett deaktivieren...

es gibt im forum einen beitrag der das deaktivieren beschreibt...

das problem ist bekannt, es ist reproduzierbar(IE) aber eine andere lösung wüsste ich auf die schnelle nicht...

MediaMuchacho · Beitrag von **MediaMuchacho** » Sa 19. Nov 2005, 16:03

könnte man nicht einfach das wiederholte speichern der vorhandenen Inhalte deaktivieren? Es reicht doch wenn der editierte Inhalt gesichert würde. Damit hätte man das Problem meines Erachtens umgangen. bei voller Funktionalität...

wieso müssen die überhaupt nochmal gespeichert werden wenn sie garnicht editiert wurden?

Wäre das evtl. eine Lösung?

Wenn ja, in welchen Bereichen des quellcodes ist das zu finden...ich würde es ggf auch selbst machen. Ne kleine Starthilfe wäre aber nicht ganz verkehrt, von jemandem, der den Contenido Quellcode kennt.

Beitrag von **emergence** » Sa 19. Nov 2005, 16:42

starthilfe -> include.con_editcontent.php

javascript funktionen

setcontent oder gleich prepareString

Beitrag von **Dodger77** » Di 6. Dez 2005, 19:50

So, das habe ich nochmal getestet mit gleich 3 mal CMS_HTML. Ist ja im Prinzip altbekannt. Lässt sich bei mir in IE6 UND FF 1.5 reproduzieren. Wird der WYSIWYG-Editor z.B. für CMS_HTML[1] aufgerufen, sind CMS_HTML[2] und CMS_HTML[3] nicht mehr valide.

Das Problem ist halt, dass der Aufruf des WYSIWYG-Editors durch die JavaScript-Funktion "setcontent" ausgelöst wird. Diese Funktion nimmt sich aber gleich alle CMS_TYPEs, für die Insite-Editing läuft, vor.
Das macht ja auch Sinn. Sollte jemand gleich in mehreren Modulen z.B. mit CMS_HTML Änderungen vornehmen, dürfen die Änderungen eben nicht verloren gehen, wenn der Redakteur auf "Save" klickt oder auch auf einen Button, der von der Seite wegführt (z.B. zum WYSIWYG-Editor).

Als Lösung könnte man natürlich das Insite-Editing deaktivieren:

http://www.contenido.org/forum/viewtopic.php?t=9705

, aber schön finde ich diese Lösung nicht gerade.

Sofern die libtidy auf dem Server aktiviert ist, könnte man natürlich den "prepareString"-Aufruf durch etwas AJAX aufbohren, sodass der Inhalt der CMS_HTML von "tidy_repair_string" in gültiges XHTML umgewandelt wird. Das setzt aber PHP5 voraus, ist also nicht so prickelnd.

Beitrag von **Dodger77** » Mi 7. Dez 2005, 14:39

OK. Ich habe mir das nochmal angeschaut. Eine Lösung auf Basis von JavaScript habe ich mittlerweile verworfen. Sinnvoll erscheint mir, auf die Chain "Contenido.Content.SaveContentEntry" zurückzugreifen und die Inhalte eben vor Eintrag in die DB nochmal auf die gröbsten Schnitzer hin zu überprüfen.

Einzelheiten hier:

http://www.contenido.org/forum/viewtopic.php?t=10870