SEO_XH - Plugin

[Holger]

Also, ich habe inzwischen schon etwas getestet (immer ohne Berücksichtigung des Pagemanagers, da muss natürlich auch angepasst werden).

CSS-Klassen als Splitt-Marker sind in der Tat ganz einfach zu realisieren. Sowohl bei der Trennung der Seiten, als auch beim Code zum Speichern der Inhalte aus dem Editor.
Ich habe das dann mal "live" durchgetestet. Der große Nachteil: löscht der User eine Überschrift, ist das nicht mehr so einfach zu reparieren. Er muss nicht nur wieder eine neue Überschrift setzen, sondern auch noch die passende CSS-Klasse zuordnen. Ansonsten funktioniert es so eigentlich ganz prima, unabhängig vom h-Tag.

Die zweite Variante, die im Gespräch war, wäre ein "Custom-Tag", wie zum Beispiel <ml_x>. Das habe ich erst überhaupt nicht getestet, weil man die Tags jedem Editor zuvor als gültigen Code beibringen müsste.

Die dritte Variante ist mein Favorit:
Splitt-Marker wäre ein, der Überschrift vorangestellter, HTML-Kommentar:

Code: Select all

 <!--XH_ml1--><hx>Überschrift</hx> 

wobei das h-Tag auch in einer neuen Zeile stehen kann, sonst aber nichts dazwischen stehen darf. Das funktioniert beim Splitten soweit prima . Der Editor führt den Kommentar, "unsichtbar" für den User, schön mit und der Power-User kann im HTML-Mode alles beeinflussen wie zuvor. Auch löscht der User nicht mehr aus versehen eine Seite, er bekäme die Meldung "fehlende Überschrift" weil der "Splitt-Kommentar" bei der Arbeit im WYSIWYG_Mode erhalten bliebe. Und der Inhalt müsste dann in dieser Seite bestehen bleiben, anstatt ihn an die vorherige Seite anzuhängen - wenn machbar. Für ihn bleibt nur: Seiten anlegen / löschen / verschieben immer im (angepassten) Pagemanager. Ein Feature, was nicht nur ich mir schon lange wünsche. Plugins wie Nope hätten sich dann erledigt. Es wird schwierig für den User, die Seite per WYSIWYG-Editor zu zerschießen.
Leider ist diese Variante auch die (für mich) aufwändigste. Splitten ist kein Problem, aber die Routinen zum Speichern der Content-Datei und zur Aufbereitung des Codes aus dem Editor sind ziemlich umfangreich. Aber wenn ich mal verstanden habe, was warum da so trickreich geregexpt wird, ist das aber auch machbar. Zumal Christoph im Zweifelsfall sicher aushelfen könnte .

Technisch ändert sich dadurch am Ende nicht viel. Die globalen Variablen, die Content, Url, Level usw. halten, werden genau gleich erstellt wie zuvor. Die Lösung dürfte somit mit den allermeisten Plugins zusammenarbeiten. Es könnte aber Plugins geben, die den Content aus irgendwelchen Gründen selber splitten. Da müsste dann nachgebessert werden. Neben dem Pagemanager, der natürlich angepasst werden muss, könnte das aber sicher nur weniger als eine Hand voll Plugins betreffen.
Die "Belohnung" wäre dann: alle Überschriften sind beliebig im Inhalt verfügbar, die Seite muss nur zwingend mit irgendeiner Überschrift beginnen (für den Text in der Navigation). Copy&Paste von HTML-Code aus fremder Quelle zerschießt nicht mehr u.U. die Seitenstruktur. Unbeabsichtigtes Löschen im WYSIWYG-Mode ist nicht mehr möglich. User, die lieber mit dem CodeEditor den Quelltext bearbeiten, haben die gleichen Möglichkeiten wie vorher.

[frase]

@Holger
Jetzt nochmal nachdenken:

Konfig-Option: Menü-Ebenen streichen (nur noch "1").

