Smalltalk - Labern, reden, diskutieren...

  • Mein Wunsch wäre ja, dass die aktuellste WSC Version auch immer die aktuellste PHP-Version voraussetzt ^^

    Aber gut die Diskussion hatten wir glaube schon zu oft.

    Wäre sicher toll, aber utopisch. Wobei man auch nicht immer alle neuen Features wirklich braucht oder nutzt. Aber ja, manchmal wäre es schöner, wenn man schon etwas weiter wäre.

    Zumindest wäre der Ausschluss von nicht mehr supporteten PHP-Versionen wünschenswert. Das würde es auch bei der Plugin-Entwicklung vereinfachen.

    Wäre durchaus wünschenswert, vor allem für die Entwickler*innen, die es eher als Nebenbeschäftigung/Hobby betreiben, auch wenn sie ihre Produkte zum Download anbieten.

    Es macht schon einen Unterschied, ob man nun Geld verdienen möchte, dann ist es richtig, dann muss man möglichst breit fächern. Wer aber weniger Interesse am Geld hat, ist da immer ein wenig "gefangen" und muss sich auch oft noch zusätzlich erklären. Finde ich doof!

  • Ob das wirklich unmöglich ist, eine neuere Version vorauszusetzen, weiß ich nicht. Pimcore, was ja auch immerhin von über 100.000 Unternehmen eingesetzt ist, setzt auch längst zwingend mindestens PHP 8.0 voraus. Aber natürlich kennt WoltLab seine eigenen Kunden am besten und deren Zielgruppe mag noch nicht so weit sein. Das ist sicherlich nichts, was man pauschal für alle Softwares zum gleichen Zeitpunkt voraussetzen kann.

  • Ihr dürft nicht vergessen, dass die Software vorwiegend für die Masse entwickelt wird und die Masse häufig auf das Wohlwollen des Hosters angewiesen ist

    Das ist richtig. Ich wollte vorhin eigentlich nur die Aussage entsprechend relativieren, dass das WSC kein Maßstab ist, bei dem breaking changes in PHP eine Sensation wären.

    Ich würde es sogar als Schikane sehen, wenn Plugin-Entwickler ihre Plugins zum aktuellen Zeitpunkt so bauen, dass PHP 8 erforderlich ist.

    Mei, man muss es halt kommunizieren. Ich mache das Ganze nicht um damit reich zu werden, insofern ist meine Priorität auch nicht möglichst viele Kunden zu catchen und mich mit Kompatibilitäten in den Wahnsinn zu treiben.

    Schlussendlich steht es auch jedem frei seinen Hoster entsprechend um eine Stellungnahme zu bitten, warum aktuelle PHP-Versionen nicht verfügbar sind.

    denke ich daß es mit 5.7/6.0

    WSC 5.6 wird immerhin PHP 7.4 voraussetzen soweit ich informiert bin.

  • Ich bin trotzdem der Meinung, dass es nicht sinnvoll ist, eine 4 Monate alte PHP-Version zwingend vorauszusetzen. Sinnvollerweise sollte sich die Plugin-Kompatibilität nach der WSC-Kompatibilität- und nicht nach der PHP-Version richten. Aber die Diskussion hatten wir schon an anderer Stelle.

    • Offizieller Beitrag

    Die Version 5.5 wird offiziell nur PHP 7.4+ unterstützen. Ein Betrieb mit PHP 7.2 bzw. 7.3 wird allerdings möglich sein, aber wird von uns nicht gewährleistet. Die Entscheidung PHP 7.2 bzw. 7.3 zu erlauben liegt schlicht daran, dass die Code-Basis grundsätzlich kompatibel ist und wir keinen Grund gesehen haben, die Kompatibilität vorsätzlich zu verbauen.

    Zukünftig werden wir aber stärker neuere PHP-Versionen voraussetzen, auch weil sich das Ökosystem bei den Hostern geändert hat. Insbesondere Plesk bietet inzwischen zeitnah neuere PHP-Versionen und auch bei den Linux-Distributionen greift das Verständnis um sich, dass Software nicht aus dem letzten Jahrzehnt stammen sollte.

    Ich kann mir auch vorstellen, mit der darauffolgenden Version direkt auf PHP 8.0 zu setzen, da wir dann auf einen Schlag eine ganze Menge an Neuerungen zur Verfügung haben. PHP 7.3 war beispielsweise ziemlich uninteressant für uns, weshalb wir für 5.4 bei PHP 7.2 geblieben sind.

  • Kann man es nicht WordPress-Style(tm) machen und sagen, der Core setzt Version X voraus, und Plugins können individuell eine höhere Version fordern?

    Milestones:

    • 18.02.2022 19:14 CET: Erste PWA installiert (und es war ausgerechnet YouTube Music)
  • eine 4 Monate alte PHP-Version

    Ah, wir reden aneinander vorbei. PHP 8 (= 8.0+) ist bald 1,5 Jahre alt. Du meintest dann wohl PHP 8.1, das ist vier Monate alt. 👀

    8.1 nutze ich aktuell nur im Packagesniffer, der bekanntlich nur intern bei mir läuft. Und evtl. im Friedhof irgendwann - nachdem ich hier mit keinem Upgrade in 2022 rechne, ist 8.1 dann auch wieder mindestens ein Jahr alt und 8.0 kriegt keinen aktiven Support mehr. Schlussendlich ist dann natürlich die Frage, ob überhaupt etwas genutzt wird bzw. werden muss, das 8.1 und nicht 8.0 erfordert; 8.0 bekommt offiziell ja Sicherheitsupdates bis Ende 2023 und wäre damit noch vertretbar.

    und Plugins können individuell eine höhere Version fordern?

    Die Reste davon wurden erst vor kurzem vollständig aus dem WSC entfernt. ^^

    Die Version 5.5 wird offiziell nur PHP 7.4+ unterstützen.

    Ah, sehr angenehm. Ich glaube wir hatten uns damals aus irgendwelchen Gründen nur über 5.6 unterhalten.

    Zukünftig werden wir aber stärker neuere PHP-Versionen voraussetzen, auch weil sic das Ökosystem bei den Hostern geändert hat.

    Aus Entwickler-Sicht finde ich das sehr angenehm. Eventuell führt das ja auch dazu, dass sich die Betreiber mehr damit beschäftigen, was sie da eigentlich machen und warum manche Sachen toll und manche eher mau sind. Ich habe das Gefühl, dass viele nicht über die technische Basis nachdenken (wollen), Hauptsache es ist billig oder am besten kostenlos.

    Ich kann mir auch vorstellen, mit der darauffolgenden Version direkt auf PHP 8.0 zu setzen, da wir dann auf einen Schlag eine ganze Menge an Neuerungen zur Verfügung haben. PHP 7.3 war beispielsweise ziemlich uninteressant für uns, weshalb wir für 5.4 bei PHP 7.2 geblieben sind.

    To be honest, 8.0 oder 8.1 würde ich mit 6.0 einführen. Eben weil man dann den Code ein Mal komplett durcharbeiten kann ohne den Spagat ins Unermessliche zu treiben. Ob nach 5.5 dann 5.6 oder 6.0 kommt, ist natürlich eine andere Frage. :D

    Ich wäre (aktuell) fast für 5.6 in 2023 mit 7.4+ und 6.0 in 2024/25 mit 8.1+, dann kann man Enums auch nutzen und 8.1 ist auch schon etwas älter. Groß darüber Gedanken gemacht habe ich mir aber nicht - liegt schlussendlich nicht in meiner Hand.

  • Pimcore, was ja auch immerhin von über 100.000 Unternehmen eingesetzt ist, setzt auch längst zwingend mindestens PHP 8.0 voraus.

    Ich glaube, hier ist ein Vergleich schwierig, da Pimcore eher explizit etwas für Unternehmen ist und daher in der Regel sowieso schon eine gewisse Infrastruktur vorhanden oder über eigene/managed Server entsprechend den Bedürfnissen vorhanden ist.

    Die WoltLab Suite dagegen hat da doch einen wesentlich größeren Fokus auch auf Privatpersonen.

    und auch bei den Linux-Distributionen greift das Verständnis um sich, dass Software nicht aus dem letzten Jahrzehnt stammen sollte.

    Debian :evil: :D

    Zumindest ist sid aktuell auf 8.1.

  • Hallo,

    wie würde ich es denn anstellen, wenn ich in CSS einen Abschnitt @media (prefers-color-scheme: dark) { für den Dark-Mode habe und diesen auch als Option für alle anbieten wollen würde?

    Also die "schönste" Lösung wäre sowas wie @media (prefers-color-scheme: dark), body.darkmode { (und dann dem <body> die Klasse "darkmode" gebe).

    Aber das geht natürlich nicht. :D

    Milestones:

    • 18.02.2022 19:14 CET: Erste PWA installiert (und es war ausgerechnet YouTube Music)
  • Hallo,

    wie würde ich es denn anstellen, wenn ich in CSS einen Abschnitt @media (prefers-color-scheme: dark) { für den Dark-Mode habe und diesen auch als Option für alle anbieten wollen würde?

    Also die "schönste" Lösung wäre sowas wie @media (prefers-color-scheme: dark), body.darkmode { (und dann dem <body> die Klasse "darkmode" gebe).

    Aber das geht natürlich nicht. :D

    Wieso soll das nicht gehen :/

    Projekte:

    XIVDATA - Eorzea Database

    A red dragon falls from the heavens... Ah, that memory has been lost. A shame. It was a favorite of mine...

  • Ich habe es bei mir so gelöst, dass Dark und Light Mode sich dasselbe CSS und Templates teilen, aber über SCSS dann eine Variable des Color-Pickers als Indikator dafür dient, ob das CSS für Dark oder Light Mode generiert werden soll. Dann kannst du sie als zwei normale Stile benutzen und bei Änderungen einfach das gesamte angepasste CSS von einem Stil in den anderen kopieren.

    • Offizieller Beitrag

    Hallo,

    ich hoffe TLDR und Xopez haben mich schon vermisst :saint:

    GitLab […] warum ich es für ein paar private Projekte noch nutze ist, dass es damals noch keine kostenlosen privaten Repositories für Gruppen auf GitHub gab und der Wechsel jetzt zu aufwändig wäre.

    Der hier ist übrigens gealtert wie Milch:

    https://news.ycombinator.com/item?id=30791162 "Upcoming changes to user limits on Free tier of Gitlab SaaS"

    Jetzt darf ich den ganzen Kram doch noch umziehen :(

    Kann ich mit tmux ja auch :p. In einem Terminal Fenster mit mehreren Panes und los gehts.

    Den Reiz dazu habe ich noch nicht so recht verstanden. Bei den Terminal-Multiplexern (egal ob screen oder tmux) gehen einem die ganzen Komfort-Funktionen des eigenen Terminals verloren bzw. müssen auf den entsprechen Mux umgelernt werden. Da kann ich doch viel besser mehrere separate Terminals aufmachen ?(

    Bisher ist es harmlos: https://php.watch/versions/8.2

    Es ist zwar „nur“ eine Deprecation, aber das hier Dynamic Properties are deprecated wird noch schön viel Fallout geben, harmlos würde ich das auf keinen Fall nennen. Im Plugin-Store versuche ich es bei der Prüfung zwar zu erkennen, aber vermutlich habe ich es auch ein paar mal übersehen. Leider versuchen manche Plugins schreibend auf ein DatabaseObject zuzugreifen. Das "scheint" zwar zu funktionieren, aber nur, weil die entsprechende Property dann implizit erstellt wird und den Original-Wert in __get() verdeckt.

    Die WoltLab Suite ist jetzt auch nichts, das man als PHP-technisch up to date, modern, innovativ oder wie man es nennen will nennen kann. WSC 5.4 basiert auf 7.2.24.

    Das Thema ist zwar schon lang gegessen, aber den halte ich nicht für ganz fair: Die Breaking Changes betreffen uns ja ganz genau so und insbesondere entfallen durch unseren strikten Error-Handler, der alle Arten von PHP-Fehler in eine Exception verwandelt bereits jetzt ganze Klassen von PHP-Footguns. Ja, der Code hat als Mindestanforderung PHP 7.2 und ja, der schleppt natürlich auch ein paar Altlasten mit, aber ob man jetzt nun match() statt switch() verwendet ist ein eher schlechter Indikator für „modern“ oder „nicht modern“.

    Das ist richtig. Ich wollte vorhin eigentlich nur die Aussage entsprechend relativieren, dass das WSC kein Maßstab ist, bei dem breaking changes in PHP eine Sensation wären.

    Und hierzu siehe:

    Tim Düsterhus
    29. November 2021 um 12:12

    Den Tweet ganz unten. PHP 8.1 selbst für Bibliotheken nach allen Best Practices (Statische Analyse, PHPUnit, Mutation Tests), die in einer sehr guten Verfassung waren, ein Alptraum.

  • Es ist zwar „nur“ eine Deprecation, aber das hier Dynamic Properties are deprecated wird noch schön viel Fallout geben, harmlos würde ich das auf keinen Fall nennen. Im Plugin-Store versuche ich es bei der Prüfung zwar zu erkennen, aber vermutlich habe ich es auch ein paar mal übersehen. Leider versuchen manche Plugins schreibend auf ein DatabaseObject zuzugreifen. Das "scheint" zwar zu funktionieren, aber nur, weil die entsprechende Property dann implizit erstellt wird und den Original-Wert in __get() verdeckt.

    Oh ja ^^ gut das ich das nun weiß...

    Diese Schandtat habe ich des Öfteren schon angewandt...

    Projekte:

    XIVDATA - Eorzea Database

    A red dragon falls from the heavens... Ah, that memory has been lost. A shame. It was a favorite of mine...

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!