Author Topic: Re: Discussion about WB-2.11.0  (Read 1119 times)

Offline badknight

  • WebsiteBaker Org e.V.
  • **
  • Posts: 819
  • Gender: Male
    • pinzweb
Re: Discussion about WB-2.11.0
« on: January 24, 2018, 09:45:26 AM »
Ok if nobody is saying it, I will:
I think it's VERY careless to announce to the world that ALL versions of WB have a vulnerability that enables the bad guys to wipe an entire WB-installation, when all you have to fix it is a still untested release candidate.
You sir, made my day - thanks haha

Ich wollte eigentlich nie wieder was in diesem Forum schreiben, doch es brennt mir schon einiges auf der Zunge.
Auch wenn ich jetzt schon weiß, dass mein Beitrag gelöscht wird - oder ich zumindest wieder angeschrieben werde, dass ich den Beitrag doch anders schreiben soll - hier meine Meinung:

Quote from: Luisehahne link=topic,30664.msg213765.html#msg213765
This is the beginning of the motto "Back to the Roots"
Das Motto kann man - wie üblich - bereits am Code erkennen.

phpLib:
Wir schreiben nun das Jahr 2018 und es wurde immer noch nicht geschafft, dieses mehr als veraltete Softwarekomponente zu ersetzen?
Kleine Info am Rande: auf Sourceforge kann man leicht sehen, dass die letzte Änderung an der 7.4a vor fast 12 Jahren gemacht wurde!

Den Sourcecode der phpLib kann man schon seit Jahren gleich ansehen: <wb>/include/phplib/template.inc, da sie keine PHP Endung hat - oder sonst eine Art der Absicherung (htaccess für Apache zum Beispiel)

Passwörter:
Bereits im Jahr 2004 gab es die ersten erfolgreichen Angriffe auf md5, aber WebsiteBaker bleibt sich auch fast 14 Jahre später noch treu - nichts ändern, was funktioniert!

Mit PHP 5.5.0 wurden eine super native Passworthashing API integriert. Warum verwendet man diese nicht endlich?
Ist euch die Sicherheit der Benutzer und deren Passwörter wirklich so zweitrangig?

Medienverwaltung:

Das dieser Punkt in die Jahre gekommen ist (optisch wie auch technisch) sollte kein Geheimnis sein. Warum überwindet man sich nicht endlich hier was neues zu gestalten? Nehmt euch mal ein Beispiel an anderen Systemen wie etwa Wordpress, da hat man um einiges mehr an Funktionen und es ist trotzdem einfach und gut zu bedienen.

header():
Das die Führeung und Community von WebsiteBaker ein Gegner von Objektorientierter-Programmierung ist, sollte jeden klar sein.
Aber, dass man es auch im Jahr 2018 nicht geschafft hat, sich mal um einige Teile zu kümmern kann ich nicht verstehen:

In fast jeder PHP-Datei im Admin-Ordner ist ein header()-Aufruf zu finden, welcher ein Redirect auslöst oder einfach einen HTTP-Status setzt.

Warum macht ihr euch nicht endlich mal eine Zentrale Funktion dazu? Verlangt doch keiner, dass ihr euch mit Klassen beschäftigen müsst, aber eine zentrale Funktion was das Ganze auslöst wäre doch praktisch. So könnte man auch ggf gewisse Angriffe mitloggen, falls das jemand wünscht...

jscalendar
Das (c) von diesem Teil stammt aus dem Jahr 2005.. warum schickt man den Kalender nicht endlich in seinen wohlverdienten Ruhestand und sucht sich eine Alternative?
Vertraut mir, man würde hier sicherlich was finden...


Ist natürlich nur ein Auszug von den Punkten. Suche und andere Themen habe ich dabei noch gar nicht angeschnitten.
Für mich ist das einfach nur eine 2.7/2.8 mit paar neuen Buttons und Meldungen..  sorry für die harten Worte!

Und nun, fühlt euch frei meinen Beitrag mal wieder zu löschen!  (Y)

AdminEdit:  Thema geteilt und Titel umbenannt

« Last Edit: January 26, 2018, 01:12:04 PM by jacobi22 »
Ich würde gern die Welt verändern, doch Gott gibt mir den Quellcode nicht...

Offline evaki

  • Posts: 2220
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #1 on: January 24, 2018, 11:03:57 AM »
Man muß den Beitrag nicht löschen, aber hier befindet er sich m.E. am falschen Platz.

Vorschlag, neuer bzw. verschobener Thread: Was ich an dem Rentner WB mittlerweile so alles besch... finde, und warum ich ihn immer noch benutze, obwohl ich weiß wo der Jungbrunnen ist. Oder wird er garnicht mehr genutzt?

Vielleicht (ver)schiebt der Moderator den Part ja.

MfG. Evaki
« Last Edit: January 24, 2018, 11:09:59 AM by evaki »
Einmal Pizza Quattro Stagioni bitte, aber ohne Herbst.

Offline badknight

  • WebsiteBaker Org e.V.
  • **
  • Posts: 819
  • Gender: Male
    • pinzweb
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #2 on: January 24, 2018, 12:04:55 PM »
Man muß den Beitrag nicht löschen, aber hier befindet er sich m.E. am falschen Platz.

Vorschlag, neuer bzw. verschobener Thread: Was ich an dem Rentner WB mittlerweile so alles besch... finde, und warum ich ihn immer noch benutze, obwohl ich weiß wo der Jungbrunnen ist. Oder wird er garnicht mehr genutzt?

Vielleicht (ver)schiebt der Moderator den Part ja.

MfG. Evaki

Wie sehr ich doch deine Nutzlosen und doch vorhandenen Kommentare vermisst habe :wink:
Ich habe kein Problem mit WB an sich - die Philosophie hinter dem System ist genial! Doch wenn nach Jahren die Punkte, welche man bereits mehr als nur einmal eingebracht hat nicht behoben wurden, fühlt man sich doch etwas im Stich gelassen.

Zum Thema "und warum ich ihn immer noch benutze":
Es ist kein Geheimnis, dass wir eine Version entwickelt haben, die auf unsere Bedürfnisse angepasst wurde und glaub mir.. diese störenden Punkte findest du da nicht ;)
Ich würde gern die Welt verändern, doch Gott gibt mir den Quellcode nicht...

Offline evaki

  • Posts: 2220
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #3 on: January 24, 2018, 12:50:56 PM »
>>Wie sehr ich doch deine Nutzlosen und doch vorhandenen Kommentare vermisst habe
Na, da muß man doch nicht derart armselig daherreden, um auf Kommentare zu reagieren. Armselig ists aber nicht nur wegen der persönlichen Attacke, sondern auch weils fachlich nur an der Oberfläche bleibt.  Vielleicht ists da sinnvoller die Ösihöhle aufzuräumen, statt hier unproduktives Zeugs rauszulassen, oder habt Ihr gerade Pause?

Dein Verhalten bestätigt nur meine schon geäußerte Einschätzung zu den Posts, sie sind hier fehl am Platze.

MfG. Evaki
Einmal Pizza Quattro Stagioni bitte, aber ohne Herbst.

Offline jacobi22

  • Posts: 5201
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #4 on: January 24, 2018, 12:58:32 PM »
Gebt mir bitte etwas Zeit, eine  längere Antwort zu verfassen, die ein wenig hinter die Kulissen blickt und vielleicht erklärt, warum es in WB 2.11.RC1 so ist wie es ist.

Laßt uns das fachlich und nicht persönlich ausdiskutieren.
Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

Offline hgs

  • Betatester
  • **
  • Posts: 920
    • EFG MG
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #5 on: January 24, 2018, 02:07:30 PM »
 (Y)
LG Harald

"Fange nie an, aufzuhören - höre nie auf, anzufangen." Marcus Tullius Cicero (106-43 v.Chr.)

