XH: alternatives Seitensplitten unabhängig von <hx> - Tags

[lck]

Sehr gute Arbeit Holger, Gratulation! Einer kleiner Schritt für uns, aber ein großer Schritt für CMSimple_XH

Hatte heute Mittag schon mal getestet, aber keine Zeit für eine Rückmeldung, deshalb erst jetzt.
Soweit ich das überschauen kann, läuft das sehr gut. Habe es mal stichprobenartig mit verschiedenen menuleveln durchgespielt, bis ml99.

./cmsimple/config.php auf $cf['menu']['levelcatch']="100"; gestellt:
Sonderfall: <!--XH_ml10:Seite ml10--> , <!--XH_ml20:Seite ml20--> , <!--XH_ml30:Seite ml30--> usw.
In der Praxis eher unwahrscheinlich, dass jemanand solch hohe menulevels nutzt, aber im Test gibt es da ein Problem mit menulevels die eine "0" am Ende haben, z.B. ml10, ml20, ml30 usw.
Sie werden nicht im Menü angezeigt, stattdessen wird deren Inhalt inklusive Kommentar, unter dem Inhalt der Seite darüber eingefügt/angezeigt.

Ansonsten, Daumen hoch.

[cmb]

./cmsimple/config.php auf $cf['menu']['levelcatch']="100"; gestellt:

Ah, der gute alte levelcatch! Der könnte bei der neuen Variante eigentlich auch dynamisch ermittelt werden, wenn ich mich nicht irre.

Sonderfall: <!--XH_ml10:Seite ml10--> , <!--XH_ml20:Seite ml20--> , <!--XH_ml30:Seite ml30--> usw.
In der Praxis eher unwahrscheinlich, dass jemanand solch hohe menulevels nutzt, aber im Test gibt es da ein Problem mit menulevels die eine "0" am Ende haben, z.B. ml10, ml20, ml30 usw.

Wieder ein guter Punkt. Schau mal in cmsimple/functions.php, da lautet Zeile 928:

Code: Select all

    $content = preg_split('/(?=<!--XH_ml[1-9]+:)/i', $content);

Das müsste geändert werden in:

Code: Select all

    $content = preg_split('/(?=<!--XH_ml[0-9]+:)/i', $content);

Und ein paar Zeilen weiter unten (Zeile 936) das gleiche Spiel. Und auch in cmsimple/admfuncs.php müssten drei entsprechende Vorkommen in function XH_saveEditorContents() geändert werden. Eventuell noch weitere Stellen.

Das würde dann allerdings auch Menu-Level 0 zulassen. Wenn man da ganz genau sein wollte, müsste man statt [0-9]+ eben [1-9][0-9]* schreiben.

[lck]

Und ein paar Zeilen weiter unten (Zeile 936) das gleiche Spiel. Und auch in cmsimple/admfuncs.php müssten drei entsprechende Vorkommen in function XH_saveEditorContents() geändert werden. Eventuell noch weitere Stellen.

Das würde dann allerdings auch Menu-Level 0 zulassen. Wenn man da ganz genau sein wollte, müsste man statt [0-9]+ eben [1-9][0-9]* schreiben.

Ob das sinnvoll ist zu ändern, nicht das dies wieder einen Rattenschwanz an Problemen hinter sich her zieht? Vielleicht ist es doch besser, den menulevel auf 9 zu beschränken

[lck]

Ich habe den Bogen jetzt mal überspannt und menulevels bis 20 angelegt, interessant aber irrelevant.

Ab ml16 kommt die Meldung oberhalb der Seite:

Gemäß Einstellungen→CMS→Uri→Length ist die URL zu lang:
Seite ml16
Gemäß Einstellungen→CMS→Uri→Length ist die URL zu lang:
Seite ml17
Gemäß Einstellungen→CMS→Uri→Length ist die URL zu lang:
Seite ml18
Gemäß Einstellungen→CMS→Uri→Length ist die URL zu lang:
Seite ml19

und im Menü bei Link mit ml17, ml18, ml19 steht dann

DOPPELTE UBERSCHRIFT 1
DOPPELTE UBERSCHRIFT 2
DOPPELTE UBERSCHRIFT 3

Alles ist wieder gut, wenn in der ./cmsimple/config.php der Wert bei

Code: Select all

$cf['uri']['length']="200"; // dementsprechend höher setzt, z.B. 300  

Aber, die Meldung "DOPPELTE ÜBERSCHRIFT" ist "eigentlich" nicht zutreffend.

[cmb]

Aber, die Meldung "DOPPELTE ÜBERSCHRIFT" ist "eigentlich" nicht zutreffend.

Da hast Du recht; eigentlich sollte es wohl "nicht unterscheidbare (Seiten-)URL" heißen. Damit kann der Anwender aber vermutlich nichts anfangen.

Ab ml16 kommt die Meldung oberhalb der Seite:
[…]

