WBCE CMS Forum

norhei

Developer

Ehrlich, ich blick das ned "upgrade-script.php"

Früher war das mal eine Einfache Liste von Kommandos , und fertig...

Ich muss da noch 2  Kleinigkeiten für dei DB unterbringen , aber ich hab keine Ahnung wo und wie das gehen soll.
Diese Datei bringt mich irgendwie um den Verstand.

Zuerst einmal müssen da 2 DB queries rein

UPDATE `usr_web207_3`.`wb00users2` SET `group_id` = IF (INSTR( groups_id ,","),SUBSTRING_INDEX(groups_id, ',', 1),groups_id ) WHERE 1;
UPDATE `usr_web207_3`.`wb00users2` SET `group_id` = 1 WHERE groups_id LIKE '%,1' OR groups_id LIKE '%,1,%'; 

Die 2 Reparieren die Gruppeneinstellungen in der Users Tabelle , wenn man jemals bei einem User die Gruppe gewechselt hat, sind die mehr oder weniger kaputt.

Und dann muss bei den Sections noch das Namensfeld dazu.
`namesection` VARCHAR( 255 ) NULL

Wo macht man das in dieser verd... Datei.

marmot

Mitglied

Re: Ehrlich, ich blick das ned "upgrade-script.php"

Hi,

Zuerst einmal müssen da 2 DB queries rein

UPDATE `usr_web207_3`.`wb00users2` SET `group_id` = IF (INSTR( groups_id ,","),SUBSTRING_INDEX(groups_id, ',', 1),groups_id ) WHERE 1;
UPDATE `usr_web207_3`.`wb00users2` SET `group_id` = 1 WHERE groups_id LIKE '%,1' OR groups_id LIKE '%,1,%'; 

Die 2 Reparieren die Gruppeneinstellungen in der Users Tabelle , wenn man jemals bei einem User die Gruppe gewechselt hat, sind die mehr oder weniger kaputt.

hmm, war nicht das Ergebnis bei http://forum.wbce.org/viewtopic.php?id=79 (ich darf keine Links einfügen, cool), dass das Feld group_id weg kann? Warum sollte man es dann updaten? Ich würde es eher löschen oder future feature backup belassen. Auf jeden Fall scheint ja egal zu sein, was drin steht.

Und dann muss bei den Sections noch das Namensfeld dazu.
`namesection` VARCHAR( 255 ) NULL
Wo macht man das in dieser verd... Datei.

grundsätzlich irgendwo. Aber vielleicht bietet sich was in der Nähe von Zeile 450 an, denn da wird schon ein anderes Feld eingefügt.

Eventuell sollte man sich aber vor Änderungen der DB Struktur fragen, wie weit man eigentlich von WB weg will. Das wird aber wohl schon wo anders diskutiert.

Gruß

norhei

Developer

Re: Ehrlich, ich blick das ned "upgrade-script.php"

Fakt ist, im Moment wird group_id noch an mehreren Stellen genutzt und möglicherweise auch in Modulen. Ich habe es erst mal soweit gefixt, das es immer einen validen Inhalt hat und wir uns den Komplettumbau für dieses Release erst mal Sparen.

Allerdings ist jede Hilfe Willkommen. Was hältst Du davon, das Du Dich hinsetzt und alle Schnipsel und Corefunktionen die noch darauf basieren umstellst?
Dann könnte es noch in dieses Release.

Eventuell sollte man sich aber vor Änderungen der DB Struktur fragen, wie weit man eigentlich von WB weg will. Das wird aber wohl schon wo anders diskutiert.

Keine Ahnung , der Patch ist drin , grundsätzlich machen Namen für Sectionen schon Sinn. Implementiert wurde der Patch bevor ich dazu kam , ich möchte nur nen Bug fixen. Es wäre schön wenn Jemand der in der Upgrade den durchblick hat, das mal kurz macht.

Wenn DV sieht was hier passiert , kannst Du dich drauf verlassen, das sie  sich mit dem nächsten Release auf jeden Fall so weit entfernt wie sie kann. Das heißt wir bekommen sowieso Probleme. Zusätzlich bedeutet JEDE Neuerung das wir uns entfernen, Selbst wenn man nur den Hook fürs OPF Dashboard einbaut. Da aber bei WB Classic seit 2.8.1 wirklich gar nichts sinnvolles mehr passiert sehe ich das doch auch sehr gelassen.

