Bug?! Keine XHTML 1.0 Valide <img /> Tags im TinyMCE

[MediaMuchacho]

Hallo

Mir ist bei der Umsetzung einer neuen Seite aufgefallen, dass die Bilder im HTML Editor in Contenido zwar im Editor richtig angegeben werden <img /> aber im output später auf der Seite leider nur ein <img> zu finden ist.


So sieht es im HTML Modus aus... :

Code: Alles auswählen

<a href="front_content.php?idart=119" target="_self"><img title="Schilder Angebote" height="91" alt="Schilder Angebote - Stabil, Wetterfest, Kratzfest, Aludibond, Plexiglas uvm" src="upload/KategoriePics/kat_druck_2schilder.jpg" width="91" border="0" /></a>

und das ist die Ausgabe im Internet Explorer später...

Code: Alles auswählen

<A title="Flyer Angebote" href="front_content.php?idart=118" target=_self><IMG title="Flyer Angebote" height=91 alt="Flyer, Plakate, Prospekte, Folder Angebote" src="upload/KategoriePics/kat_druck_1angebot.jpg" width=91 border=0></A>

Wie man sieht ist der <img> tag ohne ein / am ende, was aber im strict/transitional Doctype von xhtml1.0 erforderlich ist.

würde mich interessieren ob das bei anderen auch der fall ist...

[Dodger77]

Ich zitiere kurz aus der Ankündigung der Version 4.6.2:

- Wird der tinyMCE als WYSIWYG-Editor verwendet, so wird die XHTML-Formatierung
verworfen wenn der Content über das Insite Editing gespeichert wird. Dies ist
ein Problem der Microsoft DHTML-Editing Komponente, welche die XHTML-Formatierung
in entsprechende "Microsoft"-Standards umwandelt. Workarounds: Entweder kein XHTML
oder kein Insite-Editing verwenden.

Wenn du also der Save-Button des Insite-Editing nicht verwendest, sondern nur mit dem tinyMCE arbeitest gibt es da normalerweise keine Probleme.

[MediaMuchacho]

ok,danke

ich hab aber nicht das insite editing benutzt sondern den HTML Modus im TinyMCE Editor.

Dieser hat das aber irgendwie auch nicht hingekriegt.

Problemlösung : HTML Modus einfach links liegen lassen und nur TinyMCE aufrufen, nix ändern und auf "speichern" bzw den grünen Haken klicken.

Danach stimmt das Bild wieder...sofern der XHTML Output aktivert ist

Bissle wirr aber immerhin lösbar.

[MediaMuchacho]

ok, ich revidiere meine letzte Aussage :

Es muss ein Bug vorliegen!

Grund :

Ich habe 4 HTML Inhalte und 8 HTMLHEAD auf einer Seite.

Die 4 HTML Inhalte werden nur mit Bildern gefüllt, die als Link in eine Unterkategorie dienen.

diese 4 Bilder werden separat editiert. Editiere ich also Teil 1 davon so wird dieser Teil in korrektem XHTML1.0 Standard gespeichert.

Gleichzeitig aber werden die drei anderen wieder in ungültigen Code umgewandelt.

Es macht KEINEN Unterschied in welchem Modus ich das mache.
Es ist immer nur eines der vorhandenen Bilder valide. Also nur einer der HTML Contents. Alle anderen werden dummerweise automatisch in nicht XHTML 1.0 validem Code gespeichert.

In meinen Augen ein Bug...

[timo]

Contenido selbst nimmt keine Formatierung in XHTML und/oder reguläres HTML vor...die Inhalte kommen entweder vom tinyMCE (und hier je nach Systemeinstellung XHTML- oder normal formatiert) oder von der Insite-Editing-Komponente...

Wie du es auch drehst, im Moment gibt es keine Lösung...

[MediaMuchacho]

also ein TinyMCE Bug?

Mir scheint das Problem darin zu liegen, dass es mehr als 1 HTML Content ist.

Denn wenn nur einer editiert wird funktioniert es ja.

Sind aber noch andere Bilder in anderen HTML Contents vorhanden dann wirds durcheinander gewürfelt.

Bei mir sieht das so aus :
echo "CMS_HTML[10]";
echo "CMS_HTML[11]";
echo "CMS_HTML[12]";
echo "CMS_HTML[13]";

Editiere ich [10] (in TinyMCE) und speichere das Bild darin ab so ist es valide.
Alle anderen sind danach nicht mehr valide.

Editiere ich dann [11] so sind anschließend die anderen 3 nicht mehr valide. Auch wenn [10] vorher valide war.

[HerrB]

Du wirst recht haben. Wird "Text (HTML)" angeklickt, werden die anderen Felder sicherheitshalber gespeichert, da sonst die Änderungen verloren gehen. Wenn dieses Speichern das gleiche Speichern wie bei "Save" ist, wäre der Effekt erklärbar.

Gruß
HerrB

[MediaMuchacho]

Dann dürfte es auch fixbar sein, wenn man wüsste wo dieser save vollzogen wird.
Muss ja nur den "typ" des saves ändern...mal ins blaue ohne genaue Kenntniss des dortigen Codes vermutet...

oder?

[pulk]

ich kann das problem bestätigen, ich hab die insite-editing buttons deaktiviert das sowas nicht passiert.