Das hatte ich nicht wirklich bedacht. Die Standardlänge von 200 "Zeichen" (in Wirklichkeit sind es Bytes, und das ist ein Bug, da UTF-8 Zeichen mitten drin abgeschnitten werden können, was eine ungültige URL ergäbe) ist schon sehr reichlich bemessen (den Browser stört's nicht, aber wehe, das will mal einer eintippen), so dass zu viele Menüebenen keinen Sinn machen (okay, mit SEO_XH könnte man Seitenslugs verwenden, die dieses Problem nicht haben). Vielleicht ist es doch ganz sinnvoll, maximal 9 Menüebenen zu haben (und bei anderen Werten einen Fehler zu melden oder den Splitter zu ignorieren); schließlich ist ja die Gesamtgröße des Content ohnehin begrenzt (obwohl ich da vielleicht auch noch eine gute Idee habe), und eine extrem unausgeglichene Menüstruktur (außer wenigen Seiten mit sehr tiefer Verschachtelung nur Seiten ohne Unterseiten) ist sowieso nicht wünschenswert. Und 9 Ebenen sind ja schon 4-5 mehr als bisher sinnvoll machbar war. Das sollte genügen.

[Holger]

Ui schön, dass ihr so viel Zeit dafür investiert .

Wenn man da ganz genau sein wollte, müsste man statt [0-9]+ eben [1-9][0-9]* schreiben.

Stimmt. Da muss ich auch noch etwas mehr üben .

Ich habe den Code jetzt mal auf GitHub veröffentlicht. Die ersten Commits sind vielleicht etwas unübersichtlich, da ich immer mal wieder etwas vergessen oder zu viel hatte. Aber ich gelobe für die Zukunft Besserung.

Christoph, vielleicht wirfst du noch einmal einen Blick auf die entsprechenden Änderungen. Es würde mich nicht wundern, wenn da noch einiges Potential zur Verbesserung bestünde.
Insbesondere hier, beim Einschleusen der Split-Marker im "DAU-Mode" könnte man vielleicht nachbessern. Ich war aber unsicher, ob man den gesendeten Code nicht doch besser durch alle Prüfungen laufen lässt.

[BTW: wollen wir nicht bald mal mit dem Core auch zu Git wechseln? Meinen Segen gebe ich hiermit. Git scheint mir fast simpler in der Einarbeitung zu sein als Subversion]

[cmb]

Ui schön, dass ihr so viel Zeit dafür investiert

Was wir nicht könnten, wenn Du nicht so viel Zeit in die Idee und die Implementierung investiert hättest.

Ich habe den Code jetzt mal auf GitHub veröffentlicht

Danke!

Die ersten Commits sind vielleicht etwas unübersichtlich, da ich immer mal wieder etwas vergessen oder zu viel hatte. Aber ich gelobe für die Zukunft Besserung.

Ich denke, das passt schon. Aber kleiner Tipp: bei Git kann man leicht den letzten Commit ergänzen. Hat man also mal was vergessen, und bemerkt es noch vor dem nächsten Commit und vor dem Push, dann einfach `git commit --amend` – na ja, und wenn man schon mehr committed aber noch nicht gepusht hat, kann man das auch noch ganz akzeptabel lösen.

Christoph, vielleicht wirfst du noch einmal einen Blick auf die entsprechenden Änderungen.

Ich schau's mir gerne mal an.

[BTW: wollen wir nicht bald mal mit dem Core auch zu Git wechseln? Meinen Segen gebe ich hiermit. Git scheint mir fast simpler in der Einarbeitung zu sein als Subversion]

Das habe ich mal auf die Roadmap gepackt. Einacher ist Git, finde ich, nicht, aber nach einer Weile mochte ich es eigentlich nicht mehr missen.

[Holger]

Ich denke, das passt schon. Aber kleiner Tipp: bei Git kann man leicht den letzten Commit ergänzen. Hat man also mal was vergessen, und bemerkt es noch vor dem nächsten Commit und vor dem Push, dann einfach `git commit --amend` – na ja, und wenn man schon mehr committed aber noch nicht gepusht hat, kann man das auch noch ganz akzeptabel lösen.

Na ja, ich freunde mich ja eben erst so richtig mit Git an.

Aber meine Commits waren da doch etwas unübersichtlich.
Ich denke, ich setze das Morgen noch einmal neu auf, damit man die wesentlichen Änderungen an den paar Dateien in einem Commit findet. Da hab' ich jetzt auch meinen Ehrgeiz . Also beschäftige dich erst einmal nicht so intensiv damit. Ich melde mich, wenn ich es neu aufgesetzt habe.

Das habe ich mal auf die Roadmap gepackt. Einacher ist Git, finde ich, nicht, aber nach einer Weile mochte ich es eigentlich nicht mehr missen.

Na ja, ich fand es jetzt intuitiver. Aber ich habe ja, außer einem eigenen Poll Request selber zu mergen, noch nicht wirklich viel gemacht.
Aber alleine wie simpel man einen Poll Request erstellt und anschließend integriert finde ich deutlich einfacher.
Und außerdem ist der Issue-Tracker viel viel besser als bei SF.

Roadmap? Hmm, da habe ich schon lange mein Passwort vergessen...
Können wir die Wechsel-Entscheidung nicht auf dem kleinen Dienstweg angehen?

[cmb]

Also beschäftige dich erst einmal nicht so intensiv damit. Ich melde mich, wenn ich es neu aufgesetzt habe.

Okay.

Aber alleine wie simpel man einen Poll Request erstellt und anschließend integriert finde ich deutlich einfacher.

PRs sind in der Tat was Tolles und eine prima Verbesserung gegenüber SVN (da kann man bestenfalls Patches verschicken oder irgendwo posten).

Und außerdem ist der Issue-Tracker viel viel besser als bei SF.

Finde ich auch. Der könnte auch mal die Roadmap ersetzen.

Roadmap? Hmm, da habe ich schon lange mein Passwort vergessen...
Können wir die Wechsel-Entscheidung nicht auf dem kleinen Dienstweg angehen?

Finde ich nicht so gut, da es ja nicht nur uns beide betrifft – also lieber abstimmen, würde ich sagen. Und zwei Wochen hat es doch Zeit, oder?

[frase]

Ob das sinnvoll ist zu ändern, nicht das dies wieder einen Rattenschwanz an Problemen hinter sich her zieht? Vielleicht ist es doch besser, den menulevel auf 9 zu beschränken

+1