Author Topic: Update auf 2.10.0 scheitert (Read 42022 times)

xandi · « **on:** February 27, 2018, 03:37:35 PM »

Hallo.
Ich wollte meine verschiedenen WB Installationen von 2.8.3 SP auf die Version 2.10.0 upgraden um auf PHP7 umstellen zu können.

Ich habe die entpackten Dateinen hochgeladen und dann www.domain.de/upgrade-script.php ausgeführt.

Dann heißt es sinngemäß: upgrade sucessful - restart oder F5

Dann kommt diese Meldung:
There was an uncatched exception
Invalid admin-directory:
in line (306) of (/framework/initialize.php):

was habe ich da falsch gemacht.

Eingestellt ist im Moment PHP 5.6

dbs · « **Reply #1 on:** February 27, 2018, 04:16:32 PM »

Hi, dein admin Ordner heißt und hieß admin?

xandi · « **Reply #2 on:** February 27, 2018, 04:20:09 PM »

Ja, beides.

Ich habe vor dem Update alles per ftp heruntergeladen, so als Sicherung.

Da heißt der Ordner "admin", der neue hochgeladene auch!

jacobi22 · « **Reply #3 on:** February 27, 2018, 04:29:06 PM »

zeige mal die entsprechende Zeile aus deiner config.php
die, in der ADMIN_DIRECTORY definiert wird, etwa so

define('ADMIN_DIRECTORY', 'admin');

xandi · « **Reply #4 on:** February 27, 2018, 04:33:32 PM »

hier:(sorry, wenn ich ein bisschen kurz angebunden bin, habe einen Arm in Gips

)

<?php
/*
*** auto generated config file for 2.10.0
****[WebsiteBaker]****
*** created at 2018-02-27 03:53:00 Europe/Berlin
*/
// define('DEBUG', false);
define('DB_TYPE', 'mysqli');
define('DB_HOST', '');
define('DB_PORT', '3306');
define('DB_NAME', '');
define('DB_USERNAME', '');
define('DB_PASSWORD', '');
define('DB_CHARSET', 'utf8');
define('TABLE_PREFIX', 'wb_');

define('WB_URL', ''); // no trailing slash or backslash!!
define('ADMIN_DIRECTORY', ''); // no leading/trailing slash or backslash!! A simple directory name only!!

require_once __DIR__.'/framework/initialize.php';
// --- end of file ----------------------------------

jacobi22 · « **Reply #5 on:** February 27, 2018, 04:37:57 PM »

diese Zeile muß so aussehen - nix anderes, keine anderen Zeichen - nur das gewählte admin-Verzeichnis oder halt den Verzeichnisnamen, wenn das Adminverzeichnis umbenannt wurde

Code: [Select]

define('ADMIN_DIRECTORY', 'admin'); // no leading/trailing slash or backslash!! A simple directory name only!!
P.S. Gute Besserung

jacobi22 · « **Reply #6 on:** February 27, 2018, 04:39:30 PM »

WB-URL ist die Domain, mit der diese WB-Installation aufgerufen wird, also inklusive http:// bzw https:// und ohne einen endenen Slash

xandi · « **Reply #7 on:** February 27, 2018, 04:44:16 PM »

danke für die wünsche.

den letzten post habe ich nicht verstanden - ich rufe die WB Backend immer mit domain/admin auf. hat immer funktioniert.

das ist jetzt die neue fehlermeldung:

Exception: "Access denied for user ''@'localhost' (using password: NO)" >> Exception detected in: [/framework/class.database.php]

jacobi22 · « **Reply #8 on:** February 27, 2018, 05:02:09 PM »

Quote

Exception: "Access denied for user ''@'localhost'

heißt, die Zugangsdaten zur Datenbank sind falsch, eines dieser 4
Datenbankname
Datenbank-Host
Username Datenbank
Passwort Datenbank

jacobi22 · « **Reply #9 on:** February 27, 2018, 05:14:05 PM »

mal als Übersicht

DB_TYPE - Datenbankverbindung - immer mysqli

DB_HOST - Hostname der Datenbankverbindung - wird vom Provider vorgegeben, oft localhost, kann aber auch anders lauten, z.b. rdbms.strato.de

DB_PORT - 3306 wäre internationaler Standard, verschiedene Applikationen verwenden ggf auch andere Ports, z.B. WBPortable = 3307

DB_NAME - Name der Datenbank, wird oft vom Provider vorgegeben, aber auch der Name von selbst erstellten Datenbanken möglich

