WB-2.8.3-SP1 (die weitere, zukünftige Pflege evt. als CE)

[DarkViper]

Da ich gerade etwas Luft habe, bevor ich heute Abend wieder mit ein paar Leuten diskutieren 'darf', die Trans* für eine hochansteckende Krankheit  und Trans*Menschen für -von allen Hemmungen befreite- Sexmonster halten, vor denen die ganze Welt beschützt werden muss, will ich -relativ- kurz an mein Posting vom Dienstag anschließen.

Wie ich am Dienstag schon sagte, habe ich persönlich grundsätzlich rein gar nichts gegen die Idee, die 2.8.3 Community-gesteuert weiter zu führen. Mir ist völlig klar, dass diese Version, unabhängig von Nachfolgeversionen, noch recht lange das Netz unsicher machen wird. Denn im Prinzip läuft sie einfach sehr stabil und recht problemlos. So werden viele Nutzer keinen Grund zu einem Upgrade sehen/finden.
Auf der anderen Seite weiß ich jedoch auch, dass immer wieder mal kleinere und evt. auch größere Bugs auftauchen  werden, die dringend gefixt werden müssen/sollten.
Ich selbst und auch ein evt. wieder erweitertes Team werden diese Aufgaben gar nicht bewältigen können. Das wären dann 3 verschiedene Versionen zu entwickeln und zu warten. Das geht schlichtweg nicht.
3 Versionen? Klar, einmal muss die 2.8.3 noch für einen längeren Zeitraum gewartet werden. Gleichzeitig läuft die Entwicklung der 2.x-Serie die noch vieles an Arbeit erfordern wird sowie bereits die Nachfolgeversion der 2.x Serie.

Jetzt aber zurück zur 2.8.3!
Eine weitere Pflege dieser Version über das offizielle Repository ist durch die Revisionsnummerieru ng technisch nicht möglich. Bereits seit der Initialisierung am 1.Sep.2005 wurden sämtliche Revisionen versionsübergreifen d durchnummeriert. Diese, ursprünglich gut gemeinte, Idee hat an der Stelle jetzt leider in eine Sackgasse geführt.
 
Eine Art "Community-Edition" wäre auch meiner Meinung nach ein guter Weg, die 2.8.3 noch für einige Zeit am Leben zu erhalten.
Wie das ganze aussehen könnte und womit auch ich zu 100% einverstanden wäre, hat cwsoft bereits beschrieben.

[...]
Ich habe NorHeis "WB283-Sammlung" in reine "Patches" (beheben von Fehlern + notwendige Anpassungen an neuere PHP Versionen) und "Features" (z.B. altes News Modul etc.) unterteilt. So kann jeder selbst entscheiden, was er braucht.

Es gibt dann auch die Möglichkeit, "reine Patches" bei Bedarf in ein neues SP zusammen zu packen und direkt in das Auslieferungspaket integriert zu veröffentlichen.
Sogenannte "Features" sollten jedoch funktional getrennt einzeln ebenfalls übersichtlich an zentraler Stelle angeboten werden. Selbstverständlich mit einer für jederman halbwegs verständlichen Beschreibung(bitte kein WB_Fachchinesisch) der jeweiligen Funktionsänderungen dazu.
Ich bin gern bereit einen entsprechenden Link dafür im DL-Bereich der HP und/oder dem Addon-Bereich einzubauen. Auch eine DL-Möglichkeit von der WB-HP wäre, muss aber nicht, durchaus denkbar.

Weshalb die Trennung? Das ist ganz einfach: Nicht jeder will alle 'Feature'-Patches haben, nur weil er per SP eine Sicherheitslücke schließen will. Hier muss der Anwender unbedingt die volle Wahlfreiheit haben, was er installieren will oder eben auch nicht.

Ich möchte Euch jetzt alle bitten, meinen Vorschlag (am besten in einem eigenen Thread) auszudiskutiere, damit wir für die ganze Angelegenheit eine vernünftige, allseits befriedigende und nicht von persönlichen Mimositäten geleitete, Lösung finden.

Manuela

PS: Sobald -relative- Einigkeit herrscht, werde ich den Threadtitel noch entsprechend anpassen.

Nicht vergessen: OffTopic wird in diesem Thread ohne Rücksicht und Hinweis gelöscht!

[jacobi22]

meine persönliche Erfahrung aus vielen privaten Kontakten sagt, das viele auf eine CE verzichten, wenn diese keinen offiziellen Stempel trägt. Mag sein, das sich die Meinung noch ändert, wenn die Probleme akuter werden. Von daher würde ich ein offizielles SP einer CE-Version vorziehen.
Wie das am Ende zustande kommt, steht auf einem anderem Blatt, ich meine aber, das Norbert alles bisher bekannte zusammen getragen hat. Aktuell besteht wohl nur vereinzelt eine Notwendigkeit zur Reparatur, vielleicht können noch ein paar PHP 5.6er Test-Erfahrungen einfließen

[Stefek]

Wenn die CE Version hier entsteht und durchgetestet wird, wäre ein solcher Verzicht unbegründet.
Wie Manuela schrieb:

