WebsiteBaker 2.8.2 RC5 Tests

[ruebenwurzel]

Hallo,

mache mal das Thema auch auf deutsch auf, es gibt ja im Englischen ein gleichlautendes. Bin gerade am Testen der RC5 und nehme dieses Thema zum Anlass das niederzuschreiben, was mir an Fehlern auffällt.

Zunächst mal nur eine Kleinigkeit. Bei den Erweiterungen - Sprachen fällt auf, dass die Entities nicht mehr richtig dargestellt werden (CS, FR ...). Das sollte wieder korrigiert werden.

Denke es hängt damit zusammen, dass ich explicit nicht UTF8 verwende sondern halt ISO..... Es handelt sich um Seiten die von früheren WB Versionen upgedated wurden. In früheren Zeiten waren Darstellung und Suche ja leider nur Mit den entsprechenden charsets möglich. Das ist jetzt ja Gott sei Dank Vergangenheit (spätestens ab 2.9), aber viele langjährige WB-Nutzer werden wohl dasselbe Problem haben, dass die alten Seiten halt nicht UTF8 sind. Und solange eine Konvertierung nicht da ist (wird wohl für 2.8.2 nie kommen), sollte die Darstellung von nicht UTF8 Installationen wie bisher fehlerfrei möglich sein.

Gruß
Matthias

[testör]

Gut, dann haben wir halt noch ein paar mehr Threads- sollten wir allerdings auch die alten schließen, sonst gibt's ja nur noch Chaos, wir haben dann ja jetzt schon vier für die RCs von 2.8.2.
Dann sollte es aber auch einen Eingangsbeitrag geben, wie im alten am Schluss - sonst beteiligt man keine neuen Benutzer.

So - im Anhang gibt es eine (nach Rechtschreibfehlern!) korrigierte DE.php.
Darin sind aber keinerlei Umlaute usw. ausgeschrieben - ISO-Fehler sollte daher woanders zu suchen sein.
Da es ja jetzt /include/idna_convert gibt wäre gut zu wissen, ob das auch bei Sprachdateien greif und wenn ja, was es da genau macht. So ganz schlau werde ich aus der idna_convert nämlich nicht, wird sie ja nirgends aufgerufen.
Irgendwie scheint mir das aber nur ein Domainnamen-Ummodler zu sein (wer um alles in der Welt nun auch Umlaut-Domains benutzen will, außer bei der Pressemeldung vor einigen Jahren dass es jetzt möglich ist, ist mir das nicht untergekommen). Ob man so etwas spezielles nun in der include mitliefern sollte sei dahingestellt - aber entweder benutzen oder halt wie bisher nicht.


[gelöscht durch Administrator]

[chio]

Eine Kleinigkeit, die mich speziell nervt, ist dass die Redirect-Zeit (beim Speichern usw) wieder auf Minimum 1500 gestellt werden muss. Alles kleiner bedeutet: kein Redirect. Das nervt.
Generell würde ich ja sagen: Bei success: sofort redirect, bei error: kein redirect.

Dass das Pages-Verzeichnis jetzt zwingend beschreibbar sein muss, macht mir auf etlichen Sites Probleme, nämlich dort, wo es auf leer ("") steht und ich _nur_ en/ und de/ habe. Da kann ich keine Seiten anlegen, wenn das Root nicht beschreibbar ist.

[ruebenwurzel]

Hallo,

Darin sind aber keinerlei Umlaute usw. ausgeschrieben - ISO-Fehler sollte daher woanders zu suchen sein.

Das Problem sind nicht die Sprachdateien an sich. Das wird schon alles im Frontend richtig ausgegeben und zu 99,9% auch im Backend. Lediglich auf der Erweiterungen - Sprachen Seite gibt es Darstellungsfehler wenn man sich die installierten Sprachen anschauen oder ändern will. Da muss wieder ein htmlspecialchars oder sowas eingebaut werden in den Dateien in admin/addons/languages.

Matthias

[Luisehahne]

@Chio

Eine Kleinigkeit, die mich speziell nervt, ist dass die Redirect-Zeit

Steht auf der ToDo Liste, Vorschlag

• -1 bedeuted ausgeschaltet,
• Valider Wert 0 - 10000
• Größer 10000 wird der Timer auf 0 gesetzt

@Chio

Dass das Pages-Verzeichnis jetzt zwingend beschreibbar sein muss

Musste immer schon beschreibbar sein, habe bis zur 2.6 nachgeschaut.
Da wir auf der WB Homepage auch bereits auf 2.8.2 umgestellt haben, Testseite angelegt und keine Probleme, wurde mit Filemode 644 ohne Probleme angelegt

Ansonsten bitte mehr Infos

Dietmar

[chio]

