Update auf 2.10.0 scheitert

[Gast]

magst mir die SQL-Datei mal schicken? Mailadresse siehe Icon unterm Profilbild

[xandi]

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-&lt

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.

[hgs]

Wünsch dir viel Erfolg.
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.

[xandi]

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  .

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.

[Gast]

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?

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   

[ruebenwurzel]

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

[xandi]

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?

[Gast]

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 Datenbankverwaltungsprogramme 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 Expand

<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 Expand

<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]

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

[Gast]

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 Expand

define('DB_CHARSET',      'utf8mb4_unicode_ci');

oder

Code Select Expand

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]

in der alten config fehlte der eintrag:

define('DB_CHARSET',      'utf8');

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

[Gast]

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]

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.

[Gast]

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]

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.

[Gast]

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]

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 .....

[Gast]

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 umschreiben und mit Daten füllen. Danach wäre das Upgrade-script noch einmal zu starten und sollte dann auch problemlos durchlaufen.

[xandi]

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.

[Gast]

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ü)

[Gast]

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

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

[xandi]

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]

[Gast]

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

[Gast]

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 Expand

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

P.S. Gute Besserung

[xandi]

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 ----------------------------------