Offline jacobi22

  • Posts: 5201
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #6 on: January 24, 2018, 05:26:23 PM »
meine persönliche Worte (unabhängig von dem, was als Status beim Avatar steht)
Zu deiner Löschgeschichte:  ich kenn es nur vom Hören & Sagen
Wir hatten früher einen ShowCase-Bereich und es gab Forenregeln, das dort nur Seiten im ShowCase verlinkt werden, die mit WebsiteBaker erstellt wurden. Du warst einer der aktivsten Poster im ShowCase mit sehr vielen gelungenen Projekten, die anfangs auch alle mit WB erstellt waren. Irgendwann hast du bei dir oder ihr bei euch in der Firma ein anderes System verwendet und auch die "WB-"Seiten, die im ShowCase verlinkt waren, auf ein anderes System umgestellt und du wurdest aufgefordert, deine Einträge entsprechend den Forenregeln zu korrigieren oder auszufiltern. Du warst jahrelang selbst Moderator und musstest in dieser Funktion andere User bei Verstößen darauf hinweisen. Ist einfach eine Frage der Fairness allen anderen gegenüber.
Wie gesagt, so hab ich es gehört als ich danach fragte, wo du denn abgeblieben bist
Wie Evaki sagte, ist dieser Thread hier nicht der richtige für das "alte" Thema, sollte aber Gesprächsbedarf sein, teile ich das gerne auf

