Tests & Probleme der SVN Revision 1374 - 2.8.2 RC

[HANS 0]

Nach Update auf Revision 1458 (keine separate Neuinstallation)
>Benutzerverwaltung
Angemeldet als admin (einziger Account)
>Gruppen hinzufügen

Ob nun nichts angewählt, oder Zugangsberechtigung en: z.B. Seiten

Beim Anlegen eines Gruppennamens gibt es eine Fehlerausgabe
Der Gruppenname wurde nicht angegeben
oder
Beim Speichern der Seite ist ein Fehler aufgetreten

------------------------------
Bei Revision 1451 (separate Neusinstallation) dasselbe

[Luisehahne]

Kannst du mal bitte mit einem anderen Browser als FF versuchen, ob der Fehler dann auch noch  auftritt. Ich nehme mal an dass du mit FF testet.

Dietmar

[dbs]

im FF kommt die meldung: gruppenname wurde nicht angegeben
im IE die meldung: beim speichern der seite ist ein fehler aufgetreten

[HANS 0]

Opera und IE8 dasselbe
FF benutze ich nur wenn Tools und funktionierende Cache-Abschaltung gebraucht werden

[Luisehahne]

Es gibt nichts schlimmeres als Fehler die bei mir und Werner nicht auftreten. Ruebenwurzel hat dasselbe Problem, allerdings nur mit FF.

Aber die Hoffnung stirbt zuletzt. Wir alle zusammen werden dem Problem auf die Spur kommen. Vielleicht hat ja jemand bereits ähnliche SChwierigkeiten gehabt und weiss die Lösung. Muss ja nicht unbedingt an WB liegen.

Dietmar

[HANS 0]

Bei der Revision 1451 auch mal Anlegen Benutzer gecheckt (mit Safari),
hier ohne Anwahl einer Gruppe (außer Admin nix)

Notice: Undefined index: groups in \html\282\admin\users\add.php on line 33
Warning: implode() [function.implode]: Invalid arguments passed in \html\282\admin\users\add.php on line 33

[Waldschwein]

Es gibt nichts schlimmeres als Fehler die bei mir und Werner nicht auftreten. Ruebenwurzel hat dasselbe Problem, allerdings nur mit FF.

Aber die Hoffnung stirbt zuletzt. Wir alle zusammen werden dem Problem auf die Spur kommen. Vielleicht hat ja jemand bereits ähnliche SChwierigkeiten gehabt und weiss die Lösung. Muss ja nicht unbedingt an WB liegen.

Dietmar

Mein ausführlicherer Test auf einer der vorherigen Seiten zeigt übrigens auch, dass ich genau dasselbe Problem habe, und zwar auf zwei komplett unterschiedlichen Systemen - also muss es an WB liegen, sonst wird man ja verrückt, wenn man 90% der Benutzer ausschließt, WB nutzen zu können die es bislang aber konnten.
Übrigens benutze ich Chrome 5 / FF3.6 / IE8 / IE7 / IE6 / IE9 Prev. für die Tests - also der Browser ist es nicht.

Gruß Michael

[HANS 0]

Weiß jemand, ob es 'nen Webgucker mit einer Scriptsprache gibt, oder eine vergleichbare Lösung?
Hintergrund: Batch für die Tests, also für Eingaben, Abfragen etc anlegen, womit man sicher nicht nur Zeit sparen würde, sondern alle Tests auch konsequent wiederholt werden könnten.

[Waldschwein]

http://de.wikipedia.org/wiki/Greasemonkey

Wenn das nicht ausreicht, muss PHPUnit herhalten, das man eigentlich als Schnittstelle gleich in den Core einbauen könnte, machen ja mittlerweile fast alle Softwares.

Gruß Michael

[HANS 0]

Danke für die Tips
Kann ich FF ja wieder was neues beibringen  
(oder gegebenenfalls auch anderen)

PHPUnit hatten/haben die Sicherheitchecker (Du weißt >Firma< )

[Waldschwein]

Danke für die Tips
Kann ich FF ja wieder was neues beibringen  

Gerne. Wenn einem das Backend-Theme von WB nicht gefällt, man aber keinen Zugang zu dem FTP-Daten hat kann man sich ja einfach lokal ein Backend-Theme seiner Wünsche mit den Programmen zusammenbasteln. Geht dann auch für alle WB-Installationen.  Oder JavaScript Erweiterungen.
Ist natürlich sinnlos, aber viele Leute fahren auf sowas ab, z.B. dass Youtube knallrosa anstatt grau ist.

