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.zipUpgrade-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:
<?php
$page_id = 14;
require("../config.php");
require(WB_PATH."/index.php");
?>
Nach einem Upgrade sehen sie so aus:
<?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('../../index.php');
?>
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.
Moduledie 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 - BerechtigungIch 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öglichkeiten. 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
WebsiteBaker Community Forum
