mod_editor ... ein Gedanke

[hscha]

Hallo Marky,

ich bin mit dem direkten Word-Import nie zufrieden gewesen und kopiere entsprechende Vorlagen immer über den Windows-Editor, um alle Formatierungen raus zu bekommen. Sonst ergibt sich ein übles Gefummel am HTML-Code...

Grüße von
H.Schallnas

[Marky]

Hi,

sag' das mal den Redakteuren. Die machen alles, was sie nicht sollen. Nur für das was nötig ist, wissen sie meist nichts wie es geht. Und mal auf die Vorschau klicken, um zu sehen wie ihr Machwerk aussieht, ist nur an Sonn- und Feiertagen genehm... die Verwendung der speziellen Word-Funktionalität zum Einkopieren ganz zu schweigen... da könnte man sich die Finger blutig an Anleitungen schreiben, die eh keiner liest.
Von daher sollte diese Sache besser funktionieren und muss ****sicher sein
So gut der FCKeditor auch ist, gibt es da eben eine Menge Spielraum, der gerne mal überschritten wird.

[Marky]

Hallo Markus,

ist es möglich, den Speicherort für die Vorlagenbilder- und Texte woanders als im _data-Verzeichnis abzulegen. Dadurch dass sie wie normale Bilder hochgeladen werden, werden sie grundsätzlich auch bei der Bilderauswahl sichtbar. Genauso wie die txt-Dateien bei der Dateiauswahl.
Ich denke, solche Dinge sollten für die Redakteure transparent sein. Sie sollten eigentlich nur die Bilder sehen, die sie auch tatsächlich hochgeladen haben. Ich befürchte, wenn man solche Sachen auswählen kann, dann werden sie auch ausgewählt bzw. können für Verwirrung sorgen.
Gibt es die Möglichkeit die Bilder für die Snippets auf ein Verzeichnis umzulenken, das vom Admin im Dateisystem angelegt werden kann ?

[MarkusR]

Das ist aber sehr unpraktisch.

Stattdessen lade die zugehörigen Files für die Verwendung in Templates hoch und ändere die Zeile

Code: Alles auswählen

        ."WHERE rubric_id=-1 ORDER BY name";

in snippets.xml.php in

Code: Alles auswählen

        ."WHERE rubric_id=-2 ORDER BY name";

dann sieht sie kein Redakteur mehr.

[Marky]

danke ... werde ich morgen ausprobieren

[Marky]

Hi Markus,

das funktioniert leider nicht bei mir. Die Dateien heißen Artikelueberschrift(txt, bzw. jpg) Ebeno das Snippet. Sie wurden jetzt für Artikeltemplates hochgeladen und sind nun für Redakteure als auch für den FCKEditor nicht mehr zu sehen. Stattdesses sagt der Vorlagendialog, dass keine Vorlagen definiert seien.

[MarkusR]

Ja, Denkfehler...

vergiß die Codeanpassung (also zurück auf -1). Einfach nur die Dateien wie beschrieben hochladen. Sie müssen ja nur im Verzeichnis _data landen.

[Marky]

ok. jetza gehts ...
Aber irgendwie ja auch logisch. Hätte ich mal selber drauf kommen können, dass die Sachen nicht unbedingt für Rubriktemplates hochgeladen werden müssen. Trotzdem Danke für den Support.

[Marky]

Hallo Markus,