DB_USERNAME - Username zur Datenbank

DB_PASSWORD - Passwort zur Datenbank

DB_CHARSET - in WB 2.10 = utf8 / in WB 2.11 utf8 oder utf8mb4

TABLE_PREFIX - frei wählbarer, optionaler Vorsatz für diese WB-Installation, wb_ wäre ein Vorschlag. Damit lassen sich z.b. mehrere WB-Installationen in der gleichen Datenbank installieren, wenn jeweils andere Prefixe genutzt werden (wb1_, wb2_, usw) . Der Prefix kann auch leer bleiben

Ist man unsicher bei den Datenbank-Zugangsdaten... diese können jederzeit beim Provider eingesehen werden

WB_URL - die Adresse der Webseite, so, wie sie im Browser und für die Startseite aufgerufen wird

ADMIN_DIRECTORY - das gewünschte Adminverzeichnis, Standard ist das Verzeichnis admin. Möchte man einen anderen Verzeichnisnamen wählen, muß dieses admin-Verzeichnis umbenannt werden und dieser Eintrag zur ADMIN_DIRECTORY angepasst werden. Zu verwenden sind Kleinbuchstaben, Zahlen und der Unterstrich. Bei der Angabe des Verzeichnisnamen ist es wichtig, das weder vor noch nach dem gewählten Verzeichnisnamen andere Zeichen stehen, z.b. wie früher zeitweise üblich: Slashes /