Dass PHP-Unit aber noch keinen Einzug gehalten in die SVN wundert mich schon ein wenig, es würde viele Fehler im Vorfeld ausmerzen - zumindest für die Entwickler eine sehr interessante Sache.
Hier kurze Info, was das ist, warum auch ohne WB 3 sondern mit WB 2.8.x usw: http://www.trueorfalse.de/phpunit-und-ich/

Gruß Michael

[HANS 0]

Selenium IDE
scheint das Mittel der Wahl zu sein.
Es scheint genau dort anzusetzen wo gewünscht, nämlich nicht beim Entwickler, sondern beim Enduser/WB-Admin/Web-Designer/Tester.
Anbindung an PHP-Unit ist möglich
Ob Makros wie gewünscht greifen, müßte bzw. muß noch getestet werden. Ein kurzer Einblick scheint dies aber zu bestätigen.

[Waldschwein]

Hallo!

Ich werde nicht schlau aus dem "Nicht Gruppen anlegen".
Revision 1436 funktioniert bei mir, 1459 / 1451 nicht.
Trac hat ja die Möglichkeit, alles darzustellen
(wer will und sich mal einige Sekunden / Minuten gedulden kann bis es aufgebaut ist: http://project.websitebaker2.org/changeset?new=1459%40branches/2.8.x/wb&old=1436%40branches/2.8.x/wb#file0 )

Scheuklappe

Gruß Michael

[DarkViper]

Problemorientierte Scheuklappen absetzen und den Code in die Tiefe zu Ende verfolgen... dann erübrigt sich jede Erklärung. (nicht auf halber Strecke aufhören...)

[Waldschwein]

Hallo!

Rev. 1460 behebt das Problem mit der Gruppenerstellung - überall getestet. Dann kann man gleich einmal etwas tiefer einsteigen ins Gruppen geteste, sofern hier keine größeren Änderungen zu erwarten sind. Könnte dann als "fertig" betitelt werden.
So langsam sieht es wieder fertig aus, und sogar besser als vorher, das WB. 

Gruß Michael

[Waldschwein]

Hallo!

So, kurzer Test zur Rev. 1462.
Um wieder das Testen zu erleichtern (sollte trac nicht mögen) gibt es wieder ein Paket:
http://www.websitebaker2.org/media/websitebaker_2.8.x_Rev1462.zip

Upgrade-Script:
Bei nicht vorhandenem "/pages" Ordner wird auf Servern, wo PHP nicht in CGI läuft folgende Fehlermeldung ausgegeben:

All existing access files anew format
Error creating access file in the /pages directory (insufficient privileges)

Damit ist dann Schluss, man kann nur noch zurück.
Der "pages" Ordner kann auf solchen Servern auch nicht per FTP einfach so hochgeladen werden, selbes Problem. Es muss erst wieder umgestellt werden auf "PHP-User", das bieten aber nicht alle Hoster so einfach an. Daher ist die Frage, ob die Access-Dateien nicht WB unnötig einschränken werden - Probleme mit PHP-User / FTP-User gibt es ja zuhauf.

Eine alternative Methode kann ich mir momentan nicht vorstellen - viele haben z.B. ihren "/pages" Ordner umbenannt in "/seiten", "/cms", "/irgendwas" oder er ist gar nicht da. Daher muss der Ordner eigentlich aus der Datenbank ausgelesen werden, bevor eine Access-File angelegt werden kann. Denn eine Access-File in einem Ordner, der nie benutzt wird vom System (hier eben "/pages") macht wohl wenig Sinn.
Bitte nicht als Kritik verstehen, sondern einfach als Erklärung.

Aus einem mir unerklärlichem Grund sind alle .php Dateien in "meinen" /pages Ordnern mit einer falschen Hierarchie versehen worden. Das ganze war wohl aber beim letzten Upgrade mit Rev. 1451 (getestet ebenso mit upgrade-script aus 1462, ist 100%ig das upgrade-script). Daher wird im Frontend ein WSOD mit mehreren Fehlermeldungen ausgegeben ( require(../../index.php) | muss ich nicht posten, s.u.).

Vorher hat eine "normale" .php so ausgesehen:

Code: [Select]

<?php
$page_id = 14;
require("../config.php");
require(WB_PATH."/index.php");
?>Nach einem Upgrade sehen sie so aus:

Code: [Select]

<?php
// This file is generated by WebsiteBaker Ver.2.8.1;
// Do not modify this file!!;
// WB will rebuild this file from time to time!!
$page_id = 14;
require(&#39;../../index.php&#39;);
?>
Beide haben ja eine Hierarchie, und irgendwie muss die ja bekannt sein - bei beiden Versionen. Da muss unbedingt darauf geachtet werden, sonst zerschießt ein Upgrade solche Seiten wie z.B. websitebaker2.org (experimentiere damit ja auf einem sicheren Platz rum).

Ein "zurückgehen" ist übrigens nicht möglich, außer man hat die alten Dateien und kann sie überschreiben per FTP - auf einem Nicht-CGI System wieder ein Problem.

Wenn "/pages" vorhanden & beschreibbar ist (PHP-User), wird alles durchlaufen und grün ausgegeben.

Module
die im Paket enthalten sind (show_menu2, wysiwyg, ...) und per FTP hochgeladen wurden werden weiterhin bei einem "Add-ons -> Advanced -> Admin Settings -> Modules Reload" rot mit "The module is not installed properly!" dargestellt.
Newsbeiträge (erreichbar mit domain.xy/posts/this-announcement-13.php) werden jetzt richtig dargestellt, ebenso die News-Übersichtsseite.
Etwas das mich bei "Reload" etwas verwirrt - Reload selbst läuft unter "Admin-Tools" (über das Menü angezeigt), aber vorher und nachher ist man unter "Add-ons". Nicht weiter schlimm, man wird ja mit dem Klick auf "Back" selbst ohne JavaScript wieder zurück zu Module geleitet.

Mediencenter - Berechtigung
Ich gehe jetzt nur auf Berechtigungs"probleme" hier ein.
Ein Problem mit "Personal Folder":
Benutzer1 hat "Personal Folder" in "/media/de"
Benutzer2 hat "Personal Folder" in "/media/en"

Nur um nachzuprüfen, dass es generelles Problem ist, beide Ordner haben die Struktur
/media/xx/ <- Paar Daten
/media/xx/Help <- Keine Daten, nur Unterordner
/media/xx/Help/Ordner2 <- Einige Daten

Der Benutzer kann in seinem Pers. Ordner wie gehabt alles tun.
Der Benutzer kann im "verschlossenen" (also z.B. Benutzer1 in "/media/en") bis zur zweiten Hierarchie nichts tun.
In "/media/xx/Help/Ordner2" allerdings hat er wieder vollen Zugriff.
In allen anderen Ordnern haben beide Benutzer auch (bis zu dieser Hierarchie) keine Änderungsmöglichkei ten. Das finde ich sehr gut - muss man eben nur anführen.

Nicht-Administratoren haben in "Modify Settings" die Option "Settings for administrator only" zur Auswahl.
Aktivieren sie diese, haben sie Systemweit deaktiviert - nur ein Administrator kann diese Option wieder rückgängig machen.
Diese Option sollte nur und ausschließlich Administratoren vorbehalten sein. Gerade auf zwei meiner Webseiten, wo unterschiedliche Editoren an ihnen zugewiesenen Abschnitten der Webseite arbeiten aber keine Administrationsrech te haben kann solch eine Option zu Problemen führen.

Vorschlag: Ein Hinweis in Media "Your Personal Folder is: /media/en" oder ähnliches wäre vorteilhaft (natürlich nur, wenn Benutzer XY auch einen Pers. Ordner hat). Ich weiß - es wird wieder eine Sprachvariable benötigt, aber wenn man eh einmal dran ist kann man das einbauen. Würde einiger Verwirrung wohl vorbeugen.


So, der Test ist doch wieder umfangreicher ausgefallen als ursprünglich gedacht.
Allerdings sieht man immer mehr, wie es fertiger wird.  So viel offenes sollte eigentlich ja gar nicht mehr sein.

Gruß Michael

[Waldschwein]

Hallo!

Nachtrag: Aus Rev. 1462 funktioniert das Droplet "iEditThisPage" nicht.
Im Kommentar steht "Use: [[EditThisPage?show=7]]". Das kann gar nicht sein, weil es "Use: [[iEditThisPage?show=7]]" heißen müsste.
Bei [[EditThisPage?show=7]] => Wird im Klartext dargestellt
Bei [[iEditThisPage?show=7]] =>

Warning: sprintf() [function.sprintf]: Too few arguments in C:\xampp\htdocs\web\wb282new\modules\droplets\droplets.php(29) : eval()'d code on line 28

Warning: sprintf() [function.sprintf]: Too few arguments in C:\xampp\htdocs\web\wb282new\modules\droplets\droplets.php(29) : eval()'d code on line 35

Warning: sprintf() [function.sprintf]: Too few arguments in C:\xampp\htdocs\web\wb282new\modules\droplets\droplets.php(29) : eval()'d code on line 39

Zudem kein Hinweis, wo etwas vorhanden ist, außer etwas zerschossenes Layout.
Beim zweiten passiert also "irgendwas", wird auch nur angezeigt, wenn eingeloggt.

Gruß Michael

[gelöscht durch Administrator]

[DarkViper]

Kleckfihler....
da hab ich doch aus Versehen die falsche Datei (alte Testversion) erwischt.  

das 'richige' Droplet steckt im Anhang... SVN wird aktualisiert.

Die Ausgabe des Droplets sieht dann so aus:

Code: [Select]

<div class="iEditThisPage">
    <a href="http://xxx/admin/pages/modify.php?page_id=11" target="_blank" title="Seite &auml;ndern">
        <img src="http://xxx/templates/wb_theme/images/edit_16.png" alt="Seite &auml;ndern" />
    </a>
    <a href="http://xxx/admin/pages/settings.php?page_id=11" target="_blank" title="Seitenoptionen &auml;ndern">
        <img src="http://xxx/templates/wb_theme/images/modify_16.png" alt="Seitenoptionen &auml;ndern" />
    </a>
    <a href="http://xxx/admin/pages/sections.php?page_id=11" target="_blank" title="Abschnitte verwalten">
        <img src="http://xxx/templates/wb_theme/images/sections_16.png" alt="Abschnitte verwalten" />
    </a>
</div>
Über die CSS-Klasse 'iEditThisPage' kann die Ausgabe vollständig formatiert werden.

Welcher Button angezeigt wird, ist frei wählbar.

1 = modify page
2 = modify pagesettings
4 = modify sections

Durch Addition der Zahlen kann jede beliebige Kombination zusammengestellt werden.
Bei Gelegenheit erweitere ich das Teil noch um ein frei definierbares Template.

[gelöscht durch Administrator]

[Waldschwein]

Super, dann wird mal etwas draus gebastelt, um die Frontend-Suchtis evtl. etwas beglücken zu können. Sieht schonmal gut aus. 

Gruß Michael

[Waldschwein]

Mit den i-Droplets muss ein Fehler im System vorliegen.
Siehe Screenshots.
Zur Info: Die iEditThisPage ist in der Template index.php "hardgecodet" enthalten, daher wird sie nicht mehrmals abgebildet.

Gruß Michael

[gelöscht durch Administrator]

[dbs]

nimm mal den "iParentBlock" raus, dann sollte sich nichts wiederholen.

[[iRandomImage?dir=test]] bekomm ich nicht zum laufen-

[DarkViper]

noch nicht alle der neuen Droplets sind 100% einsatzfähig..  einige basieren bereits auf Voraussetzungen, an denen ich im Moment noch arbeite. (SVN ist eben kein Produktivsystem)

[dbs]

ist geplant das code-modul gegen code2 auszutauschen?

[Waldschwein]

ist geplant das code-modul gegen code2 auszutauschen?

Nein. Es geht eher in die andere Richtung, also das Code Modul generell rauszunehmen und / oder irgendwann etwas anderes zu nehmen.
Allerdings mag ich das Code2 Modul nicht, ich möchte das nicht als Standard drinnen haben. Das sorgt nur für Ärger, weil die Leute dann alles mögliche ohne nachdenken zu müssen reinkopieren und sich dann WB dumm und dämlich kaputt schießen.

Edit: Stimmt, der iParentBlock war es - danke!
Dass es natürlich kein Produktivsystem ist, ist klar - sonst würde ich es ja nicht testen sondern einsetzen.  Trotzdem sollte nur auf die SVN gelangen, was man eben auch testen kann, sonst macht es ja wenig Sinn. Wir wollen euch ja eigentlich nur ernsthaft unterstützen, dass dann nicht beim RC oder gar Release das Geschrei so groß ist.

Gruß Michael

[HANS 0]

Ob nun geliebt oder nicht, Code2 wird bei ALLEN meinen Anwendern und mir eingesetzt, und wenn's nur zum checken bzw dem Ausprobieren "innerhalb" von WB dient. Einer der Module, die keiner mehr missen mag.
Wer sich das Ding installiert, weiß was er tut, oder kriegt dann eben Haue. EINE derartige Schnittstelle sollte man jedenfalls beibehalten, bzw. zur Verfügung stellen.
Damit deutlich wird WARUM so ein Teil bei meinen Anwendern wichtig ist: z.B. Codeabschnitte aus ADservern in Blöcke einfügen können, statt andauernd an einem Template rumfummeln zu müssen.