Insite-Editing: valides XHTML erzeugen

[apicalart]

Hallo Thomas,

dodger war da jetzt schneller. Ich hatte die config.plugin falsch. Also bei mir klappt das jetzt prima.

Auch hier im forum nochmals Dank an Dodger.

Lösung siehe oben

[kypta]

Ja, cool, funktioniert. Dankeschön und Gruss
Thomas

[mvf]

hallo Dodger77
hallo community

danke für die mod, funzt super. um aber W3C//DTD XHTML 1.0 Strict validen code zu erzeugen, habe ich noch ein problem mit dem target="" in links, das wird automatisch gesetzt auch wenn man es manuell entfernt. damit kein valider code.

kann man das irgendwie noch raus bekommen, damit any

target=""
target="_blank"
target="_self"
.
.
.

einfach entfernt wird, egal was der redakteur wählt?
bzw das erscheint ja auch beim speichern im editor also nicht insite editing? wie erzeugt ihr da validen code für
W3C//DTD XHTML 1.0 Strict
oder sind alle Transitional unterwegs?

merci

[HerrB]

Wobei man sagen muss, dass die bei der Definition von Strict 1.0 target einfach vergessen/unterschätzt haben.

Und so wird es das in der Nachfolgeversion auch wieder geben (denn eine Alternativlösung mit JavaScript oder eigener DTD ist einfach Unfug...). Es ist z.B. ohne target, ohne JS und mit Standard-DTD gar nicht möglich, Daten eines Formulars an ein neues Fenster zu übergeben... Murx.

Bei target="" gebe ich Dir recht...

Gruß
HerrB

[mvf]

danke für deine ausführungen HerrB, darf ich resümieren, dass dann wohl TRANSITIONAL völlig ok ist?

[Dodger77]

Im tinyMCE kann man das target-Attribut ja durchaus verhindern, wenn man möchte (Thema "valid_elements"/"extended_valid_elements", siehe dazu "docs/techref/backend/backend.customizing.html").
Ansonsten ist das target-Attribut in den trasitional-/frameset-Varianten durchaus erlaubt, halt nur nicht bei (X)HTML strict. Da darauf zur Zeit nicht geprüft wird (man gibt ja je Mandant nur an, ob HTML oder XHTML), kann man das Attribut auch nicht einfach ausfiltern.

Man kann in die Chain natürlich einiges einbauen, aber erstmal geht es darum, die gröbsten Schnitzer zu verhindern:

• alleinstehende Tags (z.B. <img />, <br />) richtig darzustellen
• Tags und Attribute groß zu schreiben
• Anführungszeichen um die Attributwerte zu bekommen (ist zurzeit noch nicht implementiert)

Um alle Fehler rauszubekommen, müsste man etwas mit der libtidy machen. Die haben aber wohl die wenigsten installiert bzw. PHP damit kompiliert.

[apicalart]

Anführungszeichen um die Attributwerte zu bekommen (ist zurzeit noch nicht implementiert)

Yep Dodger !!! Und da gibt es noch ein Problem im IE . Er schmeisst mir da bei height, alt, width, lang imm er die "" raus in dem Feld, dass gerade nicht bearbeitet wird.

Aberrrrrrrrrrrrrrrr, mit dem Firefox funktioniert das prima.
Ist eben das bekannte Bill Gates Syndrom.

[Dodger77]

Anführungszeichen um die Attributwerte zu bekommen (ist zurzeit noch nicht implementiert)

Yep Dodger !!! Und da gibt es noch ein Problem im IE . Er schmeisst mir da bei height, alt, width, lang imm er die "" raus in dem Feld, dass gerade nicht bearbeitet wird.

Aberrrrrrrrrrrrrrrr, mit dem Firefox funktioniert das prima.
Ist eben das bekannte Bill Gates Syndrom.

Ja, das werde ich mir auch noch anschauen, wenn ich die Zeit finde.

[aw029]

Bei mir hats auch auf Anhieb geklappt. Danke.

[Oldperl]

Anführungszeichen um die Attributwerte zu bekommen (ist zurzeit noch nicht implementiert)

Yep Dodger !!! Und da gibt es noch ein Problem im IE . Er schmeisst mir da bei height, alt, width, lang imm er die "" raus in dem Feld, dass gerade nicht bearbeitet wird.

Aberrrrrrrrrrrrrrrr, mit dem Firefox funktioniert das prima.
Ist eben das bekannte Bill Gates Syndrom.

Ja, das werde ich mir auch noch anschauen, wenn ich die Zeit finde.

Habe die mod eingebaut, funktioniert einwandfrei bis auf obiges Problem. in beiden Browser IE6 und FF1.5 für Win werden die "", die im Backend noch im Editor (auch im Quelltext) angezeigt werden, rausgeschmissen.
Daher dann kein valides XHTML

Existiert dafür schon eine Lösung?

Gruß aus Franken

Ortwin

[maccaroni]

sorry, dass ich diesen beitrag aus der versenkung hole. hat bei mir alles geklappt, solange ich die insite-bearbeitung unter firefox mache. nach abspeichern unter dem aktuellen safari (osx) wird die «xhtml-schreibung» wieder verworfen.

ist das problem bekannt?


gruss ronan

[mvf]

hallo community, servus dodger

ich nutze die lösung hier schon länger, habe jetzt aber das problem, dass zwar bei mehreren containern, dass xhtml nicht mehr verworfen wird, allerdings nicht bei sonderzeichen

con4.6.8.5 incl der mod

2 CMS_HTML container
wenn ich normalen text eingebe alles ok, validiert
verwende ich in einem der beiden container &euro; wird dies beim speichern via insite-editing-save-button verworfen, erneutes speichern im wysiwyg bringt dann wieder das gewünschte &euro; anstatt dem eurozeichen im quelltext, welches nicht validiert

gibt es dafür eine lösung?

[mvf]

kk nachdem ich dachte es ginge mit &pound; und nur &euro; hätte das problem, war ich schon in richtung tiny-bug oder falsches charset unterwegs, ist es aber definitv nicht, habs mit 2 containern nochmal getestet

nur leider bin ich aber nicht der könig was preg_replace angeht

@dodger, kann man das dür die standard sonderzeichen erweitern?

[pulk]

Die neue Chain packt man in die Datei "include.chain.content.html2xhtml.php" im Verzeichnis "contenido/plugins/chains/includes/" mit folgendem Inhalt (zuletzt geändert 22.12.2005 15:53):

Die Chain muss weiterhin eingebunden werden in der Datei "config.plugin.php" im selben Verzeichnis durch:

nur eine kleine verständnisfrage, das verzeichnis chains existiert bei mir nicht, einfach erstellen, oder?

die config.plugin.php kommt auch in das verzeichnis contenido/plugins/chains/includes/?

[HerrB]

Ich vermute, dass Du nicht die V4.6.8.5 einsetzt (siehe Misc V4.6). Ich würde Dir empfehlen, darauf zu aktualisieren. Ansonsten: ja.

Gruß
HerrB