es hat sich ein neues Problem ergeben, was ausschlieplich mit dem FCKEditor zu tun hat: Zunächst ist mir aufgefallen, dass beim Paste über den Word-Dialog immer ein führendes <p>&nbsp</p> in den Text geschrieben wird. Das kommt nicht initial auf aus der FCK_Paste.html-Datei (hab's gedebugged) sondern aus irgendwelchen js-Skripten des Editors.
In der fckconfig.js kann man einstellen, ob man bei einem <RETURN> ein <br/> ein <p>-Tag oder ein <div>-Tag einfügen möchte. Wenn man das Ganze auf <br/> umstellt ist das Problem behoben.
ABER: Nun wird in einem leeren Feld immer ein sog. BOGUS-Tag der Form <br type="_moz"> eingefügt. Damit wird erreicht, dass der Cursor in der Editor-Area erscheint. Das hat aber zur Folge, dass dann ein Platzhalter u.U. nicht mehr leer ist, obwohl man eigentlich gar keinen Inhalt sieht. da spassiert z.B. immer dann wenn man das Editor-Feld löscht und von Code-Ansicht auf normale Ansicht umstellt. Anfragen im Template auf leere Platzhalter gehen damit u.U. schief.
Am Editor-Code rumschrauben bringt nur, dass der Cursor fehlt und bestenfalls ein &nbsp; noch übrig bleibt ... also auch nicht leer.

Wie und Wo kann ich denn in Conpresso beim Speichern im Text aufräumen und z.B. <br type="_moz"> einfach eleminieren?
Oder siehst Du evtl. eine andere Lösung?

[MarkusR]

Oder siehst Du evtl. eine andere Lösung?

Vielleicht mal im Support-Forum fragen?
http://www.fckeditor.net/forums/

Ich kann das Problem dabei auch nicht nachvollziehen...
Das leere P-Tag kann man ja einfach löschen (auch Redakteure haben Augen im Kopf) und das vollständige Löschen funktioniert genauso wie in ConPresso nicht mit ENTF sondern mit dem "Neu"-Button...

ansonsten bin ich überfragt.

[Marky]

Das leere P-Tag kann man ja einfach löschen (auch Redakteure haben Augen im Kopf)

bei uns sind sie regelmäßig blind ... oder es ist ihnen egal. Sehr ärgerlich, wenn man eine sauber formatierte Seite haben möchte.

Aber das ist nicht (mehr) das eigentliche Problem, sondern:
Ich habe ja im Template z.B. ein Feld für Teaser und Detail-Seite. Wenn ich sowas baue, dass der Teaser-Wert genommen wird, wenn der Detail-Wert leer ist, dann passiert folgendes:
Bei Öffnen der Seite und damit des FCKEditors für das HTML-Feld wird dieser Tag <br type="_moz"> automatisch in das leere HTML-Feld eingefügt. Das ist nicht zu erkennen, der Cursor sitzt am Anfang der Zeile. Da kommt ja kein Mensch drauf, dass da jetzt Inhalt drin steht. Man müsste in die Code-Ansicht wechseln um das zu sehen. Jetzt speichert man die Seite und plötzlich ist das Detail-Feld eben nicht mehr leer.

Meine Überlegung war dann, dass man beim Speichern des Inhaltes diesen besagten Tag automatisch rausfiltert. Der wird ja nur deshalb gesetzt, damit der Cursor in der Textarea angezeigt wird und hat keine Auswirkung auf die Seite.
Nur ich weiß nicht, wo im Conpresso-Code (bzw. der Save-Funktionalität) das zu machen wäre. Da wäre ich über einen Tipp virtuell dankbar.
Eine andere Lösung sehe ich nicht.

[MarkusR]

Wenn überhaupt, dann mußt Du _include/insertdb_fileds.inc.php bearbeiten.

Im Block der mit case 'html': beginnt gibt es bereits eine "Säuberungsfunktion", die Du erweitern könntest:

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']
            ); 

aber wenn man damit das <br type="_moz"> durch nichts ersetzt wird dennoch eine Speicherung durchgeführt. Daher sollte man besser

Code: Alles auswählen

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

erweitern zu

Code: Alles auswählen

if ($value['html']!='' && $value['html']!='<br type="_moz">') {

testen mußt Du das selbst...

[MarkusR]

Das scheint übrigens Browserabhängig zu sein...

Hier ist übrigens der Thread zum Bug
http://dev.fckeditor.net/ticket/1150
und
http://dev.fckeditor.net/ticket/1660

und das soll helfen

Open: fckeditor/editor/js/fckeditorcode_gecko.js Row: 48 Find: I='<br type="_moz">';this._BodyHTML=I; Replace with: I=' ';this._BodyHTML=I; Note: Do not place an empty I value (I=), the editor will disappear

Aber wenn ich es richtig lese, dann ist da nachher ein Leerschritt drin, der gespeichert würde...

[Marky]

Hallo Markus,

Das funktioniert tatsächlich ... man sollte aber in der aktuellen Version nach

Code: Alles auswählen

G='<br type="_moz">';this._BodyHTML=G; 

suchen. Und tatsächlich ... im ersten Versuch sieht es gut aus. Beim Speichern wird nix in den Platzhalter rein geschrieben. Von daher läuft es mit dem FCKEditor-Bugfix wie erhofft. Ich muss auch keine Conpresso-Codeänderung machen. Danke für die Hilfe und den Hinweis!!!

@Nachtrag: Trotzdem liegt bei dem Word --> Editor-Dialog noch einiges im Argen. Aber das ist ja reine FCKEditor-Sache ...

[Marky]

Hallo zusammen,

mal eine kleine Info an die Gemeinde ...
Wir hatten kürzlich übel Probleme bei der Verwendung des neuen Firefox 3.0 und dem FCKEditor z.B. bei der Word-Paste-Funktionalität, die nun plötzlich keinen Word-Müll mehr rausfilterte. Auch oben beschriebene Korrekturen funktionierten nicht mehr.
Insgesamt scheint der Editor (noch) nicht kompatibel zum 3.0er zu sein, wenn man bei einer oberflächlichen Suche "Google" glauben darf.
Insgesamt also Vorsicht bei dieser Browser-Version...