Nach den ganzen Querelen um WebsiteBaker 3, der jetzt dann doch PlatformRAD - äh - (derzeit) edgecms heißen wird, ist die Decke wieder etwas höher und damit der Weg frei für die nächsten Releases. Ein Blick auf die Ankündigungstafel.
WebsiteBaker 2.8 im Anmarsch
Etwas versteckt – unter Project -> Roadmap findet sich eine Liste der neuen Features von WebsiteBaker 2.8. Auf den ersten Blick etwas enttäuschend: Im wesentlichen gibt es nur kosmetische Änderungen, wirkliche Neuerungen sind nicht dabei.
Die wichtigste Neuerung ist wohl, dass die Systemanforderungen auf min. PHP 4.4.9 erhöht worden sind - was ich zb hier bei 1&1 gerade noch habe, bei vielen Webspaces meiner Kunden kann ich das Update auf WB 2.8 nicht mehr machen, ohne beim Provider vorstellig zu werden. Naja - das war zu erwarten, früher oder später ist PHP 5.2 angesagt. Also eben früher.
Aber schauen wir uns ein paar Änderungen im Detail an:
Addon pre-installation checks to check for Add-On requirements
Check vor der Modul-Installation, ob die nötigen Voraussetzungen erfüllt sind.
Immer mehr Module greifen auf Tabellen oder Funktionen von anderen Modulen zu. Bekanntestes Beispiel: AnyNews funktioniert nicht ohne News. Auch „Fremdkomponenten“ – zb der FCK-Editor oder JQuery – werden häufig vorausgesetzt. Mit zunehmender Anzahl solcher Abhängigkeiten muss ein Check gemacht werden.
Dieses neue Feature erlaubt definitiv eine neue Qualität bei zukünftigen Modulen.
section anchor is now configurable in WB Options
Der "Section Anchor" ist konfigurierbar
Der "section anchor" wurde in WB2.7 eingeführt, um etwa bei der Suche direkt auf die Abschnitte mit dem Treffer zu verweisen. Allerdings hat er nicht nur Vorteile; so ist zb eine leere Section nicht mehr wirklich leer und der eigentlich unsichtbare Link führte mitunter zu Einrückungen im ersten Absatz oder ungewünschten Abständen.
Redirect time for function print_success can now be defined in Settings
Dauer der Sichtbarkeit von Meldungen ist einstellbar
Wohl dem, der mit Analog-Modem in WB arbeitete: Nur so konnte man diverse (Miss-)Erfolgsmeldungen nach dem Speichern lesen. Wer eine schnellere Anbindung oder gar einen lokalen Testserver hatte, konnte gerade mal erahnen, was da kurz flackerte. Gute Idee.
redirect-type (301/302) is added and chooseable to menu_link
Die Art des Redirects von menu_link ist einstellbar
Der "Seitentyp" menu_link arbeitet mit Weiterleitungen. Davon gibt es im wesentlichen 2:
301: permanent moved = Der Normalzustand:
Die Seite ist nicht hier, sondern dauerhaft woanders.
302: temporary moved = Die Ausnahme:
Die Seite ist normalerweise hier, aber momentan woanders.
302 wird den NormalUser nur bedingt interessieren, für ihn reicht 301: Diese Seite ist woanders. Fertig.
Mit 302 werden teils unsaubere Tricks gemacht, etwa um PageRank zu spiegeln oder Seiten zu "Hijacken"; mitunter auch, um (in Verbindung mit weiteren Tricks) einem Hijack zu entkommen.
Dieses "Feature" halte ich für wenig sinnvoll. Dem Normal-User sind die Zusammenhänge meist nicht klar und er könnte sich damit einigen Schaden zufügen.
module and template delete function now provide additional information when module is in use
Hilfreiche Informationen, wenn ein Template oder Modul gelöscht wird
Manchmal ein Ärgernis: Man kann ein Modul erst löschen, wenn keine Section mehr damit vorhanden sind. Nur: die muss man erst einmal finden. Ein Segen.
block names btw. numbers are visible at modify pages dialogue if blocks are enabled
Namen und Nummern der Blöcke werden im Backend angezeigt.
Ein oft gehörter Wunsch: Jeder Abschnitt im Backend sollte eine kleine Überschrift haben, damit man sieht, wo er hingehört. In der Tat ist es auf Seiten mit mehreren Abschnitten oft nicht mehr zu erkennen, was was wo ist. Auch eine deutliche Trennlinie zwischen Abschnitten wäre hilfreich; bei manchen Konstellationen ist fast nicht erkennbar, wohin zb. der Speichern-Schalter gehört.
Zusätzlich geplant
including Droplets
Das war absehbar: Die Droplets erweitern die Möglichkeiten von WebsiteBaker enorm und machen vieles, was in der Vergangenheit trickreich von Entwicklern hinzugefrickelt werden musste, viel einfacher. Allerdings betrachte ich sie auch ein wenig mit Argwohn, viele von ihnen sind enorme Bremser beim Seitenaufbau. Gerne wird übersehen, dass mit den harmlosen kleinen [[Droplets]] schnell mal hunderte redundante Datenbankabfragen dazukommen – bei jedem Seitenaufruf.
skinable Admin Interface
Hier weiß ich nicht so recht, ob ich damit glücklich bin: Das ist so, als ob Toyota einen Schnappverschluss für sein Logo machen würde, damit man es leichter (gegen ein hübscheres?) austauschen kann.
Prinzipiell könnte mir das egal sein, aber ich befürchte, dass die Schnittstelle zu WB lustlos gemacht wird, und dann dem Wildwuchs Tür und Tor geöffnet wird: Einzelne Module funktionieren nur mehr mit bestimmten Admin-Templates oder andere Ärgernisse. Und die erste Frage bei Problemen mit Modulen: Welches Admin-Template verwendest du?
made Form XHTML-strict compatible
HansNULL wird endlich glücklich sein und nicht mehr quengeln.
Hoffentlich..
Neuere Themen:
Frischer Schwung bei den Templates Ein Lichtblick am Templatehimmel - im wahrsten Sin des Wortes
Die Sache mit den Bildern Internet, CMS und Webdesign: Bilderjammer
Ältere Themen:
Ein großer Wurf: Websitebaker Portable Websitebaker, Firefox Server, PHP, MySQL ohne Installation
Topics: Das Gute an der Grippe Topics kommt langsam in die Zielgerade
Kommentare:
16.03.2009
Zum ganzen Thema "Skinable Backend Themes" lässt sich sagen, dass die Idee nicht schlecht ist. Doch sie hat einen Hacken und zwar, wenn alle Dateien des Backends für ein solches "Redesign" freigegeben werden.
Der Hacken besteht daraus, dass sobald in den nächsten Versionen neue Funktionen hinzukommen, die ganze Reihe an Themes komplett neu überarbeitet werden muss.
Das ist eine undankbare Arbeit und macht wenig Sinn.
Viel besser ist es, nur jene Dateien zur Designanpassung frei zu geben, die dafür wirklich verantwortlich sind und zwar /head /foot /css-file /icons
That's it.
Alle anderen "Template Files" des Backends sollten im Core bleiben.
Nichts gegen eine Trennung von HTML und PHP - die sollte möglichst durchgeführt werden (und ist sie auch im jetzigen Stadium bereits), doch es ist einfach so, dass man - wie Chio oben schon angerissen hat - zu zu vielen Problemen führen kann.
Ich befürworte "Skinable Themes" - doch das ganze muss mit mehr Aufmerksamkeit durchgeführt werden.
Christian
23.03.2009
Rowdy
Habe die aktuelle SVN Version getestet. Highlights wie noch in WB 2.7 - Fehlanzeige. Alles in allem ein Bugfix Release mit ein paar "kleinen" Beigaben. Im SVN ist seit Wochen tote Hose und auch im Forum gibt es keine Informationen bezüglich WB 2.8. Also abwarten und Tee trinken.
Rowdy
21.04.2009
HansNULL
Zu "Form XHTML-strict compatible".
Nur weil die Formulare nicht kompatibel sind, ist's das Editor- und News-Modul. Wenn das kein Ärgernis ist. Wenn fundmentale Fehler im Core stecken quengel ich weiter. Xhtml-strict im Jahre 2009 sollte selbstverständlich sein. Die Anwendbarkeit im XML-Umfeld schadet WB bestimmt nicht. Gruß Hans>NUL
22.04.2009
Chio
"Xhtml-strict im Jahre 2009 sollte selbstverständlich sein."
Jawoll! Deswegen wird sicher auch die Verbreitung schon im Promille-Bereich liegen ;-)
03.05.2009
thorn
Zitat:
301: permanent moved = Der Normalzustand:
302: temporary moved = Die Ausnahme:
Nein, leider nicht.
Zitat von php.net zum "Location:"-Header:
Es wird nicht nur der Header an den Browser geschickt, sondern auch ein REDIRECT (302) Statuscode, wenn nicht bereits ein 3xx Statuscode gesendet wurde.
D.h. 302 ist der Normalfall in PHP!
Erst mit WB2.8 wird es möglich stattdessen (richtigerweise) einen 301 zu senden.
03.05.2009
Chio
Ja, 302 wird verwendet. War das bei WB 2.6 auch schon so? Ist mir gar nicht aufgefallen. Vieleicht verdrängt...
"Richtigerweise" - warum nicht gleich immer richtig? Ein 302 ist praktisch nie nötig.
Generell frage ich mich aber, warum hier überhaupt Weiterleitungen verwendet werden, statt einem banalen, einfachen Link gleich im Menü. Da muss man eben Showmenu(2) anpassen, aber das wird ohnehin irgendwann mal sein müssen. Die ganze Geschichte mit MenuLink ist ziemlich verzopft.
08.12.2009
Zitat:
"Nur weil die Formulare nicht kompatibel sind, ist's das Editor- und News-Modul."
Da war ich wohl besoffen, oder was?
Aua...
