WebsiteBaker 2.8.2 RC - Tests und Vorschläge

[testör]

Ich fang mal an, was in der 2.8.2 meiner Meinung nach enthalten sein sollte:

• Weiteres Durchsehen von bereits gemachten Änderungen des vorherigen 2.8er Strangs und evtl. einpflegen.
• FCKEditor sollte entfernt / ersetzt werden. 2011er Browser unterstützen diesen nicht mehr, vorrangig IE9 und FF4. FCKEditor wird nicht mehr erneuert, daher gibt es mit modernen Browsern keine vernüftige Demofunktion mehr, sowie das "übliche Überblick Verschaffen" von Leuten über CMS fällt flach, wenn kein Text mehr eingegeben werden kann.
• Module wie Droplets, Show_Menu2 usw. auf neuesten Stand bringen.
• jQuery usw. auf neuesten Stand bringen.

[FrankH]

Ich mache mal weiter:

• Sicherheitslücken beseitigen (wenigstens die vielen, wo das ohne großen Aufwand möglich ist.)

[chio]

Ging problemlos, was ich auf den ersten Blick sehe.

Zu "neuestes jQuery rein": Ich hab vor ein paar Tagen bei einer Site auf die neueste Version aufgerüstet - das machte ganz schön Ärger. Viele Plugins waren nicht mehr ganz kompatibel und mussten ebenfalls upgedated werden. Die widerum brauchen aber plötzlich andere Parameter. Ich hab ganz schön herumschauen müssen, bis wieder alles so halbwegs lief...

[instantflorian]

Hallo,

mein Wunsch:

Updatescript (2.7 => 2.8.2) fixen, sofern noch nicht geschehen
Und ja, FCK raus und CKEditor rein

Viele Grüße
-instantflorian.

[Stefek]

Hallo,

dadurch, dass der Ordner [root]/admin/images entfernt wurde, funktioniert die Darstellung der Icons in einigen Modulen nicht mehr.
Klar, es ist die "Verantwortung" der Modulautoren, sich darum zu kümmern, die THEME_URL richtig zu setzen.

Aber: dieser Ordner wurde ohne richtige Bekanntmachung entfernt und zwar nach dem der 2.8.x schon lange draussen war.
Es wäre gut, diesen Ordner als Fallback in der 2.8er Reihe noch drin zu haben.

Gruß,
Stefek

[Hans Toolbox]

Sind statt neuer Features erstmal alle Fixes in der RC2, wäre das schon viel, und eine Frage stellt sich danach: Wer arbeitet die Liste (wo ist diese) ab, um zu prüfen, ob die angegebenen Bugs nun auch beseitigt sind? Ohne systematisches Vorgehen ist der Test für die Tonne.

Bei SM2 ist noch eine Frage offen

[Luisehahne]

Sind statt neuer Features erstmal alle Fixes in der RC2,

neue Features kommen nicht rein, nur die Fixes. Da müsst ihr mir einfach vertrauen. Hab da schon mein eigenes Konzept.  

admin/images wird wieder eingefügt, macht Sinn, wurde ja bereits in 2.8.1 vergessen zu entfernen.

Bei SM2 ist noch eine Frage offen Jetzt nicht mehr

Dietmar

[BlackBird]

Zu "neuestes jQuery rein": Ich hab vor ein paar Tagen bei einer Site auf die neueste Version aufgerüstet - das machte ganz schön Ärger. Viele Plugins waren nicht mehr ganz kompatibel und mussten ebenfalls upgedated werden.

Das kann ich bestätigen. Vor allem der Sprung auf 1.4.4 hat vielen Plugins weh getan. Trotzdem macht es Sinn, die Uralt-Version von jQuery im Core zu aktualisieren.

[testör]

So, eine erste Teststaffel mit 2.8.2 Rev. 1354. Neuinstallation.

Server: PHP 5.2.9, phpinfo: http://dd6126.kasserver.com/infophp.php

Installation
- Website Baker -> WebsiteBaker (einfaches Suchen & Ersetzen)

Seite erstellen
- WYSIWYG, Keine übergeordnete, Öffentlich
-

Beim Anlegen der Zugangsdatei im Verzeichnis /pages ist ein Fehler aufgetreten (Ungenügende Zugangsrechte)

- Siehe nach FTP: Keine Datei angelegt. Allerdings Ordner "posts" mit index.php vorhanden. => Schreibrechte vorhanden, da dieser nicht hochgeladen wurde.
- Sowohl Menüpunkt als auch in Seitenübersicht Seite vorhanden.
- "Abschnitte verwalten" -> Kein Abschnitt angelegt.
- Wenn erste Seite überhaupt: Abschnitt anlegen, Seite vorhanden (wohl, da index.php hochgeladen).

