Ärgerlich: Entwickler-Gewohnheiten

grindbatzn · 16.03.2016 14:25:21

Weils mir gerade aufgefallen ist:

Diese 2 Code-Zeilen machen offensichtlich das selbe:

$retVal[] = isset($msg)?:'Info '.$module_name;
und
if (isset($msg)) {$retVal[] = $msg; } else {$retVal[] = 'Info '.$module_name;}

Der Unterschied ist:
Erste Zeile braucht neues PHP und läuft zb auf PHP 5.2 nicht mehr.
Die 2. Zeile läuft von PHP 3 bis 15
Geschwindigkeit? Sicherheit? Kein Unterschied.

Ein Großteil von dem, was in WB(CE) Ärger mit älteren PHP-Versionen macht, ist NUR sowas: Entwickler wollen "modernen Code" schreiben.
Und weil jeder andere Launen hat, läuft mal das Modul nicht mehr dort und der Core nicht mehr da.

Muss denn das sein?
Warum nicht einfach mal die Variante nehmen, die auch noch auf älteren Versionen läuft?

Puh! (grummel ;-)

florian · 16.03.2016 14:37:24

Warum nicht einfach mal die Variante nehmen, die auch noch auf älteren Versionen läuft?

Weil die alten Varianten möglicherweise irgendwann nicht mehr auf neuen Systemen laufen.
Stichwort mysql/mysqli, mysql_strict, depreciated usw.

PHP 3 bis 5.2 sind kein Maßstab. End of Life war da in grauer Vorzeit.

Entwickler wollen "modernen Code" schreiben.

Moderner Code als Selbstzweck oder aus Eitelkeit? Glaube ich nicht.

(Unsachliche Formulierung entfernt, 23.03.16)

Beitrag geändert von florian (23.03.2016 13:30:48)

grindbatzn · 16.03.2016 14:44:18

Und zur Info:
Ich habe in WB.at und beesign.com - beide WB 283 SP1 den Patch von hier eingespielt.
Abgesehen von obigem Problem scheint es klaglos zu funktionieren. (vorerst, ich habe keine Module installiert oder mein Passwort neu angefordert)

Beitrag geändert von grindbatzn (16.03.2016 14:45:08)

grindbatzn · 16.03.2016 15:09:59

Die Variante:
if (isset($msg)) {$retVal[] = $msg; } else {$retVal[] = 'Info '.$module_name;}
wird laufen, solange es PHP gibt.

Das wird NIE "möglicherweise irgendwann nicht mehr auf neuen Systemen laufen"
Die andere Variante ($retVal[] = isset($msg)?:'Info '.$module_name;) kann sehr schnell mal wieder raus sein.

Das mit dem Hinweis auf " mysql/mysqli" zu relativieren, ist - sorry: "Classic Style"

Es gab mal ein Upgrade vom MP-Form, das nur wegen einer(!) Zeile Code eine neuere PHP-Version voraussetzte.
Diese Zeile hätte ganz leicht etwas anders geschrieben werden können.

Ich finde, man sollte da etwas mehr drauf achten.
Der Durchschnittsuser kann nicht so schnell mal PHP ändern, und es kann auch nicht sein, dass sich WB(CE) selbst von Entwickler zu Entwickler fragmentiert.

bernd · 16.03.2016 16:18:45

Wenn ich das richtig verstehe ist ja der einzige Knackpunkt an der Stelle das "?:"
also die ab PHP5.3 mögliche Abkürzung das man die Angabe für den if-Fall weglassen kann.
Ein
$retVal[] = isset($msg)?$msg:'Info '.$module_name;
und es wäre alles wieder im Lot, oder?

Ich bin eh nicht so der Freund von diesen abgekürzten Schreibweisen, letztendlich leidet doch die "Lesbarkeit" des Codes drunter und mit der zusätzlichen Verkürzung "?:" wird das definitv nicht besser.

webbird · 16.03.2016 19:35:04

