WebsiteBaker RC6 Rev 1452

[testör]

So, kurzer Test. EasyPHP unter Win7, PHP 5.3.6, MySQL 5.5.10, Apache 2.2.17.

Neuinstallation durchgelaufen, RC7 Rev. 1472.

Der Hinweis nach der Installation "Entfernen upgrade-script.php" müsste umformuliert werden. Vorschlag: "upgrade-script.php bitte vom Webserver löschen".

Beim Erstellen einer neuen Seite kommt die Meldung Screenshot Nr. 1. Seiten werden damit nicht neu erstellt - ebenfalls auch keine Dateien in /pages.
Ebenfalls beim Upload jeglicher Dateien in /media.
Richtig lustig werden die Fehlermeldungen beim Erstellen eines neuen Ordners in Media - siehe Screenshot Nr. 2.

Grundsätzlich geht keine einzige Benutzeraktion. Daher kann ich auch nicht wirklich Testen.

Unter "Einstellungen" ist überhaupt nicht ersichtlich, dass bei jeder Änderung "mit aktuellem Passwort bestätigen:" ausgeführt werden muss. Logisch gehört es zum Erstellen eines neuen Passworts. Dies muss - wie schon einmal gehabt - unbedingt z.B. mittels einer <hr> und einer zusätzlichen Erklärung wie "Jede Änderung mit aktuellem Passwort bestätigen" für WB-Benutzer ersichtlich werden.

[Luisehahne]

Hallo,

Sicherheitsmeldung in der Seitenerstellung kann ich trotz Neuinstallation nicht feststellen. Mal einen anderen Browser probieren. FireFox zickt ab und zu rum.

Fehler beim Erstellen eines neuen Ordner in der Mediaverwaltung ist gefunden.

Werde jetzt doch mal wieder in die SVN hochspielen, da bei persönlichem Testen noch einige Fixes nötig waren.

Danke aber fürs Testen. So grobe Fehler wie in der Mediaverwaltung sollten natürlich in einer Stable nicht vorkommen.

Dietmar

[testör]

Hallo,

also die Sicherheitsmeldunge n sind Browserabhängig. Übrigens egal wo - der Hund liegt in der Zeile 156

Code:

if( $_SESSION[$this->_ftan_name] && (strlen($_SESSION[$this->_ftan_name]) == strlen(md5('dummy'))))

Das Problem ist übrigens auch anderen schon passiert, z.B. http://bugs.typo3.org/view.php?id=12466

Chrome lässt generell den FTAN-Check nicht zu. Wenn es jetzt ein Exot wie Opera oder IE7 wäre würde ich nichts sagen, aber Chrome (und daher wohl Webkit-Browser generell)  ist ja kein Unbekannter.
http://gs.statcounter.com/
http://marketshare.hitslink.com/browser-market-share.aspx?spider=1&qprid=0

Auf die Schnelle habe ich allerdings keine Lösung. Mit einem utf8_decode bringt man zwar die PHP-Fehlermeldung weg, aber das war es auch schon. Man müsste wohl oder übel einen Unittest laufen lassen, der die Werte der Browser analysiert. 20% der Benutzer auszuschließen sollte man gerade bei einer Stable nicht unbedingt in Betracht ziehen. Gerade wenn ein solch essentielles Thema Browserabhängig zu sein scheint. Man weiß ja nie, was Firefox 7 und IE10 alles bringen - Alphas gibt's von beiden ja schon.
Überall ist die FTAN übrigens auch nicht wirkungsvoll - z.B. beim Hinzufügen von Abschnitten einer vorhandenen Seite werden diese nicht durch die FTAN geprüft und abgespeichert. Der - grundsätzlich wirkungslose - "Speichern" Button allerdings wird geprüft.

Übrigens wäre es - wegen dem FCKeditor - sinnvoll, zumindest bei wichtigen Seiten in den IE8-Modus zu schalten, der den IE9 in den Kompatibilitätsmodus zwingt.
Laut http://blogs.technet.com/b/iede/archive/2010/06/22/ie8-compatibility-view-wie-kann-manuell-serverbasiert-oder-per-policy-das-verhalten-beeinflusst-werden.aspx