Sofern Übergeordnete Seite vorhanden:

Warning: mkdir() [function.mkdir]: Permission denied in /www/htdocs/***/framework/functions.php on line 212

Vermutung:
Da Ordner 777, aber Besitzer FTP-User wird "pages" Ordner nicht korrekt übertragen. Ebenso alle anderen (Module, Template, Media, Tmp, usw.) sind auf FTP-User. Modulinstallation, Templateinstallatio n und Medien (Ordner & Dateiupload) allerdings fehlerfrei.
2.8.1er Installationen auf selbem Server fehlerfrei. Die Ordner müssen wie in 2.8.1 und vorhergehend auf PHP-User automatisch umgestellt werden.

Deutsche Frontend-Registrierung:
- E-Mail Betreff "Deine WB Logindaten ...", allerdings E-Mail selbst formal. Vorschlag: "Ihre Logindaten".
- Kein Link zur Installation - WB_URL wäre sinnvoll einzubauen.
- Fehlermeldung nach Registrierung im Frontend

Strict Standards: date() [function.date]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezo ne_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in /www/htdocs/***/include/phpmailer/class.phpmailer.php on line 1632

Strict Standards: date() [function.date]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezo ne_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in /www/htdocs/***/include/phpmailer/class.phpmailer.php on line 1636

[testör]

Noch etwas zu Installation & Login:

/install/safe.php, Zeile 770 ff.

Code:

"MAX_ATTEMPS" => "50",
[...]
"MIN_USERNAME_LEN" => "2",
"MIN_PASSWORD_LEN" => "2",

/account/login.php, Zeile 52 ff.

Code:

"MAX_ATTEMPS" => "3",
[...]
"MIN_USERNAME_LEN" => "2",
"MIN_PASSWORD_LEN" => "2",

/admin/login/index.php, Zeile 42 ff.

Code:

"MAX_ATTEMPS" => "3",
[...]
"MIN_USERNAME_LEN" => "2",
"MIN_PASSWORD_LEN" => "2",

Alles ändern zu:

Code:

"MAX_ATTEMPS" => "3",
[...]
"MIN_USERNAME_LEN" => "3",
"MIN_PASSWORD_LEN" => "6",

Benutzernamen sollten mind. 3 Zeichen, Passwörter mind. 6 Zeichen (eher mehr) lang sein. Zudem sind unterschiedliche Handhabungen von Max_Attemps nicht sinnvoll.

Bei der Neuerstellung natürlich noch eher anpassen:

/account/signup2.php, Zeile 44 ff.

Code:

if(strlen($username) < 3) {
$wb->print_error($MESSAGE['USERS']['USERNAME_TOO_SHORT'], $js_back, false);
}

Hier ein "< 4".

Bei der Install wird keinerlei Zeichenbeschränkung vom Adminnamen bzw. Passwort verlangt. Hier sollte unbedingt auch Benutzername minimum 3 Zeichen, Passwort min. 6 Zeichen zutreffen.

Sinnvoller wäre natürlich alles zentral, aber das ist was für 2.9.

Nachteil natürlich: Benutzer die angemeldet sind können nicht mehr sich einloggen. Es werden nur wenige sein, aber die "gefühlte" Sicherheit ist zumindest höher. Hier muss dann der Admin Hand anlegen.

[Luisehahne]

Nachteil natürlich: Benutzer die angemeldet sind können nicht mehr sich einloggen. Es werden nur wenige sein, aber die "gefühlte" Sicherheit ist zumindest höher. Hier muss dann der Admin Hand anlegen.

Deswegen mein Vorschlag, den index login nicht verändern sondern nur die save.

Dietmar

[Luisehahne]

Trotzdem macht es Sinn, die Uralt-Version von jQuery im Core zu aktualisieren.

Zurzeit ist jquery 1.4.2 eingebunden. Frage an die Community, ob auf die 1.4.4 upgedated werden soll.

Dietmar

[testör]

Nachteil natürlich: Benutzer die angemeldet sind können nicht mehr sich einloggen. Es werden nur wenige sein, aber die "gefühlte" Sicherheit ist zumindest höher. Hier muss dann der Admin Hand anlegen.

Deswegen mein Vorschlag, den index login nicht verändern sondern nur die save.

Dietmar

Ja, für die 2.8xer besser. Sollte dann aber überall angepasst sein (in der preferences ist es auf jeden Fall, User & Groups weiß ich gerade nicht).

Trotzdem macht es Sinn, die Uralt-Version von jQuery im Core zu aktualisieren.