Ich wurde gerade mal wieder von meinem Provider "genervt", weil man dort den Extended Support für ältere PHP Versionen abschalten will und man daher dringendst aufgefordert wird, für seine Domains auf 5.6 zu wechseln. Eine Lauffähigkeit für 5.2 und noch älter zu fordern, die seit Jahren keinen Support mehr haben und sicherheitstechnisch ein Albtraum sein dürften, erscheint mir am Ziel vorbei geschossen. Letztendlich entscheidet jeder Entwickler für sich, wie er seinen Code schreibt und welche PHP-Version er dafür voraussetzt. Für den Core können wir das gemeinsam festlegen, für Module nicht. (Wo auch immer Du den Code-Ausschnitt jetzt gefunden hast.)

Mein Standpunkt ist, daß WBCE auf allen aktuellen (=offiziell noch supporteten) PHP-Versionen laufen muß, aber nicht auf Uralt-Versionen, deren Gebeine schon längst zu Staub zerfallen sind.

Bei meinen (!) Modulen lasse ich mir keine Vorschriften machen, was ich zu tun und zu lassen habe. Wenn das jemandem nicht paßt, möge er eben auf andere Module ausweichen.

Jeder Entwickler hat seinen Stil, und genauso wenig, wie Du, chio, Dich gern für Deinen funktionalen Spaghetti-Code kritisieren läßt, lassen sich andere gern für ihren objektorientierten oder anders eingerückten oder sonstwie "anders" aussehenden Code kritisieren. Oder soll ich mal erwähnen, daß ich es Sch... finde, daß die Leute immer noch include('...'); schreiben, obwohl das syntaktisch falsch ist? Der Interpreter toleriert es, falsch ist es trotzdem.

Kümmert Euch lieber um wirklich wichtige Dinge, z.B. daß es keine Notices geben darf, auch wenn es "nur" Notices sind. Es gibt Module, die man ohne E_NONE gar nicht benutzen kann, weil sie einem sonst den Bildschirm vollmüllen. Das fängt bei mysql_* an, geht über den /e Modifier beim preg_match und hört bei anderen seit langem als deprecated gekennzeichneten Funktionen noch lange nicht auf.

stefanek

grindbatzn · 16.03.2016 20:20:43

Das obige Stück Code habe ich im Sicherheitspatch gefunden und es hat verhindert, dass ich auf einer älteren Site (die eben noch mit PHP 5.2 läuft) den Patch einspiele.
Naja - ich kann wenigstens eine Fehlermeldung interpretieren und handeln, andere sehen nicht mal die Meldung.

Ich will da jetzt auch gar kein großes Theater machen, sondern einfach nur drauf hinweisen: Schauts bitte a bissel auf sowas. Wenns leicht geht ;-)
Dort wo keine Sicherheitsaspekte betroffen sind, sollte man eine möglichst breite Basis wählen, finde ich.

norhei · 16.03.2016 20:22:21

Ich schaue mir das gleich nochmal an , was ich weiß ist ist das Dietmar ein Faible für die neue Scheibweise hat und deswegen in jeder Änderung die If Then austauscht wo immer das geht , da der PAtch ja etwas von der Classic Version benutzt ist es kein Wunder das sowas mitkommt . Und da kaum einer noch 5.2 benutzt , fällt es halt nicht auf.

Beide Schreibweisen sind mit Sicherheit Zukunftssicher , von daher brauch sich Niemand Sorgen machen.

Offiziell wird php 5.2 ja eigentlich nicht mehr unterstützt , aber wenn ich damit jemandem eine Freude machen kann.
Das ist eines der Dinge bei denen draufsteht, das es eine Änderung ist die niemandem Wehtut und Einigen Freude macht.
also warum nicht eine Freude machen. Ich werde das anpassen.

Bin gleich wieder Zuhause , schreib da nochwas zu .

florian · 16.03.2016 21:09:33

@webbird: +1 von mir.

