WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)

Tests & Probleme der SVN Revision 1374 - 2.8.2 RC

<< < (57/62) > >>

DarkViper:

--- Quote ---(WB kastriert Dateinamen (Media), ist für einige Umgebungen gelinde gesagt nicht befriedigend.
--- End quote ---

Beschwerden bitte nicht an uns, sondern an die Extrawurstbäcker in Redmondt richten...
( ich erlebe die Probleme mit Umlauten etc. hier im heterogenen Netzwerk tagtäglich )

'echte Dateinamen' im Media-Bereich sind in der Regel überflüssig.
Dateien, die innerhalb der von WB generierten Seiten verwendet werden, werden sowieso von WB selbst verwaltet und da spielt die Schreibweise keinerlei Rolle.

Schön wäre es bei Media-Dateien, die z.B. zum Download bereitstehen und auf die Besucher mit direkten Links zugreifen.
An dieser Stelle muss ich allerdings aus sicherheitstechnisc hen Gründen  einwerfen, dass derartige Downloadmöglichkeit en von Haus aus sehr kritisch sind. Wesentlich besser ist es, wenn Downloads vom jeweiligen Modul verwaltet werden und nicht als Deeplinks für jedermann frei zugänglich sind. Und sowie ein DL-Modul die Verwaltung übernimmt, sind physikalische Dateinamen wieder irrelevant, da die Darstellung völlig im Einflussbereich des Modules liegt.

Was hier helfen könnte, wäre eine Bitte an die Modulentwickler, nicht immer den einfachen Weg zu gehen, sondern den sicheren... auch wenn dieser etwas mehr Aufwand bedeutet.

HANS 0:
Menu_Link: "Neues Fenster"
Das funktioniert mit SM2-Parameter SM2_XHTML_STRICT folgerichtig nicht.
Sollte "Neues Fenster" im Menu_Link bei Nutzung von SM2_XHTML_STRICT dann nicht konsequenterweise ausgeblendet sein?

DarkViper:
naja, ich denke, dass wesentlich mehr Beschwerden über langsamen Bildaufbau kommen, wenn jedesmal beim Öffnen der Bearbeitungsmaske erst mal alle Templatedateien durchforstet werden, ob sich da irgendwo in irgendeiner Datei ein Stück PHP-Code mit einem SM2-Aufruf versteckt hat, der auch noch ganz zufällig das richtige Flag enthält.
Templates werden manuell, ausserhalb von WB  erstellt, folglich hat das WB-Backend auch keinerlei Informationen darüber und müsste sie bei jedem Aufruf auf's neue parsen(das Template könnte ja seit dem letzten Mal geändert sein).

chio:
Es ist ganz leicht, das Target im Menüaufruf wegzulassen. Wer strikt will, soll auch strikt können.

HANS 0:
Naja, ein Teil mehr, das sich für den Anwender nicht erschließt, denn den interessiert es überhaupt nicht was die Techniker da gebaut haben.

Es ist ein Teil, was anders als angekündigt funktioniert, wenn man dem Text "Neues Fenster" glauben mag.
Ob das für einen Programmierer ein Problem darstellt, interessiert den Anwender auch nicht. Der fühlt sich in den Wald geschickt. Mit Usability ist da nich viel

Ein Schild "Hier geht's zum Klo", und dann ohne Klo in's Klo zu greifen, bringt 'ne volle Hose, mehr nich.  :roll:

Ich selbst weiß ja um die Umstände, doch lasse ich immer wieder mal Unbedarfte spiel'n, erst recht wenn "eigentlich" alles ganz einfach sein soll. Als "Kenner" staunt man dann immer wieder.

Wahrscheinlich werde ich das für meine STRICT-Anwender ändern, da externe Links bei denen per JS aufherufen werden, unter anderem wg. Barrierefreiheit. (Nicht wirklich, sondern nur wegen W3C  :wink: )

Navigation

[0] Message Index

[#] Next page

[*] Previous page