Zurzeit ist jquery 1.4.2 eingebunden. Frage an die Community, ob auf die 1.4.4 upgedated werden soll.

Dietmar

Würde ich auf jeden Fall. Evtl. jQuery noch als 1.4.2er jquery-min142.js mitliefern - aber die wird kaum einer benutzen, daher lieber ganz raus und aktuell. Ebenso jQ UI.

[DarkViper]

Zu "neuestes jQuery rein": Ich hab vor ein paar Tagen bei einer Site auf die neueste Version aufgerüstet - das machte ganz schön Ärger. Viele Plugins waren nicht mehr ganz kompatibel und mussten ebenfalls upgedated werden.

Das kann ich bestätigen. Vor allem der Sprung auf 1.4.4 hat vielen Plugins weh getan. Trotzdem macht es Sinn, die Uralt-Version von jQuery im Core zu aktualisieren.

jQuery Upgrade prinzipiell ja.
Ob das jetzt dann gleich die 1.4.4. ist, steht dabei noch auf einem anderen Blatt. Klar, für alle, die sich mit jQuery auskennen und intensiv damit arbeiten wäre das kein größeres Problem.
WB wird jedoch nicht ausschließlich von jQuery-Cracks genutzt, sondern von sehr vielen Anwendern, die sich auf eine volle Funktionalität verlassen und selbst nicht in der Lage sind, die notwendigen Anpassungen durchzuführen. Es darf nicht passieren, dass diese Nutzer nach einem Upgrade im Regen stehen und ihre Plugins etc. plötzlich nicht mehr funktionieren.

Daher mein Vorschlag: 

• Upgrade auf die letzte Version (evt. 1.4.3 ?) unter der die Plugins noch stabil laufen.
• Überarbeiten aller Plugins, so dass sie ohne Anpassungen auf 1.4.4 lauffähig sind
• nach einer gründlichen Testphase dann upgrade auf 1.4.4

Es spricht absolut nichts dagegen, dass die jeweils neueste Version installiert wird, jedoch sollte vorher zwingend sichergestellt sein, dass sich daraus für 'normale' User keine Probleme ergeben.

[testör]

Nachtrag zu Frontend Registrierung. Rev. 1354 (es gibt schon Rev. 1355 - ich finde es übrigens wirklich super, dass FrankH wieder aktiv mitarbeitet und es so jemand gibt, der mehrere Augen auf die Sicherheit hat).

Wird alles angelegt, E-Mail verschickt usw.
Aber zu den Strict standards: date() Meldungen gibt es unten im Template noch folgendes (nicht gesehen, da schnell wieder weg ist):

Notice: Undefined property: wb::$page_id in /www/htdocs/***/framework/frontend.functions.php on line 477
Fatal error: Call to a member function fetchRow() on a non-object in /www/htdocs/***/framework/frontend.functions.php on line 481

Template ist Standard-Round, URL /account/signup.php.

[DarkViper]

E_DEPRECATED Fehler werden wir für die 2.8.x noch weitestgehend beseitigen,
E_STRICT Meldungen jedoch nicht mehr unbedingt.


Ab der 2.9.x ist jedoch das verhindern von E_DEPRECATED Pflicht (Core und Module) und E_STRICT nach Möglichkeit ebenso.

[dbs]

Es darf nicht passieren, dass diese Nutzer nach einem Upgrade im Regen stehen und ihre Plugins etc. plötzlich nicht mehr funktionieren.

genau.
aber wer sagt, dass mit jquery 1.4.3 alles ganz genau so läuft wie mit der vorgänger-version.
im prinzip ist das ein fall für einen patch. wer es braucht, patcht. vor allem kann derjenige dann auch wieder auf eine ältere version patchen, falls es nicht läuft.
klingt wie bei einem modul 

[Hans Toolbox]

E_STRICT Meldungen jedoch nicht mehr unbedingt.

Soweit ich erinnere gab es in den mitgelieferten Modulen (auch in 2.8.1) keine strict-Fehler mehr

E_DEPRECATED Fehler zu beseitigen ist schon länger überfällig. Zumindest im Core und in den mitgelieferten Modulen sollte derartiges in 2.8.2 nicht mehr drin sein. (war ja auch schon wech)

Den Rest müssen schon die Modulautoren "auf die Reihe kriegen". PHP 5.3 ist ja nun schon lange genug "auf dem Markt"

[ChrusR]

Daher mein Vorschlag: 

• Upgrade auf die letzte Version (evt. 1.4.3 ?) unter der die Plugins noch stabil laufen.
• Überarbeiten aller Plugins, so dass sie ohne Anpassungen auf 1.4.4 lauffähig sind
• nach einer gründlichen Testphase dann upgrade auf 1.4.4