Code:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8"/>

sollte passen.

[mr-fan]

In Zusammenarbeit mit Dietmar hier ein Login-Droplet mit redirect-Möglichkeit.
Einmal für copy&paste die php.txt
oder
für Import das Droplet-Zip.

Aufruf z.B. so:
[[LoginBox2?redirect=http://......]]
oder
[[LoginBox2?redirect=/pages/......]]

Für alle anderen wäre zu erwähnen das es damit auch klappt...in einer Code² Section (2.8.2 Rev. 1452)

Code:

<?php //alles bunt
         echo "<form style='padding-left:60px' action='".LOGIN_URL."' method='post'>\n";
                echo "<input type='hidden' name='url' value='".$_SERVER['HTTP_REFERER']."' />\n";
            echo "<fieldset style='width:300px'>\n";

nutze das für einen Login per Loginzeile zum direkten Frontendbearbeiten $_SERVER['HTTP_REFERER'] mit einer Adresse ersetzen auf die man weiterleiten will.....kann man auch nach unterschiedlichen Usergruppen ändern....usw.

Vielen Dank Frank + Dietmar für diese Lösung mit dem input feld!

Gruß Martin

[Luisehahne]

Hallo,

ich habe das Droplet noch mal überarbeitet. Sollte kein redirect angegeben werden, versucht die LoginBox wieder auf die Seite weiterzuleiten, von der es aufgerufen wurde. Bitte beachten! Das Droplet läuft nur mit der WB 2.8.2, da es dort die von uns erweiterten Funktionen benutzt.

Dietmar

[Luisehahne]

Sollte jetzt jemand fragen, wann die 2.8.2 stable kommt, so kann ich nur mitteilen, dass wir ganz kurz davor stehen.

Statt während der Entwicklung zu testen, erfolgten die intensiven Tests durch neutrale Anwender leider erst nach den letzten Ankündigen. Wir haben zwar zwischendurch die Entwicklungsstufen von unseren Stammtestern checken lassen, aber die Tests von Unabhängigen ergeben manchmal andere Sichtweisen.

Neben allen Testern möchte ich auch Michael für seine konstruktiven Posts danken. So arbeiten wir seit Tagen hart daran, 2.8.2 immer sicherer und stabiler zu bekommen. Wir haben soweit alle bekannten Szenarien (Exploits) abfangen können.

Aus meiner Sicht macht es keinen Sinn eine stable zu veröffentlcihen, die sofort wieder gepatcht werden muss. Sicherlich kann das kein Entwickler garantieren. Ich verspreche aber jetzt und hier, dass es wirklich nicht mehr lange dauert, da bereits einige 2.8.2 Pakete im produktiven Einsatz zufriedenstellend laufen. Wenn man sich das letzte SVN (1473) anschaut, ist bereits nachgearbeitet worden und bei mir liegt wieder ein grosser Teil an Fixes und updates bereit zum Hochspielen.

Bitte habt noch ein paar Tage Geduld und keine Diskussionen. Machen wir uns lieber Gedanken, wie umfangreiche Tests rechtzeitig ablauf6en sollten, damit auch Termine eingehalten werden.

War jetzt ein bisschen Offtopic und danke für eurer Verständnis

Dietmar

[BlackBird]

Ja, wir wissen ja schon, die Community ist Schuld, daß es so lange gedauert hat.

[Stefek]

Aus meiner Sicht macht es keinen Sinn eine stable zu veröffentlcihen, die sofort wieder gepatcht werden muss. Sicherlich kann das kein Entwickler garantieren. Ich verspreche aber jetzt und hier, dass es wirklich nicht mehr lange dauert...

Gut, das freut mich.
Muss nämlich bald eine neue Installation machen und da würde ich gerne von Anfang an auf die 2.8.2 setzen.
Hat jetzt auch lange genug gedauert.
Es spricht ja nichts dagegen, einige extra Features für eine 2.8.3 aufzusparen.
Der übergang auf den 2.9.0 wird ja extremer.

Macht also nicht mehr so kompliziert mit den 2.8.x

Viele Grüße,
Stefek

[testör]

Zur FTAN Sache:

Ich habe jetzt alles mögliche ausprobiert, und es ist immer die Kombination Google Chrome & EasyPHP 5.3.6.0 (PHP 5.3.6 VC9 + Apache 2.2.17 VC9 + MySQL 5.5.10).

Wo das Problem steckt weiß ich aber nicht.

An der PHP.ini liegt es nicht. "session.use_only_co okies = 0" ändert auch nichts.
Am Port (EasyPHP läuft ja per Standrad unter 8888) auch nicht - XAMPP unter Port 234 macht keine Probleme.

Jedenfalls laut http://www.php.net/manual/de/function.strlen.php#98315 soll es ja hier ein Problem geben.

Code:

<?php
$attributes = array('one', 'two', 'three');
if (strlen($attributes) == 0 && !is_bool($attributes)) {
    echo "We are in the 'if'\n";  //  PHP 5.3
} else {
    echo "We are in the 'else'\n";  //  PHP 5.2
}
?>

Und das kommt der checkFTAN function doch ein wenig nahe.

Zum Thema testen: Das ist ein weites Feld. Mal so eben einen gescheiten Testlauf aus dem Hut zaubern klappt nicht. An fehlenden Tests in der IT verdienen Millionen von Menschen ihr tägliches Brot.
Prinzipiell würde schon ein fest definierter Testparcour ausreichen. Und um Himmels Willen nie mehr die Fehler machen, am Tag vor dem Release (oder besser: eine Stunde vorher) noch Bugs fixen!!! Das kann man mit der 2.8.2 übrigens schon angehen. Lieber eine Version mit bekannten Bugs raushauen als mit einem ungetesteten Hotfix in letzter Sekunde sich das ganze Release zu versauen.

[pcwacht]

Wo das Problem steckt weiß ich aber nicht.

Ich hoffe ich kan es erklaren:

Das problem liegt am änderte manier wie php mit strlen umgeht
vor php 5.3 alles wass geschickt werde zu strlen wird als string(!) convertiert befor es durchgegeben wurde
seit php 5.3 nicht mehr. Ain array bleibt ein array, wurde keine string mehr.
Da ist ein neuer parsing api die das macht.

So laut die fehler auch:
Warning: strlen() expects parameter 1 to be string, array given in E:\xampp-nw\htdocs\wb282\framework\SecureForm.php on line 156
Er erwartet ein string aber ain array ist angeboten.
Soll passieren mit jeder php 5.3 installation

Die falsche linie:
if( $_SESSION[$this->_ftan_name] && (strlen($_SESSION[$this->_ftan_name]) == strlen(md5('dummy')))
Da sind zwei strlen drin einer oder beider ist ein array und nicht nur ein string.

Gruss,
John

[testör]

Danke John.

Das Problem ist: Bei mir ist der Fehler nur mit Chrome und EasyPHP.
Nicht mit IE9, nicht mit Firefox 5.
Nicht mit Chrome & IE9 & Firefox 5 in XAMPP oder auf einem Online-Webspace. 

[pcwacht]

Ich hatte gleiches mit xampp, win7 mit ie8 und ie9, winxp mit ie7, auch einmal mit ff aber weiss nicht mer welches auf welches windows.

es ist doch ein php fehler. kommt von webserver mit php 5.3

Ich soll es wieder mehrmales testen und sehen ob ich etwas findet.

John

[testör]

So, nun ein wenig umfangreicherer Test mit der neuesten Rev 1476 auf EasyPHP (andere Test folgen noch).

Zuerst bin ich wirklich positiv überrascht worden - die FTAN Fehler sind alle weg unter Chrome. Unter IE9 und Firefox ja sowieso.

Ein kleiner Fehler hat sich in das Droplet "LoginBox" eingeschlichen. Die ersten beiden Zeilen brauchen eine Auskommentierung.
Die Änderungen im Mediencenter - z.B. per Standard besseres Blacklisting - klappen ebenfalls, auch aus .zip Dateien.
Die Debug-Zeile am Ende könnte man allerdings wieder entfernen bzw. ausblenden.

Grundsätzlich würde ich jetzt die Rev. 1476 als Stable ansehen. Allerdings möchte ich noch mind. einen Upgrade durchführen und auch Online testen.

Edit: Noch eine Sache. Die Blacklist in den Mediadateien sorgt dafür, dass grundsätzlich nichts hochgeladen wird mit der eingetragenen Dateiendung. Allerdings heißt die Option "Datei nach Hochladen umbenennen:". Das sollte man nicht so stehen lassen. "Folgende Dateitypen nicht hochladen:" wäre besser.

[dbs]

Grundsätzlich würde ich jetzt die Rev. 1476 als Stable ansehen. Allerdings möchte ich noch mind. einen Upgrade durchführen und auch Online testen.

Ist es nicht sinnvoller mehr Energie auf Online und Upgrade zu verwenden als auf EasyPHP?
Die Reihenfolge/Priorität ist mir nicht ganz verständlich.

[testör]

Ist es nicht sinnvoller mehr Energie auf Online und Upgrade zu verwenden als auf EasyPHP?
Die Reihenfolge/Priorität ist mir nicht ganz verständlich.

Ich teste es so wie ich es gelernt habe. Wenn gar nichts geht kann man das als Bug einstufen. Oder ist das neuerdings ein Feature, das man als gegeben hinnehmen muss?
Und wenn du meinen ersten Satz im Beitrag gelesen hast wirst du feststellen, dass es mittlerweile klappt. Ob nun EasyPHP oder ein verweichlichtes XAMPP nimmt sich nun wirklich gar nichts. Ich habe lieber ein restriktives System zum Testen als eines das alles frisst. Im übrigen kennst du bestimmt nicht mein Testparcour. 

[dbs]

Ich bezog mich auf das Zitierte in dem du sinngemäß sagst, dass es jetzt stable sein müsste, weil es bei dir auf EasyPHP läuft.
War nur eine Frage ... nothing for ungut.

[testör]

Ich bezog mich auf das Zitierte in dem du sinngemäß sagst, dass es jetzt stable sein müsste, weil es bei dir auf EasyPHP läuft.

So meinte ich das auch. Alle anderen - bislang nicht erwähnten Test-Konstellationen - habe ich ja der Übersicht wegen nicht aufgeführt.  Es geht ja nur um die Showstopper. Und jetzt noch auf irgendwelche Sachen zu warten bringt wenig.
Ich wünsche mir nur, dass es zwei - drei Tage vor Stable Release eben ein definitives Paket gibt das nicht mehr - unter KEINEN Umständen - verändert wird und genauso wie es ist - selber MD5-Wert - als späterer Download freigegeben wird. Das ist so üblich und hilft zumindest vergessene Dateien und andere wirklich heftige Fehler zu bereinigen. Kleine Bugs sind dann eh schon wurscht - irgendwann muss man rausgehen.

[ruebenwurzel]

Hallo,

hab jetzt auch mal die RC7 1476 getestet. Hab noch ein paar Dinge, die mir nicht gefallen:

1) DE.php Zeile 569

Code:

$MESSAGE['PREFERENCES_CURRENT_PASSWORD_INCORRECT'] = 'Das alte Passwort, das Sie angegeben haben, ist ung&uuml;ltig';

Bitte das wort "alte" streichen. Wenn man zur Bestätigung von Änderungen in den Einstellungen ein falsches Passwort eingiebt, ist die Fehlermeldung mit "alt" irreführend.

2.) neue Schriftgrößen im backend:
Die Schriftgröße des Menüs im Backend und der Revisionsnummer scheint mir ein bisserl zu groß, das sieht nicht sehr proffesionell aus (meiner Ansicht nach). Vorher hat sich das besser in das Gesamtbild eingefügt.

3.) Überschriften der verschiedenen Backendseiten sind unterschiedlich:
z.B. auf der Seiten Seite. Die erste Überschrift "Seiten ändern/Seiten löschen" ist kleiner als weiter unten die Überschrift für "Seiten hinzufügen". Dieses Durcheinander zieht sich durch alle Seiten. Mal groß oben, mal groß unten. Das ganze sollte aufeinander abgestimmt werden.

Ansonsten ist mir nix mehr aufgefallen. Das ganze sieht schon ziemlich nach ner Stable aus. 

Matthias