Wenn es nur noch Menülevel "1" gibt, verschiebt sich auch der Inhalt nicht, wenn ein User eine Überschrift löscht.
Es sei denn, er löscht die erste <h1>. Dann könnte man warnen: Überschrift fehlt. Löscht er eine, die die Struktur "versaut": ebenso.
Und wenn ich hier nicht irre, dann klappen beide Möglichkeiten (CSS- oder Kommentar-Marker) ganz gut.
Für mich klingt beides schlüssig und machbar.
Entscheiden müssten die Programmierer -> Zeitaufwand/Komplexität
Dumm nur, dass ich nicht nachvollziehen kann, inwieweit das Auswirkungen auf Plugins hat.
Ich hatte vermutet, dass es da größere Probleme gibt.

Zitat Holger:
"CSS-Klassen als Splitt-Marker sind in der Tat ganz einfach zu realisieren. Sowohl bei der Trennung der Seiten, als auch beim Code zum Speichern der Inhalte aus dem Editor."
Hat der Editor dann überhaupt noch etwas mit Splitten zu tun?

[Holger]

Wenn es nur noch Menülevel "1" gibt, verschiebt sich auch der Inhalt nicht...

Und es gibt auch keine automatisch generierte Navigation mehr . Menülevel abschaffen ist keine gute Idee. Auch die Plugins brauchen $ml / $l.

Und wenn ich hier nicht irre, dann klappen beide Möglichkeiten (CSS- oder Kommentar-Marker) ganz gut.

Richtig. Wobei die CSS-Methode vermutlich einfacher zu implementieren ist. Hier geht es aber eigentlich nur um die Komplexität der nötigen Regular Expressions.
Die Kommentar-Methode ist aber in jedem Fall sicherer für den Bediener.

[Holger]

Hat der Editor dann überhaupt noch etwas mit Splitten zu tun?

Hatte er noch nie. Er darf aber das Merkmal, anhand dem der Core die Seiten splittet, nicht löschen oder anderweitig manipulieren. Deswegen funktionieren Custom-Tags auch nicht ohne sie dem Editor bekannt zu machen.

[frase]

Und es gibt auch keine automatisch generierte Navigation mehr . Menülevel abschaffen ist keine gute Idee. Auch die Plugins brauchen $ml / $l.

Navigation anhand ".split_xx" oder <!--XH_ml1--> erstellen?
Ich meinte Menülevel in der Konfig nicht mehr einstellbar. Fest auf "1"

[Holger]

Und es gibt auch keine automatisch generierte Navigation mehr . Menülevel abschaffen ist keine gute Idee. Auch die Plugins brauchen $ml / $l.

Navigation anhand ".split_xx" oder <!--XH_ml1--> erstellen?
Ich meinte Menülevel in der Konfig nicht mehr einstellbar. Fest auf "1"

Ah, jetzt verstehe ich. Und klar: bei einer geänderten Lösung wird anhand der Klasse oder des Kommentars gesplittet und die Navigation erstellt. Das ist ja der Grund für den ganzen Aufwand. Und auch in meinem Vorschlag wäre der Pagemanager für die Ebene, in dem die Seite liegt, zuständig.

Prinzipiell ginge es in der Tat ohne die Konfigurationsoption. Aber wo sind die Vorteile? Und wo die Nachteile? Da aber wohl eine wirklich große Anzahl von Plugins diesen "Levelcatch" auswertet, kann man darauf nicht einfach verzichten oder ihn fest auf 1 stellen. Das wäre schon eine Änderung mit mächtigen Auswirkungen.

[frase]

Das wäre schon eine Änderung mit mächtigen Auswirkungen.

Der Laie sagt:
Nur die Möglichkeit (Menülevel) in der CMS-Konfiguration entfernen.
Intern bleibt alles wie es ist.

[cmb]

Leider ist diese Variante auch die (für mich) aufwändigste. Splitten ist kein Problem, aber die Routinen zum Speichern der Content-Datei und zur Aufbereitung des Codes aus dem Editor sind ziemlich umfangreich. Aber wenn ich mal verstanden habe, was warum da so trickreich geregexpt wird, ist das aber auch machbar.