Was diesen Thread hier betrifft, mach doch mal einen konkreten Code Vorschlag. Ich versuche mich grade durch das aktuelle Chaos zu wühlen , und muss sagen das ist sehr Anstrengend. Es hat halt immer nur jemand was dazu gebastelt :-(

marmot

Mitglied

Re: Ehrlich, ich blick das ned "upgrade-script.php"

Hi,

Allerdings ist jede Hilfe Willkommen. Was hältst Du davon, das Du Dich hinsetzt und alle Schnipsel und Corefunktionen die noch darauf basieren umstellst?
Dann könnte es noch in dieses Release.

könnte ich machen, aber ohne Zeitdruck und mit der Möglichkeit direkt zu Git Repo zu committen. Insgesamt ist das aber etwas, was eigentlich nichts bringt ausser Arbeit und möglichen Ärger. Die Wahrscheinlichkeit, dass ich was übersehe ist hoch und auch das ein oder andere Modul wird meckern. Und dass dann gleich im ersten Release. Warum sollte man das riskieren? Wenn aber von der community gewünscht, kann ich das schon machen. Einfach per PN mitteilen, dass ich Rechte habe und Sache bearbeitet werden soll.

Wenn DV sieht was hier passiert , kannst Du dich drauf verlassen, das sie  sich mit dem nächsten Release auf jeden Fall so weit entfernt wie sie kann. Das heißt wir bekommen sowieso Probleme.

ich glaube eher nicht, dass sich die wb Leute um die CE kümmern, aber wer weiß. Die Frage war aber auch was die CE sein soll / will. Ich befürchte es wird auf Fork Nr. 3 oder 4 oder so ähnlich hinaus laufen.

Was diesen Thread hier betrifft, mach doch mal einen konkreten Code Vorschlag. Ich versuche mich grade durch das aktuelle Chaos zu wühlen , und muss sagen das ist sehr Anstrengend. Es hat halt immer nur jemand was dazu gebastelt :-(

Das mit dem Basteln wird sich nicht ändern. Nach meiner Auffassung gerade das interessant heir. Das Ganze wird nie ein professionelles CMS werden. Kann und soll es ja wohl auch nicht. Wenn ich sehe wie in WB nun immer mehr Vorschriften gemacht werden, dann mach es mir keinen Spaß mehr. Dann wird es zur Arbeit.
Zum Thema:
Ich würde die Zeilen so schreiben:

[== PHP ==]
"UPDATE $table SET `group_id` = CAST(groups_id AS SIGNED)";
"UPDATE $table SET `group_id` = 1 WHERE FIND_IN_SET('1', groups_id) > '0'";

Und zum Update der Sections Tabelle (hier könnte man nachdenken ob section_name nicht aussagekräftiger wäre):

[== PHP ==]
db_add_field('namesection', 'sections', "VARCHAR( 255 ) NULL");

Im Anhang habe ich da mal ab Zeile 456 eingfügt und ein mal erfolgreich geteset.

Weil du nach konkreten Code Vorschlägen fragst  :
In der groups/index.php arbeitest du mit einer subquery und Fallunterscheidungen um die Anzahl der user pro Gruppe zu ermitteln. Dafür gibt es auch den join und FIND_IN_SET. Das ganze könnte in einer Abfrage dann so aussehen:

[== PHP ==]
$query = "SELECT g.group_id, CONCAT(name,CAST(u.groups_id AS SIGNED), ' (',COUNT(*),')') AS name    

FROM ".TABLE_PREFIX."groups AS g, ".TABLE_PREFIX."users AS u
WHERE g.group_id != '1'
AND (g.group_id = u.group_id
       OR FIND_IN_SET(g.group_id, u.groups_id) > '0')
GROUP BY g.group_id";

Gruß

Edith: Anhang als .zip, da .php nicht erlaubt

Beitrag geändert von marmot (18.08.2015 18:07:48)

cwsoft

Mitglied

Re: Ehrlich, ich blick das ned "upgrade-script.php"

@marmot: Wie lautet Dein GitHub Account Name?

@all: Würde fürs erste Release auch nix mehr gross ändern, vor allem wenn es Probleme mit existierenden Modulen und Co. mit sich ziehen könnte. Testen, Bugs melden und Fixen und die Templates auf nen aktuellen Stand bringen, dürfte noch genug Arbeit sein :-)

---

Account inactive since 2018/11/17.

florian

Administrator

Re: Ehrlich, ich blick das ned "upgrade-script.php"

Hallo,

Das Ganze wird nie ein professionelles CMS werden.

o_O
Ich weiß nicht, ich finde WBCE eigentlich ziemlich professionell. Ich meine, ich setze es für Kundenprojekte ein und verdiene mein Geld damit.

Wenn ich sehe wie in WB nun immer mehr Vorschriften gemacht werden, dann mach es mir keinen Spaß mehr. Dann wird es zur Arbeit.

Ich halte mich ansonsten mangels Fachwissen komplett aus den Entwickler_innen-Diskussionen heraus, aber das ist eine enorm wichtige Feststellung, die ich hiermit dick und fett unterstreichen und unterschreiben möchte. Codeoptimierung und Standardisierung ist gut und schön, aber bitte macht nicht dieselben Fehler wie WB classic.
Wenn alles auf einmal so und so gemacht werden MUSS und Bootstrap verwendet werden MUSS und Module so und so aufgebaut sein MÜSSEN usw., erhöht das nicht wirklich die Erfolgschancen von WBCE und führt zu genau dem, wo ich nicht hinwill, nämlich einem völlig anderen CMS mit hoher Lernkurve und noch weniger kompatiblen Modulen als sowieso schon.

---

Code allein macht nicht glücklich. Jetzt spenden!

norhei

Developer

Re: Ehrlich, ich blick das ned "upgrade-script.php"

"UPDATE $table SET `group_id` = CAST(groups_id AS SIGNED)";
"UPDATE $table SET `group_id` = 1 WHERE FIND_IN_SET('1', groups_id) > '0'";

Gute Idee !

Das mit dem Join schaut auch gut aus !

Nachdem wie ich vermute CWsoft dich freigeschaltet hat ! Magst es auch gleich einbauen ?

@all Ja, denke auch das alte Gruppensystem rauswerfen ist für das nächste Release.

cwsoft

Mitglied

Re: Ehrlich, ich blick das ned "upgrade-script.php"

Nachdem wie ich vermute CWsoft dich freigeschaltet hat ! Magst es auch gleich einbauen ?

Ja ich habe marmot eine Einladung für das WBCE Repository geschickt.

---

Account inactive since 2018/11/17.

easyuser

Mitglied

Re: Ehrlich, ich blick das ned "upgrade-script.php"

Das Ganze wird nie ein professionelles CMS werden.

Naja, ist die Frage, was die Definition eines "professionellen CMS" ist. Das Problem ist hier, dass viele Schritte in Richtung Professionalität auf den Code bezogen natürlich viele Einschränkungen mit sich bringen. Und das ist ja genau das, was viele nicht wollen...

Ich halte mich ansonsten mangels Fachwissen komplett aus den Entwickler_innen-Diskussionen heraus, aber das ist eine enorm wichtige Feststellung, die ich hiermit dick und fett unterstreichen und unterschreiben möchte. Codeoptimierung und Standardisierung ist gut und schön, aber bitte macht nicht dieselben Fehler wie WB classic.

Dazu müsste man erstmal sehen bzw. aufzählen, welche Fehler WB Classic eigentlich macht.
Die Intention von WB Classic ist eben, ein Non-Plus-Ultra zu bieten, was die Codequalität betrifft. Das ist jetzt erstmal kein Problem. Zum Problem wird es aber, wenn es so abläuft wie es seit Jahren besteht. Es wird etwas eingeführt, wieder verworfen, dann was neues eingeführt, aber gleich gesagt, dass es nur der erste Schritt ist, danach etwas anderes kommt.
Das Hauptproblem von WB Classic in Bezug auf die Codeveränderungen sind meiner Meinung nach noch nicht mal die Änderungen an sich, sondern die Konzeptlosigkeit.
Das Paradebeispiel hierfür sind die Neuerungen in 2.8.4 für die Sprachdateien.

Wenn alles auf einmal so und so gemacht werden MUSS und Bootstrap verwendet werden MUSS und Module so und so aufgebaut sein MÜSSEN usw., erhöht das nicht wirklich die Erfolgschancen von WBCE und führt zu genau dem, wo ich nicht hinwill, nämlich einem völlig anderen CMS mit hoher Lernkurve und noch weniger kompatiblen Modulen als sowieso schon.

Naja, die Kompatibilität der Module sollte man aus meiner Sicht nicht zu hoch bewerten.
Wenn klar gemacht wird was geändert werden sollte, kann man auch gerne eine Abwärtskompatibilität einbauen, die man dann gesondert auslagert. Die meisten Module kann man bestimmt relativ problemlos anpassen und ggf. mit dem Autor in Kontakt treten.
Die Lernkurve darf nicht zu hoch sein, das stimmt.
Nur ist das Problem, wenn jeder machen darf was er will (nicht negativ verstehen bitte!) hat man halt wieder recht viele Probleme, siehe z.B. upgrade-script oder so einige historisch gewachsene Module.

Achja, auch recht lustig - das Repository von WB Classic ist jetzt gar nicht mehr einsehbar: http://project.websitebaker.org/project … repository

Beitrag geändert von easyuser (19.08.2015 10:57:05)

norhei

Developer

Re: Ehrlich, ich blick das ned "upgrade-script.php"

Stell dir mal vor DV stellt unsere Bugfixes ein , da müsste sie sich ja schämen 

Edit: hast recht "Sie".

Beitrag geändert von norhei (19.08.2015 19:48:11)

webbird

Administrator

Re: Ehrlich, ich blick das ned "upgrade-script.php"

Sie. Soviel Respekt muß sein.

---

Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

florian

Administrator

Re: Ehrlich, ich blick das ned "upgrade-script.php"

Ich bin gerade dabei, die Doku zu schreiben - funktioniert das Upgradescript schon, bzw. was ist beim Umstieg von WB 2.8.x auf WBCE zu beachten, vorzubereiten,...?
(Meine derzeitige schriftstellerische Tätigkeit ist auch der Grund, weshalb ich selbst gerade nicht zum Testen komme - weder in Punkto Umgradescript, noch Fancybox oder WYSIWYG2 usw.)

---

Code allein macht nicht glücklich. Jetzt spenden!

norhei

Developer

Re: Ehrlich, ich blick das ned "upgrade-script.php"

Soweit ichs überblicke ist das Upgrade script das alte von der WBClassic , plus das zusätzliche Feld und die Korrekturen an der User Tabelle

florian

Administrator

Re: Ehrlich, ich blick das ned "upgrade-script.php"

Kann man das schon einsetzen?

---

Code allein macht nicht glücklich. Jetzt spenden!

cwsoft

Mitglied

Re: Ehrlich, ich blick das ned "upgrade-script.php"

Ich habe das Upgradescript rudimentär überarbeitet. Es kann für Upgrade einer WB 2.8.3 verwendet werden. Aktuell trägt es die Versionen von WB und WBCE in die Datenbank ein, setzt das Admintheme neu und trägt die groups_id ein. Es wird aktuell nichts gelöscht, z.B. alte Templates, oder der fkceditor oder die alte Templateklasse von DV, die nie zum Einsatz kam etc. Denke bis auf letzteres ist das auch ok.

---

Account inactive since 2018/11/17.

marmot

Mitglied

Re: Ehrlich, ich blick das ned "upgrade-script.php"

Ich habe ein upgrade von 2.8.3 SP 4 auf wbce damit erfolgreich getestet. Also grundsätzlich läuft es.

norhei

Developer

Re: Ehrlich, ich blick das ned "upgrade-script.php"

Intention war ja ein funktionierendes WB als erster Stop.
Entrümpelt werden muss noch in mehreren Stufen , aber dabei kann halt auch zwischenzeitlich was kaputt gehen.

florian

Administrator

Re: Ehrlich, ich blick das ned "upgrade-script.php"

Ist eigentlich das "Lösche alle Droplets" (vgl. hier) aus dem Upgrade-Script entfernt?

---

Code allein macht nicht glücklich. Jetzt spenden!

marmot

Mitglied

Re: Ehrlich, ich blick das ned "upgrade-script.php"

Ist eigentlich das "Lösche alle Droplets" (vgl. hier) aus dem Upgrade-Script entfernt?

nun, in diesem Thread geben ja die WB Spezialisten an, dass es kein Problem gibt .
Tatsächlich ist auf dem Weg von SP3 nach SP4 das Modul Droplets in der Liste

[== PHP ==]
$table_list = array('settings', 'groups', 'addons', 'pages', 'sections', 'search', 'users');

verloren gegangen. Deshalb wird dann hier

[== PHP ==]
$file_name = (!in_array("mod_droplets", $all_tables) ? "install.php" : "upgrade.php");
require_once WB_PATH . "/modules/droplets/" . $file_name;

nicht die upgarde.php sondern die install.php ausgeführt. Und darin enthalten ist das böse "drop table".

florian

Administrator

Re: Ehrlich, ich blick das ned "upgrade-script.php"

Oh. Habe dafür Issue #36 eröffnet.

---

Code allein macht nicht glücklich. Jetzt spenden!