eine vorhandene config.php wird beim Upgrade aus der alten Installation eingelesen und mit diesen Daten in eine neue Version geschrieben. Dies erfolgt bei jedem Start des upgrade-Scripts (ab Version WB 2.10 über den Link im Infofenster (i-Button im oberen Menü)

xandi · « **Reply #10 on:** February 27, 2018, 05:17:59 PM »

Soweit klar, die Eingaben muss man ja bei einer Neuinstallation machen.

Frage1: warum wurde das überschrieben?

Frage2: kann ich das aus meiner "Sicherung" wieder hochladen. Wenn ja, aus welchem Ordner

Frage3: Wenn nicht, wo finde ich die Einträge. Ich meine wo muss ich das ausfüllen. Die Daten der Datenbank selbst weiß ich wo ich finde.

jacobi22 · « **Reply #11 on:** February 27, 2018, 05:51:35 PM »

Quote

There was an uncatched exception
Invalid admin-directory:
in line (306) of (/framework/initialize.php):

Früher war es üblich, das WB die config-Datei nicht anfäßt, andererseits wurden aber über die letzten 10 Jahre auch verschiedene Schreibformen gewählt, zum Beispiel auch so etwas hier:

Quote

define('ADMIN_PATH', WB_PATH.'/admin');
define('ADMIN_URL', 'http://domain.tld/admin');

Mögliche verschiedenste Schreibformen wurden dann innerhalb von WB in ein lesbares Format umgewandelt. Seit WB 2.10 werden nun die Daten einer vorhandenen config.php gelesen und in eine neue Datei geschrieben, so das ab Version 2.10 auch in jeder config-Datei die gleiche Schreibform vorhanden ist.
Diese Datei wird auch im Rahmen einer Neuinstallation mit den Daten des Installers geschrieben.
Kam es in WB 2.10 zu einem Abbruch einer Neuinstallation oder des Upgrade-Scripts, hat man im schlimmsten Fall eine config.php, die nicht funktioniert. Dieses Problem ist in WB 2.11 behoben

Man kann nun spekulieren, was obige Fehlermeldung ausgelöst hat. Im Allgemeinen ist sie ein Zeichen dafür, das der Name des Admin-Verzeichnisses, der aus der alten config.php eingelesen wurde, nicht mit dem Namen übereinstimmt, der in der Ordnerstruktur gefunden wurde. Hier hilft dann nur vergleichen und ggf manuell korrigieren. Dazu muß man die alte config.php des Backups mit einem Editor öffnen. Ist das noch eine ganz alte Struktur (mein Beispiel oben), sollte man die config.php vor Starten des Upgrade-Scripts entsprechend deiner Ausführung in Antwort #4 umschreiben und mit Daten füllen. Danach wäre das Upgrade-script noch einmal zu starten und sollte dann auch problemlos durchlaufen.

xandi · « **Reply #12 on:** February 27, 2018, 07:20:38 PM »

hört sich für einen laien kompliziert an.

Geht auch eine Neuinstallation, template das ich angepasst habe neu einspielen, Datenbank nochmal eingeben (bei neuinstallation) und hoffen .....

jacobi22 · « **Reply #13 on:** February 27, 2018, 07:28:56 PM »

ist nicht notwendig, aber immerhin die sicherste Methode

Prinzipiell würde ich dann aber sowieso auf die WB 2.11 gehen, wenn man eine Neuinstallation macht (bei einem Upgrade einer 2.8.3er-Version immer erst auch WB 2.10 upgraden, dann 2.11 )

Wenn du möchtest, reparier ich das für dich, dauert im allgemeinen nur ein paar Minuten, ich würde dann aber die gesamten Zugangsdaten benötigen (FTP, Datenbank, WB-Super-Admin-Zugang)

xandi · « **Reply #14 on:** February 28, 2018, 08:58:32 AM »

Vielen Dank für das Angebot. Ist klar dass ich das nicht einfach so aus der Hand geben möchte.
Dazu kommt dass ich noch 4 weitere WB Sites betreue. Verein, Bruder, und meine drei, sowie noch eine Vereinsseite auf Strato Server.

Ich befürchte nun dass die Probleme bei allen Installationen auftr.eten, weshalb ich die Lösung bzw. umschreiben selber schaffen sollte. Alle WB Installationen habe ich letztes Jahr upgedatet auf 2.8.3 +sp´wg der sicherheitswarnung.

Das hier ist der Kernteil der alten config.php
// define('DEBUG', false);
define('DB_TYPE', 'mysqli');
define('DB_HOST', '');
define('DB_PORT', '3306');
define('DB_NAME', '');
define('DB_USERNAME', '');
define('DB_PASSWORD', '');
define('DB_CHARSET', 'utf8');
define('TABLE_PREFIX', 'wb_');

define('WB_URL', ''); // no trailing slash or backslash!!
define('ADMIN_DIRECTORY', ''); // no leading/trailing slash or backslash!! A simple directory name only!!

Wenn ich wüsste in welcher art die Eingaben gemacht werden müssen, traue ich mir das zu, die änderungen durchzuführern, hochzuladen und das update script neu laufen zu lassen.

Evtl. könnte ich dir die Angaben auch nichtöffentlich schicken, und du füllst mir ein "muster" aus. Dann könnte ich es im bedarfsfall auch bei den anderen installationen nachholen.

jacobi22 · « **Reply #15 on:** February 28, 2018, 09:34:27 AM »

Quote

Ist klar dass ich das nicht einfach so aus der Hand geben möchte.

ich wollte dir das auch nicht wegnehmen

zur config hatte ich oben ausführlich geschrieben, was wo rein müßte. Und sofern da Werte drin stehen, bräuchte man da auch garnichts ändern

xandi · « **Reply #16 on:** February 28, 2018, 10:30:48 AM »

Hurra, das update hat geklappt.

Nur sind nun leider alle umlaute verschossen. gibt es da auch eine lösung?

in der alten config war kein zeichensatz angeben. habe ich übersehen. im backend/optionen ist utf-8 eingestellt

Bei den Umlauten sind nur die Überschriften der Gallerien, Seitentitel (porträtbildhauerei) und Menüs betroffen.

jacobi22 · « **Reply #17 on:** February 28, 2018, 11:24:37 AM »

Quote

Nur sind nun leider alle umlaute verschossen. gibt es da auch eine lösung?

das war dann wohl vorher doch kein utf8

Sicherste Methode für einen Laien ist die Manuelle Korrektur. Theoretisch sollte es alle Textfelder betreffen, jedoch nicht Inhalt, der aus dem Wysiwyg-Editor kommt

Seitentitel + Beschreibung jeder Einzelseite
Webseitenbeschreibung und -titel etc in den WB-Optionen
News oder ähnliche Module - alle Felder, die kein Wysiwyg sind

P.S.: wäre eine einmalige Änderung, die vorallem auf die Änderung bei PHP zurück geht, utf8 als default_charset bei jeder Version ab PHP 5.5 einzusetzen

Es gibt auch Anbieter, die das nicht interessiert, so setzt z.B. Strato bei Neukunden as Datenbank-Charset immernoch auf latin1-swedisch-ci, wohl, um ihre Altkunden nicht zu verprellen. 1&1 macht es ähnlich

xandi · « **Reply #18 on:** February 28, 2018, 12:30:11 PM »

in der alten config fehlte der eintrag:

define('DB_CHARSET', 'utf8');

würde es ausreichen den eintrag zu ergänzen vor dem Update?

jacobi22 · « **Reply #19 on:** February 28, 2018, 12:57:30 PM »

das kann ausreichend sein, muß aber nicht, ist abhängig von dem, was in der Datenbank steht
Zur Erklärung ein Beispiel: ein Seitentitel wurde irgendwann früher mit dem Zeichensatz latin1_swedish_ci (ISO 8851) in die Datenbank geschrieben und dementsprechend codiert, z.b. der Titel "Über uns". Je nach Version von WB und der Stelle, wo es wieder eingelesen wird, wird nun diese Codierung ( Ü für ein Ü - was nur im reinen SQL-Code sichtbar ist) mit der gleichen Methode wieder in für uns sichtbare Schrift umgewandelt.
Nun wird dieser Code, der auch solch Titel in SQL-Schreibweise ist, jedoch mit einer anderen Methode (die zum Umwandeln auf UTF8) ausgelesen und bringt demnach auch ein anderes Ergebnis, z.b. eben ein Ã¼ anstelle eines ü

die config.php wird aber beim Install oder bei Ausführung des Upgrade-Scripts eh neu und mit diesem Eintrag geschrieben

richtig wäre

Code: [Select]

define('DB_CHARSET', 'utf8mb4_unicode_ci');
oder

Code: [Select]

define('DB_CHARSET', 'utf8_unicode_ci');
das so schreiben und danach das Upgrade-Script erneut starten (Link dazu siehe Infofenster - i-Button in der oberen Icon-Bar)

Infos zum Thema -> https://php-de.github.io/jumpto/utf-8/

xandi · « **Reply #20 on:** February 28, 2018, 02:02:34 PM »

nochmals vielen dank!

für alle mit gleichem problem. ERST DEN TIPP VON JAKOBI22 ausführen. Der funzt!

Nur bei den seiten die ich zwischenzeitlich manuell ausgebessert habe nicht. da steht jetzt überall ein kasten mit Fragezeichen statt der Umlaute

jacobi22 · « **Reply #21 on:** February 28, 2018, 02:27:56 PM »

ein "Kasten mit Fragezeichen"

steht für ein Zeichen, das in deinem verwendetem Zeichensatz nicht enthalten ist. Ursache (in aller Regel) ein Umschreiben der alten Table_Collation zur neuen, oft durch Import mit anderem Zeichensatz als das Original

Eventuell wurde auch ein mit UTF8-codiertes Zeichen beim Speichern und der gleichzeitigen Benutzung eines anderen Zeichensatzes als UTF8 (einfach gesagt) nochmals codiert und aus einem Ã¼ wird dann z.B. ein ÃƒÂ¼

Ist man mit PHPmyAdmin, Adminer oder wie Datenbankverwaltung sprogramme alle heißen, vertraut, korrigiert man es am besten gleich dort, setzt natürlich voraus, das man weiß, in welcher Tabelle was drin steht

Eine andere Methode für einen Laien wäre das Einspielen der vorhandenen Datenbank-Backup-Datei und ein erneutes Starten des Upgrade-Scripts über solch Verwaltungsprogramm, allerdings ist das für viele Leute auch ein Angstthema, darum ist der Weg über die manuelle Korrektur oft doch der einfachste.

P.S.: Wichtig für die Darstellung im Frontend ist dort natürlich auch der korrekte Zeichensatz.
Dieser wurde in den meisten WebsiteBaker-Templates durch solch Code flexibel gehalten, d.h. es wird auch die WB-Zeichensatzeinstellung (utf8) ausgelesen.

früher mit

Code: [Select]

<meta http-equiv="Content-Type" content="text/html; charset=<?php if(defined('DEFAULT_CHARSET')) { echo DEFAULT_CHARSET; } else { echo 'utf-8'; }?>" />

heute ab WB 2.8.3 SP7 reicht dieser Code

Code: [Select]

<meta charset="utf-8" />
Hier lohnt auch immer mal ein Blick in den Quellcode der Frontend-Seite, ob dort auch wirklich utf8 drin steht

xandi · « **Reply #22 on:** February 28, 2018, 03:10:39 PM »

Uff, man merkt sofort wer sich auskennt und wer nicht!

ich bin´s auf jeden Fall nicht.

ich denke das liegt daran dass der Befehl mit utf-8 nichts gebracht hat, der mit define('DB_CHARSET', 'utf8mb4_unicode_ci'); dagegen ging.

ich habe nun zu fuss alles ausgebesserte ausgebessert. dabei ist folgende seltsamkeit passiert. manche texte war im frontend zu sehen und im backend nicht

Laienhaft habe ich die Texte rüberkopiert. ob das eine gute Idee war weiß ich nicht! ich hoffe das ganze system ist nicht nun total verschossen.

kann oder soll ich denn nun auch das update auf 2.11.0 wagen?

ruebenwurzel · « **Reply #23 on:** February 28, 2018, 03:43:50 PM »

Hallo,

hatte auch mal das Problem, dass nach Umstellen auf UTF8 insbesonders in der Datenbank abgespeicherte Sonderzeichen von Textfeldern von WB aber auch von einigen Modulen falsch dargestellt wurden. Da ich zu faul war alles händisch zu suchen und zu ersetzen bin ich damals einen anderen Weg gegangen. Folgende Schritte habe ich unternommen:

1.) Export der gesamten Datenbank in einne .sql Datei (über phpmyadmin)
2.) Editieren dieser Datei mit einem Texteditor (Notepad++)
3.) Importieren der bearbeiteten Datei wieder in die Datenbank.