zu den fachlichen Sachen:
grundsätzlich meine Zustimmung, was die technische Seite betrifft. Alle genannten Punkte standen seit Jahren auf der "Versprech-Liste" der Chefentwicklerin, ein komplett neu gecodetes CMS haben wir mit der Version 3.x zu erwarten. Dieses Versprechen wurde seit der 2.8.4 gemacht, gesehen haben wir alle vielleicht hier und da mal ein Schnipsel. Dieses Versprechen war auch der Grund dafür, das die WB 2.11 RC1 so ist wie sie ist, mit FeatureFreeze, weil ja jede neue Funktion, jedes Stück neuer Code auch in die "fast fertige" WB 3 wandern muss (geplanter Release-Termin: Mitte-Ende 2019).
Am 30. November 2017 war Release-Termin der PHP 7.2. Am 9. Dezember 2017 wurde PHP 7.2.0 bereits als Default PHP-Version für Neuverträge bei diversen deutsch Providern angeboten.
Die RC1 hatte zu diesem Zeitpunkt das Problem, das jeder Mausklick im Back- oder Frontend 3-4 Error-Meldungen erzeugt, weil im PHP die each()-Funktion weggefallen ist. Ich war dafür, dies zu korrigieren, u.a. weil man niemanden beibringen kann, das eine neue WB-Version nicht mit den gängigen PHP-Versionen laufen wird. WB hätte eine "Warnung" vor PHP 7.2. geben müssen   
Darkviper war der Meinung, das so zu lassen und einfach zu sagen, nicht PHP 7.2-tauglich, denn es wird ja in der WB 3 alles korrigiert.
Nachdem wir in einer gründlichen Analyse festgestellt haben, das es sich wirklich nur um 5-10 kleine Stellen handelte, die Fehler reportet haben, (allerdings eben bei jedem Seitenwechsel im Backend ) und die auch mit minimalem Aufwand korrigiert werden konnten, wurde erneut das Gespräch mit der Chefentwicklerin gesucht, die daraufhin ohne eine Diskussion darüber ihr Engagement in der WB-Entwicklung beendet hat (das war am 16.12.2017), eine Entscheidung, die man zu akzeptieren hat, schließlich ist jeder hier in seiner Freizeit und unbezahlt tätig.
Mit ihrem Ausscheiden war uns aber auch klar, dass es eine WB 3 von ihr wohl nicht geben wird und wir standen vor der Frage, ob wir mit dem Paket, das hier die 2.11 RC1 ist, an die Öffentlichkeit gehen oder die Rollläden dicht machen.
Ich persönlich vertrete die Meinung, wenn irgendwo eine Tür zugeht, geht woanders eine neue Tür auf und so lange es noch Leute gibt, die sich (neben mir) mit engagieren möchten, sollte man das Projekt WB auch nicht sterben lassen. Sicherlich ist die Zahl der WB-Nutzer kleiner geworden, aber die, die es noch nutzen, sollte man nicht im Regen stehen lassen.
Vor allem in den 7er PHP-Version gibt es mit jedem Release Sachen, die die Reparatur des alten WB-Codes erfordern und diese Probleme gibt es heute, da kann man nicht warten, bis eine fiktive WB 3 Ende 2019 erscheint. Und wer die WB-Geschichte der letzten 7-8 Jahre auch nur ein wenig verfolgt hat, wird an diesem Release-Termin seine (wohl auch berechtigten) Zweifel haben.
PHPLib
Allgemein: seit Jahren der Wechsel auf Twig versprochen. Die PHPLib zieht sich durch den kompletten Core, sie bereitet jedes Template auf, das im Backend zu sehen ist. Das gilt analog auch für jedes Addon. Es komplett zu ersetzen, fällt damit aus. Man kann also nur zweigleisig fahren über eine Zeit X.
Da TWIG Bestandteil des Paketes ist und somit jedes Addon TWIG nutzen könnte, wäre es mein favorisierter Weg, erst einen Pool Addons aufzubauen und dann an den Core zu gehen. Wie gesagt, meine persönliche Meinung, die nicht richtig sein muss. Die Alternative wäre eine Schnittstelle, die die Abwärtskompatibilit ät gewährleistet mit der Frage, muss ich wirklich eine Kompatibilität zu einem Modul Baujahr 2008 haben und höchst wahrscheinlich eh noch andere Probleme mit sich bringt, die eher ein ReCoding empfehlen?
Zur Sichtbarkeit inc-Dateien:
Sicher wäre das mit den von dir beschriebenen Methoden einfach zu verhindern, inc-Dateien anzusehen, andererseits ist sowohl WB wie auch PHPlib Open Source. Jeder mit Interesse kann sich das überall anschauen.
Ich denk, es geht bei deinem Einwand eher um den Grundsatz, dass es eben einfach zu verhindern wäre und da gebe ich dir schon Recht.
Funktion und Alter: Ich muss gestehen, dass ich bei so manchen Sachen verwundert bin, das sie nach all den Jahren noch relativ Störungsfrei laufen. Es gab auch in der PHPlib in jeder WB-Version der letzten Jahre von uns kleine Änderungen, allesamt keine Probleme, die die Grundfunktionen der PHPlib beeinträchtigt hat. Dennoch funktioniert es….
Ich persönlich hätte lieber gerne und sofort Twig, weil es alles einfacher macht. Es würde den Core-Code sicher um ein Viertel schlanker machen und auch der Aufwand für den User/Modulautor reduziert sich. Die Lernphase ist hier bedeutend geringer.
Passwörter
ich glaube, in der WB 2.8.4 war schon eine neue Passwortklasse enthalten. Ich bin nicht Fachmann genug, beurteilen zu können, ob diese Klasse für die heutige Zeit noch ausreichend ist, aber auch hier gilt das, was unten als Zusammenfassung steht.
Aber auch hier meine grundsätzliche Zustimmung, dass man zumindest das anbieten sollte, was aktueller Stand der Programmiertechnik ist. Das User die Username/Passwort-Kombination admin/admin benutzen oder über 10 Jahre ihre Passwörter nicht ändern, kann ich aber wenig beeinflussen und mach ich es dennoch, wird es als Gängelung ausgelegt. Ich erinnere nur an das Theater, als WB von den früher möglichen zwei Passwortstellen auf 6 Stellen erhöht hat und das nur bei neuen Passwörtern....niem and hatte also ein Problem, sein altes Passwort weiter zu benutzen.
Medienverwaltung:
eine mögliche Variante seit mehreren Jahren ist der Elfinder, er ist up-to-date und hat auch eine gute Rechteverwaltung. Hier gilt der gleiche Spruch: Feature-Freeze, kommt ja in WB 3
jscalendar
hier gilt grundsätzlich, was zur PHPlib geschrieben wurde. Hat zwar ein älteres Baujahr, funktioniert aber dennoch problemlos. Und das größere Problem: durch die zentrale Einbindung nutzt ihn so fast jedes Modul, das eine Kalenderfunktion benötigt. Ich persönlich benutze in meinem Kram einen jquery-Calendar und das nicht nur wegen des moderneren Designs
zu header() kann ich nichts sagen, fehlt mir das technische Wissen
zu den Logs allgemein: grundsätzlich halte ich eine Menge davon. Ein gutes Fehler- oder auch Angriffs-Logging zeigt mir die Schwachstellen auf und all das, was in unseren Logs auftritt, ist ja nicht automatisch verschwunden, wenn es nicht aufgezeigt wird. Es soll ja User geben, die 40 Gigabyte in der error-log angesammelt haben, ich werde bei 4 kB schon nervös und versuche das zu beseitigen, was den jeweiligen Log auslöst.
Von daher bin ich persönlich auch eher für mehr Informationen, auch, wenn man diese vielleicht besser aufteilen sollte. Ein Log auf einen möglichen Angriff hat (für mich) mehr Bedeutung als ein "undefined_index" in Datei XY und sollte deswegen nicht in einer Liste mit eher weniger wichtigen Dingen auftauchen, sondern vielleicht in einer getrennten Datei (analog der access.log auf dem Server). Notwendig ist auch eine Methode, die solche Dateien, analog der Routine auf Online-Servern, ab z.b. einer bestimmten Dateigröße komprimiert und archiviert.
Viele Benutzer haben nicht mal die Möglichkeit, Logs auf dem Server per Klick einzusehen oder es ist zu umständlich, dorthin zu gelangen und darum hat WB dieses systemeigene Error-Logging, das ab 2.11. RC1 wieder stufenweise schaltbar ist und deren Ergebnisse jetzt nicht nur dem SuperAdmin mit ID = 1 angezeigt werden, sondern auch der Administratorengrup pe.
Der kleinere Kern, der nach Gründung von WBCE geblieben ist und mich einschließt, hat diesem Feature Freeze in den 2.8.3er Versionen zugestimmt in dem Vertrauen auf eine komplett neue Version. Das war etwa im Sommer 2015 mit Erscheinen der WB 2.8.3 SP5. Seit her sind nun 2.5 Jahre vergangen und eine komplett neue Version ist auch für den ganz internen Kreis noch nicht zu sehen gewesen, wir waren andererseits aber auch gezwungen, auf z.b. Änderungen bei PHP zu reagieren oder wichtige Sachen, die "schon immer" falsch in WB waren, nach Erkennen zu korrigieren, wie eben die Möglichkeit, unter bestimmten Bedingungen Systemordner von WB über die Mediaverwaltung löschen zu können.
Für beides gibt es eine gewisse Dringlichkeit, denn selbst die WB 2.10, die auch noch intern und öffentlich unter PHP 7.1 getestet wurde (aktuellste PHP-Version zum Zeitpunkt des Release WB 2.10), macht Zicken unter PHP 7.2.1, hier vor allem im Error-Logging. PHP wird immer restriktiver und zeigt uns heute Sachen auf, die schon vor 10 Jahren unsauber programmiert wurden.  Anderes wurde auch einfach nicht beachtet, wie z.b. $wb->preprocess(), das schon seit 2012 auf der öffentlich zugänglichen Deprecated-List steht.
Darkviper hat uns am 15.12.2017 ihren Entschluss mitgeteilt, dass sie aus der Entwicklung von WB aussteigt. Ob das ein endgültiger Ausstieg ist und wenn nicht, wie lang diese Phase der Enthaltsamkeit  andauert, kann ich nicht beurteilen. Angekündigt hatte sie dabei ein Statement im Forum. Da dieses bisher ausbliebt, war immer noch ein Funke Hoffnung, das die Entscheidung nach den Feiertagen eventuell revidiert wird. Wie in diesem Fall, sammeln sich aber die Fragen, warum dies oder das nicht geändert wurde und irgendwann muß man sich da von WB-Seite aus auch erklären. Grundsätzlich gilt das Recht, seine Tätigkeiten hier einzustellen, für jeden, egal, ob in WB oder im Kegelverein. Wenn man nicht zufrieden ist, andere Ansichten hat, steigt man aus. Ob zeitlich begrenzt oder nicht, ist die persönliche Entscheidung eine jeden Einzelnen. Solche Auszeit habe ich mir genommen und aus gleichen Gründen sind auch die Forks entstanden. Wir, der Rest der Entwicklergruppe oder wie immer man sie nennen mag, habe die Information über Darkvipers Ausstieg bewußt intern gehalten, um keine Türen zuzuschlagen, aber die Welt dreht sich weiter.
Ich finde es nur schade, wenn man über ein Problem XY nicht in normaler Form reden kann, wie das hier der Fall war. Und wenn ich mit meinem Drängen auf die Korrektur der kleinen Sachen für PHP 7.2 der Auslöser für ihren Abschied war, muss ich damit wohl leben. Das ICH der Bösewicht bin, ist wohl der Grund, warum auf Kontaktversuche meinerseits bisher keine Reaktion kam.
Für mich war die Korrektur der PHP-Sachen einfach eine logische Entscheidung, der Aufwand war minimal. Ich bin am Ende der, der es den Benutzern im Support erklären muss und für diese Entscheidung hatte ich keine Erklärung. Und es war ja auch nicht so, dass der Rest der Truppe diktatorisch entschieden hat, nun PHP 7.2. vollumfänglich zu unterstützen. Es war einfach nur der Versuch, eine verständliche Erklärung über ihre Entscheidung zu bekommen.
Natürlich reißt der Weggang eines wichtigen Mitgliedes ein Loch, aber dennoch muss es weiter gehen. Zwischen ihrer Entscheidung und dem Release der WB 2.11 lagen grade etwas mehr als 3 Wochen, die Weihnachtstage und auch der Jahreswechsel. Fachlich habe auch ich viel von ihrem Wissen profitiert, von daher bedauere ich ihren Schritt auch. Auf das Projekt WB bezogen, muss man nun sehen, wie es weiter geht.
Jeder in der internen Gruppe wusste, dass damit die mögliche WB3 mit komplettem Re-Coding zeitweise oder für immer vom Tisch ist. Die WB 2.11 RC1 war zu diesem Zeitpunkt im groben zu 90% - 95% fertig, überwiegend Code-Korrekturen und Fehlerbeseitigung, die Tickets usw. und alles mit Blick auf den Feature-Freeze. Aufgeben war keine Option, also geht man den Schritt und dann eben auch mit alter PHPlib, jscalendar usw.
Heute, mit dem Abstand von 5 Wochen, sehe ich das eher als Chance. Mag sein, dass eine neue Version schon fast fertig war, aber bis zum möglichem Release hat man auch noch Nutzer älterer WB-Versionen, die man zu betreuen hat. Niemand wird seine Webseite zwei Jahre zu machen bis ein "neues" WB erscheint. Das ewige Warten auf solch ReCoding hat nach meiner persönlichen Meinung schon viel zu lang gedauert. Bei der WB 2.8.4 hatte ich noch Verständnis, das persönliche Wohlbefinden sollte immer an erster Stelle stehen. Dietmar (Luisehahne) hatte zwei (?) Herzinfarkte, Darkviper hat ihre Prioritäten auf ihr privates Leben gesetzt (und dies hier im Forum später auch ausführlich erklärt). Seither ist aber eine lange Zeit vergangen und wir stehen code-technisch fast unverändert da. Viel Kleinkram unter der Haube und Sachen, die die Forks noch vor sich haben. Aber nicht wirklich große sichtbare Veränderungen. Geblieben ist die intuitive Bedienung, wie Daniel sagt, das große Plus gegenüber anderen Systemen.
Früher oder später muss man den Schritt gehen und alte Zöpfe abschneiden. Wir haben in den letzten 2,5 Jahren versucht, die negativen Folgen für die Userschaft so gering wie möglich zu halten, das ist nicht immer gelungen und kann auch nicht immer gelingen. Der User neigt aber dazu, Problemen aus dem Weg zu gehen. Und solang Modul XY mit einem der Forks noch kompatibel ist, nehm ich eben einen Fork, das Upgrade-Script wird's schon richten. Funktioniert ja auch und in beide Richtungen, sowohl von WB zu einem Fork wie auch umgekehrt. Egal, ich schweife ab....
Auf die Zukunft bezogen, stellt sich nun die Frage, was kann und will der Rest ohne Darkviper leisten? Geht man davon aus, das eine WB3 tatsächlich komplett recodet irgendwann Sommer 2019 test-fertig gewesen wäre, muss ich wohl sagen, dass dies eine Leistung ist, die wir mit dem aktuellem Personal so in dieser Zeit nicht schaffen werden. Ich selbst habe wohl in den letzten 4 Wochen mehr gelernt als in den letzten 2,5 Jahren davor, aber ein CMS ist ein paar Nummern zu groß für mich. Allein die Korrekturen der zahlreichen Rückmeldungen zum RC1 sind schon ein Vollzeitjob.
Und die Ablösung der PHPlib ist schon ein halbes ReCoding und Zeit, in der man kaum etwas anderes machen kann.
Nach dem Release der WB 2.10 im März 2017 habe ich auf die Entscheidung zu einer Modulschnittstelle gedrängt, die aber nicht gekommen ist, das sehen wir, wenn die WB 3 soweit fertig ist. Für mich, der mit dem Core wenig zu tun hat, wenig zufrieden stellend. Ein oder zwei Jahre verschenkte Zeit, die man für das ReCoding der Module hätte nutzen können. Also habe ich mich zurückgezogen und auf den Forensupport beschränkt. Erst zum Ende der 2.11er Tests hab ich mich da wieder eingeklinkt
Das Vertrauen in eine neue WB3 war groß genug in der internen Gruppe, zumal auch immer wieder Einzelheiten diverser WB3-Funktionen  theoretisch durchdiskutiert wurden, also nix, was nur im Kopf passiert ist. Und vertraust du darauf, fällt die Entscheidung, dem Feature-Freeze zuzustimmen recht einfach, weil sie logisch ist.
Nun haben wir eine neue Situation und müssen das Beste daraus machen. All die oben genannten Punkte standen schon lang auf der ToDo-Liste und vieles davon wurde ja auch schon zu Zeiten der 2.8.4 diskutiert.
Priorität hat aktuell die WB 2.11. Die Korrektur der gemeldeten Sachen hat doch etwas länger gedauert als geplant. Hier gab es z.b. im RC1 Probleme beim Entpacken von ZIP-Dateien in der Mediaverwaltung und unlogische Bedienung der OutputFilter-Einstellungen (u.a. von Matthias gemeldet)
Die Entwicklergruppe favorisiert eine RC2, schon allein, weil mehr Augen auch mehr sehen. Ich bin mir da derzeit noch unsicher, weil die Downloadzahlen (~50) doch eher gering sind. Andererseits sind solche Tests und Analysen doch eher etwas für "Profis", der allgemeine User, der seine Kaninchen-Webseite in 2011 mit WB 2.7 erstellt hat und diese heute noch unter 2.7. fährt, wird kaum etwas Neues testen.
Als Nächstes steht die Überarbeitung der Homepages an. Ein neues, modernes Design, überarbeitete Module (z.b. im Addons), die WB-Hilfeseite wird wieder aktiviert werden und natürlich auf die aktuellen WB-Versionen aktualisiert. Ein WIKI ist gut und schön, wenn aber nur eine Person (Darkviper) Schreibberechtigung en hat, in der Wille diverser User, sich hier zu engagieren, nutzlos.
Geplant sind zwei Sprachen, englisch + deutsch. Ist die Möglichkeit vorhanden, dann auch gern auf niederländisch.
Zum WB-Core gibt es eine lange Liste, aktuell ohne Rangfolge, die wird festgelegt, wenn die 2.11 als stableVersion draußen ist. Erfahrungsgemäß ergeben sich aus einem Schritt viele andere, wie gesagt, die PHPlib z.b. kann man nicht einfach ersetzen, man muss aber irgendwann mal damit beginnen.
Der grobe Plan ist, mehr auf Fixes zu setzen, wo nötig. Davon wird es in Zukunft wohl einige geben müssen, wenn man sich das Tempo bei PHP anschaut. Solang die (vornehmlich deutschen) Provider eine neue PHP-Version gleich als Default-PHP-Version einstellen, ist man da immer gezwungen, nachzuziehen.
Wie oben gesagt, ich kann jeden verstehen, der irgendwo den Glauben verloren hat ob des scheinbaren Stillstandes, ging mir nicht anders in den letzten 9 Monaten des letzten Jahres. Ob Darkviper nun (mit oder ohne neue Version) zurück kommt, ist ihre persönliche Entscheidung, die es zu akzeptieren gilt. Fest steht aber, dass ein(e) Chefentwickler(in) nie mehr diese absolute und letzte Entscheidungsgewalt (zurück-) bekommt, die es vorher gab. Dieser Freeze hat zu einem Stillstand geführt, der WB über die letzten Jahre geschadet hat.
Ich sehe es eher als frischen Wind mit der Hoffnung, vielleicht auch den Einen oder Anderen neu oder auch zurück zu gewinnen.
Sicher können wir jetzt nicht von heute auf morgen die Welt aus den Angeln heben, aber der Wille ist da, es zu versuchen. Jeder, der sich da gern engagieren möchte, ist herzlich eingeladen, Ideen oder Taten beizusteuern.
 „Back to he Roots“ – Zurück zu den Grundlagen
