Leerzeichen in Artikelseite

[baluo]

Hallo allerseits,

mit grösseren Abständen sitze ich noch immer an der Website vom September und wundere mich geradezu über ein "nerviges Leerzeichen":

Wenn ich ein HTML-Fenster für einen "Einführungstext" (Rubrikseite) speichere, dann scheint Conpresso 4.1.2 im HTML-Feld für den "Artikeltext" (Artikelseite) ein Leerzeichen einzufügen, obwohl ich dieses selbst nicht geöffnet habe. Das führt dazu, dass beim "Einführungstext" auf der Rubrikseite ein "Weiter"-Link erscheint, der dort eigentlich nicht sein soll.

Wenn ich das HTML-Fenster für den "Artikeltext" öffne, ist im Bearbeitungsmodus für eine Sekunde auch ein Leerzeichen zu sehen, dass dann aber verschwindet. Trotzdem muss ich vor dem Abspeichern ein "neues, leeres Dokument erstellen". Ich kann das Ganze nur vermeiden, wenn ich vor dem Abspeichern der Artikel-Bearbeitung beim leeren HTML-Feld für den Artikeltext den Inhalt "löschen" betätige.

Es gibt auch noch ein paar andere Merkwürdigkeiten, die ich in einemgesonderten Beitrag beschreibe.

Hat jemand von euch eine Idee?

Gruss, Gerhard

Edit (28.10.2010):
So, wie es momentan aussieht, scheint es ein Problem im Firefox zu sein, nicht aber im IE.

[balu]

Hi,

passiert das nur, wenn Du das Feld einmal zum bearbeiten öffnest? Oder tritt das auch auf, wenn Du nur das Intro-Feld bearbeitest, das andere aber unangetastet lässt?

Balu

[baluo]

Oder tritt das auch auf, wenn Du nur das Intro-Feld bearbeitest, das andere aber unangetastet lässt?

Genau so -- nur das Intro-Feld bearbeiten & speichern erzeugt offenbar ein Leerzeichen im Artikel-HTML-Feld ... im FF 3.5.7, nicht im IE.

[MarkusR]

Das kann ich nun bestätigen.

Es passiert, wenn bei Verwendung von Firefox in den Systemeeinstellungen eine CSS-Datei angegeben ist.
Obwohl der Quelltext des iframe definitiv leer ist, wird er von Firefox mit was auch immer gefüllt, was dann als Artikelinhalt gewertet wird.

Mit IE oder nach Entfernung der CSS-Datei aus den Systemeinstellungen ist wieder alles in Ordnung (soweit dieser Zustand als "in Ordnung" bezeichnet werden kann).

[MarkusR]

Hier ein Lösungsvorschlag, der bei ersten Versuchen ganz gut funktioniert:

in _include/insertdb_fields.inc.php

Code: Alles auswählen

if ($value['html']!='') {

ersetzen durch

Code: Alles auswählen

if (trim($value['html'])!='') {

Das würde den Textfeldern übrigens auch gut tun. Kaum ein Redakteur sieht die Leerzeichen oder Leerzeilen, die er dort einträgt...

[Mr. Magpie]

Ich bin gerade über diesen Thread gestolpert und habe mit CPO 4.0.x schon (gefühlt) immer ein ganz ähnliches Problem.

Wenn man im ConPresso-Editor mit dem Firefox
a) irgendeine Eingabe macht und diese wieder löscht, oder
b) auch nur auf die HTML-Ansicht und wieder zurückschaltet ohne irgendetwas einzugeben, oder
c) ohne etwas einzugeben einfach nur die Backspace-Taste betätigt,
wird ein br-Tag erzeugt, der von den Redakteuren allermeistens nicht gesehen wird, aber natürlich bei der ifset-Auswertung berücksichtigt wird.

Im IE sieht's nicht ganz so schlimm aus, denn erst wenn man wirklich etwas eingegeben hat und das anschließend wieder löscht, bleibt ein <P>&nbsp;</P> als Inhalt stehen.

Wo muss ich ansetzen, dass bei HTML-Feldern der br-Tag bzw. der P-Tag automatisch beim Artikelspeichern gelöscht wird, falls dies der einzige Inhalt der HTML-Felder ist?

[balu]

Hallo,

Wo muss ich ansetzen, dass bei HTML-Feldern der br-Tag bzw. der P-Tag automatisch beim Artikelspeichern gelöscht wird, falls dies der einzige Inhalt der HTML-Felder ist?

und woher weisst Du, dass der Redakteur nicht mit Absicht nur einen Zeilenumbruch eingefügt hat, damit das Feld nicht leer ist, sondern nur leer aussieht?

Ich weiß, dass sich das an den Haaren herbeigezogen anhört, aber viele Redakteure machen z.B. auch &nbsp; in ein Tabellenfeld, damit es etwas aufgeschoben wird.

Damit die Redakteure das Feld restlos löschen können, haben wir ja den "löschen"-Button unter dem HTML-Feld hinzugefügt.

Balu

[Mr. Magpie]

Ich rede hier nicht von Schilderungen von irgendwelchen Redakteuren, sondern von meinen Beobachtungen.

[MarkusR]

Firefox ist aus typographischer Sicht eine Katastrophe und ich wundere mich immer wie meine Kunden ganz merkwürdige Konstruktionen erstellen, die sich dann meist noch nicht mal mehr ohne Quelltexteingriff korrigieren lassen. Ok, Webkit-Browser sind da noch viel schlimmer...