norhei · 16.03.2016 22:13:23

Also, morgen und übermorgen werde ich mich vermutlich auf den hinsetzen und mal die 1.1.x soweit überarbeiten das wir da ein Patch Release haben das so raus kann . Morgen wird auch die Sicherheitlücke öffentlich , und dann haben wir Gewissheit was den Patch betrifft. Das wird alles dann zusammengeschnürt und gibt ein neues Release.

Die Kleinigkeit für Chio kommt einfach mit rein , es kostet uns überhaupt nichts. Wobei ich halt aber auch anmerken muss, das es bei späteren Versionen einfach sein kann, das so alte PHP Versionen nicht mehr funktionieren. Namespaces nutzen wir noch eine Weile nicht und spl_autoloader funktioniert glaube ich schon mit 5.2. Also sagen wir das mal so : Im Gegensatz zu DV forciere ich das nicht extrem mit den PHP Versionen, aber es kann halt nicht ewig gut gehen.

Nebenbei PHP 5.2 aber mit mysqli Treiber ist schon irgendwie schräg der hoster :-)

grindbatzn · 17.03.2016 00:47:24

Hier geht es ja nicht um "gefallen" oder nicht, sondern um diese "hinter mir die Sintflut"-Einstellung.
Sobald man das mal zum Usus macht, hat man das immer als Klotz am Bein. Wer kennt nicht noch die 0.0.1er Schritte beim Upgrade von WB. Ein Horror.

Die Leute da draußen haben irgendwelche Hoster, die eben irgendwann diese und jene Einstellungen eingefroren haben.
Man sollte diese Leute nicht einfach im Stich lassen, die können ja nix dafür.
Du kannst nicht zu einem Rollstuhlfahrer sagen: Selber schuld, wenn du nicht laufen kannst. Wir unterstützen nur Leute, die laufen können; das tun wir aus Gewohnheit so, wir können ja laufen.
Bitte: Ein bissel mehr Umsicht.

@norhei: die genaue Version ist: PHP Version 5.2.17
Keine Ahnung, wie schräg der Hoster ist.

florian · 17.03.2016 07:39:52

Hier geht es ja nicht um "gefallen" oder nicht, sondern um diese "hinter mir die Sintflut"-Einstellung.

Das ist eine pauschalisierende, ungerechte und unangemessene Unterstellung. Bitte bleibe sachlich.

Im übrigen: Die Systemvoraussetzungen für WBCE ist bislang (moderates) PHP 5.3.6.
Du kannst nicht erwarten und verlangen, dass ein zeitgemäßes, sicheres und komfortables CMS bzw. Modul auch noch in veralteten Serverumgebungen läuft.

Das bedeutet im Gegenzug aber natürlich auch, dass Modulentwickler_innen darauf Rücksicht nehmen oder zumindest deutlich darauf hinweisen, wenn Module neuere PHP-Versionen voraussetzen.

Beitrag geändert von florian (17.03.2016 08:01:47)

webbird · 17.03.2016 12:26:39

norhei schrieb:

Ich schaue mir das gleich nochmal an , was ich weiß ist ist das Dietmar ein Faible für die neue Scheibweise hat und deswegen in jeder Änderung die If Then austauscht wo immer das geht

Mache ich in diesem konkreten Beispiel auch. Nicht weil es eine "neue" Schreibweise ist und ich die so toll ich mich dabei so geil finde - genau genommen habe ich die schon "damals" in Perl verwendet, ich weiß gar nicht, ob PHP das da überhaupt schon konnte. Ich (!) finde es in vielen Fällen einfach übersichtlicher als eine lange if-then-else-Zeile. Genauso wie ich switch() übersichtlicher finde als endlose if-elseif-elseif-elseif-elseif-elseif-Konstrukte. Viele Schreibweisen (einschließlich Einrückungen, Platzierung von Klammern usw.) habe ich aus _dem_ Perl Best Practise Standardwerk übernommen. Ob das auf PHP übertragbar ist oder nicht will ich nicht diskutieren, es ist einfach so, daß der Autor gute Gründe hatte, die ich nachvollziehen konnte, weswegen ich sie mir zu eigen gemacht habe. Das mögen andere anders sehen, das respektiere ich - so lange man auch meinen Standpunkt respektiert.