WB ist entstanden aus der Idee eines Einzelnen (Ryan) und wurde aufgebaut durch die Community. Viele haben diese Gemeinschaft über die letzten 10 Jahre wieder verlassen, weil sie sich anders orientiert haben oder enttäuscht wurden. So manches Mal wurde in einer doch eigentlich sinnvollen Diskussion auch nicht der richtige Ton getroffen, da nehme ich mich gar nicht aus.
Als Jemand, die irgendwo die Richtung für ein CMS vorgeben muss, wird man nie jeden kleinen Vorschlag berücksichtigen können. Ich muss mir dann aber die Zeit nehmen, demjenigen zu erklären, warum sein Vorschlag nicht angenommen wird. Dies wurde in der Vergangenheit oft versäumt oder in einer Weise gemacht, die Informatiker-Kenntnisse erforderte. Das mag fachlich richtig gewesen sein, kommt so aber nicht beim Anderen an.
Bis 2010 / 2011 wurde dies hier noch in anderer Form gemacht, für die User verständlicher. Später wurde der Ton rauer, was viele abgeschreckt hat, sich überhaupt an einer Richtungsdiskussion zu beteiligen.  Mittlerweile ist es wieder deutlich angenehmer, hier zu sein, aber nur 5,6 oder 10 Leute diskutierten intern über die Ausrichtung. Auch nicht der richtige Weg, wird aber bei anderen CMS nicht anders gemacht.

Zurück zu den Wurzeln – wieder näher dran am User – so war es gemeint und so ist das Ziel!
« Last Edit: January 24, 2018, 05:42:16 PM by jacobi22 »
Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

Offline jacobi22

  • Posts: 5201
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #7 on: January 24, 2018, 05:31:44 PM »
Noch die Bitte hinterher: (hatte keine freien Zeichen mehr...)

Sollte Bedarf an einer Diskussion um dieses eben angesprochene Thema bestehen, laßt uns die aus der eigentlich technischen Report-Sache hier ausgliedern und an anderer Stelle weiterführen.

Danke!

Noch ein P.S. zum obigem Beitrag: Habe im obigem Text noch ein paar Tipfehler entdeckt, die ich nachträglich korrigiert habe, so u.a. das Datum vom 15.12.2017 auf 16.12.2018

Leider sind oben keine freien Zeichen im Beitrag mehr zur Verfügung und ich mußte einige Leerzeilen entfernen, die die Lesbarkeit des Beitrages erleichtert hätten. Bitte um Verständnis.
« Last Edit: January 24, 2018, 05:47:15 PM by jacobi22 »
Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

Offline evaki

  • Posts: 2220
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #8 on: January 24, 2018, 05:56:25 PM »
Falls das Thema ausgelagert wird, und die "Beteiligten" -huch, ich bin ja dabei- einverstanden sind, schmeiß doch bitte "die Mosereien" raus. Vermute, daß da niemand Wert drauf legt.
MfG. Evaki
Einmal Pizza Quattro Stagioni bitte, aber ohne Herbst.