Auch wenn der IE ja soooo schlecht ist, er beherrscht zumindest korrekte Typographie und ist damit die erste Wahl für strukturierte Texte, weil er sich wie ein Textverarbeitungsprogramm verhält und nicht wie ein Editor.

Du könntest mit _include/insertdb_fields.inc.php experimentieren...

da finden ja schon einige Korrekturen statt

Code: Alles auswählen

            $value['html'] = preg_replace(
                array(
                    '@<br>@',
                    '@<img((\s+[a-zA-Z]+\s*=\s*(("[^"]*")|(\'[^\']*\')))*)\s*>@' // based on http://concepts.waetech.com/unclosed_tags/
                ),
                array(
                    '<br />',
                    '<img\1 />'
                ),
                $value['html']
            ); 

Nach dem Entsorgen überflüssiger Codes sollte ein

Code: Alles auswählen

        if ($value['html']=='') break;

kommen, damit nicht ein geputzter leerer Eintrag gespeichert wird.

[Mr. Magpie]

Danke dir, Markus!

[Mr. Magpie]

Ich habe jetzt in insertdb_fields.inc.php folgende Zeilen drin (erstmal für den Firefox-Fall):

Code: Alles auswählen

    case 'html': 
        // Update if something was entered
        if ($value['html']!='') {
            $value['html'] = preg_replace(
                array(
                    '@<br>@',
                    '@<img((\s+[a-zA-Z]+\s*=\s*(("[^"]*")|(\'[^\']*\')))*)\s*>@' // based on http://concepts.waetech.com/unclosed_tags/
                ),
                array(
                    '<br />',
                    '<img\1 />'
                ),
                $value['html']
            );
// br-Tag-Behandlung ansonsten leerer HTML-Felder - Anfang
if ($value['html'] = '\n<br />') $value['html'] = '';
if ($value['html'] = '') break;
// br-Tag-Behandlung ansonsten leerer HTML-Felder - Ende

Zwei Probleme:
1.) Verursacht durch if ($value['html'] = '') break; werden nur leere HTML-Felder in die DB geschrieben, also auch die anderen HTML-Felder sind dann geleert. Lasse ich diese Zeile weg, wird zwar das gewünschte HTML-Feld geleert, aber...
2.) ... zum Zeitpunkt der Ausführung der insertdb_fields.inc.php ist das Parsing schon erfolgt, sodass die entspr. ifset-Abfrage des Templates zu dem selben Ergebnis führt als wäre das Feld nicht leer.

[MarkusR]

Hä?

Wie kann ein Parsing (=Ausgabe) bereits erfolgt sein, wenn der Datensatz überhaupt erst in die DB geschrieben wird?

Ansonsten:
Prüfungen werden mit "==" und nicht mit "=" geschrieben...
also

Code: Alles auswählen

if ($value['html'] == '\n<br />') $value['html'] = ''; 
if ($value['html'] == '') break; 

[Mr. Magpie]

Damit die Redakteure das Feld restlos löschen können, haben wir ja den "löschen"-Button unter dem HTML-Feld hinzugefügt.

Da sprichst du von CPO 4.1.x, oder?
Mir geht es aber um die Problematik bei CPO 4.0.x (weil ich die 4.1er noch nirgendwo einsetzen möchte). Dort gibt es im ConPresso-Editor zwar einen Knopf "neu", der ein leeres Dokument erzeugen soll, aber den br-Tag drin stehen lässt. Dieser muss dann separat über "Tag löschen" noch entfernt werden.

[MarkusR]

Dort gibt es im ConPresso-Editor zwar einen Knopf "neu", der ein leeres Dokument erzeugen soll, aber den br-Tag drin stehen lässt. Dieser muss dann separat über "Tag löschen" noch entfernt werden.

Habe das gerade mal mit FF getestet... und tatsächlich, das ist ja wohl der Hammer!
Dabei ist die Anweisung an FF ja unmissverständlich:

Code: Alles auswählen

        case '_new':
            bse_conWin.document.body.innerHTML = '';
            break;

Von einem <br> weit und breit nichts zu sehen...

[Mr. Magpie]

So, jetzt nach Einkauf und Mittagspause nochmal im Ganzen unter Berücksichtigung sowohl der IEs als auch des Firefox. Google Chrome macht's übrigens korrekt.
Ich habe noch rtrim()'s eingebaut, da sich gelegentlich auch noch Leerzeichen und Umbrüche reinmogeln konnten:

Code: Alles auswählen

            $value['html'] = preg_replace(
                array(
                    '@<br>@',
                    '@<img((\s+[a-zA-Z]+\s*=\s*(("[^"]*")|(\'[^\']*\')))*)\s*>@' // based on http://concepts.waetech.com/unclosed_tags/
                ),
                array(
                    '<br />',
                    '<img\1 />'
                ),
                $value['html']
            );
// ********** Behandlung von br-Tag (FF) bzw. <P>&nbsp;</P> (IEs) nach Leeren von HTML-Feldern ********** Teil 1/1 ***** Anfang *****
// folgende zwei Zeilen eingefügt:
            if (rtrim($value['html'])=='<br />' || rtrim($value['html'])=='<P>&nbsp;</P>') $value['html'] = '';
            if ($value['html'] == '') break; 
// ********** Behandlung von br-Tag (FF) bzw. <P>&nbsp;</P> (IEs) nach Leeren von HTML-Feldern ********** Teil 1/1 *****  Ende  *****

EDIT: von trim()'s zu rtrim()'s geändert, um gewieften Redakteuren die Chance zu geben, absichtlich das HTML-Feld mit einem Leerzeichen zu belegen, sodass es vom Parser als ausgefüllt betrachtet wird.