Seitentitel mit Komma

[frase-git]

{{{expand 'pages = Beispiel Seite 1,Beispiel Seite 2,Verborgene Seite 3,Seitentitel, mit Komma'}}} "Seitentitel, mit Komma" ist nicht möglich! Ergibt:

Page "Seitentitel" not found!

Entweder nur dokumentieren -1 oder das Komma im Seitentitel maskieren \, ?

[olape-git]

Ja, das Komma wird zur Trennung der Titel verwendet.

https://github.com/TN03/expandcontract/blob/1170d9141ae42901c10ae4b7e722e3e19de2cab5/index.php#L133 https://github.com/TN03/expandcontract/blob/1170d9141ae42901c10ae4b7e722e3e19de2cab5/index.php#L134

Alternativ könnte man das vielleicht per Pipe trennen. Das Gleiche wäre bei headlines.

[frase-git]

Das Gleiche wäre bei headlines.

Ja, hatte ich vergessen.

Alternativ könnte man das vielleicht per Pipe trennen.

Das wäre das Selbe in grün. Pipe könnte ja auch im Titel oder den Headlines vorkommen. Vielleicht etwas, was in url nicht vorkommen kann/darf?

[olape-git]

Seitentitel ist nicht url. In den Seitentitel kannst du alles reinschreiben.

[frase-git]

Seitentitel ist nicht url. In den Seitentitel kannst du alles reinschreiben.

Na eben, da geht auch Pipe nicht. Ich hatte gedacht, alles lassen wie es ist, nur dokumentieren, dass ein Komma im Seitentitel beim Aufruf manuell maskiert werden muss. {{{expand 'pages = Beispiel Seite 1,Beispiel Seite 2,Verborgene Seite 3,Seitentitel\, mit Komma'}}} Allerdings muss beim Zusammensuchen der Seiten dann das \, als , interpretiert werden.

[olape-git]

ne, so einfach funktioniert das nicht. Fände ich auch nicht wirklich gut. Wir brauchen ein Zeichen, oder eine Kombi, die mit sehr hoher Wahrscheinlichkeit nicht auftaucht.

[olape-git]

Dabei ergibt sich auch noch ein anderes Problem 'Beispiel Seite 1' und 'Bei|-|spiel Seite 1' sind nur optisch im Menü und bei der url das Gleiche Der Seitenname ist dann allerding 'Bei-spiel Seite 1' Vielleicht wäre es einfach besser, nicht den Seitennamen sonder die url zu suchen. Das würde beide Probleme erschlagen.

[frase-git]

Vielleicht wäre es einfach besser, nicht den Seitennamen sonder die url zu suchen.

Hm, wäre das beim Eintippen leichter für den Anwender? Kopieren aus der Adresszeile - oder?

Das würde beide Probleme erschlagen.

Scheint so. Aber es muss wieder viel umgeschrieben werden, Code, Demo und Tooltipps. Wenn's denn hilft ...

[olape-git]

Beim Code, denke ich, wir müssten damit hinkommen 2x $h gegen $u zu tauschen.

https://github.com/TN03/expandcontract/blob/1170d9141ae42901c10ae4b7e722e3e19de2cab5/index.php#L139 https://github.com/TN03/expandcontract/blob/1170d9141ae42901c10ae4b7e722e3e19de2cab5/index.php#L148

Hm, wäre das beim Eintippen leichter für den Anwender? Kopieren aus der Adresszeile - oder?

Nein und Ja Es wäre dann i.e. Beispielseiten/Beispiel-Seite-1. Also die volle url. Also eben sehr wahrscheinlich länger. Dafür aber auch eindeutig. Denn die ganze url kann es nur 1x geben.

[frase-git]

Dafür aber auch eindeutig. Denn die ganze url kann es nur 1x geben.

Stimmt. Mal sehen, was @TN03 dazu sagt.

[frase-git]

Beim Code, denke ich, wir müssten damit hinkommen 2x $h gegen $u zu tauschen.

Gerade mal getestet. Das scheint tatsächlich mit diesen zwei Änderung gut zu funktionieren. Der Aufruf wird wirlich ziemlich lang:

{{{expand 'pages = CSS-Beispiele/Beispielseiten/Beispiel-Seite-1,CSS-Beispiele/Beispielseiten/Beispiel-Seite-2,Variante-1/Verborgene-Seite-3'}}}

[olape-git]

Man müsste nochmal prüfen, wie es aussieht, wenn die url encodierte Zeichen enthält. Ich weiss jetzt nicht, wie die url im content steht, bzw. wie diese dann in $u auftaucht. Ich lasse bei aktuellen Seiten zwar alles ersetzen, meine urls bestehen tatsächlich nur noch aus Kleinbuchstaben oder -. Leider ist das aber eben noch kein Standard.

[frase-git]

Wenn alles nach dem "?" aus der Adresszeile kopiert wird, dann sollte das doch passen - oder?

[TN03]

