WebsiteBaker Community Forum
WebsiteBaker Support (2.8.x) => 
Hilfe & Support (deutsch) => General Help & Support => Diskussion über WB (closed) => Topic started by: DarkViper on July 24, 2014, 03:58:34 PM
-
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!
-
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
-
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
-
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
-
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!
-
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
-
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.
-
Merkt man, daß ich von Hause aus Lehrer bin ?!? :mrgreen:
Nöööö.. absolut nicht. Wenn man nicht gerade, so wie ich, mit einer altgedienten Klassenlehrerin verheiratet ist. :-P
Ok, back to topic.. (gilt für ALLE... nicht nur für mich! :roll:)
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.
-
@blackbird: Guter Vorschlag! Das DokuWiki nutze ich für meine Hobbyseite ohne WB: pe.hillschmidt.de (http://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.
-
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" :wink:
-
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" :wink:
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
-
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
-
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
-
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:
<?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.
-
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...
-
[Entschuldigung für mein schrecklichen Deutsch :roll:]
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.
-
ich habe alles verstanden - und schließe mich Deiner Meinung aus Anwendersicht an!
-
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.
-
.
-
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
-
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? (http://www.WebsiteBaker.org/forum/index.php/topic,27442.0.html)
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
-
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.
-
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 ;)
-
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
-
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
-
Wer sich nicht ganz sicher ist, worauf geachtet werden soll... einfach fragen, dann bastel ich ein paar kleine Beispiele dazu.
mach es doch einfach ;-)
-
Daher WB 2.8.4 für MySql und neue PHP Funktionen fit machen
Gilt die MySql-strict-Empfehlung für beide Projekte (v2.8.3 SPx/v2.8.4)?
MfG. Evaki
-
Daher WB 2.8.4 für MySql und neue PHP Funktionen fit machen
Gilt die MySql-strict-Empfehlung für beide Projekte (v2.8.3 SPx/v2.8.4)?
wird eigentlich in Manu's letztem Post beantwortet
Ich schreibe zwar schon seit gut 3 Jahren: Bitte schreibt SQL-Statements in strikt...
...Mein Vorschlag(ich mach es längst ebenso): In jeder Datei, die angefasst wird, einfach die Statements gleich mit anpassen
in der 2.8.4 ist sicher schon die Hälfte angepasst, in meinen Projekten ca 3/4
-
Gilt die MySql-strict-Empfehlung für beide Projekte (v2.8.3 SPx/v2.8.4)?
wird eigentlich in Manu's letztem Post beantwortet
Das Thema heißt: WB-2.8.3-SP1 (die weitere, zukünftige Pflege evt. als CE)
Und noch einmal: Es geht -bisher- darum bis zum Erscheinen einer v2.8.4/v2.9 die v2.8.3 betriebsfähig zu halten, ohne kapitale Änderungen wie in der v2.8.4 vorzunehmen, eine Brücke also. Sonst könnte "man" auch die v2.8.4 vollenden. Die v2.8.4 vollendet anscheinend jeder der dazu in der Lage ist für sich. Wunderbar.
Man könnte, sollte und hätte führte bisher nicht zum Erfolg.
Das von Norbert erstellte Paket "muß" raus, wenn sich ein paar Leute zum Testen entschließen.
Wenn nötig gibt es noch mehrere SP 2,3,4,5,6. und Patches, eben an die Gegebenheiten angepaßt, und auf der Downloadseite aufgeführt.
MfG. Evaki
-
Gilt die MySql-strict-Empfehlung für beide Projekte (v2.8.3 SPx/v2.8.4)?
wird eigentlich in Manu's letztem Post beantwortet
Das Thema heißt: WB-2.8.3-SP1 (die weitere, zukünftige Pflege evt. als CE)
sag mal.... hat dir wer was in deinen Tee getan?? :roll:
du fragst, ob das auch für die 2.8.4 gilt und regst dich dann über eine dazu Antwort auf?
Sicher gilt diese Empfehlung auch für die 2.8.3, da wurde da ja das Problem auch festgestellt. Ob ihr da jetzt eine Dringlichkeit drin seht, müßt ihr doch für euch entscheiden, siehe
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 ;)
-
du fragst, ob das auch für die 2.8.4 gilt und regst dich dann über eine dazu Antwort auf?
Cholerische Ausbrüche tu ich mir heute nicht an, und unaufgeregt bin ich zudem auch.
Schau Dir den Text von cwsoft an, und die Antwort (#34 am: Heute um 12:50:58) darauf,
dann kennst Du die Reihenfolge. Deshalb die Nachfrage, weil hier das Thema v.2.8.3 ist. Nicht mehr und nicht weniger.
Ist es so schwierig beim Thema zu bleiben?
MfG. Evaki
-
du fragst, ob das auch für die 2.8.4 gilt und regst dich dann über eine dazu Antwort auf?
Schau Dir den Text von cwsoft an, dann kennst Du die Reihenfolge. Deshalb die Nachfrage, weil hier das Thema v.2.8.3 ist.
dann solltest du vielleicht ihn zitieren und nicht mich
aber schon interessant, das man den paar Leuten, die hier noch wirklich aktiv sind, noch die Meinung verbieten möchte. Wo ist eigentlich dein Anteil?
-
mach mal Butter bei die Fische....
aktuell gibt es ein funktionierendes "Erste-Hilfe-Paket" für die WB 2.8.3, das von den Leuten hier zusammengetragen wurde. Fasse ich eure Rückmeldungen zusammen, wurde auch getestet und alles für okay befunden. (diese Strict-Geschichte lass ich mal außen vor, weil ich eher eine Dringlichkeit im SP2 sehe. Für eine "Strict-Umstellung" muß man sicher 80% der Dateien anfassen, das macht man nicht mal eben nebenbei - der Vorschlag SP3 oder gar SP4 ist ja auch nicht verkehrt.
Auf der anderen gab es schon mehrere User-Posting, die ihre Bedenken an der Nutzung solcher Pakete ohne einen offiziellen Stempel angemeldet haben, eine Meinung, die ich durchaus teile. Es geht um ein Core-Update, das sollte schon offiziell sein. Was nützt eine CE, wenn niemand das Vertrauen darin hat.
Das schließt ja nicht aus, das es auch ein Community-Paket mit Erweiterungen aller Art geben kann, ist aber eine andere Baustelle.
Frag mich jemand nach meiner Meinung, dann wird eine eventuelle aktuelle Entwicklung künftiger WB-Version unterbrochen und vorrangig ein SP2 auf die Beine gestellt. Das Paket ist eigentlich komplett und der meiste Code davon eh durch Manu's Hände gegangen.
Im Hinterkopf sollte man vielleicht behalten, das die bisherige Arbeit und wohl auch die an zukünftigen Projekten umsonst war, wenn man solch (bald) notwendiges SP nicht gebacken bekommt. Wer einmal das System wechseln mußte, weil seine Probleme nicht gelöst werden konnten, kommt sicher nicht wieder, egal, welche Neuheiten dann später kommen.
-
Ich stelle z.Z. einige Fragen, und zwar zum Topic. Bekomme bis auf Ausnahmen aber Antworten zu Gott und die Welt.
Testen betrachte ich erst wieder als sinnvoll, wenn ein entsprechendes Paket bereitsteht, was auch sonst. Anscheinend sehen das auch andere so, wenn man die Abstinenz als Maßstab nimmt.
Editor: Sehe soeben, daß Du schneller warst Das lese ich mir erstmal durch :-D
Fasse ich eure Rückmeldungen zusammen, wurde auch getestet und alles für okay befunden.
Bin mir nicht mehr sicher, meine aber noch auf eine Nachfrage keine befriedigende Antwort erhalten zu haben. Zumindest schien es mehrere Lösungen zu geben. (Muß ich mal rauskramen Bin dabei)
Ob die Strict-Konfiguration nun schon in v2.8.3 rein muß?
Im Moment wohl nicht zwingend, da noch Einzelfälle.
Könnte man als ServicePack nachreichen, erst recht wenn man Deine Einschätzung (80% der Dateien) teilt. Zwischenzeitlich könnte ja dann auch schon die v.2.8.4 + freigegeben sein. Die Vorgehensweise sollte m.E. im Team (DEV/Community) abgesprochen werden.
So, nun ist's gekramt und gefunden. Es ging um SERVER_ADDR
http://www.WebsiteBaker.org/forum/index.php/topic,27345.msg188644.html#msg188644
Darauf gab's mehrere Antworten.
Deaktivieren
Code von DarkViper
und meine Antwort darauf.
Frag mich jemand nach meiner Meinung, dann wird eine eventuelle aktuelle Entwicklung künftiger WB-Version unterbrochen und vorrangig ein SP2 auf die Beine gestellt.
Das kann ich so nicht teilen, da die Arbeit am SP aus der Unterbrechung der Entwicklung an v2.8.4 entstand. Ein SP braucht es, damit die schon jetzt auftretenden Probleme bei v2.8.3 beseitigt werden. Man kann die Nutzer "nicht im Regen stehen lassen". Das könnte sonst tatsächlich eine Abwanderung auslösen.
Und ja, offiziell abgesegnet sollte ein SP schon sein.
MfG. Evaki
-
Nur kurz der aktuelle Stand:
SP32 ist bis Montag komplett (so wie's derzeit ausschaugt) und ich werd es mal intern zum Testen freigeben. Wie ich mich kenne, hab ich garantiert noch ein paar Tippfehler drin.. ;-)
Wenn die Tests gut durchlaufen, kann das Teil schon kommende Woche veröffentlicht werden.
Es waren speziell wegen der DB-Treiber noch ein paar Dateien mehr anzufassen, als in den bisherigen Patches berücksichtigt wurden. Die zusätzlichen, PHP-bedingten Fixes müssten auch alle drin sein, plus ein oder zwei, die ich noch aus der .4 geholt habe.
Zusätzliche Features oder Funktionsänderungen sind _keine_ enthalten, es soll ja ein SP sein, und keine neue Version.
Nochmal zu SQL-strikt: Nein, da ist bisher weder ein SP noch sonstwas geplant. Einzig mein Vorschlag, meine Bitte, dass alle Statements sukzessive gleich mit geändert werden, wenn eine Datei zu irgendeinem Zweck sowieso angefasst wird. Das betrifft von Eurer Seite jetzt hauptsächlich die ganzen Module, da ich selbst(und Dietmar bisher auch) das im Core schon seit langem so praktizierten und ich es auch weiterhin machen werde.
Also kein großartiger Extraaufwand, sondern eine 'fließende' Aktualisierung.
Manuela
-
SP3 ist bis Montag komplett
gute Nachricht
P.S. SP2 wäre richtig, aber sicher ein Tippfehler :wink:
(oder bin ich schon kirre?)
-
Hier ist jedenfalls alles für Tests bereitgestellt.
Das funktioniert auch am blauen Montag :wink:
MfG. Evaki
-
@DarkViper: super - danke. Je nachdem wie lange 2.8.4 noch auf sich warten lässt, wäre es evtl. sinnvoll Twig noch mitzuliefern. Wurde ja bereits vor mehr als 2 Jahren integriert (ca. 20 Commits nach SP1). Dann müssen evtl. Modulentwickler nicht länger warten, oder Twig selbst mitliefern ...
Gruss
-
der "WB-Plan" sah ja die Nutzung von TWIG in Modulen und (langfristig) auch in Templates ab Vers 2.8.4 vor und etliche Autoren haben da auch schon Module "in der Pipeline", von daher wäre es schon ein allgemein nützlicher Schritt
Dagegen spricht, das das schon wieder eine Erweiterung, ein zusätzliches Feature wäre, eine Funktionserweiterun g, die vielleicht auch nicht jeder braucht oder will und die eigentlich auch nichts in einem SP zu suchen hat.
ich meine, mich zu erinnern, das ein lauffähiges separates TWIG-Modul hier mal mit einem Modul angeboten wurde, der DL ist aber in der nächsten Version dieses Modul wegen der Integration von TWIG wieder verschwunden
-
War's das [ Admin-Tool ] "addonMonitor" (DE-Thread) (http://www.WebsiteBaker.org/forum/index.php/topic,26100.msg178279.html#msg178279) ?
Kostenlose Diskussion um TWIG gibt's obendrauf.
MfG. Evaki
-
War's das [ Admin-Tool ] "addonMonitor" (DE-Thread) (http://www.WebsiteBaker.org/forum/index.php/topic,26100.msg178279.html#msg178279) ?
vom Text her möglich, das es dort dabei war, ich kann aber auch falsch liegen. Fragt doch den Autor mal
-
Ja, da war es kurzzeitig.
Aber Twig, wie es im 2.8.4. initialisiert wird, wird anders eingebunden.
Der Autor
-
Ist die Testphase des SP2 angelaufen? Kann man das SP2 irgendwo herunterladen?
-
Es ist wirklich wahr, kein Traum. Es hat jemand danach gefragt.
MfG. Evaki
-
Ist die Testphase des SP2 angelaufen? Kann man das SP2 irgendwo herunterladen?
Auch ich würde mich über ein SP2 freuen.
Jetzt sind wir schon 2 :wink:
Habe sehr aufmerksam die Sammlung im Forum verfolgt, wäre aber wahrscheinlich überfordert das alles einzeln zu instalieren/ändern.
Kann auch gerne auf meiner Testumgebung testen.
-
Auch ich würde mich über ein SP2 freuen.
Freu Dich nicht zu früh :-D
Jetzt sind wir schon 2
Drei wären besser. Da kann man in der Wartezeit Skat spielen.
Bisher stellten sich die "offiziellen" Ankündigungen anschließend als Luftnummer heraus bzw. endeten so.
Einzig die wiederholten Versuche und konkreten Umsetzungen aus der Community, wo sich möglicherweise die Devise "Die Hoffnung stirbt zuletzt" noch hält, haben bisher anwendbare Ergebnisse gebracht.
Neuankömmlinge werden bei derartigen Verhältnissen, statt Neugierde zu entwickeln, eher die Flucht ergreifen.
Bei uns wurde mittlerweile "der Stecker gezogen". Da -aus gutem Grund- reichlich WebsiteBaker-Installationen existieren, ist eine Betreuung aber weiterhin nötig. Somit sind Lösungen für den Weiterbetrieb gefragt.
MfG. Evaki
-
SP32 ist bis Montag komplett (so wie's derzeit ausschaugt) und ich werd es mal intern zum Testen freigeben.
es ist Dienstag, ca 18.00 Uhr :roll:
es war weder eine Festlegung auf Montag, noch die Ankündigung eines öffentlichen Test's
-
Hi,
Ich bitte eines zu berücksichtigen: Der Stand der Patches liegt in einem GitHub-Repository, das "cwsoft" gehört. Es ist nicht bekannt, ob DV dort Zugriff hat. Es ist auch nicht bekannt, ob "cwsoft" derzeit überhaupt online ist und Zeit dafür hat. Da sich beide derzeit nicht äußern, kann man nur rätseln.
Nur kurz. Das GitHub Repo ist öffentlich, sprich jeder kann es klonen - direkten Zugriff darauf habe aktuell nur ich. Das Repo ist/war als Backup gedacht, falls das Goggle Code Repo - so wie NorHei - von jetzt auf gleich vom Netz geht. DarkViper hat sich die Patches von NorHei angeschaut und noch ein paar weitere Dateien gefunden die gepatcht gehören. Mehr weiss ich auch nicht. Da DV ein SP2 in Aussicht gestellt hat, werde ich aktuell auch keine Diff-Packete zum Testen bereit stellen. Es wurde ja in diesem Thread auch des öfteren der Wunsch des "offiziellen Charakters" für ein SP geäußert.
Gruss cwsoft
-
es war weder eine Festlegung auf Montag, noch die Ankündigung eines öffentlichen Test's
Das kennen wir doch schon. Da können wir auch auf den Nikolaus warten.
Wenn der Test "nicht öffentlich" ist, wo findet er dann statt?
Ich gehe und ging davon aus, daß dies unter "Core DEV-Tests" stattfindet, oder entscheidet das eine Göttin?
Das anscheinend zum Grundrauschen gehörende Abwiegeln könnte man sich mal sparen.
Mal Butter bei die Fische...
MfG. Evaki
-
Wenn der Test "nicht öffentlich" ist, wo findet er dann statt?
ich mache es ganz gern, das ich etwas Neues einem Kollegen rüberschick, bevor ich das dem Auftraggeber zum Testen gebe und andersherum werde ich auch oft gefragt, ob ich mal schauen kann.
Die Chancen, das der offizielle SP2 testfertig ist, liegen bei 50% und wenn wir dann mal die "guten" 50% nehmen, rechne ich nochmal min 24 Stunden drauf für den internen Test und wenn das Paket erst Montag nacht, 23.59 Uhr fertig geworden ist, eher zwei Testtage plus einer Zeit X für mögliche Korrekturen.
Vielleicht ist das Paket aber erst heute fertig.......
P.S.: für die 1. Hilfe liegt das Paket ja unter den bekannten Links bereit
-
Na, dann schaun wir mal.
Da es keine Vorgaben gibt, macht jeder die Tests so gut wie kann bzw wo er seine Schwerpunkte hat. Auf diese Weise -bei genügender Anzahl von Testern- funktionierte das bisher ja ganz akzeptabel.
MfG. Evaki
-
ok... erstens habe ich wieder ausgeschlafen..
Wir hatten außerplanmäßig seit Samstag Besuch von einer guten Freundin, incl. deren 2-jährigem Gartenzwerg. ;-)
Da war an Arbeiten praktisch nicht mehr zu denken. Dann am Dienstag 'kurz mal' nach Murnau runter (hin und zurück nur knapp 1.200km).. aber wie gesagt... ich habe gestern gut ausgeschlafen, so dass es wieder weiter gehen kann.
Zum Vorschlag, Twig mit der 2.8.3SP2 auszuliefern: Da bin ich (aus Faulheit) dagegen. Jede Versionsänderung von Twig würde in der Regel auch ein Update des Paketes erfordern und das ist an dieser Stelle etwas too much.
Was jedoch ohne Probleme und mit geringstem Aufwand machbar ist wäre: WB schaut beim Start kurz nach, ob Twig im /include/-Ordner zur Verfügung steht und registriert dann gleich mal den Twig-Autoloder, so dass es dann an beliebiger Stelle einfach nur noch benutzt zu werden braucht.
Der Ordner wäre dann (wie in 2.8.4) wb/include/Sensio/Twig/
Denkbar wäre noch, das jeweils aktuelle Twig-Paket gleich passend umgepackt, auf der WB-Seite als Zusatz bereit zu stellen.
Jetzt erst mal am SP weiter 'basteln'.... und möglichst viele meiner Tippfehler finden..
Edit sagt: In Core DEV-Tests (http://www.WebsiteBaker.org/forum/index.php/topic,27457.msg189506.html#msg189506) ist die erste Vorabversion der DB-Patches zu finden..
-
Hi,
Zum Vorschlag, Twig mit der 2.8.3SP2 auszuliefern: Da bin ich (aus Faulheit) dagegen. Jede Versionsänderung von Twig würde in der Regel auch ein Update des Paketes erfordern und das ist an dieser Stelle etwas too much.
Naja nicht wirklich, nur bei Sicherheitspatches von Twig, aber gut.
Was jedoch ohne Probleme und mit geringstem Aufwand machbar ist wäre: WB schaut beim Start kurz nach, ob Twig im /include/-Ordner zur Verfügung steht und registriert dann gleich mal den Twig-Autoloder, so dass es dann an beliebiger Stelle einfach nur noch benutzt zu werden braucht.
Besser als nichts, dann muss man zumindest keine Coredatei selbst patchen.
Gruss cwsoft
-
Denkbar wäre noch, das jeweils aktuelle Twig-Paket gleich passend umgepackt, auf der WB-Seite als Zusatz bereit zu stellen.
aus meiner Sicht eine gute Lösung, reinkopiert und mit SP2 einsatzfähig
-
Wie siehts aus? Läuft überhaupt was?
Gruss
-
@rjg Guckst Du hier http://www.WebsiteBaker.org/forum/index.php/topic,27476.msg189974.html#msg189974 (http://www.WebsiteBaker.org/forum/index.php/topic,27476.msg189974.html#msg189974)