Die Unterstellung, Entwickler seien ignorant ("nach mir die Sintflut") oder würden sich nur deshalb auf "moderne" Schreibweisen stürzen, weil sie sich dabei so toll finden*, wie das hier durchklingt, ist nicht nur ungerecht(fertigt), sondern auch beleidigend. Oft hat einfach jemand eine Lösung gesucht, irgendwo eine gefunden, die hat funktioniert - fertig. Daß diese Lösung/Schreibweise dann möglicherweise erst ab PHP Version XY funktioniert, mag dem Betreffenden gar nicht bewußt gewesen sein. Vermutlich in 99% aller Fälle.

Es ist mit Sicherheit wichtig, für den Core eine Basis festzulegen - was auch geschehen ist, wie florian schon schrieb. Diese Basis bestimmen diejenigen, die für den Core verantwortlich sind. Das ist mein Standpunkt dazu.

(* Meine Kollegen würden sich deutlich vulgärer ausdrücken, aber das will ich den zarten Gemütern hier nicht zumuten.)

webbird · 17.03.2016 12:33:26

Wer sich wirklich mal mit Best Practice auseinander setzen möchte, dem sei diese Seite ans Herz gelegt:

http://www.phptherightway.com/

Allerdings wird da jede Menge "neumodisches Zeug" behandelt.

PHP is a flexible, dynamic language that supports a variety of programming techniques. It has evolved dramatically over the years, notably adding a solid object-oriented model in PHP 5.0 (2004), anonymous functions and namespaces in PHP 5.3 (2009), and traits in PHP 5.4 (2012).

norhei · 17.03.2016 18:01:39

Viele ähnliche Diskussionen habe ich auch schon zum gefunden wenn es darum geht welche Browser auf modernen Webseiten noch unterstützt werden sollen.

Hier mal ein paar Gedanken.

Grundsätzlich ist da die Policy bei WB ja extrem moderat. (PHP 5.3.7 oder so.)

Wenn nun ein einzelner Ausdruck verhindert das WBCE auch noch unter einer alten PHP Version läuft gibt es keinen vernünftigen Grund den nicht auszutauschen.

Allerdings ist da auch das Problem das die alten PHP Versionen furchtbar unsicher sind.

Weiterhin ist es einfach Fakt das PHP sich weiterentwickelt hat und zu erwarten das jetzt wo wir mittlerweile schon fast einen Flächendeckende Verbreitung von PHP 7 haben käme glaube ich auch Niemand auf die Idee zu erwarten das ein CMS noch PHP4 unterstützt. PHP 5.2 ist wirklich schon sehr alt und selbst der Sprung zu 5.3 ist riesig.

Solange sich mit ein paar Handgriffen da eine Compatibilität herstellen lässt , wer bin ich das ich mich in den Weg stelle.

Ein Hoster der noch bei 5.2 feststeckt ist grottenschlecht und sogar gefährlich, da er sich einen Dreck um Sicherheit schert. Also ist da schon der Gedanke nicht weit sich einen neuen Hoster zu suchen. Ich vermute einfach mal das das aus irgendeinem Grund nicht geht. Wäre schön wenn Du mir den Grund mal in einer PM senden könntest vielleicht habe ich eine Gute Idee das zu ändern.

Als Programmierer würde ich am liebsten direkt auf PHP 7 Umsteigen, weil das vieles vereinfacht, schneller ist und eigentlich die erste PHP Version ist, die nicht komplett bekloppt gebaut ist. Ich muss mich da jeden Tag zurück halten. Oder wenigstens PHP 5.5 das mindestens ein vernünftiges sicheres Bcrypt unterstützt.

