WebsiteBaker Community Forum
WebsiteBaker Support (2.12.x) => General Help & Support => 
Hilfe & Support (deutsch) => Topic started by: gottfried on January 26, 2019, 12:48:32 PM
-
Hallo!
Ich will gerade eine 2.8.3 (nach Sicherung) auf 2.12.1 r188 upgraden.
Ich hab irgendwie schon zwei mal alles falsch gemacht und neu angefangen.
Also hab ich nun die doku gelesen und frag lieber erst nochmal.
Man muß nach dem Überspielen erst mal in den Adminmodus gehen und dann in der adresszeile des browsers das upgrade script aufrufen?
Die neue Version läuft dann auch noch unter php 5.6 bevor man auf 7.2 (wegen 1&1) umschalten muß?
:-)
-
Man muß nach dem Überspielen erst mal in den Adminmodus gehen und dann in der adresszeile des browsers das upgrade script aufrufen?
kurze Antwort: JA
detailliert: Ab Version WB 2.10.0 darf nur noch der SuperAdmin mit der User-ID = 1 dieses Upgrade durchführen. In meinem aktuellen Upgrade-Auftrag hat der Admin die ID = 4, was ich leider erst im zigsten Versuch bemerkte. Also lohnt sich durchaus ein Blick in die Datenbank-Tabelle users, ob beim verwendetem Account (siehe deine Logindaten) auch diese ID = 1 vorne dran steht.
Zusatz: die USER-ID ist immer einmalig, jede Ziffer darf nur einmal vorkommen. Steht ggf noch ein alter, nicht mehr benutzer SuperAdmin aus "alten Tagen" drin, diesen erst löschen, dann deine ID auf 1 ändern
Ist die Version 2.12.1 schon auf den Server übertragen, sollte (in 99,999% ) dieses Upgrade-Script direkt nach dem Einloggen ins Backend automatisch starten. Mitunter kann es aber vorkommen, das noch die Seiten des älteren Backend-Themes im Browser-Cache hängen. In diesem Fall steht direkt unter dem oberen Menü ein Link zum Starten des Upgrade-Scripts
Startet dieses Upgrade-Script dann mit einer weißen statt der bunteren Seite, muß das Script zuerst den DEBUG-Modus ausschalten. Mit Klick auf den angezeigten Button oder mit der jeweiligen Tasten-Kombination des Browsers zum Reload der Seite (unter Win mit F5 oder auch STRG+R) startet man dann das eigentliche Script.
Abhängig von der Ausgangsversion kann es so scheinen als würde das Script mittendrin stehen bleiben. Dies ist die Stelle an der alte, nicht mehr benötigte Dateien entfernt werden wie z.b. das WB-Theme, da einfach etwas abwarten. Tut sich nach einer Minute noch nichts, mit einem Reoad der seite das script erneut laden. Acht Durchläufe habe ich schon einmal benötigt, es ist also normal, das dies vorkommen kann.
Fertig ist das Upgrade-Script erst, wenn unten die zwei Buttons erscheinen (Kick me to Front- bze to Backend)
-
Ich will mich heute auch mal an das erste Upgrade einer 2.8.3 sp7 auf 2.12.1 versuchen.
Habe ich die Schritte richtig im Kopf?
- Datenbank sichern
- Pages und Media Verzeichnis sichern
- 2.12.1 auf den Server hochladen (alte Dateien überschreiben)
- Backend aufrufen und dann den Schritten folgen?
Wann schalte ich die PHP-Version um? Aktuell ist das noch 5.6 - muss natürlich geändert werden, aber mache ich das vor oder nach dem Upgrade? (Bei Strato hat man nach dem Umstellen genau 30 Minuten Zeit, zur alten Version zurückzukehren, falls etwas nicht funktioniert...)
Was ist mit älteren Modulen - wann upgrade ich die? Z.B. Foldergallery 1.36 - dürfte mit neueren PHP-Versionen nicht laufen.
Bitte kurze Info... danke! :-)
LG,
Astrid
-
Wann schalte ich die PHP-Version um? Aktuell ist das noch 5.6 - muss natürlich geändert werden, aber mache ich das vor oder nach dem Upgrade?
Am besten, danach.
Hier geht es auch weniger um WB, eher um die Module, die dort mit laufen. Die WB-Version kann beides, 5.6 und 7. Wenn aber eines der Module zickt, kann das einen Abbruch des Upgrades erzeugen. Darum idealerweise erst nach Abschluß aller Arbeiten umstellen.
Was ist mit älteren Modulen - wann upgrade ich die? Z.B. Foldergallery 1.36 - dürfte mit neueren PHP-Versionen nicht laufen.
siehe oben, wobei es hier nicht ganz so wichtig ist, solang diese Module nicht in der sog. Whitelist des UpgradeScripts drin stehen. Dort kann man manuell Module eintragen, die damit in das große UpgradeScript eingebunden werden.
Als Beispiel: Ich überschreibe meine alte FG mit der aktuellen Version und trage diese foldergallery in die Whitelist ein. Dann schieb ich alles auf den Server, starte das große UpgradeScript und das upgradet WB und auch die Foldergallery, sie muß also nicht mehr manuell upgedatet werden.
Alles, was von WB kommt, sei es direkt von z.b. Dietmar oder im Addonsbereich, läuft auch mit PHP 5.6.
Ich bin auch gerade wieder bei einem Upgrade. Mache es lokal komplett fertig, lade es dann hoch, teste und schalte dann erst um auf 7.3
-
Hi!
Also - es ist ein ziemliches Theater mit dieser neuen Version bzw des Updates.
Ich bastle da schon Tage rum.
Datensicherungen Hin und Herspielen
Datenbanksicherunge n einspielen weil nach dem Updateversuch keine Benutzer und Gruppen mehr da sind u.s.w
kann man das nicht bißchen weniger nervig gestalten?
-
Erstes Problem beim Aufspielen der neuen 2.12.1 Version auf den Server:
Fehler beim Übertragen der Datei '../favicon.ico'.
Type=dir;Modify=20190131113306;Unique=04c800270296fb52;Perm=cmpdfe; DOCU
Type=dir;Modify=20190131113243;Unique=04c8002700a764b0;Perm=cmpdfe; account
Type=dir;Modify=20141030123825;Unique=04c80027004b4bdf;Perm=cmpdfe; admin
Type=file;Size=472;Modify=20180411065633;Unique=04c80027008f4484;Perm=adfrw; config.php
Type=file;Size=1150;Modify=20180710111428;Unique=04c800270296fb50;Perm=dfrw; favicon.ico
Type=dir;Modify=20190131113314;Unique=04c8002700e2df07;Perm=cmpdfe; framework
Type=file;Size=91;Modify=20141030124846;Unique=04c80027008f4482;Perm=adfrw; htaccess.txt
Type=dir;Modify=20190131113356;Unique=04c8002700211781;Perm=cmpdfe; include
Type=file;Size=3226;Modify=20160906094829;Unique=04c80027008f4481;Perm=adfrw; index.php
Type=dir;Modify=20190131113536;Unique=04c80027005c779c;Perm=cmpdfe; install
Type=dir;Modify=20190131113537;Unique=04c8002700558865;Perm=cmpdfe; languages
Type=dir;Modify=20180509073713;Unique=04c80027008f4480;Perm=cmpdfe; media
Type=dir;Modify=20190131113923;Unique=04c8002700e44836;Perm=cmpdfe; modules
Type=dir;Modify=20180828112224;Unique=04c8002700558863;Perm=cmpdfe; pages
Type=dir;Modify=20141030123707;Unique=04c80027005c77ac;Perm=cmpdfe; search
Type=file;Size=20598;Modify=20150508084440;Unique=04c800270ff26c0a;Perm=adfrw; systemcheck.php
Type=dir;Modify=20180905144536;Unique=04c80027005c77aa;Perm=cmpdfe; temp
Type=dir;Modify=20160906094700;Unique=04c80027002dd2e1;Perm=cmpdfe; templates
Type=dir;Modify=20160906094828;Unique=04c80027102ec86b;Perm=cmpdfe; var
Kopieren von Dateien auf den entfernten Rechner schlug fehl.
Permission denied.
Hmmmm...
-
Hi!
Ich muß mich korrigieren.
In der Datenbank befinden sich durchaus noch user und groups. In der wiederaufgespielten alten Anwendung sieht man sie nur nicht ohne Datenbank neuimport.
Die user_id und group(s)_id ist jeweils 1
anbei pdf des updateversuchs.
-
Hmmmmm.....
Upgrade ist durchgelaufen. War alles grün. Funktionierte trotzdem nicht - im Frontend kamen leere Seiten. Habe dann aber gesehen, dass es am Template lag und konnte die Fehler beheben.
Dann waren sämtliche Umlaute falsch codiert. Die ließen sich dann auch nur händisch wieder ändern. Damit bin ich jetzt durch.
Jetzt käme im nächsten Schritt der Upgrade der Foldergallery. Hieran scheitere ich.
Fehlermeldung:
[170] Ein Upgrade oder Installation von einer WebsiteBaker Version kleiner 2.12.1 ist nicht möglich.
Habe versucht von 1.36 auf 2.1.0 upzugraden.
Und jetzt????? Über FTP hochladen und dann über die Erweitert-Funktion upgraden?
-
Und jetzt????? Über FTP hochladen und dann über die Erweitert-Funktion upgraden?
Das habe ich probiert. Upgrade ist auch durchgegangen. Die Galerien waren allerdings im Backend alle weg - aber ich konnte sie neu reinladen (evtl. Beschriftungen sind dabei wohl draufgegangen - das nehme ich in Kauf, dürfte nicht viel gewesen sein..).
Aber - Frontend funktioniert immer noch nicht.
Unter PHP 5.6 bekomme ich weiterhin eine leere Seite (die Ausgabe bricht ab).
Unter PHP 7.2 bekomme ich die Fehlermeldung:
There was an uncatched exception
Class 'Template' not found
in line (284) of (/modules/foldergallery/view.php):
Habe erst mal wieder auf 5.6 zurückgestellt, da das 30-Minuten-Zeitfenster mir sonst keinen Spielraum mehr lässt.
Was mache ich nun?
-
Hallo, in der zeile 284 steht was von jqueryadmin.
Ändere mal in den Allgemeinen Einstellungen der FG die Lightbox.
-
Hi!
Also - es ist ein ziemliches Theater mit dieser neuen Version bzw des Updates.
Ich bastle da schon Tage rum.
Datensicherungen Hin und Herspielen
Datenbanksicherunge n einspielen weil nach dem Updateversuch keine Benutzer und Gruppen mehr da sind u.s.w
kann man das nicht bißchen weniger nervig gestalten?
Mal Hand aufs Herz
ist das eigentliche Problem nicht eher, das man, warum auch immer, über Jahre (mit unter auch 10) auf Updates verzichtet hat und nun, allein durch Zugzwang von PHP gezwungen wurde, doch mal etwas upzugraden?? :wink:
Nicht persönlich nehmen, es betrifft ja ebenso die letzten 20 User, die hier in den vergangenen Wochen über Probleme berichtet hatten.
Seit Anfang letzten Jahres mit Bekanntwerden der DVSGO mach ich nichts anderes mehr als Versionen upgraden (das eine WP-Projekt mal ausgenommen). Und die einzigen Installationen mit 2.10 und neuer, waren die meiner Stammkunden. Der Rest ging und geht über 2.8.0 bis 2.8.3 SP7
Und weil über die Jahre bei vielen nichts gemacht wurde, merkt man erst jetzt mit Abschaltung der PHP 5.6, das irgendwer im Web auf UTF8 umgestellt hat. Und was für jemandem vom Fach in 5 min erledigt ist, wird dann zu einem Problem, das nun noch mit dem WB-Upgrade zusammen kommt und ggf auch böse Nebenwirkungen erzielt, weil z.b. der Editor nix mit UTF8-Zeichen anfangen kann. Dann funktioniert etwas nicht, die Datenbank steht auch noch auf Latin und man wundert sich.
Aber - Frontend funktioniert immer noch nicht.
Unter PHP 7.2 bekomme ich die Fehlermeldung:
Code: [Auswählen]
There was an uncatched exception
Class 'Template' not found
in line (284) of (/modules/foldergallery/view.php):
zu alte FG-Version
der Unterschied ist in dieser Zeile, etwas tiefer als die hier genannte Zeile 284
alt:
$t = new Template($sAddonTemplatePath);
neu
$t = new \vendor\phplib\Template($sAddonTemplatePath);
aber das tauschen der Zeile bringt da nix. Verwende die aktuellste Version
-
Die Help-Seite ist auch wieder auf dem neuseten Stand, zumindestens beim Upgarde.
siehe hier
https://help.WebsiteBaker.org/de/benutzerhandbuch/installation/vor-der-installation.php?searchresult=1&sstring=Upgrade#anker4
ist ein Step by Step Anleitung zum nachlesen.
Und als Ergänzung hier eine Anleitung, die auch für die WB 2.12.1 gilt
-
Mal Hand aufs Herz
ist das eigentliche Problem nicht eher, das man, warum auch immer, über Jahre (mit unter auch 10) auf Updates verzichtet hat und nun, allein durch Zugzwang von PHP gezwungen wurde, doch mal etwas upzugraden?? :wink:
Nicht persönlich nehmen, es betrifft ja ebenso die letzten 20 User, die hier in den vergangenen Wochen über Probleme berichtet hatten.
Seit Anfang letzten Jahres mit Bekanntwerden der DVSGO mach ich nichts anderes mehr als Versionen upgraden (das eine WP-Projekt mal ausgenommen). Und die einzigen Installationen mit 2.10 und neuer, waren die meiner Stammkunden. Der Rest ging und geht über 2.8.0 bis 2.8.3 SP7
Und weil über die Jahre bei vielen nichts gemacht wurde, merkt man erst jetzt mit Abschaltung der PHP 5.6, das irgendwer im Web auf UTF8 umgestellt hat. Und was für jemandem vom Fach in 5 min erledigt ist, wird dann zu einem Problem, das nun noch mit dem WB-Upgrade zusammen kommt und ggf auch böse Nebenwirkungen erzielt, weil z.b. der Editor nix mit UTF8-Zeichen anfangen kann. Dann funktioniert etwas nicht, die Datenbank steht auch noch auf Latin und man wundert sich.
Also in meinem Fall liegt das dann hauptsächlich daran, dass der Wartungsvertrag meiner Kunden ein permanentes Upgraden einfach nicht hergibt. Mit ganz wenigen Ausnahmen haben die Kunden bei mir ein Zeitkontingent von 2 Stunden pro Jahr - und das wird in der Regel für andere Aktualisierungen verbraucht.
Wenn es dringend notwendig ist - und das ist es ja zur Zeit mit der PHP-Aktualisierung und dem angedrohten extended Support von 1&1 und Strato - dann sehen auch die Kunden ein, dass es notwendig ist. Ist halt nicht immer so. Ich betreue inzwischen um die 100 Websites.
aber das tauschen der Zeile bringt da nix. Verwende die aktuellste Version
OK - habe jetzt die 3.0.14 genommen - das funktioniert, also danke. Auch wenn ich dieses blöde Hover-Styling bei den Kategorien überhaupt nicht mag. Muss ich mich jetzt wieder ans CSS machen, um das auszuschalten.
LG,
Astrid
-
Also - es ist ein ziemliches Theater mit dieser neuen Version bzw des Updates.
.....
Ich bastle da schon Tage rum.
Ich biete dir gern an, nach Zusendung des Datenbank-Backups, dieses Upgrade auf die neueste Version durch zu spielen und so Probleme zu finden.
Und wenn du dann noch das Dateien-Paket zippst und zur Verfügung stellst, bekommst du das vollständig upgegradet wieder zurück, mußt dann nur einmal den Server mit der WB-Installation leer machen, das ZIP-Paket hochladen. Analog mit der Datenbank.
Vorausetzung wäre, das es für alle verwendeten Module auch schon etwas Neues gibt
-
@Astrid: läuft das Frontend nun?
-
@Astrid: läuft das Frontend nun?
Ja, danke. :-)
-
betrifft Foldergallery
Auch wenn ich dieses blöde Hover-Styling bei den Kategorien überhaupt nicht mag. Muss ich mich jetzt wieder ans CSS machen, um das auszuschalten.
habe es selbst noch nicht probiert, aber die Kollegen schwärmen von einer frontend-user.css in den Module-Ordnern
Kopiere dort mal das Kram deiner alten frontend.css rein. Die frontend-user.css wird bei späteren Upgrades nicht mehr überschrieben.
-
Hi!
Betreff Hand auf's Herz
Ich schließ mich da astricia an.
Der Preis, den ich mit meinen Kunden für Ihre meist Künstlerhompages mit Foldergallery Marke Eigennachbau ausgemacht habe gibt die ganze updateritis nicht her.
Wo mich nun eigentlich dieser php Schrott am meisten nervt.
Mein VBA Code von 2000 läuft doch auch noch und ist wartbar.
Ich hab da einige WB Installationen, die ich updaten muß und ich muß da eben durch.
-
betrifft Foldergallery
Auch wenn ich dieses blöde Hover-Styling bei den Kategorien überhaupt nicht mag. Muss ich mich jetzt wieder ans CSS machen, um das auszuschalten.
habe es selbst noch nicht probiert, aber die Kollegen schwärmen von einer frontend-user.css in den Module-Ordnern
Kopiere dort mal das Kram deiner alten frontend.css rein. Die frontend-user.css wird bei späteren Upgrades nicht mehr überschrieben.
Ist schon behoben. Geht im Prinzip nur um einen einzigen Befehl, der das Hovern ausschaltet:
div.categories-info {
top: 110%;
}
muss ersetzt werden durch
div.categories-info {
top: 80%;
}
Der Rest ist ne Anpassung der Farben, damit sie zum allgemeinen Styling passen. (Finde ich eigentlich ein Unding, dass die Foldergallery da Farben vorgibt...)
LG,
Astrid
-
Also in meinem Fall liegt das dann hauptsächlich daran, dass der Wartungsvertrag meiner Kunden ein permanentes Upgraden einfach nicht hergibt. Mit ganz wenigen Ausnahmen haben die Kunden bei mir ein Zeitkontingent von 2 Stunden pro Jahr - und das wird in der Regel für andere Aktualisierungen verbraucht.
ich kenn ja die Problematik auch und hab mich auch schon von Kunden getrennt, wenn mein Name irgendwo mit drin steht und ich weiß, das hier Probleme kommen. Eine Partneragentur aus Thüringen hatte zum Jahresende noch 48 solcher alten WB-Installationen upzugraden und nur wenige waren schon eine 2.8.3.
Im kommerziellem Bereich gehe ich da auch mit, aber wenn ein User, vornehmlich aus dem Nachbarland, jetzt mehrere NEU-Installationen mit 2.10.0 macht, geht mir der Hut hoch. 2.10.0 kann PHP 7.1 bis max 7.2.3. Da weiß ich, das der Kollege in zwei Wochen wieder heult.
Ich weiß z.b. das die originale 2.8.2 keine Probleme im Upgrade auf 2.12.1 macht, aber eben nur diese und nicht die Version mit der nächsten Revisionsnummer, die immernoch unter 2.8.2 lief..
Ein grundsätzlicher Tip von mir für die, die noch mit latin1 arbeiten (Blick in die Datenbankverwaltung / Übersicht der Tabellen reicht):
Erst die Konvertierung auf UTF8 abschließen und dann erst upgraden.
Ich weiß, das viele Leute diese Zeichenkonvertierun g im Upgrade erwarten, dem ist aber nicht so, zu komplex, zu gefährlich.
Wo mich nun eigentlich dieser php Schrott am meisten nervt.
In aller Regel reagiert WB ja auch nur auf solche PHP-Ankündigungen
Mein VBA Code von 2000 läuft doch auch noch und ist wartbar.
funktioniert auch mit PHP-Code. Nur als Beispiel eregi vs preg_match. ersteres mittlerweile entfernt in PHP, Letzteres stand damals aber auch schon zur Verfügung. und je nachdem, was der Modulautor damals verwendet hat, läuft ein Modul heute noch oder eben nicht
-
Eine Partneragentur aus Thüringen hatte zum Jahresende noch 48 solcher alten WB-Installationen upzugraden und nur wenige waren schon eine 2.8.3.
Kleiner als 2.8.3 habe ich nix mehr - aber immerhin noch 26 x 2.8.3, die jetzt nach und nach upgegradet werden. Nützt ja nix. :-/
Wer keine kritischen Module hat, bei dem kann ich ja auch mit 2.8.3 auf die PHP 7.2 hochstellen. Dann ist zumindest der extended Support erst mal vom Tisch. Aber upgraden muss ich dann demnächst trotzdem.
-
habe es selbst noch nicht probiert, aber die Kollegen schwärmen von einer frontend-user.css in den Module-Ordnern
Es wurde sich dann geeinigt auf frontendUser.css bzw. js, gleiches für backendUser.css/js
Einfach die originale frontend.css umbenennen zu frontendUser.css und alle eigenen Änderungen bleiben erhalten.
-
Hallo!
Also wie gesagt ich möchte von 2.8.3 auf 2.12.1 upgraden, was ja gehen soll, eigentlich.
Momentan php 5.6 mysql 5.5
Ich muß da durch. Es stehen mir ja noch mehrere bevor.
Diese Seite ist relativ einfach ohne irgendwelchen Schnickschnack wie galerien kontakt oder so.
Trotzdem kommt im Lauf der Prozedur die Meldung
Exception: "No such file or directory" >> Exception detected in: [/framework/class.database.php]
siehe Anhang.
Auch bei weiteren Seitenaufrufen.
Ich hab auch schon das Installationspacket neu heruntergeladen.
:-)
Im Grund hätte ich wohl in der Zwischenzeit die Seite neu gebaut, weil einfach - aber wie gesagt hab ich noch mehrere.
:-)
Hoster ist 1und1
-
Hallo Jakobi!
Du könntest natürlich gerne den datenbankbackup und die Dateien haben, aber nicht die setup.ini.php
:-)
den update letztendlich möcht ich selber machen, weil ich wissen muß,warum das nicht geht.
:-)
-
Kannst du mir ein Backup von WB und der DB auf einen Testserver kopieren?
Dann können wir uns das in Ruhe mal anschauen.
Als BetaTester habe ich 100derte 2.8.3 in jeglicher Form in einem Rutsch auf 2.12.1 gebracht und diese Meldung war nie dabei.
Wenn ja lass ich dir per PM die FTP-Zugangsdaten vom Server zu kommen.
-
Du könntest natürlich gerne den datenbankbackup und die Dateien haben, aber nicht die setup.ini.php
bräuchte ich nicht
Am Ende ist es deine Entscheidung - für mich brauch ich das nicht
-
Hallo!
Also wie gesagt ich möchte von 2.8.3 auf 2.12.1 upgraden, was ja gehen soll, eigentlich.
Kann es sein das du eine WB 2.8.4 da im Einsatz hast? Eine "setup.ini.php" gibt es in den offiziellen Versionen 2.8.3 bis 2.12.1 nicht.
-
Hi!
Ja klar, hab dir die downloadlinks als PM geschickt.
-
@hgs
ääh - ja - eine 2.8.4 - ich seh nicht sonderlich gut trotz brille und hab mich wohl vertippt.
:-)
-
Ja klar, ...
Heist, es ist eine 2.8.4?
Dann bin ich raus, keine Erfahrung mit dieser Experimental Version, Sorry
-
Hi!
Ich hab also gar keine offizielle Version ?
Spaßig.
:?
-
Hallo!
HGS gat mir nun schonend beigebracht, daß ich ja eine inoffizielle 2.8.4 als Basis für paar Kundenprojekte genommen hab.
Da bin ich ja selber schuld. Die hat mir aber gut gefallen und war jahrelang recht stabil.
Auf jeden Fall hilft mir diese Information aber weiter.
Bin froh, daß hgs das gesehen hat!
Auch vielen Dank an Jakobi22 für seine Unterstützung.
Ich sag, wenn ich weitergekommen bin.
:-)
-
eine inoffizielle 2.8.4
es gibt keine "inoffizielle" 2.8.4
Sie wurde damals veröffentlicht, war also offiziell - wenn auch nur für Stunden
das Upgrade geht über die 2.10.x oder 2.11.x - oder über manuelle Eingriffe wie manuelles Anlegen einer korrekt befüllten config.php auch mit 2.12.x
-
das Upgrade geht über die 2.10.x oder 2.11.x - oder über manuelle Eingriffe wie manuelles Anlegen einer korrekt befüllten config.php auch mit 2.12.x
Hier eine Anleitung zum Upgrade der WB 2.8.4. auf WB 2.12.1
Das Vorhandensein einen Dateien- und Datenbank-Backups setze ich voraus
1. Lösche diese Ordner der Version 2.8.4 komplett
account
admin
framework
include
search
sowie unter modules die Ordner
- captcha_control
- code
- droplets (ggf Sicherung der vorhandenen Droplets vorher durchführen und in einen anderen Ordner legen)
- fckeditor
- form
- jsadmin
- menu_link
- MultiLingual
- news
- output_filter
- SecureFormSwitcher
- show_menu2
- wrapper
- wysiwyg
außerdem im WB-Hauptverzeichnis die Dateien
index.php
upgrade-script.php
Benenne die Datei setup.ini.php vorerst um, der Name ist beliebig, Dateiendung sollte .php bleiben. Dies dient nur dazu, die Werte der aus dieser setup.ini.php in die config.php zu übertragen. Danach kann und sollte die setup.ini.php gelöscht werden
Es empfiehlt sich, eine möglicherweise vorhandene Datei .htaccess für die Dauer des Upgrades umzubenennen, z.b. in htaccess.txt
##############################
2. du benötigst eine funktionierende Datei config.php. Überschreibe dazu den Inhalt der in WB 2.8.4 enthaltenen Datei mit diesen Inhalt oder lege, wenn nicht vorhanden, eine solche Datei mit einem editor wie Notepad an
Inhalt der Datei
Der Code kann so direkt kopiert werden. Die jeweiligen Werte sind anzupassen (siehe Kommentare). Die Datei config.php wird im Upgrade-Prozess neu geschrieben. Die von mir eingefügten deutschsprachigen Kommentare sind dann verschwunden, die englischen bleiben stehen, sie enthalten jeweils Datum und Versionsangaben des zuletzt durchgeführten Upgrades.
<?php // gehoert zum Script, muss mit kopiert werden
/*
*** auto generated config file for 2.12.1
*** WebsiteBaker upgrade from 2.8.4 to 2.12.1
*** created at 2019-01-16 02:00:15 Europe/Berlin
*/
// define('DEBUG', false);
define('DB_TYPE', 'mysqli');
define('DB_HOST', 'localhost'); // ggf anpassen (siehe auch Datei setup.ini.php)
define('DB_PORT', '3306');
define('DB_NAME', 'xxxxxxx'); // (siehe auch Datei setup.ini.php)
define('DB_USERNAME', 'xxxxxxx'); // (siehe auch Datei setup.ini.php)
define('DB_PASSWORD', 'xxxxxxx'); // (siehe auch Datei setup.ini.php)
define('DB_CHARSET', 'utf8_unicode_ci'); // wer Emoticon im CKEditor benutzen möchte, benötigt hier utf8mb4_unicode_ci
define('TABLE_PREFIX', 'wb_'); // (siehe auch Datei setup.ini.php)
define('WB_URL', 'https://...........'); // no trailing slash or backslash!! - ist anzupassen
define('ADMIN_DIRECTORY', 'admin'); // no leading/trailing slash or backslash!! A simple directory name only!! - anpassen, wenn anderer Name für das Verzeichnis erwünscht ist, der admin-Ordner muß dann manuell umbenannt werden
require __DIR__.'/framework/initialize.php';
// --- end of file ----------------------------------
P.S.: ein schließendes ?> ist nur notwendig, wenn nach dem PHP-Code noch anderer Code wie HTML erscheint, in reinen PHP-Dateien wie dieser config.php ist es nicht notwendig
3. Sichere ein ggf im Root-Ordner von WB enthaltenes Favicon
4. Übertrage nun die WB 2.12.1 in diese WB-Installation - alles überschreiben
5. Logge dich ins Backend ein. Du wirst von dort entweder direkt zum UpgradeScript geleitet oder siehst auf der Startseite des Backend einen Link zum Starten des Upgrade-Scripts.
Aktiviere im Upgradescript alle drei Checkboxen und Klicke auf START.
6. Angezeigt wird das Protokoll des Upgrade-Scripts. es sollte am Ende die zwei Buttons "Kick me to Frontend/ Kick me to Backend" zeigen und keine roten Warnmeldungen enthalten. Bleibt das Upgrade unterwegs stecken und die genannten Buttons werden nicht gezeigt, starte das Upgrade erneut mit einem Reload der Seite (F5-Taste). Der Vorgang kann beliebig oft wiederholt werden. Ursache wäre, das das Script zu Beginn die benötigten Teile der Datenbank ausliest und damit feste Vorausetzungen hat. Im Verlauf schreibt es dann neue Settings in die Datenbank. Kommt es nun an einen Schalter, der beim ersten einlesen "falsch" steht, weil dieser beim Auslesen der alten WB-Version z.b. nicht gesetzt war, bricht das Script ab. Durch den Reload liest es nun das neu geschriebene ein und geht weiter im Script
7. Wechsel nun ins Backend und lade die Seite nach Anzeige erneut, wenn das obere Menü nicht komplett oder miniklein dargestellt wird. In dem Fall befindet sich noch altes kram im BrowserCache, der durch den Reload überschrieben wird. Eine korrekte ansicht wäre dies hier
(https://i.gyazo.com/668ca4107d4fa17e2e1cd0d87a8e66ae.png)
8. Gehe zu Optionen -> erweiterte Optionen anzeigen -> Servereinstellungen -> PHP-Fehlerberichte und wähle dort "Production"- Speichere diese Einstellungen
9. Gehe in die Seitenübersicht und kontrolliere Seite für Seite, Section für Section
10. Schaue, ob du für Module, die nicht mit dem WB-Paket geliefert wurden, im Addon-Bereich eine neue Version bekommst, z.b. Foldergallery. Das gern genutzte SimplePageHead wäre zu testen, keine Ahnung, ob es da was neues gibt. Ich selbst nutze es nicht mehr, weil ich keine Module dieser Art nutze und für meine eigenen eine andere Methode verwende
11. Module wie wblib, libraryAdmin, lib_jquery wurden meines Wissens nicht mehr weiter gepflegt. User dbs kann da eventuell Tips für Alternativen geben, ich habe aber vielfach hier gelesen, das man sich von diesen Addons verabschiedet hat. Bitte korrigieren, wenn ich hier falsch liege
12. Kontrolliere deine Droplets. Vorhandene, in der Datenbank gespeicherte Droplet werden im Upgrade nicht überschrieben und nicht verändert. Es ist aber möglich, das dafür im Ordner modules/droplets/example eine neue Version vorhanden ist.
Verwendet ein Droplet oder auch ein Modul eine Zeile mit dem Code $wb->preprocess(), ist diese Zeile auszukommentieren oder zu löschen. Diese Funktion war der Vorgänger des heutigen OutputFilters und wurde 2011 schon in WB entfernt. Bis WB 2.12 wurde aber keine Fehlermeldung dafür gesetzt
13. Kontrolliere unter AdminTools -> OutputFilter die dort gesetzten Einstellung. Im Normalfall ist dort bis auf JQuery UI, OPF und RelUrl alles gesetzt. Wer das Modul OPF nutzt, muß dies natürlich aktivieren.
Beachte auch die Einstellungen für das Ersetzen von @ und Punkt in Mailadressen, Standard ist [at] und [dot]
14. Kontrolliere in den WB-Optionen zuerst die Einstellung für die Datenschutzrichtlin ie und wähle bei aktivierter Datenschutzrichtlin ie eine Section mit der Datenschutzerklärun g aus, die dann in der Zustimmungsfrage der Formulare in Form und Newskommentare verlinkt wird.
15. das alte Backend-Theme der WB 2.8.4 (WbTheme) und ggf davon erstellte eigene Theme-Kopien sind nicht zu WB 2.12.x kompatibel. Der bzw die Ordner kann nach Abschluß des Upgrades gelöscht werden. Bitte aber nicht vor dem Start des UpgradeScripts löschen, da dies die Anmeldemaske zum Backend-Login enthält.
Ende der Anleitung
getestet mit WB 2.8.4 Rev 1866 (war nur für den Community-Test) und Rev 2101 (offiziell für 6Std (?) oder so) - es gab noch eine Rev 2103, die die Reparaturen zu 2101 enthielt, aber (warum auch immer) damals nicht zeitnah veröffentlicht wurde. Beide liefen bei mir bis PHP 7.1, aber nicht mehr ab 7.2
Upgrade durchgeführt von diesen beiden Versionen auf WB 2.12.1 Rev 188 (Version aus dem Download ohne Fixes) mit PHP 7.2.3 und PHP 7.3.0
@ gottfried - Punkt 15 hatte ich in der Mail vergessen. Das WbTheme ist auch noch im Zip enthalten, bitte löschen, wenn fertig
-
Ein grundsätzlicher Tip von mir für die, die noch mit latin1 arbeiten (Blick in die Datenbankverwaltung / Übersicht der Tabellen reicht):
Erst die Konvertierung auf UTF8 abschließen und dann erst upgraden.
Ich weiß, das viele Leute diese Zeichenkonvertierun g im Upgrade erwarten, dem ist aber nicht so, zu komplex, zu gefährlich.
Habe heute das zweite Update gemacht - und dabei auch extra darauf geachtet, dass wirklich UTF8 eingestellt war. Auch in der Datenbank bei wb settings stand utf-8.
Leider waren die Umlaute nach dem Upgrade trotzdem alle verhackstückelt. Hat mich jetzt gerade 1,5 Stunden gekostet, das alles wieder zu richten, weil es viele einzelne Abschnitte und Seiten gab.
Interessanterweise gab es dann auch ganz vereinzelt einige Abschnitte, bei denen es OK war - ich habe aber keine Ahnung, was bei denen anders war als bei den anderen. Kannst du mir kurz einen Überblick geben, wie genau ich so etwas VOR dem Upgrade feststelle und ändere, damit mir das beim nächsten Mal nicht wieder passiert?
Danke,
Astrid
-
Habe heute das zweite Update gemacht - und dabei auch extra darauf geachtet, dass wirklich UTF8 eingestellt war. Auch in der Datenbank bei wb settings stand utf-8.
Leider waren die Umlaute nach dem Upgrade trotzdem alle verhackstückelt. Hat mich jetzt gerade 1,5 Stunden gekostet, das alles wieder zu richten, weil es viele einzelne Abschnitte und Seiten gab.
bitte nicht persönlich nehmen, aber ich denke, du hast die Problematik noch nicht richtig verstanden.
Früher war es üblich, das Webseiten im deutschen Sprachraum den Zeichensatz latin1 oder einer seiner Abwandlungen wie z.b. latin1_swedish benutzt haben.
Mit diesem Zeichensatz werden Sonderzeichen wie unsere Umlaute usw innerhalb der Datenbank kodiert.
Über den in der Auslesedatei (i.d.R der Browser) eingestellten Zeichensatz wird dann der SQL-Code wieder zurück in für uns lesbare Zeichen decodiert.
Einzig möglicher Zeichensatz in WB ist der Standard-Zeichensatz von PHP, also UTF8. Da in deiner Datenbank aber keine UTF8-Zeichen vorhanden sind, sondern mit latin1 kodierte, kann der Browser dies nicht übersetzen, denn der soll und kann ja nur UTF8. Und darum kommt es dann zur Darstellung dieser UTF-Zeichen wie z.b. hier Grüße im Wort "Grüße"
UTF8 ist eine andere Form der Codierung. Mit dieser ist es möglich, alle Schriftzeichen der Welt darzustellen, egal, ob chinesisch, arabisch oder kyrillisch. Latin1 hat dagegen nur einen begrenzten Zeichensatz. Zudem ist ein UTF8-Zeichen ist mit seinen 2 Stellen auch kürzer als die meist 5-stelligen HTML-Special-Chars in Latin1
Heutzutage verfügen auch die Editoren über interne Konverter, um SQL-Code in lesbare Buchstaben umzuwandeln, sichtbar z.b, wenn man eine reine SQL-Datei in Notepad++ öffnet
Hier ein Bild davon aus einem Backup in Notepad++
(https://i.gyazo.com/f4dbae54a873ab9c1861e7eaf7b0f5fe.png)
und nun das Gleiche in reinem SQL-Code aus einer per utf8 kodierten Datei (gleiche Stelle der Datei) in einem SQL-Editor
(https://i.gyazo.com/17122008b3f0ad25228efecb5d15881a.png)
das Gleiche noch einmal in Latin1 mit HTML-Special-Chars (siehe etwa mittig im Feld "name")
(https://i.gyazo.com/fe52a3d0ff7ed3d9aa580ed8b1f8d70e.png)
Um nun eine alte per Latin1 kodierte SQL-Backup-Datei nach UTF8 zu kodieren, braucht es eigentlich einen Konverter. Im begrenztem Rahmen reicht dafür Notepad++
Sollte es da nicht automatisch geschehen (ist abhängig von den Einstellungen), geht es dort auch über search&replace. Für deutsch-sprachige Seiten sind es ja meist nur ä, ö, ü, ß bzw ä ö usw, und das für Groß- und Kleinbuchstaben getrennt. Die Kodierung sollte auf UTF8 stehen. Zu ersetzen wären die Specialchar's mit Buchstaben in Reinschrift, also ä mit ä ersetzen, Ä mit Ä
Irgendwo habe ich auch mal ein Konvertertool gesehen, hier oder in den Downloads, finde es aber nicht auf die Schnelle.
Dies hat dann auch gleich die Tabellen umgeschrieben, z.b. so etwas hier
`ftp_server` varchar(255) character set latin1 collate latin1_general_ci NOT NULL,
Als Vorlage zum Abschauen dient z.b. eine Backup-Datei einer WB-Installation ab WB 2.10.0
Dies läßt sich aber auch in PHPmyAdmin per (vielen) Mausklicks erledigen (theoretisch für jede Tabelle und jedes Text-Feld einmal)
Nach dem Ersetzen wird diese dann in PHPmyAdmin oder Adminer usw wieder in die Datenbank importiert.
Die Änderung der sogenannten Table Collation bzw Field Collationen legen fest, mit welcher Kodierung Daten in die Tabelle geschrieben werden, es wirkt also nur beim Speichern neuer und geänderter Datensätze
-
bitte nicht persönlich nehmen, aber ich denke, du hast die Problematik noch nicht richtig verstanden.
Da hast du wohl recht und ich nehme das auch gar nicht persönlich - ich mag es gar nicht und fühle mich sehr unsicher dabei, auf SQL-Ebene rumzuhantieren. Aber wenn ich dich jetzt richtig verstanden habe, komme ich da nichtdrum herum.
Nur noch mal zum Verständnis. Die Vorgehensweise wäre wie folgt:
- Datenbank runterladen
- Sicherheitskopie machen (sicher ist das...)
- Datenbank mit dem Notepad++ Editor öffnen
- Überprüfen ob das reine Öffnen bereits die Umlaute bereinigt hat
- Falls nicht, hier ein manuelles Bereinigen über die Suche und Ersetze Funktion (so hatte ich das in den einzelnen Textabschnitten hinterher gemacht..)
- Datenbank dann wieder speichern
- Geänderte Datenbank hochladen
Ich habe jetzt mal eine gespeicherte Datenbank mit dem Notepad++ geöffnet. Da wird bei mir nichts konvertiert. Ich finde sowohl HTML Entities (also ä für ä) als auch diese Hieroglyphen (ä für ä). Muss ich dann beides über Suchen+Ersetzen ändern, oder nur die Hieroglyphen?
Ersetze ich also ä durch ä oder ä durch ä ? Und muss ich noch irgendwas ersetzen außer ä,ö,ü,Ä,Ö,Ü,ß ?
Und mache ich das Ganze VOR Upgrade auf 2.12.1 oder nachher?
Sorry für die doofen Fragen, aber bei SQL bin ich echt raus. Gibts da nix in WB, was man installieren kann, dass das dann automatisiert gemacht wird?
-
Sorry für die doofen Fragen
es gibt keine doofen Fragen :wink:
Und mache ich das Ganze VOR Upgrade auf 2.12.1 oder nachher?
spielt keine Rolle
Wenn du es vorher machst, könntest du es sogar in der alten Version schon testen, die noch die Zeichensatzeinstell ungen in den WB-Optionen haben
Ersetze ich also ä durch ä oder ä durch ä ? Und muss ich noch irgendwas ersetzen außer ä,ö,ü,Ä,Ö,Ü,ß ?
kommt auf die Einstellungen in Notepad an (Kodierung soll auf UTF8 stehen)
dann aber ä durch ä und ä durch a - wobei Letzteres nicht ganz so wichtig wäre
Ich finde sowohl HTML Entities (also ä für ä) als auch diese Hieroglyphen (ä für ä). Muss ich dann beides über Suchen+Ersetzen ändern, oder nur die Hieroglyphen?
Ja, wenn man einmal dabei ist, beides. Zwingend wäre aber ä für ä
Ursache ist hier entweder eine Umstellung in der Datenbank, vielleicht wurde manuell das Charset geändert oder vom Anbieter beim Upgrade der Serversoftware
Auch möglich: diese Textteile wurden mit älteren FCK- oder CKEditor-Versionen eingefügt. Dort wurde beim Speichern noch mal ein htmlspecialchars() benutzt. Dies stammt noch aus den Zeiten unterschiedlicher Zeichensätze. Die Browser können mit Zeichensatz UTF8 alle diese HTMLSpecialChars (like ä) lesen und "übersetzen" und einige ältere Module
-
Hallo Jacobi !
Ich hab den upgrade meiner 2.8.4 auf die aktuelle 2.12.1 nach deiner Beschreibung selber durchgeführt.
Mit einer config.php
Alles ist grün .....
Ich kann mich danach in das Backend einloggen und mir das alles ankucken.
Nur wenn ich aus dem Backend die aktuelle Seite aufrufe, lande ich immer auf der Startseite.
Auch wenn ich das Frontend aufrufe, komme ich nicht über die hinaus.
Dann habe ich die Seite, die du upgegradet hast auf den Server gelegt. Wenn ich da versuche in den admin zu kommen, kommt eine weiße Seite.
Aber ich komme im Frontend genau soauch nicht über die Startseite hinaus.
(ich hab momentan auf dem Server 3 Versionen und 3 Datenbanken, die sich nicht überschneiden)
Die Startseite läuft quasi in Schleife.
Das kann ja nur noch eine Kleinigkeit sein?
php ist immer noch 5.6 ????
:-)
-
Hast du zufällig in den WB-Optionen -> erweiterte Optionen oben unter allgemeine Einstellungen den Punkt URL Umleitung zur Homepage aktiviert?
der macht nämlich genau das
Werde mir deine Installation noch einmal "auflegen" - die war nach dem PC-Crash schon wieder fort. Wird aber heute nix mehr, hab zuviel aufzuholen
-
Hallo Jacobi!
nö - die Url Umleitung zur Homepage ist deaktiviert.
Foldergallery, Libraryadmin u.s.w sind nur zufällig drin, weil ich einfach eine andere Anwendung kopiert habe.
Die Seiten sind eigentlich ganz einfach.
Bis auf die erste. Die hat ein eigenes Template ohne Menü und leitet nach 3 sec auf die zweite weiter. (Künstlerminimal)
Das Standardtemplate ist aber das ohne Weiterleitung
Da ist ein Sectionpicker auf der zweiten Seite (mit Menü) auf die erste , das Menü soll also quasi verzögert auftauchen.
eilt nicht rasend.
:-)
-
Hallo! :-o
Ich hab nun etwas weiter "gebastelt". Das Backend funktioniert mit nun php 7.3 bisher störungsfrei.
Ich habe im Frontend immer noch den Effekt, daß immer die erste Seite aufgerufen wird, was ich auch (vom Backend aus) ansehen will.
Ich hab nun kapiert, daß die Seiten nur nicht mit Ihren zugewiesenen oder dem StandardTemplate aufgerufen werden sondern immer mit dem Template der ersten Seite.
Es steht zwar der link auf die richtige Seite in der Adressleiste des Browsers aber im Sourcecode ist klar das Template der ersten Seite erkennbar, das nur für diese verwendet wird.
Nur bei dieser ersten Seite ist eigentlich das Template schon die Seite. Also klar identifizierbar.
ist die Beobachtung hilfreich?
-
Ich glaube, das deine Aussage so nicht richtig ist.
Ich hab nun kapiert, daß die Seiten nur nicht mit Ihren zugewiesenen oder dem StandardTemplate aufgerufen werden sondern immer mit dem Template der ersten Seite.
Denn diese Einstellung wird im BackEnd unter "Optionen-->Standardeinstellung-->Template" gemacht.
Jede neue Seite wird dann erst mal mit diesem Template verknüpft.
Um einer Seite ein anderes Template zuzuweisen gehst du über "Seiten-->dort auf den Stift-->Template (steht auf Standarttemplate-->Auswahl treffen" ändern für genau diese Seite.
Kann leider keine Bilder mit anhägen,Sorry
-
Hallo HGS!
Denn diese Einstellung wird im BackEnd unter "Optionen-->Standardeinstellung-->Template" gemacht.
Jede neue Seite wird dann erst mal mit diesem Template verknüpft.
Um einer Seite ein anderes Template zuzuweisen gehst du über "Seiten-->dort auf den Stift-->Template (steht auf Standarttemplate-->Auswahl treffen" ändern für genau diese Seite
Ja genau so sollte es sein, so mach ich das seit Jahren, wenn ich verschiedene Templates verwende, so ist es bei mir aber nach der Umstellung eben nicht mehr.
Normal wähle ich unter Optionen-->Standardeinstellung en_Template jenes, das ich am häufigsten verwende
und suche mir unter Seiten-->dort auf den Stift-->Template (steht auf Standarttemplate-->Auswahl treffen das gewünschte besondere heraus falls die Seite ein anderes haben soll.
Ich habe nun bei mehreren Seiten, bei denen ich Standard eingestellt habe das dedizierte gewählt, das funktioniert aber eben auch nicht.
das habe ich ja versucht zu formulieren.
ich meine damit auch wenn ich
Um einer Seite ein anderes Template zuzuweisen gehst du über "Seiten-->dort auf den Stift-->Template (steht auf Standarttemplate-->Auswahl treffen" ändern für genau diese Seite
mache ruft der wb aus dem Backend diese Seite nicht mit dem so gewählten Template auf sondern immer mit dem der ersten Seite.
:-)
-
Nur mal als Übersicht, wie es sein sollte
Voraussetzungen bei mir gerade: Unter WB-Optionen ist das DefaultTemplate als Standard eingestellt.
Seite 1 nutzt in den Seiteneinstellungen -> Template die Einstellung "Standardeinstellung en"
Seite 2 nutzt in den Seiteneinstellungen -> Template die Einstellung "ResponseBlue"
(https://i.gyazo.com/937d812fadd667d2a06d83535d9a9885.png) WB-Top-Menu oben in der Mitte
- geht immer auf die Startseite, wenn man nicht gerade eine andere Seite als die oberste im Seitenbaum bearbeitet. Bearbeite ich meine Seite 2 in "Seite verändern", "Einstellungen bearbeiten" oder "Abschnitte verwalten", verlinkt auch das Haus im Top-Menü auf diese Seite
Seitenübersicht
(https://i.gyazo.com/311d5302d6b0502e11a2279467242723.png) geht immer direkt auf die Seite, die gerade angewählt wurde,
Vorausetzungen sind immer eine entsprechende Sichtbarkeit (nicht "delete", nicht "none"), sowie die erforderlichen Berechtigungen
Verwendet wird auf jeder Seite immer das Template, das in dessen Seiteneinstellungen eingestellt ist, genauer: das, was in der pages-Tabelle der DB für diese Seite eingetragen ist.
Als Fallback gibt es eine Absicherung, die für den Fall eintritt, das ein hinterlegtes Template nicht erreichbar ist (Ordner entfernt oder umbenannt). In diesem Fall wird das Standard-Template unter WB-Optionen verwendet. Ist auch das nicht erreichbar, crasht das Dingen.
Was sich zuletzt geändert hat, ist die Unterbindung von Verzeichnis- oder Templatenamen mit Bindestrich. Ein neues Template mit Bindestrich ließe sich dann nicht mehr installieren, es würde aber, per FTP auf den Server kopiert und unter Erweiterungen -> Erweitert eingelesen, auch funktionieren.
Wurde solch ein Template aber nun umbenannt und der Bindestrich mit Unterstrich ersetzt in Ordnername und info.php, steht auch nach dem Einlesen dieser Informationen das alte Template mit Bindestrich in der Datenbank und muß hier neu eingestellt werden. So etwas in der Art vermute ich auch bei dir.
Geht es um die Seite, die ich vor kurzem hatte?
-
Hallo Jakobi!
Ich bin gottfried, nicht astricia, die sich auch in dieser thread meldet.
Ich denke aber du antwortest auf den vorhergehenden Eintrag von mir.
Du hattest zwar meine Seite über PM aber die erste bzw Kopfseite nutzt nicht Standardeinstellung en sondern
rued_intro
Die meisten anderen Seiten benutzen Standardeinstellung en rued_pages_1
Response Blue taucht gar nicht auf.
die templates sind mit Unterstrichen.
Ich habe nun bei z.B impressum das template von Standard auf rued_pages_1 gesetz,
die Seite wird aber immer noch (aus dem Backend) mit template rued_intro aufgerufen,
wobei der link in der adressleiste des Browsers richtig wäre.
:-) läuft deine Kiste wieder !? :-)
find das super, daß man von euch so schnell eine Antwort bekommt! :-D
-
Ich bin gottfried, nicht astricia, die sich auch in dieser thread meldet.
?? :-o :-o :-o
hab nix von der Astrid gesagt, oder?
Hab nur dargelegt, wie es in WB funktioniert und dies an einem Beispiel mit zwei verschiedenen Templates
Ich habe mir jetzt in jedem deiner Templates den Templatenamen oben hin geschrieben und alles läuft so, wie es in der Datenbank hinterlegt ist
Standard ist rued_pages_1
Alles unterhalb von "Werke" und Unterhalb von "Im Raum" benutzt das Template rued_bilder_1, inkl der genannten Hauptseiten
In der Datenbank (in der ich nix verändert habe) haben 6 von 34 Seiten keine Templates in der Pages-Tabelle eingetragen, nutzen also das Standard-Template "rued_pages_1". Das sind, bis auf die zwei eben genannten Seiten "Werke" und "Im Raum" alle anderen Seiten des oberen Hauptmenüs
Alle Seiten werden vom Backend aus mit dem korrektem Template angezeigt, analog der Schaltung im Frontend und analog zu den in der pages-Tabelle hinterlegten Templates für jede Seite.
Ich tippe jetzt mal auf ein Cache-Problem, denn bei mir funktioniert es ohne Probleme. Gern auch per Teamviewer als "Beweis" :wink:
Ich könnte die Seite auch mal online auf einem Testserver laufen lassen
P.S.: Die Schaltung, die ich im Beitrag davor beschrieben habe, ist seit Jahren und zig WB-Versionen unverändert
:-) läuft deine Kiste wieder !? :-)
ne, "diese" Kiste nicht mehr. Meine Frau hat den Stecker gezogen und festgelegt, das hier was Neues ran muß, zwei Wochen Streß und schlechte Laune haben gereicht. Und natürlich lief danach die alte Kiste wieder. Memtest hat mich angelogen und meinte, die Arbeitsspeicher wären okay. Mit einem einzelnem läuft der Apperat wie geschmiert, mit einem zweiten drin komm ich nicht mal zum Passwort eingeben, dann ist er eingefroren.
-
Hi!
Ist irgendwie abstrus.
Ich glaub dir schon, daß das bei dir funktioniert.
wie testest du ? xampp?
Ich leg die Geschichte jetzt mal auf einen "stratoserver" statt 1&1.
Vielleicht hab ich noch einen Gedankenblitz.
Bin 2 Wochen weg in Prag. Danke vorab! :-D
Das mit den Rams kommt mir bekannt vor. u.U hat memtest ja gar nicht gelogen, nur zu wenig
Ram auf ok getestet? Ist mir mal passiert, daß memtest nur 1/2 Ramriegel erkannt und getestet hat.
Der war natürlich defekt - aber ohne Fehlermeldung.
P.S.
"1und1" baut gerade um zusammen mit "IOS" . u.U liegt es daran. nix funktioniert gerade flüssig, find ich. :-)
-
Hallo Jacobi!
Da bin ich wieder!
Echt abstrus. Ich habe die besagte Seite mal auf Strato gelegt und es ist das gleiche.
Mein mich in der Situation (nervöser Kunde) rettender Gedankenblitz war der, daß ich die erste Seite, die quasi ohne menü vorgeschaltet sein soll und nach ca 10 Sekunden Verzögerung eine ähnliche nur mit Menü aufruft nun mit Template "Standardeinstellung" eingestellt habe und nun funktioniert das, wie es soll. (Leider ohne die Verzögerung des speziellen Templates rued_intro und mit menü)
Sicher nervt mich die Kundin solange bis das geht (künstlerischer Minimalismus) - sollte ja eigentlich auch.
Ich kann dir gerne über PM einen Testzugang geben falls du dir das anschauen willst ?
-
da gibt es doch schöne JQuery Effekte ;-) (auch, wenn ich davon wenig halte, weil ich als Besucher ja nicht weiß, das ich hier 10 Sec warten soll)
Nur mal, um es gesagt zu haben
Beispiel auf dieser Seite -> http://thisinterestsme.com/jquery-display-element-5-seconds/
blendet einen Block, hier message, nach 5 Sekunden wieder aus. Das geht natürlich auch anders herum
hier ein einfaches Beispiel,
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Show Message For 3 Seconds and Menu after 5 seconds</title>
</head>
<body>
<div class="w3-right w3-hide-small" id="topmenu" style="margin-right:20px!important;display:none;">
<!-- show_menu2 -->
<ul id="header_menu" class="menu w3-white">
<li class="#"><a href="#" class="#"><span>DE</span></a>
<ul style="max-width:250px;">
<li class="#"><a href="#" class="#"><span>Gallery</span></a> </li>
</ul>
</li>
<li class="#"><a href="#" class="#"><span>IT</span></a>
<ul style="max-width:250px;">
<li class="#"><a href="#" class="#"><span>IT 1</span></a>
<ul style="max-width:250px;">
<li class="#"><a href="# class="#"><span>test3-it</span></a> </li>
</ul>
</li>
<li class="#"><a href="#" class=""><span>IT 2</span></a> </li>
</ul>
</li>
</ul>
</div>
<!--Our div is hidden by default-->
<div id="message" style="display:none;">Hello!</div>
<script src="https://code.jquery.com/jquery-1.12.4.min.js"></script>
<script>
//When the page has loaded.
$( document ).ready(function(){
$('#message').fadeIn('slow', function(){
$('#message').delay(3000).fadeOut();
});
$('#topmenu').hide(0).delay(5000).fadeIn('slow');
});
</script>
</body>
</html>
-
Hallo Jacobi!
Ich find die Zwangswarterei zwecks künstlerischem Minimalismus auch irgendwie verquer.
Block sichtbar machen nach n sec ist wohl auch eine Möglichkeit.
:-)
-
Am Ende gibt es da jemanden, der als Auftraggeber fungiert, von daher sollte man sich vielleicht keine Gedanken drum machen :wink:
10 Sekunden ist aber wirklich etwas viel. Ich habe, sicher auch aus Unwissenheit über die Umschaltung, nie gewartet, sondern mittig aufs Bild geklickt. Ich denke, das machen auch 99% der Besucher so - einzige Ausnahme wohl die Kundin selbst :-D
Also vielleicht mal mit 3 oder max 5 Sekunden Wartezeit probieren
Für's FadeIn gibt es dann auch noch andere Effekte als das aktuelle slow, fadeIn(2000) zieht es z.b. auf 2 Sec hin, fadeTo("slow", 0.7); zeigt den Block mit einer Transparenz von 0.7 usw, Schau dir die Try It Beispiele hier an, vielleicht ist was nettes dabei, das der Dame gefällt
https://www.w3schools.com/jquery/jquery_fade.asp
-
Hi!
Es waren ursprünglich 3 Sekunden, zwecks Testen des Problems hab ich das auf 10 verlängert um das genauer verfolgen zu können, also daß die richtige Seite (bei mir) mit dem falschen Template aufgeht.
Eh seltsam. Manche Installationen (noch 2.8.3) funktionieren nach Umstellung auf php 7.2 noch auf Anhieb, bei anderen
sind gerade bei einfachen Templates (round / all CSS / Uboot) die Menüs weg. Das ist gerade mein Hauptproblem. Die Zeit überbrücken ohne daß die Kunden nörgeln.
:-)
-
...sind gerade bei einfachen Templates (round / all CSS / Uboot) die Menüs weg...
showmenu durch showmenu2 ersetzen :-D
Matthias
-
Hallo Mathias!
Nö -sind showmenu2. Simple taugt aber u.U als Brückenlösung falls der Kunde schmollend abzuwarten geruht.
:-)
-
dafür gibt es ein Forum und ein paar Leute, die da rumlungern ;-) :-D
Am Showmenu2 hat sich nicht allzuviel geändert, im Idealfall bitte den Code posten, der nicht funktioniert und den groben Seitenaufbau dazu, mit MenuLink vorweg oder nicht, usw.
Und nicht vergessen: eine möglicherweise vorhandene Intro-Seite muß nach wie vor von Hand eingetragen werden
-
Hi!
Ich meinte mit "Simple" funktioniert die Seite ja unter 2.8.3 mit php 7.2 . Sieht nur nicht so doll aus wie uboot
Ist also nicht dringlich.
Ich will ja in den nächsten Tagen umstellen.
Danke! :-D
-
Uboot
Install.:
WebsiteBaker Error log
"created: [Mon, 25 Feb 2019 19:18:18 +0000]
Mon, 25 Feb 2019 19:19:37 +0000 [E_USER_NOTICE] \admin\templates\install.php:[168] from \admin\templates\install.php:[168] trigger_error "Missing Template-Parameter [$template_function] in uboot/info.php!""
====================
Template: Uboot als default gesetzt
Aufruf im Frontend:
"created: [Mon, 25 Feb 2019 19:21:09 +0000]
[25-Feb-2019 19:22:57 UTC] show_menu2 error: $aOptions is invalid. No flags supplied!"
MfG. Evaki
-
Hi!
Hört sich an wie Chio der Inquisition unterziehen zu müssen.
:-)
-
Probier mal den Anhang
(ohne Gewehr: Peng / auffe Schnelle)
Falls Menü "noch nicht stimmt", z.B. jacobi22 fragen :-D
Der hat sowas "im Kopf".
Die Frage, die sich mir beim Lesen der Lizenz noch stellt, ist" Darf man das hier korrigiert reinstellen?
3. Das Anbieten des Template auf anderen Seiten, zum Download, ist nicht erwünscht. Sie können jedoch einen Link zum Download auf www.WebsiteBaker.at setzen.
Frag mal den Author, damit gegebenenfalls der Anhang wieder gelöscht wird (vom Forenboss)
-
siehe auch hier -> https://forum.WebsiteBaker.org/index.php/topic,31341.msg218760/topicseen.html#msg218760
Hört sich an wie Chio der Inquisition unterziehen zu müssen.
es gibt Sachen, die waren immer schon vorgegeben, z.b. der Pflichtparameter aus Group1 im show_menu2
Auszug aus einer readme zum show_menu2 von 2010!!!
GROUP 1
-------
Aus dieser Gruppe muss stets genau ein Flag angegeben werden. Diese Flags
bestimmen auf welche Weise die Geschwisterelemente im Menübaum in der
Ausgabe unterdrückt werden.
und auch das angemeckerte $template_function - steht bestimmt seit 10 Jahren in den Richtlinien, die die Urväter/-mütter hier mal festgelegt hatten.
An Hand dieser Definition unterscheiden sich ein Backend-Theme ($template_function = 'theme') und ein Frontend-Template ($template_function = 'template') z.B in der Auswahl unter WB-Optionen usw. Die Themes werden aber nur nach deren Definition abgefragt, also 'theme', darum ist das bisher nicht aufgefallen. Seit WB 2.11 oder so wird aber auch auf 'template' gecheckt
-
Hallo! :-(
Ich hab nun besagte website, die auf 2.8.3 und php7.2 mit template "Simple" eigentlich ganz gut funktioniert nach Anleitung oben auf den aktuellen wb hochziehen wollen.
(Die Umsetzung einer anderen Installation hatte eigentlich schon ganz gut funktioniert und ist im Einsatz)
Wenn ich im aktuellen Fall nun den adminbereich aufrufen will, kommt das login und sonst nichts.
angeblich immer wieder falsch Zugangsdaten.
wenn ich url/upgrade-script.php aufrufe, sagt mir das, das ein config.php erfolgreich von 2.8.3 auf 2.12.x erstellt wurde
und ich z.B F5 drücken soll.
Dann kommt diese Meldung im Browser:
There was an uncatched exception
missing template file maintenance.htt
in line (771) of (/framework/class.wb.php):
und dann immer wieder.
im Frontend von http://firmlinge2.channel-1.de/ erscheint die Meldung
Menü:There was an uncatched exception
Call to undefined function show_menu()
in line (75) of (/templates/simple/index.php):
Ich hab den Upgrade paarmal wiederholt. mit uboot als showmenu2 kam beim ersten mal keine Fehlermeldung dafür aber alle Seiten in einem Handtuch untereinander.
Die Dateien sind aber wirklich alle an dem Platz an dem Sie seien sollten (z.B maintenance.htt)
ich vermute nun unprofessionel, daß der domainname da einen Einfluß haben könnte, wegen Bindestrich?
:roll:
-
Du musst dir immer sicher sein, dass wirklich alle Dateien übertragen und die alten Dateien überschrieben wurden.
Call to undefined function show_menu()
Wurde weiter oben schon mal erwähnt, gegen show_menu2() tauschen.
-
Hallo DBS
Du musst dir immer sicher sein, dass wirklich alle Dateien übertragen und die alten Dateien überschrieben wurden.
Ich bin mir da ganz sicher und hab die page zum ca 4.Mal Male von der funktionierenden 2.8.3 mit 7.2 Version mit Filezilla heruntergeladen, nach Beschreibung auf 2.12.1 geändert und wiederholt hochgeladen / überschrieben /neue verzeichnisse.
Ich komme aber trotzden micht in's Backend und das upgrade-script.php sagt mir (beim 2. Aufruf oder mehr) immer
There was an uncatched exception
missing template file maintenance.htt
in line (771) of (/framework/class.wb.php):
nach Änderung im class.wb.php mit ergänzender Pfadangabe kam dann
}There was an uncatched exception
missing template file /mnt/web012/e1/50/5428950/htdocs/channel-1/dbs/firmlinge2/templates/argos_theme/templates/maintenance.htt und /mnt/web012/e1/50/5428950/htdocs/channel-1/dbs/firmlinge2/admin/themes/templates/maintenance.htt
in line (771) of (/framework/class.wb.php):
Aus
public function correct_theme_sourc e($sThemeFile = 'start.htt') {
$sRetval = $sThemeFile;
if (file_exists(THEME_PATH.'/templates/'.$sThemeFile )) {
$sRetval = THEME_PATH.'/templates/'.$sThemeFile;
} else {
if (is_readable(ADMIN_PATH.'/themes/templates/'.$sThemeFile )) {
$sRetval = ADMIN_PATH.'/themes/templates/'.$sThemeFile;
} else {
throw new InvalidArgumentExce ption('missing template file '.THEME_PATH.'/templates/'.$sThemeFile.' und '.ADMIN_PATH.'/themes/templates/'.$sThemeFile);
}
}
return $sRetval;
was stimmt. Da ist kein maintenance.htt im ordner argos_theme/templates/
muß wohl rein?
:-)
-
Schalte mal die Seite auf das Default-Theme um, WB 2.12.1 funktioniert nur mit diesem, nicht mit argos_theme!!!
Das argos_theme hätte beim upgrade von WB 2.8.3 auf WB 2.12.1 deinstalliert werden müssen.
Gerne kann ich mir das mal mit den Zugangsdaten anschauen, oder du spielst mir das mit einem DB-Backup mal auf meinen Testserver. Und wir schauen uns das gemeinsam an.
Wenn das in deinem Sinne ist, schreib mir eine PM mit deiner E_Mail-Adresse, dann bekommst du die FTP-Zugangsdaten von mir.
LG Harald
-
Hallo!
umschalten konnte ich im Original (ich setze eine Kopie um)
aber jetzt kommt
There was an uncatched exception
missing template file /mnt/web012/e1/50/5428950/htdocs/channel-1/dbs/firmlinge2/templates/wb_theme/templates/maintenance.htt und /mnt/web012/e1/50/5428950/htdocs/channel-1/dbs/firmlinge2/admin/themes/templates/maintenance.htt
in line (771) of (/framework/class.wb.php):
im templates/wb_theme der 2.8.3 ist ja auch kein maintenance.htt
das finde ich im 2.12.1 download im ordner templates/DefaultTheme/templates
einen ordner templates/wb_theme gibt es nicht.
ich find im 2.12.1 download auch kein maintenance.htt im ordner admin/themes/templates wo es eigentlich auch sein sollte.
-
nur mal am Rande - es ist für mich nicht ersichtlich, das hier überhaupt das Upgrade-Script gelaufen ist. Und wenn das so ist, wurde weder in der Datenbank etwas aktualisiert, noch veraltete Dateien wie eben das WB_Theme gelöscht
-
Hallo!
Ja schreib ich doch.
Das Backend nimmt meinen login nicht an. Also startete ich das update script.
Das upgrade_script.php kam zu dem punkt, wo es die config.sys erzeugt hatte und ich F5 drücken sollte.
Ab da kamen beim beim wiederholten Probieren (Backend läßt mich ja nicht einloggen) des upgrade scripts besagten Fehlermeldungen.
das login nimmt nebenbei keinen der 4 möglichen logins an.
:-o
muß das unbedingt "admin" sein ?
-
Hi!
Ha! Es muß admin sein! Und Uboot hat sein Menü wieder!
:-D :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D
-
There was an uncatched exception
missing template file /mnt/web012/e1/50/5428950/htdocs/channel-1/dbs/firmlinge2/templates/argos_theme/templates/maintenance.htt und /mnt/web012/e1/50/5428950/htdocs/channel-1/dbs/firmlinge2/admin/themes/templates/maintenance.htt
in line (771) of (/framework/class.wb.php)
Zur Erklärung, was hier passiert ist......
Das Dateisystem der alten Version 2.8.3 wurde herunter geladen, mit den Dateien der WB 2.12.1 überschrieben und wieder hoch geladen.
In der Datenbank stehen aber noch die alten Einstellungen, wie eben in der settings-Tabelle der Wert "wb_theme" für das Backend-Theme.
Dadurch bauen sich natürlich die Pfade auch falsch zusammen, wie man hier
missing template file /mnt/web012/e1/50/5428950/htdocs/channel-1/dbs/firmlinge2/templates/argos_theme/templates/maintenance.htt
oder hier
missing template file /mnt/web012/e1/50/5428950/htdocs/channel-1/dbs/firmlinge2/templates/wb_theme/templates/maintenance.htt
sehr gut sieht. Durch die manuelle Anpassung der Core-Dateien wird das Chaos dann perfekt
Das Backend nimmt meinen login nicht an. Also startete ich das update script.
Das upgrade_script.php kam zu dem punkt, wo es die config.sys erzeugt hatte und ich F5 drücken sollte.
Das Upgradescript kann nicht starten, wenn du nicht im Backend eingeloggt bist
muß das unbedingt "admin" sein ?
Nein, natürlich muß der Displayname des SuperAdmin's mit dem in der Datenbank übereinstimmen, er muß aber nicht "admin" heißen, es kann auch "PeterPan" sein oder "HansMueller" oder sonst etwas. Wichtig ist, das man auch den SuperAdmin-Account benutzt, nur der User mit der User-ID == 1 darf ein Upgrade ausführen. Aber wenn der displayname des Users mit ID = 1 nun mal admin ist, muß er natürlich auch admin benutzen.
Mal ein Beispiel, das ich hundertfach im letztem Jahr hatte. Person XY, vielleicht Webmaster für das Projekt, hat das alte WB installiert und damals die User-ID == 1 bekommen. Mittlerweile ist er aus dem Projekt ausgeschieden und wurde in der Datenbank manuell gelöscht, dann ist aber kein User mit der User-ID == 1 mehr vorhanden und das Upgrade startet nicht. Hier hilft nur das manuelle Umschreiben in der Datenbank, also das Ändern der User-ID eines funktionierenden Accounts, mit der möglichen Folge, alle Beitragszuordnungen zu verlieren, z.b. in den News (created by, modified_by usw). Die anderen Möglichkeiten wie das Anlegen eines Neuen SuperAdmins spare ich mir, ist zu kompliziert, wenn man nicht ständig mit der Datenbank arbeitet.
-
Hi!
Hatte vergesen, daß es "admin" überhaupt gab, hab ich vor 1/2h gottseidank in der Datenbank gesehen und das Passwort getürkt (andres kopiert)
juchu !!!
-
Und ich glaube, da wurde noch etwas vergessen, drum tu ich es:
Herzlichen Dank den Helfern in diesem Forum, die mit viel Fachwissen noch mehr (fast schon unendlicher) Geduld dabei halfen, das Problem zu lösen und zu einem guten Ende zu führen.
mfg
Paulchen
-
(Y)
Dann weiter viel Spaß und Erfolg mit dem besten WebsiteBaker aller Zeiten.
Die nächste "Stufe" ist schon in Vorbereitung.
-
Hallo!
Ich schließ mich den Ausführungen von Paulchen an. Es ist super, daß da Leute gibt, die Blinde sehend machen
und dabei nie die Nerven verlieren!
:-D :-D :-D :-D :-D