WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)

2.8.3: Update-Erfahrungsbericht

(1/2) > >>

instantflorian:
Hallo,

in den vergangenen drei Tagen habe ich 68 WebsiteBaker-Installationen auf die neue Version 2.8.3 aktualisiert.
Ausgangsversion war alles von 2.7er-Altlasten bis 2.8.2 SP2.
Die Websites liegen auf den unterschiedlichsten Servern, vom Billig-Massenprovider bis zur Hinterhofklitsche ist alles dabei.

Standardinstallatio nen habe ich reibungslos und ohne Probleme innerhalb weniger Minuten aktualisieren können.
(Das längste ist immer die Datensicherung und dann das Hochladen der Dateien gewesen.)

Es gibt also aus meiner Sicht keine Gründe,auf das Update zu verzichten. *
Ich musste bei keiner einzigen Seite einen Rollback auf die alte Version durchführen.
(* Voraussetzung ist natürlich, dass auf dem Server PHP 5.2.x oder 5.3.x laufen und auch sonst alle Voraussetzungen erfüllt sind! Prüfen: mit Check WB.)

Probleme gab es in folgenden Fällen:
- Installationen, bei denen Standardmodule wie form, news oder frontendfilter deinstalliert waren.
Da hat das Update-Script gestoppt und fehlende Datenbankeinträge bemängelt. Der Tipp, über Module > Erweitert das fehlende Modul nachzuinstallieren, scheiterte an der allseits beliebten "Sicherheitsverletzu ng!! Zugriff verweigert!!" (reproduzierbar).
Abhilfe in solchen Fällen bestand darin, die fehlenden Felder direkt in die Datenbank einzufügen, d.h. via phpMyAdmin o.ä. von einer nackten Testinstallation (Version spielt keine Rolle) die entsprechenden Felder (aufpassen: wirklich nur diese) zu als SQL exportieren und diese dann bei der in die Datenbank der zu updatenden Installation zu importieren (auf richtigen Prefix dabei achten! Ggf. vorher mit Texteditor und Suchen/Ersetzen anpassen.). Nicht ganz trivial, aber machbar.

- Installationen mit bestimmten, älteren, Modulen.
Dies betrifft z.B. Bakery vor 1.5.9, FormX und eventuell noch andere, die sich der Funktion get_output_filter_settings bedienen. Da die Funktion in getOutputFilterSettings umbenannt wurde, führt der alte Aufruf zu PHP-Fehlern und Abbruch des Seitenaufbaus. In diesen Fällen muss dann in der jeweiligen view.php des Moduls (bei Bakery: view_form.php) der alte Aufruf durch den neuen ersetzt werden.

Brax_Highslide_Gallery: führt nach dem Update zu bizarren Darstellungsfehlern, da ist aber einfach nur in der view.php eine Zeile zu korrigieren.

FancyBox als Modul: führt zu vermeintlich leeren Seiten. Ursache ist hier ein IE6-conditional comment, der durch das neue, etwas rigide CSS-Handling geschreddert wird, sodass zwar der öffnende, nicht jedoch der schließende Kommentar-Tag geschrieben wird und die Seite somit ab dort als auskommentiert behandelt wird. Abhilfe: Conditional Comment raus. Wer jetzt noch den IE6 benutzt, dem ist eh nicht zu helfen.

Sitemap als Modul: muss auf 3.1.3 aktualisiert werden. Download auf AMASP.

AddOn File Editor AFE: Muss auf 2.1.0 aktualisiert werden. Download auf gitHub

CKEditor: Muss auf 0.6.9 aktualisiert werden. Download im Forum

Diese Liste erhebt keinen Anspruch auf Vollständigkeit; das waren die Module, bei denen es mir konkret aufgefallen ist. Faustregel: meistens hilft Aktualisieren des Moduls. Solche sehr komplexen Module wie Topics, Members, KIT, mpform o.ä. setze ich nicht ein, bin ich zu doof für, kann mir aber gut vorstellen, dass es da Probleme geben könnte.

Unbedingt zu prüfen nach erfolgreichem Update
Formulare. Das Formular-Modul ist ja grundlegend überarbeitet worden; es werden jetzt andere CSS-Klassen für die Felder verwendet (frm-textfield statt bisher nur textfield usw.). Warum das so ist, weiß ich nicht, ebensowenig, weshalb man nicht mehr die Eingabe in einem E-Mail-Formularfeld als Absenderadresse einstellen kann, aber egal. Jedenfalls, wer sein Formular bisher nicht über dessen frontend.css gestylt hat, muss in seinem Stylesheet die Bezeichnungen entsprechend anpassen.

News. In den News-Optionen veraltete Variablenplatzhalte r ersetzen, z.B. [PUBL_DATE] durch [PUBLISHED_DATE].
 
CSS-Handling. WebsiteBaker "erzieht" dazu, keine <style>...</style>-Abschnitte dynamisch irgendwo in der Seite mehr zu verwenden. Die werden nämlich einfach mal kommentarlos rausgeschmissen. Wer also über Droplets bislang solcherlei zu tun pflegte, muss sich nunmehr etwas anderes überlegen. Konkrete Lösungsvorschläge kann ich da nicht bieten, bei mir half es, das dann mit PHP abzufangen (if (PAGE_ID==1) usw.)


tl;dr: Update ist empfehlenswert und i.d.R problemlos möglich.

In diesem Sinne vielen Dank an alle an der neuen Version Beteiligten Entwickler und Tester.

Viele Grüße
_florian.

DarkViper:

--- Quote from: instantflorian ---CSS-Handling. WebsiteBaker "erzieht" dazu, keine <style>...</style>-Abschnitte dynamisch irgendwo in der Seite mehr zu verwenden. Die werden nämlich einfach mal kommentarlos rausgeschmissen. Wer also über Droplets bislang solcherlei zu tun pflegte, muss sich nunmehr etwas anderes überlegen.
--- End quote ---

