WebsiteBaker Community Forum
WebsiteBaker Support (2.10.x) => General Help & Support => 
Hilfe & Support (deutsch) => Topic started by: 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
-
Hi, dein admin Ordner heißt und hieß admin?
-
Ja, beides.
Ich habe vor dem Update alles per ftp heruntergeladen, so als Sicherung.
Da heißt der Ordner "admin", der neue hochgeladene auch!
-
zeige mal die entsprechende Zeile aus deiner config.php
die, in der ADMIN_DIRECTORY definiert wird, etwa so
define('ADMIN_DIRECTORY', 'admin');
-
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 ----------------------------------
-
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
define('ADMIN_DIRECTORY', 'admin'); // no leading/trailing slash or backslash!! A simple directory name only!!
P.S. Gute Besserung
-
WB-URL ist die Domain, mit der diese WB-Installation aufgerufen wird, also inklusive http:// bzw https:// und ohne einen endenen Slash
-
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]
-
Exception: "Access denied for user ''@'localhost'
heißt, die Zugangsdaten zur Datenbank sind falsch, eines dieser 4
Datenbankname
Datenbank-Host
Username Datenbank
Passwort Datenbank
-
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ü)
-
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.
-
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:
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 (https://forum.WebsiteBaker.org/index.php/topic,30775.msg214476.html#msg214476) umschreiben und mit Daten füllen. Danach wäre das Upgrade-script noch einmal zu starten und sollte dann auch problemlos durchlaufen.
-
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 ..... :oops:
-
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)
-
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.
-
Ist klar dass ich das nicht einfach so aus der Hand geben möchte.
ich wollte dir das auch nicht wegnehmen :-o :-o :-o
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
-
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.
-
Nur sind nun leider alle umlaute verschossen. gibt es da auch eine lösung?
das war dann wohl vorher doch kein utf8 :roll:
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
-
in der alten config fehlte der eintrag:
define('DB_CHARSET', 'utf8');
würde es ausreichen den eintrag zu ergänzen vor dem Update?
-
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
define('DB_CHARSET', 'utf8mb4_unicode_ci');
oder
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/
-
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 :x
-
ein "Kasten mit Fragezeichen" (https://i.gyazo.com/ea547af8d180d6d7cd2fc1a31b2c86fb.png) 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
<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
<meta charset="utf-8" />
Hier lohnt auch immer mal ein Blick in den Quellcode der Frontend-Seite, ob dort auch wirklich utf8 drin steht
-
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 :-o :-o :-o
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?
-
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
-
define('DB_CHARSET', 'utf8mb4_unicode_ci'); dagegen ging
What?? :-o :-o :-o
war da schon WB 2.11 drauf oder wurde solch Install/Upgrade auf WB 2.11dort schon versucht?
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 :wink:
-
Oh gott, schreck. Wenn ich es mir leisten könnte, würde ich ja die Finger davon lassen.
Nein, 2.11 war nicht drauf! Lesen kann ich gerade noch :|. Es steht ja ganz rot dort, dass man erst 2.10 aufspielen muss.
ich träume ja auch eher von der "in luft auflösen" lösung 8-).
in der info über die datenbank übrigens steht latin1.
Ich werde morgen mal ein upgrade versuchen. mein hoster macht in der nacht immer automatisch ein datenbank backup, das ich dann relativ einfach einspielen könnte.
-
Wünsch dir viel Erfolg. (Y)
Hab es auch als DAU hinbekommen, mit der tollen Hilfe hier im Forum.
Seit gestern laufen alle 5 Webseiten auf WebsiteBaker 2.11 mit php7.2 sauber unter utf8.
-
Ich habe nun zwei Installationen auf 2.11 upgegradet.
Die erste, die auch nach dem ersten Update nur in den Menüs Probleme machte, ging einwandfrei.
Die zweite, von der ich hier die ganze Zeit schon schreibe, ist wieder komplett verschossen. Obwohl ich vorher alle Umlaute manuell ausgebessert hatte. Grrrr.
Weiter habe ich versucht:
1. Die 'utf8mb4_unicode_ci' die in der config eingetragen war auf utf-8 geändert - keine Lösung.
2. Die Datenbank wie im Tipp von Rübenwurzel, exportiert, in Text-Datei umgewandelt, alle falschen Umlaute geändert, und als *.sql wieder eingespielt.
Dabei kam die Fehlermeldung:
Statische Analyse:
9 Fehler wurden während der Analyse gefunden.
Unerwarteter Statement-Anfang. (near "Datenbank" at position 1)
Unerwarteter Statement-Anfang. (near "alexand_db4" at position 11)
Unerwarteter Statement-Anfang. (near "Tabellenstruktur" at position 27)
Unerwarteter Statement-Anfang. (near "für" at position 44)
Unerwarteter Statement-Anfang. (near "Tabelle" at position 48)
Unerwarteter Statement-Anfang. (near "wb_addons" at position 56)
Unerwarteter Statement-Anfang. (near "Spalte" at position 76)
Unerwarteter Statement-Anfang. (near "Typ" at position 83)
Unerkannte Statement-Typ. (near "Null" at position 87)
SQL-Befehl:
=Datenbank alexand_db4 == Tabellenstruktur für Tabelle wb_addons |------ |Spalte|Typ|Null|Standard |------ |//**addon_id**//|int(11)|Nein| |type|varchar(20)|Nein| |**directory**|varchar(128)|Nein| |name|varchar(250)|Nein| |description|text|Nein| |**function**|varchar(48)|Nein| |version|varchar(255)|Nein| |platform|varchar(255)|Nein| |author|varchar(255)|Nein| |license|varchar(255)|Nein| == Daten für Tabelle wb_addons |144|module|event|Event Calendar|This module is a event calendar|page|1.8b3|2.6.x|Bennie Wijs, Matthias Gallas, Rob Smith, Marc Geldon, Ploc|GNU General Public License |142|module|wysiwyg|WYSIWYG v3.0.7|This module allows you to edit the contents of a page using a graphical editor|page|3.0.7|2.11.0|Ryan Djurovich|GNU General Public License |143|module|lightbox2|Lightbox2|This module adds support for the open source Lightbox javascript. http://www.huddletogether.com/projects/lightbox2/ and for the script at http://www.justinbarkhuff.com/lab/lightbox_slideshow/|page|0.911|2.7.x|Christian Thamer, Tom Schiemer|GNU General Public License |140|module|code|Code v3.0.3|This module allows you to execute PHP commands (limit access to users you trust!!)|page|3.0.3|2.11.0|Ryan Djurovich|GNU General Public License |141|module|colorbox|colorbox_v1.6|ColorBox v1.6 - a full featured, light-weight, customizable lightbox based on-<
MySQL meldet: Dokumentation
#1064 - Fehler in der SQL-Syntax. Bitte die korrekte Syntax im Handbuch nachschlagen bei '=Datenbank alexand_db4
== Tabellenstruktur für Tabelle wb_addons
|------
|Spa' in Zeile 1
Die Fehler sind nach wie vor vorhanden.
Natürlich kann das an meiner "hemdsärmeligen" Vorgehensweise liegen. Wie man eine Datenbank in "ANSI" umwandelt, bekomme ich nicht heraus. Ich kann über meinen Hoster auch nur die aktuelle Datenbank öffnen. Die Backups der letzten 14 Tage kann ich nur wieder einspielen.
Als letzte Lösung fällt mir nur noch ein, eine alte Datenbank Sicherung einzuspielen. Bevor ich das tue, wollte ich aber erst ein OK vom Forum.
-
magst mir die SQL-Datei mal schicken? Mailadresse siehe Icon unterm Profilbild