WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)
Tests & Probleme der SVN Revision 1374 - 2.8.2 RC
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:
--- Quote ---All existing access files anew format
Error creating access file in the /pages directory (insufficient privileges)
--- End quote ---
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: ---<?php
$page_id = 14;
require("../config.php");
require(WB_PATH."/index.php");
?>
--- End code ---
Nach einem Upgrade sehen sie so aus:
--- Code: ---<?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');
?>
--- End code ---
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. :wink: 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]] =>
--- Quote ---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
--- End quote ---
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. :roll:
das 'richige' Droplet steckt im Anhang... SVN wird aktualisiert.
Die Ausgabe des Droplets sieht dann so aus:
--- Code: ---<div class="iEditThisPage">
<a href="http://xxx/admin/pages/modify.php?page_id=11" target="_blank" title="Seite ändern">
<img src="http://xxx/templates/wb_theme/images/edit_16.png" alt="Seite ändern" />
</a>
<a href="http://xxx/admin/pages/settings.php?page_id=11" target="_blank" title="Seitenoptionen ändern">
<img src="http://xxx/templates/wb_theme/images/modify_16.png" alt="Seitenoptionen ä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>
--- End code ---
Ü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. :-D
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]
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version