Die Url zu nehmen finde ich nicht gut. Man kann sie ja auch nicht einfach mal so aus der Adressleiste kopieren, Dann müssten wir sie besser noch Parsen, dann werden die Parameter aber noch viel viel länger.

Ich finde die Idee von Frank viel besser und üblicher

oder das Komma im Seitentitel maskieren \, ?

Und das ist auch leicht machbar. Muss halt dokumentiert werden. In diesem Branch ist mal eine index.php mit der das klappen sollte: https://github.com/TN03/expandcontract/tree/EscapeKommas Die Änderungen dazu sind trivial: https://github.com/TN03/expandcontract/commit/b680c8aca763499d89f718e2a7f025e148594d0a

Ich habe es nicht getestet. Es sollte aber funktionieren ;-).

[frase-git]

Ich habe es nicht getestet. Es sollte aber funktionieren ;-).

Es funktioniert mit pages und auch mit headlines. sinnfreies Beispiel: Aufruf: {{{expand 'pages = Beispiel Seite 1,Beispiel Seite 2,Verborgene Seite 3,Seite\, mit Komma','headlines = Beispiel Seite 1,Beispiel Seite 2,Verborgene Seite 3,Seite\, mit 2 \, Kommata'}}} Gefunden wird die Seite "Seite, mit Komma" und angezeigt als: "Seite, mit 2 , Kommata"

Ich vermute, dass das die bessere Lösung ist. Die manuelle Maskierung muss dokumentiert werden. Wird das vergessen, gibt es ja die Fehlermeldung. Einziger Nachteil dabei ist, dass bei Seiten im Seitenbaum mit gleichem Namen, immer nur die erste aufgefundene verwendet wird. Man kann eben nicht "die zweite" ansprechen.

[TN03]

Ich vermute, dass das die bessere Lösung ist.

Sehe ich auch so.

Einziger Nachteil dabei ist, dass bei Seiten im Seitenbaum mit gleichem Namen, immer nur die erste aufgefundene verwendet wird.

Das ganze Ursprungsdesign, also "versteckte Unterseiten automatisch", finde ich nicht gelungen. Wenn es, vermeintlich, auch sinnvoll erscheint. Im Edit-Mode führt das zu unendlich langen Navigationslisten nur, weil jeder Eintrag eine neue Seite haben muss. Zumindest eine Art "Anfangsseite", unter der die versteckten zu finden sind, wäre bei dem Design schön. Noch besser, wie bei acDIVs, alles für ein Akkordeon auf einer Seite und dann nach einem Tag splitten.

Vielleicht mal später, wenn es mich in der Praxis zu sehr nervt ;-).

[TN03]

Ach ja, soll ich das so mal in den Master schieben?

[frase-git]

Noch besser, wie bei acDIVs, alles für ein Akkordeon auf einer Seite und dann nach einem Tag splitten.

Das widerspricht wohl Svastis ursprünglicher Intuition. Es sollten hier wohl wirklich nur "ganze" Seiten verwendet werden. Ich würde die Tag-Splitting-Variante auch nicht in dieses Plugin "reinwürgen" wollen - dazu gibt es ja acDIVs - was wir dann auch noch aufmöbeln könnten.

Ach ja, soll ich das so mal in den Master schieben?

Von mir: Ja - wir sollten aber noch auf die Meinung von @olape-git warten.

[olape-git]

Von mir aus auch. Ich persönlich finde das Maskieren eher ungewöhnlich für einen normalen Anwender, aber gut. Ich kann damit leben.

[TN03]

Erledigt mit https://github.com/TN03/expandcontract/commit/5ce6287206494591f2b47cdb2c314297da2e195f

[olape-git]

Aber, wenn es in pages oder headlines jeweils nur eine Angabe, dafür aber mit \, gibt, läuft es auch in das if für das Zerlegen in ein Array. Das temporäre erstezen von \, in , müsste jeweils vor die Abfrage if (strpos($link, ',')) { oder if (strpos($linktext, ',')) {

Das funktioniert deswegen. Die Frage ist vielleicht, braucht es denn überhaupt die Abfrage if (strpos($link, ',')) { oder if (strpos($linktext, ',')) {? Oder lässt man einfach immer explode laufen.

[TN03]

Dann musst du vorher immer die Ersetzungen machen, obwohl bestimmt zu 99% nicht erforderlich. Und das Beispiel pages / headlines nur eine Angabe, ist wohl auch eher die Ausnahme, genau wie pages / headlines insgesamt. In den meisten Fällenwird wohl einfach {{{expand}}} ausreichend sein.

Bitte versteh' das nicht falsch, aber das kostet alles eine Menge Zeit, wenn man sich richtig damit befassen will. Und ich bin nicht sicher ob es wirklich sinnvoll ist wirklich alles zu machen was geht. Hier konkret glaube ich, dass die Änderung langfristig gesehen sogar mehr Ressourcen kostet als nötig. Und auch die insgesamt übertriebene Validierung kostet Code, Ressourcen und ist im Zweifel auch fehleranfällig.