WBCE CMS – Way Better Content Editing.
Du bist nicht angemeldet.
Ich biete auf meiner Website das Upgrade + Drüberschauen um pauschal € 100 (+20% Ust) an. Das wird relativ oft in Anspruch genommen, ich mache das daher 1 - 2x / Woche.
So geplagt wie diesmal hab ich mich aber schon lange nicht mehr, das ist gründlich schief gegangen.
Das Error-Log hat in wenigen Minuten 300 MB erreicht, durch einen Bug in einem älteren Modul ("lightbox2") und einen Fehler im outputfilter_dashboard
Ein noch gravierenderer Fehler war: Die Dateiberechtigungen (777/755) war 0 - wodurch sich weder Seiten anlegen ließen, noch irgendwas installieren. Auf die Ursache bin ich lange nicht draufgekommen.
Da man in WBCE 1.4.2 die Module nicht mehr manuell installieren kann, war auch eine Installation per FTP nicht mehr möglich.
Ob es noch weitere Fehler gab, kann ich nicht sagen, ich habs dann entnervt umgekehrt gelöst, so wie ich es bei steinalten WB 2.6 / 2.7 Installationen mache:
1: In die selbe DB eine Neuinstallation rein, mit anderem prefix (zb eben "wbce_")
2: Die Tabellen pages, sections, wysiwyg, menu_link und eventuell andere Module: von "wb_" nach "wbce_" umbenennen (die vorhandenen vorher umbenannt, zb "wbce_dings_hide")
3: Fehlende Felder hinzugefügt. Ich denke: Das sollte auch passieren, wenn ich nochmal ein upgrade mache, muss ich mal probieren.
Auf diese Art gehen natürlich sämtliche User-Daten und sonstige Einstellungen verloren, aber das schadet eh nicht, wenn man die neu anlegt.
Etwas störend:
Stefeks Addon-Monitor funktioniert dann nicht mehr, man findet also die Seiten nicht, die zb Kontaktformulare enthalten haben und man muss daher über die Datenbank suchen.
Bist Du noch an Hintergrundinfos und Lösungsansätzen interessiert?
Auch, wie Du ggf. die Änderungen in 1.4.2 hinsichtlich "Da man in WBCE 1.4.2 die Module nicht mehr manuell installieren kann, war auch eine Installation per FTP nicht mehr möglich." umgehen kannst?
Ich könnte da was zu erklären, ich hatte letztens ähnliche Probleme. Aber ich möchte ungern hier langatmig herumposten, wenn es nicht gewünscht ist.
Offline
Ein noch gravierenderer Fehler war: Die Dateiberechtigungen (777/755) war 0 - wodurch sich weder Seiten anlegen ließen, noch irgendwas installieren. Auf die Ursache bin ich lange nicht draufgekommen.
Der Fehler ist bekannt und wurde im development Branch bereits behoben, siehe hier.
Das Problem tritt aber nur auf wenn ein anderer User als der SuperAdmin (UserID ==1) Etwas an den Einstellungen ändert und speichert.
Da man in WBCE 1.4.2 die Module nicht mehr manuell installieren kann, war auch eine Installation per FTP nicht mehr möglich.
Manuell installieren geht schon noch sofern, das Modul nicht bereits in der DB steht.
Eine Andere Variante die install.php/upgrade.php per Update Script erzwingen oder die Anweisungen der install.php in die upgrade.php kopieren und ausführen (Ist aber nur empfohlen wenn man weis was man macht - dadurch können Daten verloren gehen.)
Offline
boeseroeser schrieb:Ein noch gravierenderer Fehler war: Die Dateiberechtigungen (777/755) war 0 - wodurch sich weder Seiten anlegen ließen, noch irgendwas installieren. Auf die Ursache bin ich lange nicht draufgekommen.
Der Fehler ist bekannt und wurde im development Branch bereits behoben, siehe hier.
Das Problem tritt aber nur auf wenn ein anderer User als der SuperAdmin (UserID ==1) Etwas an den Einstellungen ändert und speichert.
Ja, das war in diesem Fall so, ich war NICHT Admin 1. Der Admin1 (der Webdesigner) hat sich die Website wohl schon seit Jahren nicht mehr angeschaut.
Durch die Neuinstallation hat sich das erübrigt.
Und wenn ich daran gedacht hätte: Man hat ja so seine Scripte...
Manuell installieren geht schon noch sofern, das Modul nicht bereits in der DB steht.
Wie? Ich hab ja die Auswahlliste nicht mehr. ?
Dazusagen möchte ich noch:
Unmittelbar nach dem Upgrade gab es heftige Umlaut-Probleme. Ich habe daher die DB exportiert, zu utf8 konvertiert und dann neu importiert.
Könnte sein, dass einige der Probleme dadurch entstanden sind (?)
Beitrag geändert von boeseroeser (26.02.2020 10:20:39)
Wenn ich es richtig verstanden habe checked WBCE automatisch ob in /modules/, Module drinnen sind die nicht in der DB stehen, dann wird es angezeigt.
*Sofern man SuperAdmin (UserID ==1) ist.
Offline
Stefeks Addon-Monitor funktioniert dann nicht mehr, man findet also die Seiten nicht, die zb Kontaktformulare enthalten haben und man muss daher über die Datenbank suchen.
Warum geht Stefeks Addon-Monitor nicht mehr?
Ich kann mir vorstellen, Du kannst das Tool ganz einfach umbenennen und neu installieren.
Oder hat das auch nicht geklappt?
Gruß,
Christian
“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale
Offline
boeseroeser schrieb:Stefeks Addon-Monitor funktioniert dann nicht mehr, man findet also die Seiten nicht, die zb Kontaktformulare enthalten haben und man muss daher über die Datenbank suchen.
Warum geht Stefeks Addon-Monitor nicht mehr?
Ich kann mir vorstellen, Du kannst das Tool ganz einfach umbenennen und neu installieren.
Oder hat das auch nicht geklappt?Gruß,
Christian
Servus!
Ich weiß nicht, warum:
Installed Modules: 0
0 x Page/Section Modules
0 x TOOLS
0 x SNIPPETS
0 x WYSIWYG EDITORS
Deinstalliert hab ich ihn, die aktuelle Version 0.6.6 eingespielt. Keine Besserung.
Der Addon-Monitor ist unverzichtbar, wenn man alte, historisch gewachsene Websites aktualisiert. Damit findet man den ganzen Schrott sehr schnell und kann sich einen guten Überblick verschaffen. Danke!
Das ist ein Strict-Problem, ich hatte das letztens irgendwo auch, da fehlen nur ein paar Backticks in der functions.php.
Öffne die functions.php und ersetze alle Vorkommnisse von [Leer]function[Leer] durch `function`, das sollte das Problem beheben.
Ansonsten kannst Du statt des Addon Monitors "mein" Tool Section List verwenden.
Beitrag geändert von florian (26.02.2020 13:10:15)
Offline
Ja, da hat florian recht mit den backticks.
function ist auch ein SQL Ausdruck und irgendwie will es dann, wenn eine Column so heißt, dass sie explizit (strict) mit Backticks umsäumt wird.
Gruß,
Christian
“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale
Offline
...Wobei das in der 1.4.2 und auch dem Download vom Addon-Monitor im AOR schon drin ist. Dann scheint es noch ein anderes Problem zu geben.
Offline
Bei diesem Hoster "webgo" hatte ich schon öfter mal Probleme mit der Datenbank.
Das `function` scheint in addon_monitor Version 0.6.6 schon korrigiert zu sein.
Ich habe mir jetzt $sQueryAddons ausgeben lassen und per phpMyAdmin in SQL reinkopiert. DIe Fehlermeldung lautet:
SELECT DISTINCT a . * , IF( s.module IS NOT NULL , 'Y', 'N' ) AS active FROM wbce_addons a LEFT JOIN wbce_sections s ON a.directory = s.module WHERE `function` LIKE '%page%' OR `function` LIKE '%snippet%' OR `function` LIKE '%tool%' OR `function` LIKE '%wysiwyg%' LIMIT 0, 25
MySQL meldet: Dokumentation#1267 - Unerlaubte Mischung von Sortierreihenfolgen (utf8_unicode_ci, IMPLICIT) und (utf8_general_ci, IMPLICIT) für Operation '='
Ich kann damit nichts anfangen.
Beitrag geändert von boeseroeser (26.02.2020 13:54:17)
Haben die Tabellen wbce_sections und wbce_addons die gleiche Speicherengine und Kollation?
Offline
Addons: InnoDB utf8_unicode_ci
sections: MyISAM utf8_general_ci
EDIT: Da hab ich was durcheinander gebracht. Jetzt gehts
Jetzt beide: MyISAM utf8_unicode_ci
Insgesamt sind die Tabellen wie gewohnt Kraut und Rüben (meist MyISAM utf8_unicode_ci, aber auch sowas wie InnoDB latin1_swedish_ci bei NWI)
Was sollte sein? Gibt es da Empfehlungen?
Beitrag geändert von boeseroeser (26.02.2020 14:50:12)
Doofe Frage welches DB Charset hast du bei der Neuinstallation angegeben?
So wie es aussieht war die alte DB uft8 und die neue latin1 (bzw. vise versa) was die ganzen Probleme erklären könnte.
Ob es MyISAM oder InnoDB ist macht nicht so viel aus (muss der Modulentwickler entscheiden).
Beim charset ist eine Mischung aus latin1_irgendwas und uft8_irgendwas nicht ideal, bei utf8(mb3)_unicode_ci und utf8mb4_general_ci ist dass nicht so Problematisch.
Offline
So wie es aussieht war die alte DB uft8 und die neue latin1 (bzw. vise versa) was die ganzen Probleme erklären könnte.
Da kann ich dir ein lautes Lied davon singen..
Praktisch IMMER hat man gemischte Kollationen in der DB, kreuz und quer von latin, swedish, utf8 general utf8 unicode usw.
Warum das so ist, ist mir ein Rätsel, vor allem auch, warum das sogar bei Neuinstallationen so ist.
Gibt es ein Script, das ALLE Tabellen auf einen - hoffentlich endgültigen - Wert umstellt?
Warum das so ist, ist mir ein Rätsel, vor allem auch, warum das sogar bei Neuinstallationen so ist.
Ich denke das kommt daher, weil unterschiedliche Module auf unterschiedliche Weise die DB Tabellen anlegen (in ihrer jeweiligen install.php).
Beispiele:
https://github.com/WBCE/WBCE_CMS/blob/d … ll.php#L27
https://github.com/WBCE/WBCE_CMS/blob/d … ll.php#L32 (nix angegeben)
https://github.com/WBCE/WBCE_CMS/blob/d … n.php#L254
https://github.com/WBCE/WBCE_CMS/blob/d … e.php#L540 (der SQL Importer selbst).
Gruß,
Christian
“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale
Offline
Naja: Es kommt daher, dass sich (seit Jahren) niemand auf eine eindeutige Empfehlung festlegen will.
Man bekommt im wesentlichen nur so allgemeine Hinweise, dass wohl utf8 (welches auch immer) besser sei als latin.
SIehe oben utf8_unicode_ci vs. utf8_general_ci: Es klemmte, weil die Tabellen verschieden waren. Das wird wohl sehr häufig sein, wenn es keine Festlegung gibt.
Die meisten Module geben wohl nichts vor, weil es ja eigentlich nicht Sache des Modul-Autors ist, hier einzugreifen. Und es ist nicht Sache des Anwenders, in der DB herumzustochern - schon gar nicht, wenn man nix genaues weiß.
Irgendwann wird man sich festlegen MÜSSEN.
Dass bei dieser Website das Update so problematisch war, liegt v.a. daran, dass bei diesem Hoster (Webgo) sehr strenge Datenbank-Einstellungen sind. Wahrscheinlich hat es schon im Update-Script Fehler gegeben. Das wird wohl immer häufiger vorkommen.
Ja, ich wäre auch dafür, dass es vereinheitlicht wird.
Christoph scheint dafür der richtige Kandidat zu sein 
“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale
Offline
Ich würde für eine Festlegung auf utf8mb4_unicode_ci plädieren, z.B. damit mehr Sprachen/Sonderzeichen unterstützt werden oder man auch Emojis einfügen kann (vgl. https://forum.wbce.org/viewtopic.php?pid=29251#p29251)
Ich weiß aber nicht, ob das bei allen Anbietern verfügbar ist.
Offline
boeseroeser
utf8mb4_unicode_ci
Damit lassen sich vor allem die ganzen Emojis anzeigen, die per Smartphone so daherkommen. Zumindest was genormt ist.
Bei GlobalComments bin ich da auf das THema gestoßen; hab es dann so gelöst, dass die üblichen Kandidaten ;-)
usw in Ascii geändert werden, und der Rest ist eben Fragezeichen. War mir nicht so vordringlich, ich muss keine lachenden Schei**haufen haben..
Eine frische Wordpress-Installation legt durch die Bank an:
utf8mb4_unicode_520_ci
Seltsamerweise steht drunter Gesamt: MyISAM latin1_swedish_ci
Keine Ahnung ob das ein Bug ist, oder ob das die Datenbank-Grundeinstellung ist. EDIT: Wenn ich eine Tabelle anlege und NICHTS bei Kollation oder Engine angebe, wird MyISAM latin1_swedish_ci verwendet.
Beitrag geändert von boeseroeser (26.02.2020 21:27:04)
Festgelegt wurde ja schon WBCE verwendet utf8_unicode_ci, falls ein Entwickler eine andere nimmt wird diese genommen und falls keine definiert ist wird die der DB, verwendet.
MySQL 8.0 verwendet als default bereits utf8mb4, utf8mb4_unicode_ci ist Gegenwart und Zukunft, da utf8mb4 echtes utf8 ist und viel kann was andere Varianten nicht können.
utf8(mb3) ist zu utf8mb4 identisch nur dass utf8mb4 mehr speichern kann.
in phpmyadmin gibt’s in der DB unter Operationen einen Button um Tabellen und Spalten in eine andere Kollation umzuwandeln.
Für das was WBCE können muss reicht utf8(mb3), ob die DB jetzt utf8(mb3) oder utf8mb4 hat ist egal, da kompatible, aber wenn möglich (kein muss) utf8mb4 verwenden, da es eben echtes utf8 ist.
Ganz durchgestiegen bin ich noch nicht, da es einmal schlecht bis gar nicht dokumentiert ist, teilweise eine verwirrende Namensgebung vorhanden ist, gut gemeinter Pfusch in der Vergangenheit die aktuellen Probleme erzeugt und der Unwille von den Entwicklern alte Zöpfe abzuscheiden um fehlerfrei und modern neu zu starten.
Wobei ich sagen muss dass 2020/2021 durchaus interessant wird, PHP 8 kommt und bei den DB laufen 4 Meilensteine aus.
Wer leichte Charset Leküre braucht: Unterschied zwischen gernal_ci und unicode_ci.
Wer eine Motivation auf ein oder mehrere Feierabendbiere braucht: Supported Character Sets and Collations der mariaDB
Offline
Seltsamerweise steht drunter Gesamt: MyISAM latin1_swedish_ci
Keine Ahnung ob das ein Bug ist, oder ob das die Datenbank-Grundeinstellung ist. EDIT: Wenn ich eine Tabelle anlege und NICHTS bei Kollation oder Engine angebe, wird MyISAM latin1_swedish_ci verwendet.
Ja dass bei Gesamt ist die DB an sich.
Offline
Nachtrag:
Das ist mir nie aufgefallen, dass man mit phpMyAdmin ALLE Kollationen auf einmal ändern kann. Na, das hab ich gleich mal bei einer Testsite probiert. utf8mb4_unicode_520_ci, weils so schön klingt.
Geändert hat sich nichts (ist auch eine einfache, sehr kleine Website)