Beim Editieren (Punkt 2) gibt es mehrere Möglichkeiten:
- entweder über suchen und ersetzen alle falschen Zeichen ersetzen
- oder die Textdatei in UTF8 konvertieren (meine bevorzugte Version)

Die Schritte beim konvertieren habe ich mir leider nicht notiert, insofern kann es sein dass die folgenden Schritte in der falschen Reihenfolge dargestellt sind. Muss das später noch einmal durchexerzieren, und würde gegebenenfalls die richtigen Schritte nochmals posten.
- Die Datei, die phpmyadmin liefert ist vermutlich eine UTF8 Datei.
- Diese Datei muss man dann speichern unter ANSI (nicht konvertieren !!)
- Dann die ANSI Datei konvertieren in UTF8
Bei dieser Konvertierung ist es völlig wurscht, wo Sonderzeichen sind, am Ende sollten dann alle Sonderzeichen korrekt in der Datenbank stehen (also "ö" als "ö" und nicht als Zeichenwirrwarr)

Da man sich bei dieser Aktion die Inhalte der Datenbank auch sehr schnell komplett zerlegen kann, bitte immer die im ersten Schritt exportierte .sql Datei als Sicherung separat abspeichern. Falls beim konvertieren und einspielen irgenetwas schief geht, kann man dann die Sicherung wieder einspielen und man hat zumindest den Ursprungszustand wieder.

