XH: alternatives Seitensplitten unabhängig von <hx> - Tags
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Tags
Genau das meinte ich auch. Um nie die gleiche Headingsformate in Splitter/Navigation und im Text den Seiten nutzen zu können.
Nur, wie es sicherzustellen?
Sei es 9 Ebene möglich - 3 werden für Seitenstruktur reserviert - 6 bleiben übrig für interne Seiteninhalt und nur die sollten in der Auswahlliste erscheinen. Geht es überhaupt irgendwie durch die CMS Konfiguration feststellen?
Nur, wie es sicherzustellen?
Sei es 9 Ebene möglich - 3 werden für Seitenstruktur reserviert - 6 bleiben übrig für interne Seiteninhalt und nur die sollten in der Auswahlliste erscheinen. Geht es überhaupt irgendwie durch die CMS Konfiguration feststellen?
CMSimple.sk
It's no shame to ask for an answer if all efforts failed.
But it's awful to ask without any effort to find the answer yourself.
It's no shame to ask for an answer if all efforts failed.
But it's awful to ask without any effort to find the answer yourself.
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Tags
Kann man es später dann schaffen eine korrekte HTML5-Seitenstruktur hinzubekommen?
Da ist es doch zulässig mehrere H1-Überschriften auf einer Seite stehen zu haben.
https://wiki.selfhtml.org/wiki/HTML/Tut ... section.3F
Da ist es doch zulässig mehrere H1-Überschriften auf einer Seite stehen zu haben.
https://wiki.selfhtml.org/wiki/HTML/Tut ... section.3F
in diesem Sinne isometric
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Tags
Das verstehe ich nicht ganz. Wozu ist es gut, auf einer Seite (ich unterscheide hier Webseite und Seite, d.h. eine Webseite in meinem Verstanden besteht aus mehreren Seiten), mehrere z.B. H1 Überschriffte zu haben?
Wenn eine Webseite der Music dienen solle, dann alles, das unter H1-Instrumente gehört, soll die Überschriffte von H2 und tiefer nutzen.
Und alle H2-Streichinstrumente dann H3 und tiefer. Wenn keine tiefere Teilung auf der H3 Seite gibt, die Subgruppen von Strechinstrumenten werden mir H4 Überschrifftet und die Beschreibung der einzelnen Instrumenten mit H5, einzelne Besonderheiten einen Instrument dann mit H5 usw.
Obwohl die Subgruppen are in der Navigation unnötig und daher werden sie nicht gezeigt, es ist logisch, dass auf der Seite erscheinen sie unter einer eindeitig zugewisenen Überschrifft.
Oder verstehe ich noch immer die Sache falsch (nicht ausgeschlossen )?
Wenn eine Webseite der Music dienen solle, dann alles, das unter H1-Instrumente gehört, soll die Überschriffte von H2 und tiefer nutzen.
Und alle H2-Streichinstrumente dann H3 und tiefer. Wenn keine tiefere Teilung auf der H3 Seite gibt, die Subgruppen von Strechinstrumenten werden mir H4 Überschrifftet und die Beschreibung der einzelnen Instrumenten mit H5, einzelne Besonderheiten einen Instrument dann mit H5 usw.
Obwohl die Subgruppen are in der Navigation unnötig und daher werden sie nicht gezeigt, es ist logisch, dass auf der Seite erscheinen sie unter einer eindeitig zugewisenen Überschrifft.
Oder verstehe ich noch immer die Sache falsch (nicht ausgeschlossen )?
CMSimple.sk
It's no shame to ask for an answer if all efforts failed.
But it's awful to ask without any effort to find the answer yourself.
It's no shame to ask for an answer if all efforts failed.
But it's awful to ask without any effort to find the answer yourself.
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Tags
Hier sind zwei Fälle zu unterscheiden, und zwar je nachdem ob $cf['headings']['show'] true oder false ist. true ist die Voreinstellung, und sollte wohl für unerfahrene Anwender auch so bleiben. In diesem Fall werden dann alle Seitenüberschriften immer gemäß $cf['headings']['format'] formatiert, also gemäß Voreinstellung immer als <h1>. Innerhalb der Seiten können also <h2>-<h6> verwendet werden. Würde $cf['headings']['format'] nur eine Auswahlliste (<h1>, <h2>, …, <h6>) anbieten, dann könnte man im Editor automatisch nur die kleineren Headings anbieten. Allerdings kann $cf['headings']['format'] derzeit frei belegt werden kann (Flexibilität), also müsste der Editor manuell konfiguriert werden.Tata wrote:Sei es 9 Ebene möglich - 3 werden für Seitenstruktur reserviert - 6 bleiben übrig für interne Seiteninhalt und nur die sollten in der Auswahlliste erscheinen. Geht es überhaupt irgendwie durch die CMS Konfiguration feststellen?
Ist $cf['headings']['show'] false, dann will der Anwender ja ganz frei Hand bezüglich der Seitenstruktur haben, so dass im Editor auch alle <h1>-<h6> auswählbar sein sollten.
Ja, wenn <article>, <section> und Co. verwendet werden. Das wird aber von Editoren und Templates nicht unbedingt unterstützt, so dass XH-split darauf ausgelegt ist, es dem Anwender zu ermöglichen eine korrekte Heading-Struktur zu erzeugen, ohne sich eben um die "Sektionierung" kümmern zu müssen.isometric wrote:Da ist es doch zulässig mehrere H1-Überschriften auf einer Seite stehen zu haben.
Anders gesagt: in der Voreinstellung von XH-split (und die ist eben für unerfahrene Anwender gedacht), ist die Überschrift jeder Seite <h1>, so dass innerhalb einer Seite nur <h2> - <h6> verwendet werden sollten. Diese richtig zu setzen, bleibt nach wie vor dem Anwender überlassen.
Christoph M. Becker – Plugins for CMSimple_XH
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Tags
Stimmt, meine Frage war Quatsch, auf einer Seite, die im Adminbereich geschrieben wird, braucht man nur <h2> - <h6> und das geht dann ja.Tata wrote:Das verstehe ich nicht ganz. Wozu ist es gut, auf einer Seite (ich unterscheide hier Webseite und Seite, d.h. eine Webseite in meinem Verstanden besteht aus mehreren Seiten), mehrere z.B. H1 Überschriffte zu haben?
cmb wrote:Anders gesagt: in der Voreinstellung von XH-split (und die ist eben für unerfahrene Anwender gedacht), ist die Überschrift jeder Seite <h1>, so dass innerhalb einer Seite nur <h2> - <h6> verwendet werden sollten. Diese richtig zu setzen, bleibt nach wie vor dem Anwender überlassen.
in diesem Sinne isometric
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Tags
Bisschen weiter verstanden.
Soweit ich es verstehe, dem Pagemanager und Splitter ist es absolut egal, wie die Überschriffte formatiert sind oder ob überhaupt irgendwie.
Das heisst, die Formatierung auch weiterhin nur für Editor gilt.
Dann sollte aber gesichert werden, dass im Editor nur die Klassen erscheinen, die nur ausser Seitensplitting benutzt sein dürfen.
Wie kann dass aber flexible sein (ich meine die Klassenliste mit $cf['menu']['levels'] dynamisch verbunden)?
Es fürchtet mich die Vorstellung, dass man im Inhalt der Seite die optische Anordnung der Seiten/Absätze ausser Kontrolle rutscht.
Soweit ich es verstehe, dem Pagemanager und Splitter ist es absolut egal, wie die Überschriffte formatiert sind oder ob überhaupt irgendwie.
Das heisst, die Formatierung auch weiterhin nur für Editor gilt.
Dann sollte aber gesichert werden, dass im Editor nur die Klassen erscheinen, die nur ausser Seitensplitting benutzt sein dürfen.
Wie kann dass aber flexible sein (ich meine die Klassenliste mit $cf['menu']['levels'] dynamisch verbunden)?
Es fürchtet mich die Vorstellung, dass man im Inhalt der Seite die optische Anordnung der Seiten/Absätze ausser Kontrolle rutscht.
CMSimple.sk
It's no shame to ask for an answer if all efforts failed.
But it's awful to ask without any effort to find the answer yourself.
It's no shame to ask for an answer if all efforts failed.
But it's awful to ask without any effort to find the answer yourself.
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Tags
Schau mal hier:
https://cmsimpleforum.com/viewtopic.php ... 384#p57283
Im Prinzip kann man es relativ einfach schaffen, dass im Editor nur die Klassen zur Verfügung stehen, die man will.
https://cmsimpleforum.com/viewtopic.php ... 384#p57283
Im Prinzip kann man es relativ einfach schaffen, dass im Editor nur die Klassen zur Verfügung stehen, die man will.
in diesem Sinne isometric
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Tags
Manu hat gerade auf Github kommentiert:
Die Idee ist halt ein deutlich strukturierteres Export/Import-Format zu verwenden, dass "universell" gut unterstützt wird. Sinnvoll wäre so gesehen XML oder vielleicht auch JSON. Bzgl. des Upgrades auf XH 1.7 müsste dann der User vor dem eigentlichen Upgrade erst den Content exportieren, und nach erfolgtem Upgrade den Export wieder importieren. Durch die Verwendung eines gut strukturierten Formats in Verbindung mit entsprechendem Import/Export im Core (fürs erste ginge das natürlich auch als Addon oder Plugin) sollte die Konvertierung robuster sein, als bei meinem simplem Entwurf – sowohl was die eigentliche Konvertierung angeht, als auch bezüglich der Bedienung.
Wichtiger Punkt, der ja auch hier schon mehrfach angesprochen wurde. Ich könnte mir vorstellen, dass wir das mit einer allgemeinen Export/Import Funktionalität gut umsetzen könnten; diese könnte auch anderweitig genutzt werden (Migration von/zu einem anderen CMS) und vermutlich auch bei später vielleicht anfallenden Änderungen Wiederverwendung finden.As solid converting tool is needed.
Die Idee ist halt ein deutlich strukturierteres Export/Import-Format zu verwenden, dass "universell" gut unterstützt wird. Sinnvoll wäre so gesehen XML oder vielleicht auch JSON. Bzgl. des Upgrades auf XH 1.7 müsste dann der User vor dem eigentlichen Upgrade erst den Content exportieren, und nach erfolgtem Upgrade den Export wieder importieren. Durch die Verwendung eines gut strukturierten Formats in Verbindung mit entsprechendem Import/Export im Core (fürs erste ginge das natürlich auch als Addon oder Plugin) sollte die Konvertierung robuster sein, als bei meinem simplem Entwurf – sowohl was die eigentliche Konvertierung angeht, als auch bezüglich der Bedienung.
Christoph M. Becker – Plugins for CMSimple_XH
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Tags
So, mal ein erster Entwurf.frase wrote:+1
XML +1
Bisher ist nur der Export implementiert, weil ich mir bezüglich der XML-Struktur unsicher bin: welche Namen, was als Attribut, was als Element, verschachtelte Struktur (so wie jetzt) oder flach wie bei CMSimple_XH? Gibt es da vielleicht irgendwelche "Standards" für CMS Inhalte? Was ist praxistauglich?
Jedenfalls könnt Ihr den Entwurf herunter laden, und den enthaltenen Ordner exchange_xh-master/ als exchange/ nach plugins/ kopieren, um es mal auszuprobieren. Dazu die Pluginadministration aufrufen → Main Settings → Export. Dann sollte im aktuellen content/ Ordner neben content.htm content.xml erzeugt worden sein. Bei mehrsprachigen Websites muss der Export für jede Sprache individuell durchgeführt werden.
Ich hoffe auf Euer Feedback!
Christoph M. Becker – Plugins for CMSimple_XH