Meinst Du XH_saveContents() und XH_saveEditorContents()? Letztere tut so einiges, was aber zumindest mit kurzen Kommentaren erklärt ist, und erstere fügt die Page-Data wieder in den Content ein. Das ganze halt ist so aufwendig, weil HTML per RegExp bearbeitet wird; eine alternative Variante per DOM wäre vielleicht auch mal prüfenswert.

Ich meinte Menülevel in der Konfig nicht mehr einstellbar. Fest auf "1"

Soweit ich es überblicke würde diese Einstellung keinen besonderen Sinn mehr haben, und könnte ganz entfallen (sprich, falls vorhanden, einfach ignoriert werden), da sie ja nur da war, um zwischen eigenen Seiten und seiteninternen Heading zu unterscheiden, was ja mit den Vorschlägen nicht mehr nötig wäre (menu_levels könnte ja aus den vorhandenen "Split-Infos" ermittelt werden).

Hat der Editor dann überhaupt noch etwas mit Splitten zu tun?

Hatte er noch nie. Er darf aber das Merkmal, anhand dem der Core die Seiten splittet, nicht löschen oder anderweitig manipulieren. Deswegen funktionieren Custom-Tags auch nicht ohne sie dem Editor bekannt zu machen.

Zur Klärung: der Editor selbst hat tatsächlich nichts mit dem Splitten zun, wohl aber die Routine, die den Editor-Inhalt speichert (Seiten löschen oder erstellen per Editor).

Was ich insgesamt von diesen Ideen halten – ich bin noch nicht sicher. Gut wäre vermutlich, wenn das ganze mal implementiert würde, damit es getestet werden kann. Dann fallen vielleicht auch inkompatible Plugins auf.

Auf jeden Fall ist aber auch zu bedenken, dass bestehenden Templates bzgl. der Headings wohl angepasst werden müssten – nicht unbedingt ein Problem, aber eben zu bedenken.

[frase]

Gut wäre vermutlich, wenn das ganze mal implementiert würde, damit es getestet werden kann. Dann fallen vielleicht auch inkompatible Plugins auf.
Auf jeden Fall ist aber auch zu bedenken, dass bestehenden Templates bzgl. der Headings wohl angepasst werden müssten – nicht unbedingt ein Problem, aber eben zu bedenken.

Das betrifft, was ich mit "Break" meinte.
Wir suchen eine Lösung, damit CMSimple "modern" bleiben kann.
Ohne "Bruch" an einigen Stellen wird es nicht abgehen.
Deshalb der Vorschlag, für eine Weile zwei Varianten auszuliefern.
"klassisch" wie bisher. Und neu.

[Holger]

Meinst Du XH_saveContents() und XH_saveEditorContents()?

Genau. Was die Funktionen tun sollen, ist mir (inzwischen) klar. "Wie" nicht so ganz. Das liegt aber nur daran, dass ich die eingestzten Patterns nicht immer ohne nachzulesen verstehe. Aber mit Spickzettel geht es.

Gut wäre vermutlich, wenn das ganze mal implementiert würde, damit es getestet werden kann.

Bin ich ja, wie gesagt, schon dabei . Aber ich kann das auch nur abends und nachts angehen und, wie z.B. heute, gibt es noch andere Verpflichtungen "nebenher".

Auf jeden Fall ist aber auch zu bedenken, dass bestehenden Templates bzgl. der Headings wohl angepasst werden müssten – nicht unbedingt ein Problem, aber eben zu bedenken.

Na ja, verschobene Headings haben doch Tradition bei uns . Von daher kann's ja nicht so schlimm werden.
Die Navigation sollte immer kompatibel sein, da habe ich keine Bedenken. Und wenn das Template dann selbst schon ein <h1> definiert, dann ist das, gegenüber jetzigem Stand, auch kein Beinbruch.