Offline dbs

  • Betatester
  • **
  • Posts: 7553
  • Gender: Male
  • tioz4ever
    • WebsiteBaker - jQuery-Plugins - Module - Droplets - Tests
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #9 on: January 24, 2018, 07:42:42 PM »
Schön ausführliches Statement von Uwe, danke dafür.
Obwohl schon an vielen WB-Stellen vieles verbessert wurde, ist auch klar, dass man nicht alles aufeinmal machen kann.
Wichtig ist, dass es weiter voran geht. Und dass es nicht nur totschicken Code unter der Haube geben muss, sondern was Sichtbares ebenfalls. Dietmar und Helfer machen das schon, da mach ich mir keine Sorgen.

Offline Martin Hecht

  • Betatester
  • **
  • Posts: 535
  • Gender: Male
    • meine Homepage
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #10 on: January 25, 2018, 09:10:44 AM »
dem kann ich mich nur anschließen: Danke für das ausführliche Statement und für das Engagement für WB

Offline Viktor

  • Posts: 23
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #11 on: January 25, 2018, 09:28:22 AM »
Als regelmäßiger Mitleser in diesem Forum, in dem es insgesamt sehr ruhig geworden ist, freue ich mich darüber, dass es hier eine klare und offene Ansage bezüglich des aktuellen Stands der Dinge gibt - technisch wie menschlich / persönlich. Ich gebe zu, dass ich wegen der angesprochenen Probleme, soweit sie nach außen hin wahrzunehmen sind, längst bei einem der Forks gelandet bin, der sich meiner Wahrnehmung nach wirklich sehr gedeihlich entwickelt (auch wenn ich nicht beurteilen kann, ob und ggf. welche Altlasten dort noch ihr Wesen treiben).
Aber die "Mutter" des Forks interessiert mich, wie hier gerade zu sehen ist, immer noch. Und ich finde es schade, dass sich die Kompetenzen heute auf mehrere Zweige verteilen, statt dass Kenntnisse und Energien wieder in und zu einem gebündelt werden. (Man könnte da einen leisen Wunsch heraushören.)

Offline evaki

  • Posts: 2220
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #12 on: January 25, 2018, 10:11:00 AM »
>>welche Altlasten dort noch ihr Wesen treiben
Bei WB und Forks gibts nicht wenige derartige Gemeinsamkeiten, die wohl auch noch eine Weile bestehen bleiben, solange man nicht Teile komplett erneuert. Alter Wein in neuen Schläuchen kann jedenfalls nicht das Ziel sein. Kosmetik genausowenig -wie "genauso wenig". Und Features sind entweder unabdinglich für Bedienung, Normen, spezielle Aufgaben usw., oder erschöpfen sich Wunschlisten  :-D

MfG. Evaki


 
« Last Edit: January 25, 2018, 10:18:30 AM by evaki »
Einmal Pizza Quattro Stagioni bitte, aber ohne Herbst.

Offline badknight

  • WebsiteBaker Org e.V.
  • **
  • Posts: 819
  • Gender: Male
    • pinzweb
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #13 on: January 25, 2018, 10:51:32 AM »
Wir hatten früher einen ShowCase-Bereich und es gab Forenregeln, das dort nur Seiten im ShowCase verlinkt werden, die mit WebsiteBaker erstellt wurden. Du warst einer der aktivsten Poster im ShowCase mit sehr vielen gelungenen Projekten, die anfangs auch alle mit WB erstellt waren. Irgendwann hast du bei dir oder ihr bei euch in der Firma ein anderes System verwendet und auch die "WB-"Seiten, die im ShowCase verlinkt waren, auf ein anderes System umgestellt und du wurdest aufgefordert, deine Einträge entsprechend den Forenregeln zu korrigieren oder auszufiltern.
Ich sende dir dazu eine PN - hat hier nichts verloren, mir geht es um den Code!

Alle genannten Punkte standen seit Jahren auf der "Versprech-Liste" der Chefentwicklerin, ein komplett neu gecodetes CMS haben wir mit der Version 3.x zu erwarten. Dieses Versprechen wurde seit der 2.8.4 gemacht, gesehen haben wir alle vielleicht hier und da mal ein Schnipsel. Dieses Versprechen war auch der Grund dafür, das die WB 2.11 RC1 so ist wie sie ist, mit FeatureFreeze, weil ja jede neue Funktion, jedes Stück neuer Code auch in die "fast fertige" WB 3 wandern muss (geplanter Release-Termin: Mitte-Ende 2019).
Bitte lasst uns jetzt keine Hetzjagd auf Leute machen, die sich dazu nicht äußern werden! Fakt ist jedoch, dass es nicht an einer Personen liegt - du weißt genau wie ich, dass ich dazu einfach zu viele Internas mitbekommen habe!
Auch dazu sende ich dir gerne ein PN!

PHPLib
Allgemein: seit Jahren der Wechsel auf Twig versprochen. Die PHPLib zieht sich durch den kompletten Core, sie bereitet jedes Template auf, das im Backend zu sehen ist. Das gilt analog auch für jedes Addon. Es komplett zu ersetzen, fällt damit aus. Man kann also nur zweigleisig fahren über eine Zeit X.
Oder es könnte einfach mal jemand umsetzen. Doch da kommen wir zu dem Problem von WB: Genau 2 Leuten war es gestattet Source-Code ins SVN zu übermitteln. Der Rest musste per Skype an eine der Beiden Entwickler den Code senden.
Von BEIDEN Seiten aus gab es bei dem Thema immer ein Abblocken, einfach weil kein Bock da war das Thema mal anzugehen.
Als kleine Info für Außenstehende: Seit Twig sich im Include-Ordner befindet, wird darüber schon diskutiert ob man das nicht machen sollte ;)

Da TWIG Bestandteil des Paketes ist und somit jedes Addon TWIG nutzen könnte, wäre es mein favorisierter Weg, erst einen Pool Addons aufzubauen und dann an den Core zu gehen. Wie gesagt, meine persönliche Meinung, die nicht richtig sein muss.
Man könnte aber einfach alles in einem Zug tauschen und fertig. Ich kenne den kompletten Source-Code von WB; kann dir sagen in welcher Datei was zu finden ist und glaub es mir: Man könnte das Thema in 1-2 Wochen Arbeit komplett abschließen.

Die Alternative wäre eine Schnittstelle, die die Abwärtskompatibilit ät gewährleistet mit der Frage, muss ich wirklich eine Kompatibilität zu einem Modul Baujahr 2008 haben und höchst wahrscheinlich eh noch andere Probleme mit sich bringt, die eher ein ReCoding empfehlen?
Genau da kommt der nächste Brocken ins Spiel.. Bei WB muss immer eine Abwärtskompatibilit ät ins extremste gegeben sein.
Man kann doch einfach mal eine Version machen und den Usern mitteilen, "so hier ist ein cut und ab da gibt es nun Veränderungen". Muss es wirklich sein, dass ich noch auf einen Code Rücksicht nehmen, der teils noch aus Zeiten von 2.7 ist?

Ich denk, es geht bei deinem Einwand eher um den Grundsatz, dass es eben einfach zu verhindern wäre und da gebe ich dir schon Recht.
Richtig - es zieht sich wie ein roter Faden durch das Projekt - viele Sachen die einfach zum realisieren sind, werden nicht gemacht.

Ich persönlich hätte lieber gerne und sofort Twig, weil es alles einfacher macht. Es würde den Core-Code sicher um ein Viertel schlanker machen und auch der Aufwand für den User/Modulautor reduziert sich. Die Lernphase ist hier bedeutend geringer.
Du bist mit Twig auch um einiges flexibler als mit der phpLib.. die ist einfach alles andere als "state of the art".

Passwörter
ich glaube, in der WB 2.8.4 war schon eine neue Passwortklasse enthalten. Ich bin nicht Fachmann genug, beurteilen zu können, ob diese Klasse für die heutige Zeit noch ausreichend ist, aber auch hier gilt das, was unten als Zusammenfassung steht.
Aber auch hier meine grundsätzliche Zustimmung, dass man zumindest das anbieten sollte, was aktueller Stand der Programmiertechnik ist.
Die von dir angesprochene Klasse hat auch schon paar Jahre hinter sich das stimmt. Aber das Ganze wurde geplant, als bei WB noch eine Mindestversion von < 5.5.x war. Somit gab es keine wirkliche Passwort-Hashing Funktion.