Es spricht absolut nichts dagegen, dass die jeweils neueste Version installiert wird, jedoch sollte vorher zwingend sichergestellt sein, dass sich daraus für 'normale' User keine Probleme ergeben.

Die "nicht im Forum aktiven WB-Nutzer" und auch ich danken für diese Gedankengänge. WB's Stärke soll hoffentlich bleiben, dass nicht nur sehr aktive Insider damit viel erreichen können.

[DarkViper]

aber wer sagt, dass mit jquery 1.4.3 alles ganz genau so läuft wie mit der vorgänger-version.
im prinzip ist das ein fall für einen patch. wer es braucht, patcht. vor allem kann derjenige dann auch wieder auf eine ältere version patchen, falls es nicht läuft.

patchen können evt. die User hier im Forum, die sich ausgiebig mit jQuery beschäftigen. Der 'Otto-Normalverbraucher' kann das nicht. Für den ist die jQuery-Funktionalität ein Bestandteil des Komplettsystems und wenn er dieses upgraded, erwartet er dass auch diese Funktionen ohne weiteres Rätselraten funktionieren.
Anwender != Codierer != Programmierer ==> assoziiert mit dem Begriff Java(script) allerhöchstens eine Ferieninsel...  oder eine Kaffeebohne. 

Was die Version angeht, die habe ich bewusst freilassend mit ? angegeben. Das sollte Aufgabe der jQ-Spezis sein, dafür zu sorgen dass die jeweiligen Updates/Upgrades stabil laufen  .... ohne zusätzliche Patches ....

@Hans Werkzeugkiste:
den 'alten' Zustand werden wir die nächsten Wochen vollends wiederherstellen (soweit noch nicht geschehen)

[testör]

Naja, bei jQuery Sprung von 1.3.2 (WB 2.8.0) auf 1.4.2 (WB 2.8.1) hat sich auch keiner beschwert. Warum soll jetzt genau der Sprung auf 1.4.4 so große Probleme bereiten? Wenn wirklich, dann lässt man es halt beim Alten - so alt ist 1.4.2 nun wirklich nicht. Ist auch wurscht - wer auf Nummer sicher gehen will bindet einfach die jQ Datei extern ein.  Übrigens ist 1.4.3 http://blog.jquery.com/2010/10/16/jquery-143-released/ der "Übeltäter".

Wo wir gerade bei JavaScript sind: FCKEditor sollte wenn er beibehalten wird mind. auf 2.6.6 upgedatet werden.

Zudem: "Fatal Error" hat nichts mit E-Deprecated zu tun. Wollte es nur sagen. Das ist ein ganz anderes Kaliber, und da ist wohl ein eindeutiger Fehler irgendwo. Denn einen Fatal Error sieht jeder, egal welchen Errorlevel man gerade hat.

[Luisehahne]

Ich meine da sollte uns Bianca etwas zu sagen können.

Dietmar

[Luisehahne]

So damit jeder die gleiche Version testet, haben wir soeben dir 2.8.2 RC2 zum Download freigegeben. Jetzt geht es an die nächsten Fixes.

@Michael
schick mir bitte mal deine Datenbank, bekomme den Fehler mit Anlegen von untergordneten Seiten nicht reproduziert

Dietmar

[dbs]

1356 Media-Ordner:
argos_theme: es ist ein Unterschied ob ich Bilder per FTP oder per Media hochlade.
Die Vorschaufunktion zeigt die Farben stark reduziert bei Bildern die über Media hochgeladen wurden.
Auch die Funktion um die Größe der hochgeladenen Bilder zu begrenzen, liefert dann nur Bilder mit geschätzen 16 Farben, aber das Resizing funktioniert (egal ob nur Breite als Wert angegeben wurde oder beides).

[testör]

@Michael
schick mir bitte mal deine Datenbank, bekomme den Fehler mit Anlegen von untergordneten Seiten nicht reproduziert

Ist wie gesagt nur auf Servern, wo PHP nicht in CGI läuft, also FTP / PHP User Unterschied macht - All-Inkl ist hier wohl der übliche. Es gibt natürlich einen Weg drum herum, aber genügend Leute haben halt solche Webspaces.
Werde noch mal mich versichern und dann dir eine Nachricht zukommen lassen.

Edit: Achja -bitte einen Blick auf http://www.websitebaker2.org/forum/index.php/topic,20331.msg137428.html#msg137428
Der Fix zur Validierung von E-Mails in der class.wb.php wäre evtl. auch was.