aber sobald ich mit dem tiny ein feld bearbeite, werden die anderen wieder invalid. gibt es eine möglichkeit generell die save funktion auszuschalten (auskommentieren?).

[mvf]

Contenido :: Thema anzeigen - Insite-Editing: valides XHTML erzeugen
http://contenido.org/forum/viewtopic.ph ... html+valid

[Karin Dähne]

Auch ich konnte bisher das Problem bestätigen, daß bei mehreren Textfeldern in einem Template (CMS_HTML[x]) trotz der Erweiterung

Contenido :: Thema anzeigen - Insite-Editing: valides XHTML erzeugen
http://contenido.org/forum/viewtopic.ph ... html+valid

die neuen Einträge die alten, validen überschreiben.
Beispiel: 3 Textfelder:
1. Textfeld: Listen (ol/li ul/li) werden valide ausgegeben
2. Textfeld: Listen, die zusätzlich in diesem Feld angelegt werden, sind auch valide. ABER: die Listen im ersten Textfeld werden invalide.
3. Textfeld: Listen sind valide, dafür die ersten beiden invalide.

Ein nettes Spiel: Zum Haare raufen!

Lange Rede, kurzer Hinweis:

Durch Zufall bin ich bei einer Installation von Contenido mit einem Beispielmandanten auf folgende Einträge gestoßen:

Code: Alles auswählen

ADMINBEREICH: Administration / Mandanten / Mandanteneinstellungen:

Typ          Name                                        Wert
wysiwyg   tinymce-extended-valid-elements   *[*]
wysiwyg   tinymce-valid-elements                 *[*]
wysiwyg   tinymce-stylesheet-file                   css/style_tiny.css

Seit ich da übernommen habe, macht er anscheinend keine Zicken mehr.
Alle 3 Textfelder haben valide Listen!

(Und wenn mir jetzt jemand im Gegenzug das mit dem "printing / containers_to_print" erklären könnte ...
Steht mit in der Liste, zeigt bei meiner Installation aber keine Wirkung ...)

Grüße,
Karin Dähne.

[HerrB]

Das eine hat mit dem anderen nix zu tun.

Und nochmal in Zeitlupe:
- Es werde der IE verwendet
- Es seien 3 Text (HTML)-Bereiche a, b und c auf der Seite vorhanden. Klickt man nun entweder bei einem Bereich a auf Save oder "HTML" (-> Online-Editor) werden die anderen Bereiche (b und c) nochmal gespeichert.

Hintergrund: Ich ändere direkt im Insite-Editing einen Bereich a) und klicke danach bei einem anderen Bereich b) auf "HTML", um in den Online-Editor zu kommen. Würden nicht alle Bereiche gespeichert, würden die Änderungen in Bereich a) damit verloren gehen.

Da ich mich aber im IE befinde, werden die Einträge aus den Bereichen über das DHTML-Control des IE aufbereitet und an den Server gesendet - dieses Control erzeugt den nicht-validen Code (Blame Microsoft).

Dazu nochmal das Zitat von oben:

- Wird der tinyMCE als WYSIWYG-Editor verwendet, so wird die XHTML-Formatierung
verworfen wenn der Content über das Insite Editing gespeichert wird. Dies ist
ein Problem der Microsoft DHTML-Editing Komponente, welche die XHTML-Formatierung
in entsprechende "Microsoft"-Standards umwandelt. Workarounds: Entweder kein XHTML oder kein Insite-Editing verwenden.

Und da steht auch bereits die Lösung...

Die Angaben zu valid-elements betreffen nur den tinyMCE-Online-Editor - die Probleme entstehen aber nicht durch den Online-Editor (im Gegenteil, der biegt das meiste sogar wieder gerade), sondern durch das Insite-Editing.

"printing / containers_to_print" wurde mal für ein Modul verwendet, welches die Seiten für den Ausdruck nochmal gesondert aufbereitet hat - kannste löschen, da das Modul nicht dabei ist und man sowas heute auch eher über CSS macht.

Gruß
HerrB

[Lachi]

Hallo, ich bin zwar noch recht neu mit Contenido und bin auch auf dieses Problem gestoßen. Nach einer Suche hier im Forum bin ich darauf gestoßen, den Save-Button zu deaktivieren. Deswegen konnte man aber immernoch mit dem insite-edit die Texte bearbeiten, und diese wurden dann sogar abgespeichert, sobald man auf den "edit"-Button klickt.

Bei mir hat folgendes geholfen:

DB-Tabelle con_type CMS_HTML bzw. CMS_HTMLHEAD den Code ändern:

Code: Alles auswählen

$tmp =  $finalEditingDiv . $finalEditButton . $finalSaveButton;

wird zu:

Code: Alles auswählen

$tmp = stripslashes($tmp) . $finalEditButton;

Damit ist zwar auch der Rahmen um das Element ausgeschalten, aber als Notlösung besser als keinen validen XHTML-Code.

Bei mir hats funktioniert, mit zwei Containern CMS_HTML und CMS_HTMLHEAD, ich werde es aber weitertesten.
Interessant wäre für mich noch ein Code, mit dem man das über die Mandanteneinstellungen an und abschalten könnte.

[mvf]

die sufu hätte auch geholfen

Contenido :: Thema anzeigen - Insite-Editing: valides XHTML erzeugen
http://contenido.org/forum/viewtopic.ph ... html+valid