Medienverwaltung:
eine mögliche Variante seit mehreren Jahren ist der Elfinder, er ist up-to-date und hat auch eine gute Rechteverwaltung.
Rate mal wer elFinder dem WB-Team nahegelegt hat. Auch den habe ich probehalber mal in eine WB Installation gepackt: ohne Probleme..

jscalendar
hier gilt grundsätzlich, was zur PHPlib geschrieben wurde. Hat zwar ein älteres Baujahr, funktioniert aber dennoch problemlos. Und das größere Problem: durch die zentrale Einbindung nutzt ihn so fast jedes Modul, das eine Kalenderfunktion benötigt. Ich persönlich benutze in meinem Kram einen jquery-Calendar und das nicht nur wegen des moderneren Designs
Siehe meine Meinung zu "Abwärtskompatibilit ät"

zu den Logs allgemein: grundsätzlich halte ich eine Menge davon. Ein gutes Fehler- oder auch Angriffs-Logging zeigt mir die Schwachstellen auf und all das, was in unseren Logs auftritt, ist ja nicht automatisch verschwunden, wenn es nicht aufgezeigt wird.
[...]
Von daher bin ich persönlich auch eher für mehr Informationen, auch, wenn man diese vielleicht besser aufteilen sollte. Ein Log auf einen möglichen Angriff hat (für mich) mehr Bedeutung als ein "undefined_index" in Datei XY und sollte deswegen nicht in einer Liste mit eher weniger wichtigen Dingen auftauchen, sondern vielleicht in einer getrennten Datei (analog der access.log auf dem Server). Notwendig ist auch eine Methode, die solche Dateien, analog der Routine auf Online-Servern, ab z.b. einer bestimmten Dateigröße komprimiert und archiviert.
Alle Logs haben eine Berechtigung. Es sollte einfach die Möglichkeit geben, dass der Admin selbst bestimmt welche Logs er benötigt.
Es ist auch kein Problem, dass man für jeden Tag eine neue Log-Datei anlegt und die alte in eine ZIP-Datei legt.

Für beides gibt es eine gewisse Dringlichkeit, denn selbst die WB 2.10, die auch noch intern und öffentlich unter PHP 7.1 getestet wurde (aktuellste PHP-Version zum Zeitpunkt des Release WB 2.10), macht Zicken unter PHP 7.2.1, hier vor allem im Error-Logging. PHP wird immer restriktiver und zeigt uns heute Sachen auf, die schon vor 10 Jahren unsauber programmiert wurden.  Anderes wurde auch einfach nicht beachtet, wie z.b. $wb->preprocess(), das schon seit 2012 auf der öffentlich zugänglichen Deprecated-List steht.
Siehe meinen Punkt zum Thema "Abwärtskompatibilit ät"

Für nicht Techniker:
Code: [Select]
   
public function preprocess(&$content) {
    trigger_error('invalid method call: '.__METHOD__, E_USER_DEPRECATED);
    //   do nothing
}
Wir reden von einem Code der - genau - nichts macht  :wink:


Als Nächstes steht die Überarbeitung der Homepages an. Ein neues, modernes Design, überarbeitete Module (z.b. im Addons), die WB-Hilfeseite wird wieder aktiviert werden und natürlich auf die aktuellen WB-Versionen aktualisiert. Ein WIKI ist gut und schön, wenn aber nur eine Person (Darkviper) Schreibberechtigung en hat, in der Wille diverser User, sich hier zu engagieren, nutzlos.
Kann ich so nicht bestätigen - in meiner aktiven Zeit hab ich ohne Probleme Schreibberechtigung en bekommen?
Ich würde gern die Welt verändern, doch Gott gibt mir den Quellcode nicht...

Offline evaki

  • Posts: 2220
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #14 on: January 25, 2018, 01:48:56 PM »
Sind die unter Add-ons aufgeführten Module etc. alle unter php 7.2 lauffähig?
Gibts -falls nicht- 'ne Favoriten- bzw. Prioritätenliste?
MfG. Evaki
Einmal Pizza Quattro Stagioni bitte, aber ohne Herbst.

Offline jacobi22

  • Posts: 5201
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #15 on: January 25, 2018, 02:40:01 PM »
Aber die "Mutter" des Forks interessiert mich, wie hier gerade zu sehen ist, immer noch. Und ich finde es schade, dass sich die Kompetenzen heute auf mehrere Zweige verteilen, statt dass Kenntnisse und Energien wieder in und zu einem gebündelt werden. (Man könnte da einen leisen Wunsch heraushören.)

Ein Fork ist immer nur so gut wie das Original  ;-)
Man muß zugeben, das der Florian "drüben" marketing-technisch eine ausgezeichnete Arbeit macht, auch, wenn die Mittel, die für diesen Zweck eingesetzt wurden, nicht immer der Wahrheit entsprachen. So ist WBCE eben nicht die Weiterentwicklung von WebsiteBaker, wie es auch heute noch in der Öffentlichkeit dargestellt wird. Es ist, wie auch Lepton, ein im Open Source-Bereich ganz legaler und auch üblicher Weg, einem Projekt XY einen eigenen Touch zu geben. Dabei spielt es keine Rolle, ob oder welche Veränderungen am Produkt vorgenommen werden.
Wie oben gesagt, es geht nicht um den Fork, Konkurrenz belebt das Geschäft. Mir ging es nur darum, auszudrücken, das er, wie auch die anderen Forks, daraus entstanden sind, weil Leute in ihrem Engagement gebremst wurden.
Wer ein CMS dieser Größe als Entwickler in seiner Freizeit betreut, so wie Darkviper/Luisehahne hier, Florian und andere bei WBCE, Bianca bei Blackcat usw., für den ist es so etwas wie ein "Lebenswerk". Man steckt einen Großteil seiner Zeit und Energie in solch Projekt. Es gibt Lebenspartner und /oder familie, die mitziehen muß, oft ist auch finanzieller einsatz nötig, um "sein Baby" voran zu bringen. Da gibt es Höhen und es wird auch Tiefen geben, aber egal was passiert, man wird nie wieder zurück zur "Mutter" gehen, das verbietet schon der persönliche Stolz und wäre auch den Benutzern kaum erklärbar. Mir fallen auf Schlag 50 oder 100 Punkte ein, warum ich WB allen Forks vorziehe. Und genau wie ich, haben die Leutz bei WBCE ebenfalls ihre Punkte auf der Liste  und bei Lepton, wenn denn noch wer da ist, wird es genauso sein. Bei einer Wiedervereinigung müßte man erklären, warum diese Punkte nun alle nicht mehr wichtig sind. Eigentlich unmöglich, will man nicht die Glaubwürdigkeit verlieren.
Natürlich ist es schade um die Ressourcen, die nun gesplittet sind. Es hätte damals andere Möglichkeiten gegeben, aber zu dem Zeitpunkt wo eine "Community Edition"  diskutiert wurde, waren die Domains wohl schon bestellt.
Heute, nach gut 2,5 Jahren braucht man darüber nicht mehr zu reden. Es ist so wie es ist und offensichtlich können alle Beteiligten damit leben.
Du bist ja nicht der einzige, der diesen leisen Wunsch hat, ist aus Usersicht auch verständlich. Egal, mit welchem System man seine Homepage am Ende laufen hat, es steckt immer viel Arbeit drin, Herzblut, für manchen ist es Einnahmequelle oder auch Pflichtprogramm weil Schulprojekt.
Am Ende muß es laufen.
Und wenn man sieht, das ein Modul XY hier läuft, da aber nicht mehr, stellt man sich als User schon die Frage, warum geht das nicht zusammen, wo doch so vieles noch kompatibel ist? Solch Frage bekomm ich heute einmal pro Monat, war häufiger in der Vergangenheit. Den meisten Benutzern im Privatbereich interessiert kein Code, oft auch keine Sicherheitswarnung, wichtig ist, das "mein Projekt" nach dem Update sofort und störungsfrei läuft. Die Einführung der Filtergeschichte in SP6 hat u.a. dafür gesorgt, das das Script versucht, Links zu CSS-Dateien innerhalb einer Modul-Contentausgabe nach oben in den head-Bereich der Datei zu verschieben. Dafür gibt es HTML-Standards, das ist seit mehr als 10 Jahren bekannt. Nun gibt es aber überall nur noch wenige aktive Modulautoren, andererseits aber jede Menge alter Downloads z.b. auf AMASP mit solch falschen Code, wo auch trotz guter und aktueller Downloadquellen sowohl hier wie auch bei WBCE neuere Modulversionen zu finden sind.
Geht diese Verschiebeversuch in die Hose, gibt es eine weiße Seite. Ein geringer Teil der User fragt dann nach Lösungen, ein anderer Teil probiert einen der Forks. Da der Fork diesen Filter nicht benutzt und mittlerweile auch eine andere Technik verwendet, funktioniert das Modul dort "plötzlich" wieder. Das der Validator darüber meckert und solch "Fehlkonstruktionen" ggf auch negative Auswirkungen in Darstellung und Indizierung haben, interessiert nur die wenigsten. Die Browser gehen immer mehr dazu über, ihr eigenes CSS über diverse Definitionen zu setzen, von daher würde es mich nicht wundern, wenn solch Link zu einer CSS mal irgendwann ignoriert wird.
Durch meine Supporttätigkeit bin ich mindestens einmal pro Woche auf User-Domains, man kennt die Probleme und auch Denkweisen und so manches Mal saß ich mit einem User noch nachts um zwei vor einem Problem, damit die Schul-Homepage morgens um 7 wieder läuft. Wenn ich per Mausklick das System wechseln kann, ist das Problem in einer Stunde gelöst. Ob das in der Zukunft auch noch so funktioniert, werden wir sehen.
Für exakt dieses Problem mit einen <link> in der view.php eines Moduls XY ist der Reparaturaufwand vielleicht für einen Ungeübten max 2 Minuten pro Modul, das entsprechende HOWTO zu suchen, dauert sicher länger. Ein Wechsel auf einen Fork dauert im Prinzip und Idealfall genauso lang.
Die Umstellungen bei PHP erfordern bei jedem CMS Anpassungen und Korrekturen, egal, ob Wordpress, Joomla, WBCE, Lepton oder auch WB. Wir haben da, auch auf Darkvipers Drängen rechtzeitig begonnen, Dinge anzupassen, aus heutiger Sicht absolut richtig. Das Risiko, das dann ein Addon Probleme macht, hast du überall. Unsere Addons waren zum Zeitpunkt der Veröffentlichung der WB 2.10 in 03/2017 alle PHP-7.0 lauffähig, heute, ein Jahr später ist das auch schon wieder überholt und man muß ständig dran bleiben. Wie das bei den Forks ist, kann ich nicht beurteilen, ich nutze eigentlich kaum Original-Module, egal wo her sie stammen.

