Page 1 of 1

locator: Trennzeichen als Sprachvariable

Posted: Fri Jan 11, 2019 12:48 pm
by frase
Ein Wunsch, dessen Verwirklichung nicht allzuviel Arbeit verursachen dürfte (?)

Datei ... \cmsimple\tplfuncs.php ca. Zeile 418 (XH 1.7.2)
IST:

Code: Select all

$html .= ' > ';
Damit ist das ">" zwischen den Locator-Links hart kodiert.
Wäre es nicht besser, dieses Zeichen als Sprachvariable zu haben?
Dann wäre es wählbar (evtl. sogar FA) oder könnte so auch weggelassen werden.

Re: locator: Trennzeichen als Sprachvariable

Posted: Fri Jan 11, 2019 1:02 pm
by olape
Probier es aus:

Zeile 418 ersetzen mit:

Code: Select all

$html .= $tx['breadcrumb']['seperator'];
de.php oder besser default.php

Code: Select all

$tx['breadcrumb']['seperator'] = " | ";

Re: locator: Trennzeichen als Sprachvariable

Posted: Fri Jan 11, 2019 1:10 pm
by frase
olape wrote:
Fri Jan 11, 2019 1:02 pm
Probier es aus:
Das habe ich schon lange für mich selbst gelöst. ;-)
Aber das ist nicht updatesicher.
Wäre vielleicht ein gutes Feature für "alle".

Re: locator: Trennzeichen als Sprachvariable

Posted: Fri Jan 11, 2019 1:16 pm
by olape
frase wrote:
Fri Jan 11, 2019 1:10 pm
Aber das ist nicht updatesicher.
Wäre vielleicht ein gutes Feature für "alle".
Klar, solange es nicht offiziell im Release ist, ist es auch nicht updatesicher.
Für alle? Da habe ich noch gar nicht darüber nachgedacht, das mal zu ändern.
Aber schlecht ist die Idee nicht. Bei dem einen oder anderen Layout wäre es sicher von Vorteil.

Besser wäre es allerdings vielleicht in der config aufgehoben. Man wird wohl kaum pro Sprache verschieden Trennzeichen einstellen.

Re: locator: Trennzeichen als Sprachvariable

Posted: Fri Jan 11, 2019 1:20 pm
by frase
olape wrote:
Fri Jan 11, 2019 1:16 pm
Besser wäre es allerdings vielleicht in der config aufgehoben. Man wird wohl kaum pro Sprache verschieden Trennzeichen einstellen.
Da glaubst ja gar nicht, was es so für "Chef-Designer" gibt - und was die alles wollen.

Re: locator: Trennzeichen als Sprachvariable

Posted: Fri Jan 11, 2019 2:17 pm
by cmb
frase wrote:
Fri Jan 11, 2019 12:48 pm
Damit ist das ">" zwischen den Locator-Links hart kodiert.
Wäre es nicht besser, dieses Zeichen als Sprachvariable zu haben?
Dann wäre es wählbar (evtl. sogar FA) oder könnte so auch weggelassen werden.
Man könnte das hart-kodierte > sogar als Bug einstufen; ist ja nicht so, dass das in Unicode-Zeiten noch irgendwie besonders sinnvoll ist. Vom Markup in den Sprachvariablen möchte ich aber lieber irgendwann ganz wegkommen (so gesehen wäre FA nicht unbedingt zukunftssicher); zum einen weil ich einem Endanwender eher nicht zumuten will, dass er dort > statt > schreibt, und auch aus Sicherheitsgründen.

Re: locator: Trennzeichen als Sprachvariable

Posted: Fri Jan 11, 2019 2:29 pm
by frase
cmb wrote:
Fri Jan 11, 2019 2:17 pm
Man könnte das hart-kodierte > sogar als Bug einstufen; ist ja nicht so, dass das in Unicode-Zeiten noch irgendwie besonders sinnvoll ist.
Wenn dem denn so ist, dann möchte ich meinen Post als solchen verstanden wissen ;-)
cmb wrote:
Fri Jan 11, 2019 2:17 pm
Vom Markup in den Sprachvariablen möchte ich aber lieber irgendwann ganz wegkommen (so gesehen wäre FA nicht unbedingt zukunftssicher); zum einen weil ich einem Endanwender eher nicht zumuten will, dass er dort > statt > schreibt, und auch aus Sicherheitsgründen.
Das fände ich sehr schade, hat mir schon oft in kritischen Situationen geholfen.
(FA-Home-Häuschen statt "Startpage")

Übrigens:
Sicherheitsgründen => 404

Re: locator: Trennzeichen als Sprachvariable

Posted: Thu Feb 21, 2019 11:51 am
by cmb
frase wrote:
Fri Jan 11, 2019 2:29 pm
Wenn dem denn so ist, dann möchte ich meinen Post als solchen verstanden wissen ;-)
Okay, nun endlich als Issue auf Github eingetragen. Mühsam nährt sich das Eichhörnchen …
frase wrote:
Fri Jan 11, 2019 2:29 pm
Sicherheitsgründen => 404
Stimmt! Kanns auch sonst nirgends finden; es ging darum, dass man mangels CSRF-Schutzes einem eingeloggten Webmaster ein Formular unterjubeln konnte, und dort dann gleich ein paar Sprachvariablen (ich glaube, v.a. der Site-Title) mit <script> Elementen präparieren konnte, was als CSRF/XSS-Sicherheitslücke geführt wurde.