Die Welt geht einfach weiter und wer nicht mitgeht wird irgendwann überrollt . Zwar sind wir hier noch eine Weile davon entfernt , aber wie schon gesagt irgendwann wird es nicht mehr gehen.

Oft hat einfach jemand eine Lösung gesucht, irgendwo eine gefunden, die hat funktioniert - fertig. Daß diese Lösung/Schreibweise dann möglicherweise erst ab PHP Version XY funktioniert, mag dem Betreffenden gar nicht bewußt gewesen sein. Vermutlich in 99% aller Fälle.

100% ! Zum Beispiel hat mein Hoster gar keine Möglichkeit mehr mit weniger als 5.6 zu testen. Nebenbei, auch bei Bitnami gibt es nur noch 5.5 als minimale LAMP Version. Und ansonsten kenne ich keinen Hoster mehr der noch vor 5.4 unterstützt.(Will nicht sagen das es das nicht gibt. )

Nebenbei es ist einfach Keinem aufgefallen das es da ein Problem gibt , weil keiner sonst das Problem hatte. Mehr als zu sagen: "na gut das wird gepatcht" können wir nicht machen ? Die Schreibweise ist schon seit 7 Jahren funktionierender PHP Standard.

webbird · 17.03.2016 20:32:49

norhei schrieb:

Viele ähnliche Diskussionen habe ich auch schon zum gefunden wenn es darum geht welche Browser auf modernen Webseiten noch unterstützt werden sollen.

Das hat oft Ähnlichkeit mit Glaubensfragen. Die einen bestehen auf X, die anderen auf Y. Dazwischen gibt es nichts.

Weitere Beispiele:

* Objektorientiert vs. prozedural
* Javascript ja oder nein
* jQuery vs. MooTools vs. Vanilla
* Dürfen Module zusätzliche Abhängigkeiten haben?
* Sollten Buttons nicht besser grün sein...?

wink

easyuser · 17.03.2016 23:34:27

Vielleicht nur als Gedankenstütze, wie es "die anderen" machen:
https://wordpress.org/about/requirements/
Der rechte Kasten hierzu ist ganz interessant:

https://wordpress.org/about/requirements/ schrieb:

Why do we support older versions?
We strongly recommend the latest versions of PHP and MySQL, but we understand that this isn’t right for everyone, and that sometimes hosts can be slow or hesitant to upgrade their customers since upgrades to PHP and MySQL have historically broken applications.
WordPress will always work on the latest versions of PHP and MySQL, which are often faster and more stable.

Das grausige Problem bei Webhosts ist es einfach, dass es Unmengen an unterschiedlichen Kombinationen gibt und noch mehr "Webhoster" die meinen, ohne Updates lassen sich Supportkosten niedrig halten.
Allerdings gibt's das Problem bei moderneren Umgebungen als dem alten WWW ebenfalls, man sehe sich nur mal bei Android um...
Und selbst Microsoft hat es bis heute nicht geschafft, den Internet Explorer und Windows XP zu töten.
Auf der anderen Seite muss ich auch als Entwickler gestehen (auch wenn ich beruflich meine Umgebungen selbst definieren kann): Alles was neu ist wird sofort benutzt... Ein schwieriges Thema das ist - denn man will ja WB(CE) so genügsam wie irgend möglich halten.

grindbatzn · 18.03.2016 00:22:51

Ich wollte da jetzt niemanden zu nahe treten, sorry.

In der gelebten Praxis ist es einfach so:
Natürlich fängt heute niemand eine neue Site mit PHP 5.2 an.

Aber: jede Installation wird mal alt. Die Hoster können oft nicht so, wie sie wollen, weil da ein Haufen Kunden ihr altes Zeugs drauf haben.
Also kommen eben neue Kunden auf einen neuen Server und die alten lässt man, wo sie sind.