Die Konvertierung muss in der Regel nur bei älteren WB-Installationen durchgeführt werden. Aktuelle Installationen von WB 2.10 und WB 2.11 sollten alles korrekt darstellen. Da ich WB bereits seit Version 2.3.1 (ja, die gab es auch mal) einsetze und sowohl WB als auch die damaligen Webserver mit dem Zeichensatz sehr abenteuerlich umgegangen sind, musste ich viele Datenbanken nachträglich konvertieren. Habe das aber schon vor einigen Jahren gemacht, so seht mir bitte nach, wenn in obiger Anleitung ein Fehler drin ist. Das schöne am konvertieren ist, hat man einmal seine Datenbankinhalte sauber auf UTF8 konvertiert und setzt eine aktuelle WB-Version ein, hat man nie mehr Probleme mit Sonderzeichen.

Gruß
Matthias

jacobi22 · « **Reply #24 on:** February 28, 2018, 04:00:20 PM »

Quote

define('DB_CHARSET', 'utf8mb4_unicode_ci'); dagegen ging

What??

war da schon WB 2.11 drauf oder wurde solch Install/Upgrade auf WB 2.11dort schon versucht?

Quote

kann oder soll ich denn nun auch das update auf 2.11.0 wagen?

Wenn du mich fragst, darf ich hier eh nur mit JA antworten. Ich halte es aber durchaus für möglich, das in der Datenbank 4-Bit-Zeichen (utf8mb4) vorhanden sind statt den für utf8 üblichen 2-Bit Zeichen
Wer nicht wagt, der gewinnt auch nicht

Eventuell löst sich das Problem dann auch in Luft auf

News

Support WebsiteBaker

Your donations will help to:

You can donate by clicking on the button below.

Author Topic: Update auf 2.10.0 scheitert (Read 42022 times)