XH: alternatives Seitensplitten unabhängig von <hx> - Tags
Re: XH: alternatives Seitensplitten
Bitteschön, wieder drin. Eine Durchstreichenfunktion wäre wünschenswert.
„Bevor du den Pfeil der Wahrheit abschießt, tauche die Spitze in Honig!“ 
Ludwig's XH-Templates for MultiPage & OnePage
Ludwig's XH-Templates for MultiPage & OnePageRe: XH: alternatives Seitensplitten unabhängig von <hx> - Ta
+1lck wrote:Eine Durchstreichenfunktion wäre wünschenswert.
Ich muss die Boardsoftware eh dringend mal updaten. Vielleicht gibt es dann ja bessere Möglichkeiten bzw. ein entsprechendes Addon.
An den kommenden Feiertagen vielleicht...
Re: XH: alternatives Seitensplitten
Schade, dass es das nicht gibt! Jetzt gibt's einen Button dafür in der Editor-Toolbar ganz rechts.lck wrote:Eine Durchstreichenfunktion wäre wünschenswert.
Last edited by cmb on Sun Nov 20, 2016 11:39 pm, edited 1 time in total.
Reason: Tippfehlerkorrektur
Reason: Tippfehlerkorrektur
Christoph M. Becker – Plugins for CMSimple_XH
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Ta
Szenario:
Original unveränderter Demo-Content.
Menü-Ebenen "1" eingestellt.
"Seite 4" über Pagedata page_params neuen Titel verpasst: "Seite 4x".
Ergebnis ->
In der Vorschau erhält die Überschrift der ehemaligen Unterseite "Seite 4.2" ebenfalls die geänderte Überschrift.
Grund: Sie hat auch eine <h1> .
Im Demo-Content hat die "Seite 4.1" eine <h2> und die "Seite 4.2" eine <h1>.
Absicht zum Testen?
In diesem Szenario, werden bei Menülevel=1 die Seiten NICHT gesplittet - trotz Marker.
Wenn Menülevel=1 fest im System eingestellt wäre (und die Möglichkeit der Änderung in der Konfig entfernt würde), könnte diese mögliche Fehlerquelle vermieden werden.
Dazu muss das Splitting aber unabhängig vom Level und ausschließlich (und immer) bei den Markern erfolgen.
Um eine neue Seite/neues Level zu erreichen MUSS IMMER oben ein <h1> stehen (inkl. Marker).
Das könnte man prüfen und warnen "Strukturfehler".
Im Original wird bei Menülevel=3 auch schon bei einer <h2> gesplittet. Es kann also immer noch die h-Lücke entstehen bzw. eine neue Seite nicht mit <h1> beginnen (gewünscht), sondern auch mit irgendwas.
In der Demo beginnt der Content von "Seite 4.1.1" mit Marker 3, aber <h2>.
Der Marker ist korrekt, aber die Überschrift nicht. Sollte eigentlich <h1> sein.
Und: Wenn auf einer Seite oben keine Überschrift steht, rutscht der Text (wie bisher und wie von Holger beschrieben) an die vorherige Seite.
Da das oft unbeabsichtigt passiert, sollte hier zumindest eine Warnung erfolgen. Oder (wie früher schonmal beschrieben) gleich eine "FEHLENDE ÜBERSCHRIFT" eingesetzt und mitgespeichert werden. Idealerweise mit passendem Marker, aus der aktuellen Position.
Das ist zwar ein Komfort-Verlust für diejenigen, die das ausdrücklich wollen (verschieben), aber es ist sicherer für Normal-User.
Ich hoffe, ich konnte mich verständlich machen.
@Christoph
Danke für die strike-Möglichkeit.
Original unveränderter Demo-Content.
Menü-Ebenen "1" eingestellt.
"Seite 4" über Pagedata page_params neuen Titel verpasst: "Seite 4x".
Ergebnis ->
In der Vorschau erhält die Überschrift der ehemaligen Unterseite "Seite 4.2" ebenfalls die geänderte Überschrift.
Grund: Sie hat auch eine <h1> .
Im Demo-Content hat die "Seite 4.1" eine <h2> und die "Seite 4.2" eine <h1>.
Absicht zum Testen?
In diesem Szenario, werden bei Menülevel=1 die Seiten NICHT gesplittet - trotz Marker.
Wenn Menülevel=1 fest im System eingestellt wäre (und die Möglichkeit der Änderung in der Konfig entfernt würde), könnte diese mögliche Fehlerquelle vermieden werden.
Dazu muss das Splitting aber unabhängig vom Level und ausschließlich (und immer) bei den Markern erfolgen.
Um eine neue Seite/neues Level zu erreichen MUSS IMMER oben ein <h1> stehen (inkl. Marker).
Das könnte man prüfen und warnen "Strukturfehler".
Im Original wird bei Menülevel=3 auch schon bei einer <h2> gesplittet. Es kann also immer noch die h-Lücke entstehen bzw. eine neue Seite nicht mit <h1> beginnen (gewünscht), sondern auch mit irgendwas.
In der Demo beginnt der Content von "Seite 4.1.1" mit Marker 3, aber <h2>.
Der Marker ist korrekt, aber die Überschrift nicht. Sollte eigentlich <h1> sein.
Und: Wenn auf einer Seite oben keine Überschrift steht, rutscht der Text (wie bisher und wie von Holger beschrieben) an die vorherige Seite.
Da das oft unbeabsichtigt passiert, sollte hier zumindest eine Warnung erfolgen. Oder (wie früher schonmal beschrieben) gleich eine "FEHLENDE ÜBERSCHRIFT" eingesetzt und mitgespeichert werden. Idealerweise mit passendem Marker, aus der aktuellen Position.
Das ist zwar ein Komfort-Verlust für diejenigen, die das ausdrücklich wollen (verschieben), aber es ist sicherer für Normal-User.
Ich hoffe, ich konnte mich verständlich machen.
@Christoph
Danke für die strike-Möglichkeit.
Last edited by frase on Mon Nov 21, 2016 3:45 am, edited 1 time in total.
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Ta
Ach, ganz vergessen:
Aus oben beschriebenem Kuddelmuddel folgt: Pagedata page_params muss auch geändert werden.
Sollte sich nur auf <!--XH_ml1--> beziehen.
Aus oben beschriebenem Kuddelmuddel folgt: Pagedata page_params muss auch geändert werden.
Sollte sich nur auf <!--XH_ml1--> beziehen.
Last edited by frase on Mon Nov 21, 2016 3:45 am, edited 1 time in total.
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Ta
@Holger
Schau mal in deiner demo unter "Page-Data Bereinigung".
Schau mal in deiner demo unter "Page-Data Bereinigung".
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Ta
Nach einer Kurzschlafphase und etwas Nachdenken, habe ich noch eine Alternative.
Statt Menü-Ebenen = 1, könnte evtl auch Menüebenen = 6 fest eingestellt werden (interne Vorgabe).
Die Möglichkeit zur Änderung sollte trotzdem entfallen.
Die Prüfung sollte aber wie oben beschrieben erfolgen (wie zurzeit schon bei der ersten Seite).
Page-Params müssen auch hier geändert werden, für den Fall, dass mehrere <h1> vorkommen (ohne Marker).
Diese Variante scheint mir programmiertechnisch nicht so aufwändig.
Statt Menü-Ebenen = 1, könnte evtl auch Menüebenen = 6 fest eingestellt werden (interne Vorgabe).
Die Möglichkeit zur Änderung sollte trotzdem entfallen.
Die Prüfung sollte aber wie oben beschrieben erfolgen (wie zurzeit schon bei der ersten Seite).
Page-Params müssen auch hier geändert werden, für den Fall, dass mehrere <h1> vorkommen (ohne Marker).
Diese Variante scheint mir programmiertechnisch nicht so aufwändig.
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Ta
Warum denn überhaupt noch konfigurierbare Menüebenen haben? Das ist doch gar nicht mehr nötig. Ich würde vorschlagen, dass $cf['menu']['levels'] automatisch beim Lesen von content.htm gesetzt wird, und zwar gemäß dem größten vorhandenen <!--XH_ml?-->. (Gesetzt sein sollte diese Variable, da sie ja z.B. für das Menü benötigt wird, und eventuell auch von Plugins.) Wird das nicht so gemacht, dann kann es passieren, dass <!--XH_m?--> Splitter einfach ignoriert werden.frase wrote:Statt Menü-Ebenen = 1, könnte evtl auch Menüebenen = 6 fest eingestellt werden (interne Vorgabe).
Die Möglichkeit zur Änderung sollte trotzdem entfallen.
Ja, page_params müsste auf jeden Fall angepasst werden. Und zwar, wenn ich es recht überblicke, eigentlich nur die RegExp, die nicht mehr nach <h[1-3] suchen sollte, sondern nach <!--XH_ml[1-3].frase wrote:Page-Params müssen auch hier geändert werden, für den Fall, dass mehrere <h1> vorkommen (ohne Marker).
@Holger: magst Du das ganze vielleicht mal als Projekt auf Github einrichten? Das würde zumindest den Codeaustausch erleichtern.
Christoph M. Becker – Plugins for CMSimple_XH
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Ta
Genau das meinte ich. Ich drücke mich nur manchmal etwas verquast aus.cmb wrote:Warum denn überhaupt noch konfigurierbare Menüebenen haben? Das ist doch gar nicht mehr nötig.
Aber:
Reichen 3 Menülevel? Besser wären doch 6 - oder?
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Ta
Also, zunächst noch einmal zur Klarstellung, die Einstellung Menü-Levels werden derzeit auch von den alternativen Splitt-Markierungen beachtet. Beschränkt man in der Konfiguration auf eine Ebene, wird auch nur eine Ebene beachtet - egal was in der content.htm steht.
Wie schon gesagt, technisch ist diese Konfigurationsmöglichkeit unnötig für das Seitensplitten. Die Anzahl der Ebenen muss theoretisch nicht begrenzt werden.
Ich bin nur unsicher, ob man die Variable wirklich auf einen festen Wert (wobei "6" sicher sinnvoller wäre) einstellen soll.
Ich glaube, dass mehrere Plugins diese Variable nutzen und auch der Core, zum Beispiel bei der Bildung der Navigation, von dieser Variable abhängig ist.
Beibehalten stört eigentlich IMO auch nicht. Zumal ja auch der PageManager irgendwo her wissen muss, wie viele Ebenen er zulassen soll.
Diese Sache muss in jedem Fall noch einmal genauer durchdacht werden.
Zu dem "Durcheinander" im Demo-Content: es ist Absicht, dass eine Seite mit einer beliebigen Überschrift beginnen kann. Egal, ob <h1> oder <h6>. Zumindest muss es möglich sein, auch mit <h2> zu beginnen, wenn z.B. das Template schon <h1> vorgibt.
Man könnte, so wie bei der ersten Seite, eine Prüfung auf eine einleitende <hx> - Überschrift machen. Was aber, wie du erkannt hast, verschieben dann unmöglich macht. Und ich bin mir auch nicht sicher, ob man dem Benutzer vorschreiben muss, wie er seine Inhalte generiert.
IMO muss es einfach nur möglich sein, alle Überschriften zu verwenden.
Bzgl. PageParams: dafür ist die Demo ja da, eben um Probleme zu finden. Vermutlich wird es noch weitere Inkompatibilitäten geben. PageParams muss vermutlich so angepasst werden, dass es einfach die erste Überschrift in der Seite ersetzt.
BTW: die Einschränkung "zwischen Split-Marker und Überschrift darf nur ein Zeilenumbruch, aber keine Zeichen sein", sollten wir vielleicht aufheben. Ich bin nicht sicher, aber dadurch könnte man auch Plugins, z.B. Slider etc., seitenweise oben in den Content setzen. Das hätte natürlich auch wieder Auswirkungen auf die Definition, wann eine Seite gesplittet wird.
Momentan kann ich mich aber nicht einloggen, bei keiner der reichhaltigen Installationen auf dem Server. Nach dem Login kommt ein 500er
. Keine Ahnung was da falsch läuft. Nur bei einer gepatchen 1.4x klappt es. Auch das Board wirft sporadisch 500er. Vermutlich ein temporäres Serverproblem.
Wie schon gesagt, technisch ist diese Konfigurationsmöglichkeit unnötig für das Seitensplitten. Die Anzahl der Ebenen muss theoretisch nicht begrenzt werden.
Ich bin nur unsicher, ob man die Variable wirklich auf einen festen Wert (wobei "6" sicher sinnvoller wäre) einstellen soll.
Ich glaube, dass mehrere Plugins diese Variable nutzen und auch der Core, zum Beispiel bei der Bildung der Navigation, von dieser Variable abhängig ist.
Beibehalten stört eigentlich IMO auch nicht. Zumal ja auch der PageManager irgendwo her wissen muss, wie viele Ebenen er zulassen soll.
Diese Sache muss in jedem Fall noch einmal genauer durchdacht werden.
Zu dem "Durcheinander" im Demo-Content: es ist Absicht, dass eine Seite mit einer beliebigen Überschrift beginnen kann. Egal, ob <h1> oder <h6>. Zumindest muss es möglich sein, auch mit <h2> zu beginnen, wenn z.B. das Template schon <h1> vorgibt.
Man könnte, so wie bei der ersten Seite, eine Prüfung auf eine einleitende <hx> - Überschrift machen. Was aber, wie du erkannt hast, verschieben dann unmöglich macht. Und ich bin mir auch nicht sicher, ob man dem Benutzer vorschreiben muss, wie er seine Inhalte generiert.
IMO muss es einfach nur möglich sein, alle Überschriften zu verwenden.
Bzgl. PageParams: dafür ist die Demo ja da, eben um Probleme zu finden. Vermutlich wird es noch weitere Inkompatibilitäten geben. PageParams muss vermutlich so angepasst werden, dass es einfach die erste Überschrift in der Seite ersetzt.
BTW: die Einschränkung "zwischen Split-Marker und Überschrift darf nur ein Zeilenumbruch, aber keine Zeichen sein", sollten wir vielleicht aufheben. Ich bin nicht sicher, aber dadurch könnte man auch Plugins, z.B. Slider etc., seitenweise oben in den Content setzen. Das hätte natürlich auch wieder Auswirkungen auf die Definition, wann eine Seite gesplittet wird.
Ja, die Content-Datei stammt aus einer Dev-Umgebung mit vielen anderen Plugins. Ich habe sie vorher nicht bereinigt.frase wrote:@Holger
Schau mal in deiner demo unter "Page-Data Bereinigung".
Momentan kann ich mich aber nicht einloggen, bei keiner der reichhaltigen Installationen auf dem Server. Nach dem Login kommt ein 500er
. Keine Ahnung was da falsch läuft. Nur bei einer gepatchen 1.4x klappt es. Auch das Board wirft sporadisch 500er. Vermutlich ein temporäres Serverproblem.Mann Christoph, da hätte ich auch selbst drauf kommen können. Danke für das Mitdenken.cmb wrote:Schade, dass es das nicht gibt! Jetzt gibt's einen Button dafür in der Editor-Toolbar ganz rechts.lck wrote:Eine Durchstreichenfunktion wäre wünschenswert.