Ich - der weit über 100 Sites betreue - bin dann in der Zwickmühle. Für einen kleinen Sicherheitspatch (der wohl nur ein paar geänderte Zeilen umfasst) müsse ich die ganze Site umreißen. Zahlt keiner, aber ich habe Ärger.

Klar weiß ich, dass ein alter 2.8er nicht gerade ein Sicherheitswunder ist. Aber: Wenn die Site gehackt wird, naja, dann macht man eben dann einen Relaunch. Mit Serverwechsel und überhaupt Flutschen und Krachen. Die Datenbank ist meist noch da und rest ist eh zum wegschmeißen.

Bis dahin solle das Leben nicht unnötig kompliziert sein ;-)

norhei · 18.03.2016 00:32:00

Ich - der weit über 100 Sites betreue - bin dann in der Zwickmühle. Für einen kleinen Sicherheitspatch (der wohl nur ein paar geänderte Zeilen umfasst) müsse ich die ganze Site umreißen. Zahlt keiner, aber ich habe Ärger.

Genau so hatte ich das hatte ich vermutet. smile

grindbatzn · 23.03.2016 12:22:30

Diesen Fehler sehe ich jetzt häufig, seit ich *sorglos* den Patch auf einer 5.2er Version eingespielt habe. Hat teils fatale Auswirkungen.
Call to undefined method database::escapeString()

better-work · 24.03.2016 11:34:25

webbird schrieb:

Wer sich wirklich mal mit Best Practice auseinander setzen möchte, dem sei diese Seite ans Herz gelegt:
http://www.phptherightway.com/
Allerdings wird da jede Menge "neumodisches Zeug" behandelt.

Und hier direkt in German:
http://rwetzlmayr.github.io/php-the-right-way/

WBCE CMS Forum

#1 16.03.2016 14:25:21

Ärgerlich: Entwickler-Gewohnheiten

#2 16.03.2016 14:37:24

Re: Ärgerlich: Entwickler-Gewohnheiten

#3 16.03.2016 14:44:18

Re: Ärgerlich: Entwickler-Gewohnheiten

#4 16.03.2016 15:09:59

Re: Ärgerlich: Entwickler-Gewohnheiten

#5 16.03.2016 16:18:45

Re: Ärgerlich: Entwickler-Gewohnheiten

#6 16.03.2016 19:35:04

Re: Ärgerlich: Entwickler-Gewohnheiten

#7 16.03.2016 20:20:43

Re: Ärgerlich: Entwickler-Gewohnheiten

#8 16.03.2016 20:22:21

Re: Ärgerlich: Entwickler-Gewohnheiten

#9 16.03.2016 21:09:33

Re: Ärgerlich: Entwickler-Gewohnheiten

#10 16.03.2016 22:13:23

Re: Ärgerlich: Entwickler-Gewohnheiten

#11 17.03.2016 00:47:24

Re: Ärgerlich: Entwickler-Gewohnheiten

#12 17.03.2016 07:39:52

Re: Ärgerlich: Entwickler-Gewohnheiten

#13 17.03.2016 12:26:39

Re: Ärgerlich: Entwickler-Gewohnheiten

#14 17.03.2016 12:33:26

Re: Ärgerlich: Entwickler-Gewohnheiten

#15 17.03.2016 18:01:39

Re: Ärgerlich: Entwickler-Gewohnheiten

#16 17.03.2016 20:32:49

Re: Ärgerlich: Entwickler-Gewohnheiten

#17 17.03.2016 23:34:27

Re: Ärgerlich: Entwickler-Gewohnheiten

#18 18.03.2016 00:22:51

Re: Ärgerlich: Entwickler-Gewohnheiten

#19 18.03.2016 00:32:00

Re: Ärgerlich: Entwickler-Gewohnheiten

#20 23.03.2016 12:22:30

Re: Ärgerlich: Entwickler-Gewohnheiten

#21 24.03.2016 11:34:25

Re: Ärgerlich: Entwickler-Gewohnheiten

Fußzeile des Forums