Ich bin gern bereit einen entsprechenden Link dafür im DL-Bereich der HP und/oder dem Addon-Bereich einzubauen.
Auch eine DL-Möglichkeit von der WB-HP wäre, muss aber nicht, durchaus denkbar.

Es besteht natürlich ein Unterschied zwischen einer WebsiteBaker CE (Community Edition, die weitere Features und vielleicht sogar eine Fortentwicklung anstrebt) und einem reinen Community Patch der 2.8.3.

Christian

[cwsoft]

Hallo,

schön dass es hier mal wieder sachlich weiter geht.

@darkviper: Die Änderungen nach REV 1638 (SP1) sind so umfangreich, die gehören eigentlich in eine WB 2.9 Reihe (z.B. Sprachdateien, Autoloader, Admin themes, config.ini.php ...). Daher würde ich auch gleich einen radikaleren Schritt vorschlagen.

Weg vom Klein-Klein und dem "not-invented here Syndrom":
Der WB-Verein legt auf GitHub/Bitbucket eine neue Organisation an (z.B. WebsiteBaker). Dort werden zwei öffentliche Repos erstellt WB-Org, WB-CE. Da WB seit einigen Jahren ein 1-2 Mann Projekt ist, sollte man sich auf das wesentliche konzentrieren und nicht nebenbei noch Server, Redmine, SVN etc. warten und pflegen müssen. GitHub/Bitbucket müssen nicht extra gewartet werden und haben eine fast 99% Verfügbarkeit. Wenn der Service dann doch mal für 1-2 Stunden ausfällt, erlaubt Git/Mercuri auch das lokale arbeiten (branchen, commit, etc.). Viele OS-Projekte - u.a. auch das CMS SilverStripe - haben durch den Schritt weg vom privat gehosteten Repo hin zu einer Platform with GitHub/Bitbucket einen Push in Sachen OS erlebt.

CE-Edition: Möglicheit 1
Alle Commits seit 1638 werden in das Projekt WB-Org überführt. Alle Commits bis einschliesslich 1638 in WB-CE. Das kann mit, oder auch ohne die alte SVN-Historie geschehen. Die offizielle WB-Entwicklung findet dann öffentlich zugänglich (also nicht ist bereits in meiner privaten 2.9er, meines Servers ...) auf WB-Org statt, die Community-Entwicklung in WB-CE.

CE-Edition: Möglicheit 2
Die WB 2.8.4 für PHP 5.4+ (mysql_, regex...) fit machen (4 Patches von Norhei), testen und veröffentlichen und zwar sehr zeitnah - nicht erst in einem Jahr. Im Anschluss dann den WB 2.8.4 Zweig an die Community übergeben (WB-CE). Parallel kann dann an WB 2.9 (WB-Org) gearbeitet werden. Beides auf GitHub/Bitbucket wie oben beschrieben.