Da <style>...</style>-Abschnitte innerhalb des <body>...</body> - Tags laut W3C nicht erlaubt sind (abgesehen von den längst überholten und veralteten DocTypen) werden diese Abschnitte normalerweise vom Core ausgeschnitten und oben am Ende des <head>...</head> - Tags wieder eingefügt. Vorraussetzung ist natürlich, dass der style-Tag keine Syntaxfehler  enthält.


--- Quote from: instantflorian ---Formulare. Das Formular-Modul ist ja grundlegend überarbeitet worden; es werden jetzt andere CSS-Klassen für die Felder verwendet (frm-textfield statt bisher nur textfield usw.). Warum das so ist, weiß ich nicht, ...  Jedenfalls, wer sein Formular bisher nicht über dessen frontend.css gestylt hat, muss in seinem Stylesheet die Bezeichnungen entsprechend anpassen.
--- End quote ---

Ok, zu einer 'grundlegenden Überarbeitung' würde schon noch einiges mehr gehören. ;-)
Das mit den CSS-Klassennamen ist nur eine Wiederannäherung an die alten Regeln. CSS-Definitionen eines Modules sollen für genau dieses Modul gelten, nicht für andere Module und schon gar nicht für das Haupttemplate. Eine 'nackte' Klasse textfield kann es prinzipiell in jedem x-beliebigen Modul geben, ebenso wie auch im Haupttemplate. Bei der Ausgabe 'gewinnt' dann die Definition, die zuletzt ausgegeben wird. Alle anderen werden gnadenlos überschrieben.
Deshalb ist es sinnvoll, den CSS-Definitionen eines Modules einen Präfix mitzugeben, der eine Definition eindeutig einem ganz bestimmten Modul zuordnet. Für die Haupttemplates werden keine Präfixes verwendet. Schon sind viele seltsame CSS-Phänomene Vergangenheit. Vor allem, wenn auf einer Seite mehrere verschiedene Module eingebaut sind.
Die Methode wurde übrigens schon vor einigen Jahren von 'doc' im Grundgerüst des 'Hello World' - Modules festgelegt/empfohlen. Dieses Teil hat für die ganze 2.8.x Serie auch noch heute weitestgehend Gültigkeit.


--- Quote from: instantflorian ---...ebensowenig, weshalb man nicht mehr die Eingabe in einem E-Mail-Formularfeld als Absenderadresse einstellen kann, aber egal. ...
--- End quote ---

Ein Formular ist nicht zwangsläufig ein Emailprogramm, auch wenn die abgeschickten Daten per Email an den Betreuer des Formulares geleitet werden. Genausogut könnten die Daten ja auch in der Datenbank gespeichert und dann per RSS/SMS oder einfach durch eine Datenbankabfrage weitergeleitet/ausgewertet werden. Der Absender einer scriptgesteuerten Emailbenachrichtigu ng ist physikalisch grundsätzlich das Script, in diesem Falle also WebsiteBaker. Die Beachtung dieser Tatsache wird immer wichtiger, je stärker die Emailserver im Netz gegen Spam abgesichert werden. Viele Emaildienste verweigern schon heute die Annahme, wenn eine Mail z.B. über wwwrun@example.com verschickt wird oder als Absender eine andere Domain drinsteht als die, über deren Server die Mail verschickt wurde. Oft genügt schon das versenden mit der PHP-Funktion mail() um die Post im Spamfilternirwana verschwinden zu lassen. Sendet dann eine Domain dazu noch sehr häufig Mail aus, die als Spam identifiziert wird, so ist es nur noch eine Frage der Zeit, bis die IP-Adresse dieser Domain z.B. bei Spamhouse als Spamschleuder in der Blacklist steht. Da kommt dann beim Hoster Freude auf, wenn durch die IP-Blacklistung dann gleich alle Kundendomains eines Servers gesperrt sind. Eine fristlose Kündigung des Webspaces und schlimmstenfalls eine zusätzliche Schadensersatzforde rung ist dann meist fällig.

Stefek:
Hallo Florian,

danke, dass Du Dir die Zeit für diese ausführliche Berichterstattung genommen hast.

- Stefek

VSG:
Hi, zusammen!

Und vielen Dank wieder einmal für das Update und Eure Zeit, die ihr immer da rein packt.

Ich hab das aktuelle einmal in einer XAMPP-Umgebung installiert (als Update meiner bisherigen Seite). Das klappt soweit auch ganz gut.
Selbst das WYSIWYG with history and draft v2.7.5.4 läuft.

Nur wenn ich den PageCloner benutze, kommt eine unschöne Meldung:

--- Quote ---Strict Standards: mktime () [function.mktime]: You should be using the time() function instead in [...]\modules\pagecloner\tool_doclone.php on line 89
--- End quote ---
.

Die Seite wird trotzdem geklont, aber gibt es eine Möglichkeit, das Modul anzupassen, damit das "schön" ausschaut? :D

Danke im Vorfeld für die Antworten. Da die Meldung erst seit 2.8.3 auftritt hab ich es hierhin und nicht in den Module-Thread gepostet.

Viele Grüße,
VSG

PS: An der Stelle darf ich mich als großer Befürworter dieser "Changed Files"-Pakete outen. Dabei geht mir deutlich weniger an Einstellungen/Design verloren, als mit einem kompletten Update und es macht für mich den Update-Prozess viel, viel einfacher.

instantflorian:
Hallo VSG,

der PageCloner ist auch ein Aktualisierungskand idat. Auf Version 0.56 updaten sollte helfen. Download hier

hth
_florian.

Navigation

[0] Message Index

[#] Next page