WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)
Feedback zu WB 2.7 RC1
Ralf Hertsch:
Hallo zusammen,
ich bin ja kein Freund von hartcodierten Formatierungsanweis ungen, aber im Falle der ASP Funktion im FORM Modul schlage ich eine hartcodierte Anweisung vor... :wink:
Problem:
Um die Lockfelder zu verstecken verwendet das FORM Modul in der view.php die Anweisung
--- Code: ---<p class="nixhier">
--- End code ---
damit die Felder nicht gesehen werden muss das style Attribut display:none gesetzt werden. Dies geschieht über die Einbindung von asp.php am Anfang der Datei, die nichts weiter tut, als
--- Code: ---<style type="text/css">
.nixhier { display:none; }
</style>
--- End code ---
in die Datei zu schreiben. Das hat den Vorteil, dass niemand versehentlich das Attribut ändert, führt aber dazu dass die Anweisung nicht W3C konform innerhalb des body tags ausgegeben wird. Damit sind die entsprechenden Dateien nicht valide.
Ich schlage vor auf die asp.php ganz zu verzichten und innerhalb der view.php
--- Code: ---<p style="display:none;">
--- End code ---
zu verwenden.
Keine gute Idee. Viele Spambots füllen keine Felder aus, deren display Eigenschaft auf none steht. Daher die Klasse. (doc)
Gruß
Ralf
Lonesome Walker:
Warum nicht einen eigenen div-container?
Das mit den style-angaben ist ja schon wieder halbherzig...
Matthäus:
--- Quote from: bisi on February 26, 2008, 02:17:55 PM ---Hi, so kam gerade dazu paar Sachen einzubinden in WB 2.7.
Habe locker flockig damit angefangen, Seiten einzufügen und da fiel mir auf, dass man Seitentitel die mit Umlauten anfangen nicht einfügen kann. Darauf folgt nur der Hinweis":
--- Quote ---"Eine Seite mit einem ähnlichen oder demselben Titel existiert bereits"
--- End quote ---
Kann ich nicht nachvollziehen (XAMPP, WinXP, PHP 5.2). Schau mal im /pages Verzeichnis nach, ob nicht bereits eine Seite mit diesem Menütitel vorhanden ist. Umlaute werden vor dem speichern automatisch umbenannt und in Kleinbuchstaben gespeichert (Ä --> ae, Ö --> oe). (doc)
--- End quote ---
Das Problem kann ich hier übrigens auch bestätigen. Beim Einsatz von Umlauten wird übrigens der Dateiname auf ".php" gesetzt, der komplette Titel wird also anscheinend in einen Leerstring konvertiert. Bei der zweiten Umlautseite scheppert es dann also.
Bitte eine genauere Beschreibung eurer Konfiguration, sowohl mit .php als auch mit .html als Page Extension funktionert hier das Anlegen von Seiten und Unterseiten, die nur aus Umlauten bestehen ohne Probleme. (ruebenwurzel)
thorn:
Hallo,
--- Quote from: Matthäus on February 29, 2008, 05:05:23 PM ---Das Problem kann ich hier übrigens auch bestätigen. Beim Einsatz von Umlauten wird übrigens der Dateiname auf ".php" gesetzt, der komplette Titel wird also anscheinend in einen Leerstring konvertiert. Bei der zweiten Umlautseite scheppert es dann also.
--- End quote ---
Bitte mal mit error_reporting auf E_ALL (Optionen -> erweiterte Optionen -> PHP Fehlerberichte) testen.
Kommen da Fehlermeldungen?
Interessant wäre auch zu wissen
- welcher Zeichensatz in wb eingestellt ist
- ob/wie AddDefaultCharset gesetzt ist (apache)
- wie die Umlaute im Text bei highlighting aussehen (Suche -> gefundene Seite wählen)
EDIT: ok, hier sollten ja keine Diskussionen hin, also bitte hier https://forum.WebsiteBaker.org/index.php/topic,8836.msg52314.html#msg52314 antworten.
thorn.
EDIT: Problem erkannt (AddDefaultCharset lässt Grüßen), und im svn behoben (besser: "umgangen"): Dateinamen mit Umlauten werden dann wie bei 2.6.5 als "123ö"->"123E4.php" erzeugt.
Wir sollten im install- und upgrade-script einen Test implementieren, der warnt wenn AddDefaultCharset gesetzt ist.
EDIT: Ach so, die Lösung zum Problem:
.htaccess-Datei anlegen mit Inhalt:
--- Code: ---php_value default_charset utf-8
--- End code ---
oder in wb iso-8859-1 einstellen (der Charset, der in AddDefaultCharset genannt ist)
oder in der apache.conf (oder ähnlich)
--- Code: ---AddDefaultCharset Off
--- End code ---
Christian:
Formmailer:
Beim Anlegen eines Feldes im Kontaktformular kann man einen Standardtext eintragen; Dieser wird beim Anklicken des Feldes im Frontend nicht gelöscht - dadurch kann die Funktion "erforderliches Feld", also der Zwang etwas einzutragen, umgangen werden. Das war schon bei allen anderen Versionen so und sollte noch geändert werden.
Nach Update von 2.67 auf 2.7 lassen sich die neuen .css-Dateien nicht bearbeiten, da sie keine korrekten chmod-Rechte besitzen. Sollte in der Doku erwähnt werden, daß die Rechte händisch neu gesetzt werden müssen
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version