Jeder hier wie da hat seine eigenen Methoden, seine eigenen Verbesserungen, Code-Modernisierungen und niemand wird bereit sein, auf seine Arbeit zu verzichten, um einen Code von woanders zu übernehmen und darum wird dein leiser Wunsch wohl gelesen, aber nirgens beachtet werden. Tut mir leid, dir da jegliche Hoffung zu nehmen...
« Last Edit: January 25, 2018, 02:45:18 PM by jacobi22 »
Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

Offline jacobi22

  • Posts: 5201
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #16 on: January 25, 2018, 06:17:34 PM »
....... $wb->preprocess(), das schon seit 2012 auf der öffentlich zugänglichen Deprecated-List steht.
Siehe meinen Punkt zum Thema "Abwärtskompatibilit ät"

Für nicht Techniker:
Code: [Select]
   
public function preprocess(&$content) {
    trigger_error('invalid method call: '.__METHOD__, E_USER_DEPRECATED);
    //   do nothing
}
Wir reden von einem Code der - genau - nichts macht  :wink:

genau, sie macht nichts seit Jahren Und seit genau so vielen Jahren steht es auf der DEPRECATED-List

Einfache Frage: ist es dann wirklich nötig, diese Funktion in Module mit Baujahr 2016 oder 2017 einzubauen?

Die Überlegung war recht einfach: Da offensichtlich diese DEPRECATED-List nicht gelesen wird, mach ich jetzt eine Notiz in der error-log
Dann sind gut zwei Jahre Zeit, dies unnütze Kram raus zu werfen, weil es solch Funktion, die NIX macht, in der Nachfolgeversion sicher nicht mehr gegeben hätte. Ist sie ersatzlos raus, gibt es aber einen FATAL-ERROR und was passiert dann?  Die Leute rennen weg, weil es Alternativen gibt

Wie per PN schon mitgeteilt, es ist ein Unterschied, ob ich ein einzelnes Projekt vor mir habe, wo ich es bedenkenlos rauswerfen kann oder ob ich 100.000 oder 800.000 Nutzer mit möglichen Altlasten zu betreuen habe
Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

Offline jacobi22

  • Posts: 5201
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #17 on: January 25, 2018, 06:37:00 PM »
Sind die unter Add-ons aufgeführten Module etc. alle unter php 7.2 lauffähig?
Gibts -falls nicht- 'ne Favoriten- bzw. Prioritätenliste?
MfG. Evaki

ehrlich gesagt: keine Ahnung  :|

Im Rahmen der RC1-Tests werden wohl so an die 50-60% der Addons auch genutzt, aber ein kompletter Test auf PHP 7.2.x aller Addons ist aktuell aus Zeitgründen nicht drin. Die PHP 7.2.0 kam am 30.11.2017, die 7.2.1 (ich glaube) am 4.Januar 2018.
Nicht jeder Tester nutzt schon eine der 7.2er Versionen und wenn doch, konzentriert man sich eher auf das WB-Paket und macht keinen detaillierten Module-Test.
Idealerweise sortiert man nach LAST UPDATED und schaut aufs Datum dieser letzten Aktualisierung. Was irgendwo in der error-log auftaucht, wird in der Regel auch direkt im Modulpaket repariert.

Ich gehe davon aus, das das neue Modul zur Ausgabe der Addons über eine erweiterte Suche verfügt, die die PHP-Versionen unterscheidet, aber das frühestens im März oder April. Wer bis dahin Fehlermeldungen oder Probleme hat, immer her damit, idealerweise im Thread zu Modulen. Ist kein Thread offen, einfach einen neuen anlegen. In aller Regel reagieren wir da recht zügig
Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

Offline evaki

  • Posts: 2220
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #18 on: January 25, 2018, 06:41:41 PM »
Und ich warte seit Jahren auf den barrierefreien Zugang zum Backend.
Eine Userverwaltung, die einen beliebigen parallel installierten Editor individuell einem User zuordnen kann, wäre schon mal ein Anfang, da sich möglicherweise jemand findet, der sich ein Theme dazu strickt.
Ich hab 'ne gaaanz lange Liste...

MfG. Evaki
p.s. Könnt ihr das alte Zeugs nicht anderswo austragen? Büdde, büdde, büdde.
Wers wissen will, kann doch im Archiv nachlesen.
« Last Edit: January 25, 2018, 06:50:11 PM by evaki »
Einmal Pizza Quattro Stagioni bitte, aber ohne Herbst.

Offline jacobi22

  • Posts: 5201
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #19 on: January 26, 2018, 12:02:57 AM »
Habe die Editor-Fragen mal in ein neues Thema ausgegliedert und den Titel entsprechend angepasst

Discussion about WB -Alternative Editor
Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

Offline BlackBird

  • Posts: 2573
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #20 on: January 26, 2018, 11:08:39 AM »
Ein Fork ist immer nur so gut wie das Original  ;-)

'n Brüller. :-D

Man muß zugeben, das der Florian "drüben" marketing-technisch eine ausgezeichnete Arbeit macht, auch, wenn die Mittel, die für diesen Zweck eingesetzt wurden, nicht immer der Wahrheit entsprachen. So ist WBCE eben nicht die Weiterentwicklung von WebsiteBaker, wie es auch heute noch in der Öffentlichkeit dargestellt wird.