Weitere Entlastungen
a) nach wechsel zu GitHub/Bitbucket, die WB-Projektseite einstellen
b) die WB-Homepage verschlanken (maximal zwei sprachig: DE/EN), keine News die eh nicht gewartet werden
c) wieder mehr öffnen (ja absprachen kosten Zeit. Fällt aber z.B. DarkViper nach Dietmar aus, steht das Projekt vor einem 2-3 jährigen Trümmerhaufen mit vielen notwendigen und tollen - aber nicht fertigen Änderungen unter der Haube. Der oder die das dann übernehmen sollen, haben dann so richtig viel Freude - falls es überhaupt gelingt ...

Soweit mein Senf.

Gruss cwsoft

[hillschmidt]

Wenn ich einmal etwas aus Sicht eines (begeisterten) Nutzers von WB sagen darf:
ZWEI Versionen werden mehr verwirren als hilfreich sein!
Als Alt-Anwender stehe ich vor der Frage, welchem Pfad ich denn folgen werden - der Community Edition (CE) oder der "offiziellen" Version ...
Als potentieller Neu-OpenSource-CMS Anwender (hoffentlich kommen auch noch welche dazu!) finde ich -wenn überhaupt- zunächst einmal die offizielle Version, um dann spätestens  im Forum auf die CE-Version zu stossen ... und dann fängt man doch natürlich an zu zweifeln, ob das CMS WB das Richtige ist.

Marketing-mäßig steht WB meines Erachtens ganz schlecht da im Vergleich zu (Teil-)kommerziellen anderen CMS Systemen ... auch wenn sich auf der Website einiges verbessert hat. Aber das Hickhack um Versionen und Updates im Forum ist nicht wirklich gut - eine neue Sachlichkeit ist da angebracht (wie Manuela/DarkViper das auch angemerkt hat!)

Wirklich hilfreich wäre meines Erachtens nur ein klarer Schnitt: Hier kommt 2.8.4 - auch wenn das vielleicht nur ein 2.8.3 SP2 wäre (technisch gesehen - ich bin kein Entwickler!).
Ein Beheben der erkannten Fehler von 2.8.3 SP1 würde doch zunächst einmal Ruhe an der Front der Rufer nach 2.8.4 geben - klar, ich weiß auch aus den hier geführten Diskussionen, daß 2.8.4 einiges im Core ändern soll - aber es kommt und kommt nicht offiziell, und die Bereitschaft, 2.8.4 nach sooo langer Ankündigungs- und Verschiebezeit zu installieren, sinkt.
Ganz natürlich kommt da doch die Frage auf, ob dieser Neuansatz so mit Kompatibilitätsprob lemen zu Erweiterungen etc. behaftet ist, daß es mehr Fehler im Feld produzieren wird als ein Releasewechsel je zuvor ...

Wie gesagt: ich bin nur ein Anwender ... aber mache mir auch so meine Gedanken, ob WB eigentlich ein Weg mit Zukunft ist.

Liebe Entwickler, rauft Euch doch in irgendeiner Form (vor allem außerhalb des Forums!) wieder zusammen, baut einen stabilen Update auf eine neue Versionsnummer (was im Core dann tatsächlich neu und anders ist, spielt zunächst einmal keine Rolle für den Nutzer), und baut im Hintergrund 2.9.0 (was Eurem eigentlichen 2.8.4 entspräche ...) - aber bringt mal EIN OFFIZIELLES neues Release / Update raus. Baut bitte keine ZWEI WB Versionen ... verzettelt Euch nicht - zieht an EINEM Strang! Danke!

Noch eine Anmerkung: eine Website habe ich mal auf Version 2.8.4 Revision 2101 hochgezogen - lief völlig problemlos. Auch meine Erweiterungen dort (im Wesentlichen die FolderGallery, News, Aggregator, MapBaker, AudioPlayer und andere) laufen unverändert gut! Insofern: es geht doch

Und nutzt die sozialen Netwerke (zumindest Facebook) für WB intensiver als bisher vielleicht bringt auch das neue Mitglieder in der COMMUNITY!

[Stefek]

CE-Edition: Möglicheit 2
Die WB 2.8.4 für PHP 5.4+ (mysql_, regex...) fit machen (4 Patches von Norhei), testen und veröffentlichen und zwar sehr zeitnah - nicht erst in einem Jahr.

(y) Wir brauchen einen "thumbs-up" Smiley.

GitHub, ja, ich verstehe. Wurde so oft angesprochen beim Dev-Team.
Das würde das Projekt aus der Kathedrale auf den Markt bringen.
Zudem hat GitHub gute Einrichtungen um Bugs zu reporten und Features zu besprechen.

Christian

[fischstäbchenbrenner]

Das Problem ist der Stillstand. Ob tatsächlich oder gefühlt - das spielt keine Rolle. Er zermürbt.

Aus meiner Sicht wäre es das beste, man bringt zunächst einmal die WB 2.8.3 wieder auf Vordermann. Einerseits als Servicepack für bestehende Sites, andererseits als Komplett-Download.

Bekannte Sicherheitslücken und Bugs entfernen, vielleicht 1-2 deutlich sichtbare Features dazu, damit man auch einen Unterschied merkt.
Den Durchschnittsuser interessiert nicht allzu sehr, ob da jetzt auch die Datenbank schöner abgefragt wird; er will einfach sehen, dass was passiert.

Schmerzlos wären zb neue Templates beizulegen. In der Praxis werden die eh kaum verwendet, aber sie machen den ersten Eindruck und das ist ja auch wichtig. Und Kompatibilitätsprob leme gibt es deswegen nicht.

Weitere Sache: bei den Core-Modulen (Frontend-Settings) und bei den Search-Optionen die Tabellen raus.
Das ist sehr einfach und es gibt keine kompatibiltätsprobl eme. (Bei news/add.php müsste man die Art übernehmen, wie Topics das macht: Von der zuletzt angelegten Section übernehmen.)

Vielleicht noch irgendein gängiges Admin-Tool dazu, das sich als nützlich und stabil erwiesen hat. AFE oder sowas.

[DarkViper]

Merkt man, daß ich von Hause aus Lehrer bin ?!?  

Nöööö.. absolut nicht. Wenn man nicht gerade, so wie ich, mit einer altgedienten Klassenlehrerin verheiratet ist.  

Ok, back to topic..  (gilt für ALLE... nicht nur für mich!  )
Ich hab ja (wie angekündigt) auch mitgelesen und mir meine Gedanken gemacht.
Alles was hier im Thread läuft soll ja -vorerst- auf die 2.8.3 bezogen sein. Um die geht es hier primär.

Ich würde jetzt gerne sämtliche Patches/Fixes zur 2.8.3 einsammeln und in ein SP2 packen. Bzw. gleich ein komplettes Paket 2.8.3-SP2 zusammenstellen und das 'alte' 2.8.3-SP1 damit ersetzen.
Unter Patches/Fixes verstehe ich in diesem Zusammenhang alles, was mit der Behebung von Sicherheitslücken, Funktionsstörungen sowie Anpassungen an PHP5.5 zu tun hat. Nicht jedoch irgendwelche Zusatzfeatures oder Funktionsänderungen .

Was mich vor allem interessiert ist der -komplette- Patch zur DB-Anpassung(alle betroffenen Dateien). Ich hatte mir den schon vor einiger Zeit mal angeschaut und noch einen kleinen Denkfehler darin gefunden. Darüber will ich allerdings erst reden, wenn ich den neuesten Patch daraufhin getestet habe. Könnte ja durchaus sein, dass das bereits behoben und dadurch jede Diskussion überflüssig ist.

Auf die HP gehören dann noch ausführliche Anleitungen, was beim Wechsel von 2.8 auf 2.9 zu beachten ist ($database etc.). Im Addons-Bereich braucht es ein Feld mit einer Info, ob ein Modul 2.9-tauglich ist oder nicht.

Die HP steht spätestens seit den letzten Serverproblemem sehr, sehr weit oben in meiner persönlichen ToDo-Liste.
Geplant ist, das Labyrinth extrem abzuspecken. Zum Beispiel wird der komplette Hilfe-Bereich gestrichen.
Nein, wir wollen die User natürlich nicht hilflos im Regen stehen lassen. Der bisherige, nur schwer und sehr zeitintensiv zu pflegende Bereich innerhalb der HP wird durch ein eigenständiges Wiki ersetzt, das, wie z.B. wiki.ubuntuusers.de von jedermann ergänzt, verbessert und erweitert werden kann.
Bis jetzt trudeln in der Regel immer nur Beschwerden ein, was wir noch alles schreiben sollen. In Zukunft heißt es dann einfach: 'Selber schreiben!'. Logischerweise nur zu denen, die sich mit dem jeweiligen Punkt auch auskennen.

@hillschmidt:
[...]
Du kannst ja nicht sagen "jetzt gibt es 2.8.4 (oder 2.9), alles was davor war interessiert uns nicht mehr". Das kannst Du für Dich selbst und Deine Installationen so sehen, aber nicht als Projektmanager. Dazu gehört dann eine saubere Abkündigung des Supports, wenn man seriös sein will. Bloß weil es ein Open Source Projekt ist, heißt das nicht, daß man alle Regeln über Bord schmeißen darf.

Aus diesem Grund habe ich um Mithilfe/Übernahme der Pflege der aktuellen 2.8.3 gebeten, da das von mir/uns nicht bewältigt werden kann.

Eine offizielle Weiterentwicklung der 2.8.3 kann und darf es aber auf keinen Fall geben. Nicht weil ich hier meinen bayrischen Steinbock-Dickkopf durchsetzen will, sondern um ein Chaos zu vermeiden.
Nemen wir mal an, es werden zusätzliche Features in die .3 eingebaut und benutzt. Beim Umstieg auf die .4 oder gar auf die 2.9 werden diese dann in aller Regel fehlen. Sei es, weil das bereits völlig anders gelöst wurde, oder in dieser Art im neuen System einfach nicht vernünftig lösbar ist. Die offizielle Erweiterung einer Vorläuferversion setzt nur laufend die aktuelle Entwicklung unter Zugzwang, was letztendlich völlig kontraproduktiv sein kann.

[hillschmidt]

@blackbird: Guter Vorschlag! Das DokuWiki nutze ich für meine Hobbyseite ohne WB: pe.hillschmidt.de
Da könnte ich auch meine Erfahrungen einbringen ... aber, wie gesagt, ich bin kein Entwickler, nur Anwender!

@DarkViper: Super Idee - WB 2.8.3 SP2 - damit würde dann alles gefixt, was gefixt werden muß (Sicherheit, PHP Kompatibilität, etc.) und bisher alles so schön verteilt im Forum geschrieben steht.

[cwsoft]

Hallo,

meine letzter Versuch wieder sachlich zu werden, bevor auch ich hier den Bettel hinschmeisse.
Edit sagt:  nicht nötig, ich musste nur erst wieder am richtigen Rechner sein, da der Netbook für sowas zu lahm ist..
Hier die Datenbank Fixes von NorHei/Marmot (mysql_* -> mysqli_*):
https://code.google.com/p/wbcom/source/detail?r=36512ae344660e3177b1d9a73e425e0793f3f522
https://code.google.com/p/wbcom/source/detail?r=50fad11564fe677edf376745d7b62238a3968db6

Betroffen sind 5 Dateien (habe ne ZIP, kann diese aber nicht anhängen).

Ich werde NorHeis Repo im Laufe des Tages auf meinen GitHub Account schieben und dort belassen, bis es nicht mehr gebraucht wird (NorHei will sein Repo demnächst löschen).

Dann gibt es noch ein paar Patches für veraltete PHP Funktionen (preg_replace mit /e modifier, ini_set):
https://code.google.com/p/wbcom/source/detail?r=044d5590904044a29410965167ba1cd547d53797
https://code.google.com/p/wbcom/source/detail?r=c95f7724eb98542e90bf6bb73402197151d5d14e
https://code.google.com/p/wbcom/source/detail?r=77a3874c83959da4a15998302a2e7b856cafef56

Betroffen sind 4 Dateien (habe ne ZIP, kann diese aber nicht anhängen).

Die meisten der anderen Fixes sind "Backports" der künftigen WB 2.8.4, oder "Features", für die ich persönlich keine Verwendung habe.

Gruss cwsoft

P.S.: Was in zukünftigen Releases vermieden werden sollte. Die WB283-SP1 ist im SVN nicht getaggt, daher nicht wirklich nachvollziehbar. Die ZIP-Datei der WB283-SP1 (REV 1638) auf der WB-Addonseite unterscheidet sich zudem in 2-3 Dateien von der SVN REV 1638. Das ist wenig transparent und fördert nicht gerade das "vertrauen"

[DarkViper]

Hier die Datenbank Fixes von NorHei/Marmot (mysql_* -> mysqli_*):
Betroffen sind 5 Dateien (habe ne ZIP, kann diese aber nicht anhängen).

Ok, wie ich es mir gedacht habe. Es fehlen noch ein paar Dateien.   z.B. die upgrade.script.php.

Auf der anderen Seite sehe ich, dass es eigentlich fast ausschließlich die mysqli_real_escape_ string() Funktion ist.
Ich fände es sinnvoller, die mysql_* und mysqli_* Funktionen völlig aus dem Code verschwinden zu lassen. Das erspart viele erneute Anpassungen, falls doch mal auf PDO  etc. umgestiegen wird.

Deshalb mein Vorschlag: Ich bau die real_escape so wie in der 2.8.4 in die class.database ein. Sollten noch 1-2 andere Funktionen betroffen sein, so die eben auch noch.
Und schon ist der eigentliche Code vom verwendeten Datenbanktreiber deutlich unabhängiger.

Dann gibt es noch ein paar Patches für veraltete PHP Funktionen (preg_replace mit /e modifier, ini_set):
https://code.google.com/p/wbcom/source/detail?r=044d5590904044a29410965167ba1cd547d53797
https://code.google.com/p/wbcom/source/detail?r=c95f7724eb98542e90bf6bb73402197151d5d14e
https://code.google.com/p/wbcom/source/detail?r=77a3874c83959da4a15998302a2e7b856cafef56
Betroffen sind 4 Dateien (habe ne ZIP, kann diese aber nicht anhängen).

show_menu2 sollte eigentlich die Version aus der 2.8.4 problemlos einkopierbar sein. Die wurde zwar gefixt, jedoch keine .4 spezifischen Anpassungen eingebaut.

Die meisten der anderen Fixes sind "Backports" der künftigen WB 2.8.4, oder "Features"
, für die ich persönlich keine Verwendung habe.

Schaug mer mal, wenn was dabei ist, das in .4 sauber läuft und für die .3 auf selbem Weg implementiert wurde, könnte man daraus evt. kleine Zuckerln für Chio machen.

P.S.: Was in zukünftigen Releases vermieden werden sollte. Die WB283-SP1 ist im SVN nicht getaggt, daher nicht wirklich nachvollziehbar. Die ZIP-Datei der WB283-SP1 (REV 1638) auf der WB-Addonseite unterscheidet sich zudem in 2-3 Dateien von der SVN REV 1638. Das ist wenig transparent und fördert nicht gerade das "vertrauen"

Hatte mir auch leichte Bauchschmerzen bereitet, aber zu dem Zeitpunkt, als das SP gepackt wurde, waren bereits zu viele .4 Änderungen zwischen drin, also musste das wie jetzt auch das SP2 manuell zusammengepackt werden.

Das ist ja das große Problem mit der Versionsübergreifen den Revisionierung seit 2005(das Jahr/nicht die Rev-Nr.).
Mit der neuen Version (2.9) werden wir anfangen, nach jedem Rollout ein neues Repo zu starten, das eben immer bei Rev.#1 beginnt. Dadurch bleibt für Vorgängerversionen jederzeit beliebig 'Luft' nach oben für alle Fixes etc.

Manu

[cwsoft]

Hallo,

habe nun das geklonte und nach Git konvertierte Repository von NorHei auf GitHub zur Verfügung gestellt:
https://github.com/cwsoft/wbcom

Ich fände es sinnvoller, die mysql_* und mysqli_* Funktionen völlig aus dem Code verschwinden zu lassen. Das erspart viele erneute Anpassungen, falls doch mal auf PDO  etc. umgestiegen wird.

Ist sicher die sauberste Lösung. In der aktuellen Situation sollte man aber aufhören Sachen zu "vergolden". Sprich sich jetzt auf das wesentliche konzentrieren und die WB 2.8.4 (oder 2.8.3 SP2) rausbringen, nicht nochmals Monate mit technisch zwar besseren, aber für den Endanwender nicht sichtbaren Änderungen zu vertrötteln.

Das ist ja das große Problem mit der Versionsübergreifen den Revisionierung seit 2005(das Jahr/nicht die Rev-Nr.).
Mit der neuen Version (2.9) werden wir anfangen, nach jedem Rollout ein neues Repo zu starten, das eben immer bei Rev.#1 beginnt. Dadurch bleibt für Vorgängerversionen jederzeit beliebig 'Luft' nach oben für alle Fixes etc.

In einem verteiltem SVN wie Git/Mercurial machen die ollen SVN keywords ($Id, $Date, $Revision, $HeadURL ...) eh keinen Sinn und sollten aus den Kommentarblöcken der Dateien ersatzlos gestrichen werden (z.B. über einfach Regex in Notepad++).

In Git erstellt man bei einem neuen Softwarerelease (z.B. SP1) einfach einen neuen Tag (z.B. WB 2.8.3-SP1). Danach kann man einfach weiter entwickeln (z.B. fünf Änderungen ins Repo einführen). Der Git-Befehl: "git describe" spuckt dann sowas wie folgt aus: 2.8.3-SP1-5-g79cae1e (rot:=letzter offizieller Tag, grün:= Anzahl Änderungen seit dieser Version, blau:=Kurzform des SHA1 Hashes des aktuellen Standes = letzter Commit). Mit der Kurzform des SHA1 Hashes hat man den Backlink zur Version im Repository.

Gruss cwsoft

[rjgamer]

Hi,

hab mich gerade durchgelesen und will als langjähriger Nutzniesser von WB auch noch meinen Senf dazu geben: Ihr seid die besten - weiter so konstruktiv - ich freue mich auf das SP für WB2.8.3!

Gruss

[DarkViper]

Ich hab da mal ne Frage, bitte nicht schon wieder als Provokation auffassen...

Wenn ich solch eine -eigentlich berechtigte- Frage als Provokation auffassen würde, dann wäre es echt Zeit für Rente und Rosenbeet.
Obwohl, die Frage gehört ja eigentlich in den/einen 2.8.4 Thread.
Aber egal, solange sich aus einem kurzen OT keine Dauerdiskussion entwickelt, können wir das schon kurz dazwischen schieben.

@Manu: Was spricht eigentlich dagegen, mit den bisherigen Quellen für 2.8.4 den Sprung auf Versionsnummer 2.9 zu wagen? WB verweilt schon viel zu lange im 2.8-Zweig, die umfangreichen Änderungen rechtfertigen den Versionssprung hinreichend, und es würde auch viele andere Dinge einfacher machen. (Z.B. die Tatsache zu begründen, warum manche Module nicht mehr funktionieren, wenn sie $database oder die DB_*-Konstanten benutzen.)

Ich hatte das schon Mitte Mai zu erklären versucht:

[...]
Viele haben sich bereits gewundert, weshalb ich die Versionsnummer nicht bereits jetzt schon deutlich erhöht habe. Die 2.8.4 enthält ja inzwischen schon viele Komponenten, die bereits auf die Nachfolgeversion 2.9 ausgerichtet sind. Jedoch ist diese Version noch weitestgehend abwärtskompatibel. Deshalb blieb sie trotz der ganzen Änderungen in der 2.8.x - Reihe.[...]

Bis zur 2.8.4 sind -bis auf ganz wenige Ausnahmen- viele älteren Techniken nur DEPRECATED, und nicht grundsätzlich verboten. Was auch bedeutet, dass auch ältere, halbwegs sauber codierten Module weiterhin funktionieren werden(abwärtskompatibel).
Fehlfunktionen von Modulen auf Grund von Änderungen in neueren PHP-Versionen spielen in einer anderen Liga, da diese auch ohne jede Änderung an WB selbst genauso aufgetreten wären und behoben werden müssten.
Erst mit der 2.9 werden zwangsweise erste, ernsthaftere Inkompatiblitäten auftreten.

Auch die derzeit noch globale Variable $database funktioniert in der 2.8.4 noch ohne Probleme.
Was jedoch nicht mehr geht ist:   $x = new database();  bzw. eben $x = new WbDatabase();. Ein simpler S&R reicht da jedoch völlig aus um alle new database() gegen $GLOBALS['database'] auszutauschen.

Ob ich jetzt innerhalb einer Funktion/Methode/Klasse mit
global $database;
importiere oder mit
$GLOBALS['database']->doQuery();
direkt anspreche oder mit
$database = WbDatabase::getInstance();,
wiederum importiere, ist für den Moment im Prinzip völlig identisch.
Der Unterschied macht sich erst in der nächsten Version bemerkbar, wenn das 3. Beispiel weiterhin funktioniert und die beiden ersten nicht mehr.

Gut, die alten Konstanten mit den Datenbank-Zugangsdaten die sind ersatzlos weg. Das erfolgte allerdings rein aus Sicherheitsgründen, ebenso wie die Umstellung von der config.php auf die setup.ini.php und hat erst ein mal mit einem Upgrade etc. nichts zu tun..
Wer die Zugangsdaten in seinem Code benötigt, kann sie jederzeit mittels der, durch framework/initialize.php zur Verfügung gestellten Funktionen (aber bitte, bitte die initialize.php auf keinen Fall extra nochmal includen! Die ist grundsätzlich immer bereits geladen!)

(array) function initReadSetupFile()
und
(array) initGetDbConnectDat a(array $aCfg, string $sDbConnectType = 'url')
in Kombination:
= initGetDbConnectDat a(initReadSetupFile(), 'url');
abrufen, wobei eine Verbindungs-URL zurückgeliefert wird, die mit dem normalen PHP-Statement parse_url() in ihre Elemente zerlegt werden kann.

Wobei eigentlich der Aufbau einer zweiten Instanz von WbBatabase auf die selben Datenverbindung irgendwie sinnfrei erscheint. Von einem direkten Einsatz von Treiber-Kommandos ala msql_open() bzw. mysqli_open() etc. ausserhalb der WbDatabase wird dringendst abgeraten!

Völlig anders sieht es natürlich aus, wenn z.B. ein Modul33 zusätzlich auf eine zweite, andere Datenbank zugreifen muss.
Aber auch das ist mit der WbDatabase kein Problem mehr:

Code: [Select]

<?php

$oMyDb = WbDatabase::getInstance('Module33');
if ($oMyDb->doConnect('mysqli://user:password@example.com:3306/DatabaseName?Charset=utf8&TablePrefix=xx_')
{

// mit
$oMyDb = WbDatabase::getInstance('Module33');
// kann dann spaeter jederzeit diese Instanz importiert werden, ohne ueber globale Variablen gehen zu muessen.


[hgs]

Hi,

hab mich gerade durchgelesen und will als langjähriger Nutzniesser von WB auch noch meinen Senf dazu geben: Ihr seid die besten - weiter so konstruktiv - ich freue mich auf das SP für WB2.8.3!

Gruss

Dito!
und liebe(r) BlackBird
als "nur Nutzer" habe ich die Argumente für die 2.8.4 verstanden.
Also weiter so konstruktive und wie gesagt: Freue mich auf das SP für die 2.8.3 und bei Neuigkeiten auf die Tests mit 2.8.4
Meine Testversion 2.8.4 Rev2101 läuft und läuft und...

[Argos]

[Entschuldigung für mein schrecklichen Deutsch  ]

Ich bin kein Entwickler, so ich kann nichts sagen über die technische Aspekte der Zukünft WB. Aber ich kann etwass sagen über wichtige Sachen für Anwender.

Nach meiner Meinung soll ess 1 WB geven, nicht eine CE and eine "Team" Version (wie auch hillschmidt hat erklärt). Dass is sehr verwirrend für Anwender.

Die wichtige Aspekte für ein CMS sind (im English):
1. Looks
2. Core features
3. Usability
4. Addons (Plugins, Modules, Templates)

Die code und andere technische sachen interessiert Anwender NICHTS! Die letzten (3, 4, 5?) Jahren WB is nicht wesentlich weiter entwickeld an die 4 haupt Aspekte. Usability ist noch gut, aber wann ess geht um Looks, Features und Plugins, WB is nicht mit der Zeit mitgegangen. Wordpress hasst alles was WB nicht hasst. Nur Usability ist besser (in meine Meinung) dann die von Wordpress.

Um WB neues Leben zu geben ist es nötwendig die erste Focus zu legen an Core Features und Looks. WB's News feature ist kaum brauchbar für moderne sites. Top Priorität ist die Enwicklung ein kräftige News/Blog feature wie Wordpress oder Joomla 3. Anwender brauchen fast immer ein richtiger News/Blog feature. Dann die Entwicklung ein professionelle Form feature mit gute Usability, und mindestens 1 gute Gallery (mit Lightbox) feature, und mindestens 1 gute responsive generale Template. Und dann soll man die WB website erneuen.

WB 2.8.4 soll alle Patches UND neue "features" erhalten die Norhei hat gesämmelt. Unterscheidt is nicht nötig und gar nicht erwünscht. Ess soll wie schnell wie möglich publiciert müssen worden, und die andere sachen sind für WB 2.9.

WB 3 kann am Hintergrund erwickeld worden, mit alle technischer erbesserungen am Core und soweiter.

Dass ist meine Idee von langzeitiger Anwender Standpunkt. Top Priorität: Entwicklung missing FEATURES, not code und Database erbesserungen die Anwender nicht sehen. WB functioniert für Anwender ohne Probleme wie es ist.

[hillschmidt]

ich habe alles verstanden - und schließe mich Deiner Meinung aus Anwendersicht an!

[fischstäbchenbrenner]

Argos bringt es auf den Punkt. Und ich sehe das ebenso.

Den Devs und allen anderen , die sich über die "gängigen Versionierungsstand ards" herumstreiten, ist nicht klar, dass sie darüber streiten, ob ein i-Tüpferl rund, eckig oder oval sein soll.
Dem Anwender ist das völlig egal.

Jetzt werden natürlich Blackbird und andere sagen: Zuerst müssen die Grundlagen geklärt sein....

Jou:
Ein Taxifahrer, der erst wegfährt, wenn er auf den Meter genau die Strecke vorausberechnet hat - und dazu die Meinung von 30 Kollegen einholen muss, die alle was verschiedenes sagen... nojo: Der macht etwas wesentliches falsch.

[jacobi22]

.

[evaki]

Alle anderen Wortmeldungen sind ebenfalls nur eine Meinungsäußerung und haben ebenso viel oder wenig Einfluß wie die meine.

Als Norbert mit seiner Arbeit begann, hat er sich um Meinungen im positiven Sinne nicht geschert, sondern ein Ziel definiert und ist mit diesem auf Akzeptanz gestoßen. Nochmal zur Erinnerung: Es geht/ging darum bestehende v2.8.3-Installationen betriebsfähig zu halten, ohne daß wegen dieser vorgenommenen Änderungen Patches für eingesetzte Module, Snippets u.a. fällig werden, es sei denn aus gleichen Gründen (PHP-Version).
Seine Lösung war also eine den Verhältnissen entsprechend pragmatische, ohne wieder Grundsatzdiskussion en anzustoßen.
Nun fängt mit Verlaub dieser Mist schon wieder an.

Wer v2.8.4 im Auge hat, könnte diese Diskussion im entsprechenden und vorhandenen Thread führen. Keine Lust (gehabt), aus welchen Gründen auch immer? Tja, dann muß man essen was auf den Tisch kommt.
Ein Verein, einer mit Obhutspflicht(en), hätte tätig werden müssen, als absehbar etwas aus dem Ruder lief. Aber jetzt bitte nicht auf diese Nebenbemerkung einsteigen. Dann sind wir endgültig Off-Topic.
MfG. Evaki

[DarkViper]

Die Arbeit wird nicht weniger... ganz im Gegenteil.
Die nächste Welle wird uns wohl demnächst einholen.
Can't disable strict mode in MySQL?

Ich schreibe zwar schon seit gut 3 Jahren: Bitte schreibt SQL-Statements in strikt... (ok.. evt. nicht gaaanz sooo nett und verständlich )
nur war das halt großteils 'für die Katz'.   Wozu auch? funktionierte doch....

Anscheinend haben neuere MySQL-Serverversionen jetzt bereits gelegentlich Verdauungsprobleme mit etwas salopp gecodeten SQL-Statements. Noch nicht tragisch, aber es beginnt.

Mein Vorschlag(ich mach es längst ebenso): In jeder Datei, die angefasst wird, einfach die Statements gleich mit anpassen, dann dürfte der Löwenanteil bereits erledigt sein, bevor das Theater richtig losgeht.
Das Ziel sollte sein, dass unsere Statements auf jedem Server ausgeführt werden, egal welche Einstellungen dieser gerade hat(solang der nicht zur Waschmaschine umkonfiguriert wurde...).

Wer sich nicht ganz sicher ist, worauf geachtet werden soll... einfach fragen, dann bastel ich ein paar kleine Beispiele dazu.

Manuela

[evaki]

Da frag ich mich warum bei uns zwar schon mit Maria-DB "gespielt" wurde, aber keine Anweisungen zu neueren MySQL-Versionen existieren. Unser Admin wird wohl wie immer eine Antwort parat haben. Ich vermute, daß unsere genutzten Provider -noch- nichts neueres im Sinn haben.
MfG. Evaki
Editor: Das war eine kleine Fehlleistung. Wir benutzen v5.6.10, nur halt nicht im strict-Modus. Soweit ich erinnere war es bei uns bisher nur die Telekom die damit in Erscheinung trat. Wer macht denn sonst "sowas"?

Zum Problem im angegebenen Link. Hier muß man wohl die Zeile mit der Anweisung einfach löschen. So verstehe ich die Doku. In unseren inis fehlt diese auch komplett.

[DarkViper]

Wir benutzen v5.6.10, nur halt nicht im strict-Modus. Soweit ich erinnere war es bei uns bisher nur die Telekom die damit in Erscheinung trat. Wer macht denn sonst "sowas"?

Deshalb ja auch nur eine 'Vorwarnung'.  Jedoch müssen wir eben damit rechnen, dass andere Provider nachziehen. Bei eigenen und Rootservern ist das kein größeres Problem, jedoch aber bei Shared-Hostings, deren Hoster ganz auf Nummer sicher gehen wollen. .. und vorbereitet sein, war noch nie ein Fehler

[evaki]

damit rechnen, dass andere Provider nachziehen

Bisher deutet nichts darauf hin.
Schon 2007 konnte man lesen, daß WebsiteBaker nicht strict-tauglich ist.

Da  das Projekt SP2 zwar erneut angestrebt wird, aber niemand das Vorgehen erläutert, besteht  anscheinend wieder Stillstand. Dafür kommen wieder Ideen und Vorschläge, ohne daß geklärt ist, wer das/was denn nun macht.

Außenstehende bekommen über solche Vorgänge einen fatalen Eindruck. Was für ein Trauerspiel.

MfG. Evaki

[cwsoft]

Hi,

um nochmal auf Argos Post zurückzukommen, was ein gutes CMS ausmacht:

1. looks
2. core features
3. usability
4. Addons

Für mich sind die Punkte 1 und 4 keine reinen "Entwicklerschwerpun kte", hier könnte die Community sich einbringen.

WB hat aktuell genau EINE Entwicklerin (darkviper), zwei Hardcoresupporter im Forum (marmot, jacobi22), zwei halbwegs aktive Modulmaintainer (freesbee, mich aber nur für die jeweils eigenen Module) und gefühlt tausend Leute die gerne mitreden, aber sonst nicht gerade durch sichtbare Resultate glänzen.

In den letzten 2 Jahren wurden Modulentwickler systematisch dazu angehalten keine neuen Module zu entwickeln und auf WB 2.8.4 zu warten. Neue, herausragende Templates, Addons etc. gibt es schon seit Jahren nicht mehr, dafür zuhauf Diskussionen um den heissen Brei.

Um die 4 Punkte von Argos weiter oben anzupacken, braucht es mehr als einen Entwickler, es bräuchte den breiten Support einer an einem Strang ziehenden Community. Beides sehe ich nicht wirklich.

Daher  WB 2.8.4 für MySql und neue PHP Funktionen fit machen und veröffentlichen, kein vergolden unter der Haube, sondern erstmal ein klares Lebenszeichen. Und ja, man könnte auch zwei schicke Frontendtemplates von Chio mit reinpacken und die ollen 2003er Templates entsorgen.

Gruss