Ich habe etliche Seiten, die mit WB 2.8.2 nicht mehr funktionieren, weil das Root der Domain NICHT beschreibbar ist. Vielleicht bin ich der einzige, kann ja sein.
Man muss sich aber auch fragen: Warum wird das überhaupt überprüft? Das passiert bei der Installation, dann sollte das eigentlich klar sein.

[Luisehahne]

Ich habe jetzt bei mir nachgeschaut, Doc_root Rechte steht auf 745. Ordner innerhalb werden mit 755 und Files mit 644 angelegt.

Sprich mit deinem Hoster. Ich kann dir nur versichern, dass es schon immer abgeprüft wurde. Schau mal selber im SVN in die vergangenen Versionen.

Dietmar

[DarkViper]

Man muss sich aber auch fragen: Warum wird das überhaupt überprüft? Das passiert bei der Installation, dann sollte das eigentlich klar sein.

Leider ist das auch nach der Installation nicht klar, da es so seltsame Programme wie z.B. FileZilla gibt, mit denen sich Rechte jederzeit nachträglich ändern lassen.
Und weist ja selbst aus Erfahrung, dass User immer erst die Rechte von Verzeichnissen und Dateien wahllos ändern, bevor sie es evt. mal mit ihrem Adminzugang versuchen wenn irgendetwas nicht funktioniert. [/sarkasmus off] 

[susigross]

Also wenn ich mich recht erinnere, habe ich auf manchen sites auch deswegen den Core gepatcht in einer älteren WB-Version. Es gibt garantiert einen alten Thread hier im Forum, wo über das Problem diskutiert wurde.
Meine Meinung:

• Natürlich müssen die Schreibrechte für das Verzeichnis, in das geschrieben werden soll, überprüft werden.
• Es ist sinnlos, die Schreibrechte eines weiter übergeordneten Verzeichnisses zu prüfen, weil das völlig irrelevant für den Schreiberfolg im Unter-Unterverzeichnis ist. Der User könnte ja auch die Schreibrechte für das Unterverzeichnis verstellt haben, aber nicht für root, und dann bringt die Überprüfung in root 0 Punkte.

Werner, es gibt doch eigentlich kein Argument gegen eine solche Realiserung, oder?
Ich kann das gerne machen, weil bei meinem Provider habe ich das Problem auch

[DarkViper]

Solange es rein um das Anlegen/Löschen untergeordneter Seiten geht ist das durchaus machbar.
Probleme werden aber auftreten, sowie eine Seite auf Level 0 geändert, gelöscht oder gar hinzugefügt werden soll. Ebenso beim automatischen, rekursiven Neuaufbau der Accessfiles, wenn wenn irgendwo eine Datei fehlt und die Pagesverwaltung daraufhin den Neuaufbau anstößt, sowie die entsprechende Seite neu abgespeichert wird.

...grummel... Waschmaschine kaputt...

[NorHei]

Leider ist das auch nach der Installation nicht klar, da es so seltsame Programme wie z.B. FileZilla gibt, mit denen sich Rechte jederzeit nachträglich ändern lassen.

Äh, eben nicht unbedingt habe hier PHP als Apachemodul laufen das heist Dateien die von WB angelegt werden laufen unter unter einem anderen Benutzer als die per FTP eingespielten.
Da ist es dann garnicht so einfach mal die Rechte wieder zu ändern.

Vielleicht mal auf einem Server testen auf dem PHP als Apachemodul läuft.

Was ich nicht verstehe ist das dem pages Verzeichniss die Rechte entzogen wurden, denn nach der Installation wahren sie ja wohl gesetzt. Ich verstehe einfach nicht den Sinn warum man das machen sollte.

[DarkViper]

Vielleicht mal auf einem Server testen auf dem PHP als Apachemodul läuft.

Das Problem ist leider allzugut bekannt.... aber es wird daran gearbeitet..

Was ich nicht verstehe ist das dem pages Verzeichniss die Rechte entzogen wurden, denn nach der Installation wahren sie ja wohl gesetzt. Ich verstehe einfach nicht den Sinn warum man das machen sollte.

Dem /pages/ wurden keine Rechte entzogen, es wurde nur in die DocumentRoot 'verlegt'. Verschiedene Admins haben eben lieber Links wie http://example.com/startseite.php  anstatt http://example.com/pages/startseite.php.
Normalerweise kein Problem, solange der Provider bei einem unter apache2modul laufenden Server dem www-run nicht die Schreibrechte für DocumentRoot entzieht.
Bei derartiger Konfiguration gibt es nur 2 Möglichkeiten:

• einen Webspace nehmen, der diese Probleme nicht bereitet... bzw. auf fast/CGI umschalten
• jedes Unterverzeichnis in DocumentRoot erst mal per FTP anlegen und passende Rechte vergeben, bevor www-run da was reinschreiben kann.

[ruebenwurzel]

Hallo,

Bei derartiger Konfiguration gibt es nur 2 Möglichkeiten:

• einen Webspace nehmen, der diese Probleme nicht bereitet... bzw. auf fast/CGI umschalten
• jedes Unterverzeichnis in DocumentRoot erst mal per FTP anlegen und passende Rechte vergeben, bevor www-run da was reinschreiben kann.

Hätte da noch eine dritte Variante anzubieten. Bin auch bei einem Provider (allinkl) bei dem Apache als Modul läuft. Dennoch ist es da recht einfach Seiten ins "root" zu bekommen ohne in Konflikt mit den Rechten zu kommen. WB wird einfach in ein Unterverzeichnis des Server-roots gelegt (z.B. in das Verzeichnis "wb"), in der Konfiguration zu diesem Webspace (bei allinkl die KAS-Oberfläche) ändert man den Zeiger auf die Domäne dann auf dieses Verzeichnis. Fertig.

Matthias

P.S.
Kann auch angewendet werden wenn man parallel zu einer alten Seite eine neue mit WB anlegen will. Da kann man die alten Seiten unverändert lassen, die neuen WB Seiten in einem Unterverzeichnis komplett fertig machen und am Tag X dann einfach den Zeiger und (bei WB 2.8.x) in der config.php den Pfad ändern und alles ist gut.

[HANS 0]

- LightTPD (win32)
- MySQL 5.1.35
- PHP 5.3.4      
- WB RC5
Bitte Direktzugriff (Client) auf modules/admin.php unterbinden.
(für'n richtigen Satz hab' ich i.M. keine Zeit )

[NorHei]

Das mit dem Verschieben der /pages in Webroot war mir so noch nicht bekannt, das mit den Unterverzeichnissen scheint mir da ne gute Lösung wenn man keinen eigenen Server nutzt.
Zumal man ja von Seiten Websitebakers keinen Einfluss auf diese Schreibrechte hat.
Dann währe es wohl tatsächlich besser nur das aktuelle Verzeichniss zu überprüfen in das geschrieben werden soll, und beim Verschieben eben wieder prüfen kann ich am Zielort schreiben.
Den nicht bei jedem Hoster hat man eine der drei Optionen um im Webroot Schreibrechte zu bekommen.
Zusätzlich beugt  das Überprüfen beim Verschieben auch gleich Manipulationen vor bei denen vielleicht etwas wohin verschoben wird wo es nicht hingehört.

[instantflorian]

Hallo,

der Administrator kann bei RC 5 seine Angaben unter "Einstellungen" nicht ändern. Das Passwort wird grundsätzlich abgelehnt ("Das alte Passwort, das Sie angegeben haben, ist ungültig"). Versucht man, ein Neues einzugeben, erscheint zudem die Meldung

Warning: preg_match() [function.preg-match]: Compilation failed: missing terminating ] for character class at offset 3 in /.../admin/preferences/save.php on line 104

CMS Version 2.8.2.RC5
Revision 1394
Admin version 1.4
PHP 5.2.9

Grüße
-instantflorian.

[susigross]

Das kann ich nicht nachvollziehen.
Hast du irgendwelche ungewöhnliche Sonderzeichen im Passwort?
Schon mal mit einer sauberen Neuinstallation versucht, gibt es da das gleiche Problem?

[dbs]

für rev 1398 kann ich das nicht bestätigen, außer bei der Zeitzone.

passwortänderung auch möglich. danach erscheint meldung wie im bild.

[gelöscht durch Administrator]

[susigross]

Sehen diese Zeilen anders aus als

Code: [Select]

$pattern = '/[^'.$admin->password_chars.']/';
if( preg_match($pattern, $new_password_1) )
??

[dbs]

ich habe lediglich einige dinge bestätigt, andere nicht und seine fehlermeldung wohl überlesen.
problem damit?
ß-taste kaputt?

[instantflorian]

Hallo,

es ist eine Neuinstallation, und das allermerkwürdigste ist, dass die Passwortänderung dann trotz der Fehlermeldung klappt. Fehler tritt auch auf, wenn ein einfaches PW ohne Sonderzeichen eingegeben wird.

Grüße
-instantflorian.

[susigross]

Werner hat das gefixt in r1412

[dbs]

keine meldung mehr nun nach 1412. 
zeitzone bleibt immer auf standard.

[instantflorian]

Das ist fein, dann warte ich mal auf RC6

[Steve_O]

Hallo,

habe mit dem RC5 Rev 1394 ein kleines Problem entdeckt:
Wenn man versucht, im FCKEditor ein Bild mit einem WBLink zu versehen, erscheint die Fehlermeldung "Bitte zuerst einen Text markieren, der verlinkt werden soll!".

Kann das jemand bestätigen oder liegts an meiner Installation?

Edit: Eben gesehen, das Problem bestand in der 2.8.1 mit FCK 2.9.4 auch schon, hat also nichts mit RC5 per se zu tun...