Steht wo? Ich lese da lediglich:

Quote
WBCE CMS ist ein Fork (also eine unabhängige Weiterentwicklung) des Content-Management-Systems WebsiteBaker, und wurde im Sommer 2015 gegründet.

Da man hier nicht auf Forks verlinken darf, sucht das Zitat bitte selber.

Davon ab ist jeder Fork automatisch auch immer eine Weiterentwicklung, nämlich exakt ab dem Moment, da der erste Entwickler die erste Änderung im ursprünglichen Code macht. Somit ist kein Fork "nur ein WB mit anderem Namen auf der Schachtel", egal wie nahe er optisch der ursprünglichen Quelle noch sein mag. (BC2 ist im übrigen auch kein Fork mehr, sondern eine komplette Neuentwicklung, aber das nur am Rande.)

Ansonsten kann sich jeder selber ein Bild davon machen, inwieweit der Code der Forks dem von WB voraus ist. Es ist okay, wenn jacobi 100 Gründe nennen kann, bei WB zu bleiben; ich kann mindestens ebensoviele nennen, warum ich anderer Meinung bin. Jedem sei seine eigene Meinung gestattet, zumindest so lange die Argumente sachlich und wahrheitsgemäß sind.

Übrigens: Obwohl ich selber einen WB-Fork habe, habe ich die Gründung von WBCE unterstützt und unterstütze sie immer noch. Die Communities von BC und WBCE sind "befreundet" und gehen freundlich, sachlich und offen miteinander um. Stänkereien bis hin zu Feindschaften werden auf beiden Seiten nicht geduldet. Es wäre sicherlich ein erster Schritt zur Annäherung, wenn das auch in diesem Forum bzw. dieser Community hier möglich wäre.

Offline BlackBird

  • Posts: 2573
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #21 on: January 26, 2018, 11:12:09 AM »
Quote
Eine Abspaltung (auch Fork; englisch fork ‚Gabel‘, üblicherweise im Maskulinum verwendet) ist in der Softwareentwicklung ein Entwicklungszweig nach der Aufspaltung eines Projektes in zwei oder mehrere Folgeprojekte; die Quelltexte oder Teile davon werden hierbei unabhängig vom ursprünglichen Mutterprojekt weiterentwickelt.

https://de.wikipedia.org/wiki/Abspaltung_(Softwareentwicklung)

Nichts anderes steht auf der WBCE-HP.

Offline evaki

  • Posts: 2220
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #22 on: January 26, 2018, 11:56:57 AM »
Wird die alte Art miteinander umzugehen wieder aufgenommen und weitergeführt?
Kann man nicht mal etwas einfach so stehen lassen, auch wenns möglicherweise der größte Unsinn ist? Mich nervt sowas ungemein. Macht das bitte, bitte anderswo (z.B. verschieben). Zur Annäherung gereichen solche Ausuferungen jedenfalls nicht. Unser "Gastkünstler" meint zu derartigem: "In eurem Land wollen die Leute "Recht", statt Zustimmung haben. Das ist sehr befremdlich"

Topic ist:
Re: Discussion about WB-2.11.0 RC1 - Public release test
Wurde ich gerade auch wieder dran erinnert (Alternativer Editor -wer brauchts?)

MfG. Evaki
« Last Edit: January 26, 2018, 12:04:21 PM by evaki »
Einmal Pizza Quattro Stagioni bitte, aber ohne Herbst.

Offline hgs

  • Betatester
  • **
  • Posts: 920
    • EFG MG
Re: Re: Discussion about WB-2.11.0 RC1 - Public release test
« Reply #23 on: January 26, 2018, 12:06:37 PM »
 (Y)
LG Harald

"Fange nie an, aufzuhören - höre nie auf, anzufangen." Marcus Tullius Cicero (106-43 v.Chr.)

Offline Martin Hecht

  • Betatester
  • **
  • Posts: 535
  • Gender: Male
    • meine Homepage
Re: Re: Discussion about WB-2.11.0
« Reply #24 on: January 29, 2018, 11:59:31 PM »
Hallo,

von meiner Seite möchte ich in der Diskussion zu 3 Punkten einhaken:

zur php 7.2 Kompatibilität der Module:

Wenn es da Probleme gibt, findet sich im Forum meist ein Vorschlag. Wenn es für das jeweilige Modul einen Maintainer gibt, der noch aktiv an dem Modul arbeitet, hilft es meist, ihn auf das  Problem bzw auf die im Forum vorgeschlagene Lösung hinzuweisen. Mir entgeht hin und wieder auch die ein oder andere Diskussion und da bin ich für solche Hinweise dankbar.
Wenn es keinen Maintainer mehr gibt, dann sind solche Lösungen im Forum trotzdem hilfreich. Dann können andere die im Forum gepostete Version testen, und nicht selten lädt sie einer aus dem Kern-Team dann ins Addons-Repo hoch.

zum Thema Kompatibilität der Addons zwischen WB und dem besagten Fork:

Als Modulentwickler erreichen mich gelegentlich Anfragen, dies oder jenes anzupassen, um mit der nächsten Version hier oder dort kompatibel zu sein. Bisher waren das meist Altlasten schlechter Programmierung, die auch die Module aus historischen Gründen mitschleppen, wenn man sie nicht mal von Grund auf komplett neu schreibt. In den meisten Fällen sind solche Code-Bereinigungen der Kompatibilität auf der anderen Seite nicht abträglich. Manche anderen Wünsche ließen sich mit relativ einfachen Prüfungen unter welchem System das Modul gerade läuft behandeln. Entsprechend ließ sich zumindest bisher die Kompatibilität zu beiden Platformen bewahren.
Ich weiß allerdings nicht, wie das andere Autoren handhaben. Ich würde hoffen, dass die meisten ähnlich vorgehen. Bei manchen Modulen (vor allem die Core-Module) gibt es mittlerweile zwei separate Entwicklungen. Solange im jeweiligen Addons-Repo eine aktuelle Version verfügbar ist oder direkt im Core-Paket ausgeliefert wird, passt das ja auch. Wenn die Datenbankstrukturen des Moduls beim Upgrade umgestellt werden, müssen beide Seiten darauf Rücksicht nehmen, schon allein im Interesse der eigenen Benutzer, die von der jeweils anderen Version migriert haben und anschließend hoffentlich noch lauffähige Module haben.

zu phplib vs. Twig:

Man könnte den Core mal auf Twig umstellen. Dann hätten Modulautoren innerhalb des Core genug Beispiele, an denen sie sich orientieren können. Ich habe Outputfilter Dashboard vor einiger Zeit von PMF auf phplib umgestellt. Meine Wahl fiel auf phplib aus 2 Gründen: alle Module, mit denen ich bis dahin zu tun hatte, haben phplib verwendet und der Core verwendet im Backend durchgängig phplib. Daher war es naheliegend, diese hierfür auch einzusetzen.
Klar ist die Umstellung jedes Moduls mit Aufwand verbunden, aber wenn mal der Core umgestellt ist und ein Zeitplan vorliegt, können die Module nachgezogen werden. Ein Problem sind dabei sicherlich die alten Module, um die sich niemand mehr kümmert. Auch dafür wäre es denkbar, die phplib als Kompatibilitäts-Modul anzubieten, das der Anwender auf eigenes Risiko zusammen mit einem Uraltmodul installieren muss. Übrigens: über Bestrebungen, die phplib rauszuschmeißen habe ich sowohl hier als auch dort schon gelesen.

Martin

PS: Offtopic: Da es zum Umgangston im Forum hier in diesem Thread auch schon Äußerungen gab, lasse ich mich zu der Aussage hinreißen, dass das wohl für manche ein Grund ist, zum Fork zu wechseln. Nicht dass es da auch manchmal verbale Entgleisungen gibt, aber im Durchschnitt gesehen ist dort der Ton doch deutlich angenehmer. Ich hoffe dass sich mit der Neuausrichtung hier bei WB auch  (wieder) ein freundlicheres Klima durchsetzt.

 

postern-length