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...   

Problem:

Um die Lockfelder zu verstecken verwendet das FORM Modul in der view.php die Anweisung

Code: [Select]

<p class="nixhier">
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: [Select]

<style type="text/css">
  .nixhier { display:none; }
</style>
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: [Select]

<p style="display:none;">

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]

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":

"Eine Seite mit einem ähnlichen oder demselben Titel existiert bereits"

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)

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,

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 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: [Select]

php_value default_charset utf-8
oder in wb iso-8859-1 einstellen (der Charset, der in AddDefaultCharset genannt ist)

oder in der apache.conf (oder ähnlich)

Code: [Select]

AddDefaultCharset Off

[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

[lotec]

... auch ich möchte dem WB-Team hier mal danken. BigTHX für die bisher geleistete Arbeit!

Der erste Installationsversuc h scheiterte, da ich den PHP-Safe Mode "On" hatte.
Beim 2. Versuch (Safe Mode=Off) verlief alles wie gewohnt reibungslos.
Habe nach der Installation den Safe Mode wieder auf "On" gesetzt und bisher keine Probleme gehabt.

Mit WB 2.67 hatte ich immer das Problem unter Firefox "cut&paste" nicht benutzen zu können und war daher ab und zu gezwungen mit dem MSIE zu arbeiten. In der neuen 2.7er Version funktioniert cut&paste wunnäbar.

Die Java Drag & Drop Funktion und Captchas sind schon allein ein update Wert.

Die Installation und Administration bleibt weiterhin an Einfachheit kaum zu unterbieten.

Vermelde also hier unter Vista mit Xampp 1.6.6a volle Funktionalität.

[chio]

Hab mir gerade die aktuelle Version von der Startseite geladen.
Die ist _deutlich_ buggier als eine frühere Version:
Stelle ich als extension ".html" ein, werden die die Access-Files trotzdem als .php angelegt, in News MUSS ich ein EndDatum angeben, sonst wird immer heute 00:00 eingesetzt. Bei der früheren Verison funktioniert das alles. Die hatte ich aber woanders her.
<edit>Access-Files als .php (statt.html): Dafür scheint der PageCloner verantwortlich zu sein. Das habe ich vorher nicht getestet (pageCloner + html)

[blickwinkel]

Hallo,

eine Sache, die mich verwundert ist der Umgang mit der Sichtbarkeit von Seiten:
Wenn eine Seite nur für registrierte Mitglieder sichtbar sein soll, war es bei WB 2.6.x so, dass der Menüname sichtbar ist, auch wenn der websitebesucher nicht registriert ist. Klickt er dann drauf, kommt ein login-screen.

Das war ja auch gut so.

jetzt wird eine Seite, die für Registrierte definiert wurde, gar nicht im Menü angezeigt. Wenn ein nicht angemeldeter Besucher die Seite direkt über die url aufruft (habs probiert) wird man zur index.php verfrachtet.

Komisch, dass das noch keiner vermerkt hat...

verwechselst du da nicht privat mit registriert? Außerdem hat show_menu da einen bug, richtig funktionieren tut es nur mit show_menu2. (ruebenwurzel)

nein. Hab die Seite definitiv auf registriert gestellt. Mit show_menu2 ist genau das selbe Problem.
Hallo, private Seiten werden nur im Frontend-Menü angezeigt, wenn man gleichzeitig im Backend angemeldet ist und die Berechtigung hat, private Seite anzusehen (genehmigter Besucher).
Registrierte Seiten werden nur angezeigt, wenn Du in den WB-Optionen Anmeldung aktiviert hast. Ausserdem muss das Template Frontend-Anmeldung unterstützen. Das funktioniert für 2.6.x gleich wie für 2.7. Die Dokumentation könnte mit Hinblick auf registrierte Seiten etwas ausführlicher ausfallen, das werden wir noch bereinigen. Wenn Du nur eine private Seite und eine registrierte Seite erstellst, Anmeldung deaktiviert hast und nicht im Backend angemeldet bist, erscheint lediglich: Keine Webseite verfügbar (doc)

[Syslord]

Erstmal Danke gesagt an alle die mit gemacht haben.

Klasse Arbeit

Bis jetzt konnte ich nix negatives finden

Kurz gesagt einfach spitze

Bitte macht weiter so

Gruß
Syslord

[doc]

Hallo,

wir haben soeben den zweiten Release Candidate von WB 2.7 veröffentlicht. Dieser Thread wird daher geschlossen.
Nochmals vielen Dank für all euer Feedback zu RC1.

Gruss Christian