Von php ist einfach crap am Fr, 1. August 2014 um 11:11 #
durch seine Stümperhaftigkeit.
D.h. das Ganze wurde jahrelang einfach so runterprogrammiert ohne klare Definition?
Vor zwei Tagen hatte ich wieder alten PHP Code anfassen müssen und mich über die konfuse Lib gewundert. Da war wohl auch der Zufall im Spiel als man Namen und Funktionalität gewisser Funktionen ausgewürfelt hat. sort() : sortiert ein array. array_xy sind Funktionen für Arrays. Es gibt aber arsort, das sort aber rückwärts, dann gibts array_multisort aber eben kein erwartetes array_sort. Ist das krank? Nein das ist behindert^3.
Oder echte Konstanten die halbgar umgesetzt sind wo man dann doch wieder auf define zurückgreifen muss. .... Alles wirkt halbfertig und hält beim Entwickeln ständig auf, mit seinen Quirks und Gemurkse, verteilt auf unterschiedliche Versionen und Konfigurationen und dem Stand der Sterne.
Wer diese Sprache gut findet hat noch nie was anderes gesehen oder entwickelt nur Trivialkram und merkt gar nicht auf welchem Müllevel er sich bewegt (Dunning-Kruger).
Was soll da überraschen? Es gibt nur ein PHP Interpreter den man als Referenz hernimmt. Klar das da Facebook eine Spezifikation braucht, wenn sie diesen nicht nutzen. Alle anderen begnügen sich damit was der Interpreter macht.
Es ist ja richtig, dass PHP weit davon entfernt ist, perfekt zu sein und dass es tatsächlich auch höchst merkwürdige Macken hat, die ziemlich amateurhaft wirken.
Aber dennoch wird eben "Trivialkram" wie Mediawiki und WordPress damit entwickelt.
Man kann PHP durchaus produktiv benutzen, obwohl man weiß, dass es Macken hat. Und der Umstand, dass es bis heute kein einziges weit verbreitetes CMS in Python oder Java gibt, weist irgendwie darauf hin, dass es Gründe geben muss, warum diese besser gemachten Sprachen eben doch nicht an PHP vorbeiziehen können.
Weil die 0815 Hoster bis vor Kurzem (teilweise noch heute) keine alternativen neben einfachen CGI und PHP anbieten. Damit bleibt einem nur PHP wenn man die entwickelte Software nicht nur auf dem heimischen Server verwenden möchte.
Viele Hoster haben allerdings früher lange Jahre auch PHP als CGI laufen lassen (um die Prozesse mit Userrechten auszuführen. ), womit dies kein so großer Unterschied war. Später folgre Fast-CGI, dann andere Lösungen. Am Anfang hatten also durchaus viele Lösungen eine Chance. Aber PHP ist eben dennoch einfacher, man musste sich um so wenig Kümmern. Eine HTML Datei mit PHP anreichern, hochladen, fertig. Es gab wenig Lib-Mischmasch, alles wichtig war dabei, und zudem leicht lokal eingesetzt.
Sicher? Bei nahezu allen Hostern mit denen ich in den letzten Jahren zu tun hatte funktionierten PHP Dateien an beliebiger Stelle unter der DocRoot. Alternativen wie Perl müssen dagegen immer explizit im cgi-bin liegen. Das PHP nur aus cgi-bin funktioniert habe ich wirklich noch nie erlebt.
Ich kann natürlich nicht für alle Hoster sprechen, aber um 2000 herum, als PHP wirklich fahrt aufgenommen hat, war CGI-PHP weit verbreitet. Anbieter wie 1und1 haben noch mind. bis 2010, danach war es mir egal, Fast-CGI Lösungen eingesetzt.
Dies bedeutet ja nicht, das die Dateien deswegen in einem cgi-Ordner liegen müssen Das war für manche Sprachen zwar üblich, aber eigentlich nicht notwendig. Bei PHP ist mir dies nie begegnet, dennoch konnte man erkennen, das es CGI war (ließ sich ja aus den PHP Info Vars herauslesen, bei 1und1 mit SSH Zugang sogar sehen).
Dies bedeutet ja nicht, das die Dateien deswegen in einem cgi-Ordner liegen müssen
Doch, genau das ist der Unterschied. Vor 20 Jahren, als ich mit dem Kram angefangen habe, da gab es nur CGI und alle Skripte mussten in cgi-bin liegen. Irgendwann kam PHP und das funktionierte mit einmal überall. Man musste seine Seite nicht mehr über mehrere Ordner verteilen, nur weil man ein paar aktive Inhalte haben wollte. Das das eine Konfigrationssache des Webservers bzw. Hosters ist, darüber brauchen wir nicht reden. Das ist mir als Webentwickler oder Homepagebetreiber auch egal. Neben dieser Bevorzugung hatte PHP keine Vorteile. In allen Benchmarks lag PHP deutlich hinter Perl und später Python zurück. Gegen CPAN kam PEAR und PECL nicht an. Und als ausgewiesene Web-Sprache hatte PHP bis vor kurzem nicht mal einen Opcode-Cache an Board, das musste erst von außen ran gebastelt werden.
"Doch, genau das ist der Unterschied. Vor 20 Jahren, als ich mit dem Kram angefangen habe, da gab es nur CGI und alle Skripte mussten in cgi-bin liegen."
Du brichst hier einige Techniken sowie Konfiguration durcheinander (bzw. so verstehe ich deinen Text) CGI ist erst einmal nur eine Art, wie der Webserver mit einem externen Programm kommuniziert, um eine Anfrage beantworten zu können. Aus Sicherheitsgründen haben die meisten Webserver per Default einen cgi-bin Ordner vorgesehen. ABER: Dies war nicht Teil dessen, was CGI ist, sondern nur eine Konvention, die man auch durchgehend ändern konnte.
Zudem geht es in diesem Fall um eine Lösung, bei der ein Interpreter als CGI aufgerufen wird, um einen Script auszuführen. Das ist nicht identisch mit dem Ausführen eines Scriptes, der selbst den Interpreter definiert.
Beispiel: Du hast einen Script mit shebang (#!...), der definiert das der Script als Interpreter Python zu nutzen hat. Du packst diesen Script in den cgi-bin Ordner, und markierst ihn als ausführbar. Daneben legt du eine Binärdatei, die ebenfalls als CGI nutzbar ist.
Beide werden nun vom Webserver entsprechend ausgeführt, einer mit dem verlangten Interpreter, der andere direkt. Jeweils als CGI (also über Pipes und co. als Kommunikation)
PHP aber war als CGI meist anders konfiguriert. Hier wurde dem Webserver mitgeteilt, welcher Interpreter für die Dateiendung .php zuständig ist, sodass dieser mit der PHP Datei als Parameter aufgerufen wurde. Derlei ging auch mit so gut wie jedem anderen Interpreter, war aber seltener genutzt. Technisch möglich war es aber immer. In diesem Fall hatte der hochladende Webmaster gar keine Wahl, welchen Interpreter er wählt. Der Script konnte überall liegen, und es konnte eben auch nur ein Script sein, und nicht z.B. eine Binärdatei. Dies hat den Vorteil, das der Webserver-Betreiber bestimmen kann, was der Interpreter tun kann (durch Änderung dessen Config oder Quellcode). Da der User den Interpreter nicht frei wählen kann, ist dies eine sicherere Lösung, und entsprechend gelten üblicherweise keine Einschränkungen auf den cgi-bin Ordner. Wobei natürlich auch dort Sicherheitsvorkehrungen nötig sind. Insofern war es immer eine eher seltsame Konvention, die alleine nie ausreichend war.
Der cgi-bin Ordner war also eine Konvention, aber kein muss. Auch vorher schon konnte man das sehr wohl anders lösen, und diese wurde auch getan. Andere Lösungen wie fast-cgi (aber nicht nur), bei denen Permanent ein Interpreter lief, gibt es bis heute im Einsatz. Diese verbinden die Vorteile von CGI (eigene Userprozesse getrennt vom Webserver), mit denen einer schnellen Ausführung.
Der Vorteil von PHP war, wenn man es als mod_php nutze, das man keinen Interpreter bei jedem Aufruf starten musste, was beim normalen CGI nötig war, und gut und gerne eine halbe Sekunde Ausführungszeit gekostet haben kann. Aber es gab eben auch ein CGI-PHP, und dennoch waren dei Scripte nicth an cgi-bin gebunden.
Was soll dieses endlose Geschreibsel? Bitte lese doch mal, worauf die geantwortet hast. Mit
"Derlei ging auch mit so gut wie jedem anderen Interpreter, war aber seltener genutzt."
bestätigst Du meine Aussage. Der Rest ist komplett am Thema vorbei, außer Du willst mir unterstellen, dass ich nicht weiß was CGI ist.
btw: Kennst du einen prägnanten, kurzen und für jedermann verständlichen Begriff der den klassischen Weg ein CGI Skript zu starten beschreibt? Wenn ja, bitte her damit.
"Man kann PHP durchaus produktiv benutzen, obwohl man weiß, dass es Macken hat. Und der Umstand, dass es bis heute kein einziges weit verbreitetes CMS in Python oder Java gibt, weist irgendwie darauf hin, dass es Gründe geben muss, warum diese besser gemachten Sprachen eben doch nicht an PHP vorbeiziehen können."
Meiner Meinung nach basiert dies vor allem auf der Tatsache, das man einen PHP-Script einfach als Datei auf einen Server schmeißen kann, und alles klappt sofort. Es ist simpel. Es läuft. Und wenn sich die Leute an etwas gewöhnt haben, bleiben sie dabei, selbst wenn es für ihre steigenden Anforderungen bessere Lösungen gäbe.
Allerdings sehe ich in PHP auch kein extremes Problem. Die Sprache ist nicht sooo schlimm, und die Libs werden sowieso meist über Wrapper benutzt. Ohne Zweifel stören die Probleme bei den Basis-Funktionen wie den genannten Array (sowie u.a. String-)funktionen, aber das lernt man einmal, dann weiß man es.
Heute wird PHP auch einfach oft verwendet, weil es eben alle machen. Das ist kein guter Grund, aber einer, der nicht schwer zu erfassen ist. Dazu kommt deroben genannte einfache Einfache einstieg, und schon ist die Sprache immer noch erfolglos.
Vielleicht sind wir zu doof, aber wir können uns auf diesen Artikel keinen Reim machen.
Aber auf php.net gibt es zu jeder verdammten Funktion, Klasse und allem, was PHP sonst noch hat eine eigene Beschreibungsseite mit Infos, was das Ding kann, was es erwartet, und was es zurück gibt (und natürlich mit Links dazu, was das, was es erwartet und zurück gibt ist)
Es geht nicht um die Dokumentation von Funktionen sondern um die Spezifikation der Sprache PHP. Falls Du Dir darunter nichts vorstellen kannst, den aktuellen Stand der Spezifikation findest Du im GIT Repository von php.net und bei Github.
Andere Sprachen haben das selbstverständlich in ihrer Dokumentation mit integriert, wie z.B. Python: https://docs.python.org/3/reference/index.html
Es geht - wie ja bereits im Artikel und hier mehrfach erwähnt - um die Sprache und nicht um die Bibliotheken. Also z.B. welche Schlüsselwörter gibt es, welche Syntax-Elemente, was für Typen, usw.
Eine Spezifikation beinhaltet eigentlich eher mathematisch genau, welche Semantik sich hinter welchem Teil der Sprache befindet und Details zur Speicherverwaltung und Funktion eines Interpreters. Ist halt eher nur für Implementatoren von PHP-Interpretern wichtig.
Ist aber alles sowieso für die Katz, da Zend sich wohl kaum daran aufhalten wird.
Abgesehen davon scheint die normale Doku ja nicht so gut zu sein, wenn es sowas http://www.phptherightway.com/ hier gibt.
"Abgesehen davon scheint die normale Doku ja nicht so gut zu sein, wenn es sowas http://www.phptherightway.com/ hier gibt."
Das Problem ist weniger die normale Dokumentation, als viel mehr die vielen anderen Seiten im Internet. Es gibt wohl Millionen Seiten im Netz, welche sich mit Lösungen von PHP Problemen beschäftigen, dabei aber fehlerhaften Code oder schlechte Lösungen propagieren.
Die offizielle Doku ist eigentlich ganz gut, die meisten Beispiele zeigen einen einfachen aber relativ guten Stil.
ABER: Auch dort beziehen sich die Beispiele natürlich immer rund um einzelne Funktionen, und können den Zusammenhang in einer komplexeren Anwendung kaum genau erklären. Zudem kann sie nicht auf jede externe Lib verweisen, die man statt einer direkten Funktion nutzen sollte (z.B. Doctrine anstelle der direkten mysql Funktionen). Daher braucht es eben auch mal Seiten, die dies tun. Wobei ich nicht weiß, wie gut die verlinkte Seite dies tut, ich kannte sie bisher nicht, und habe sie nur überflogen. Nicht genug für eine fundierte Meinung
durch seine Stümperhaftigkeit.
D.h. das Ganze wurde jahrelang einfach so runterprogrammiert ohne klare Definition?
Vor zwei Tagen hatte ich wieder alten PHP Code anfassen müssen und mich über die konfuse Lib gewundert. Da war wohl auch der Zufall im Spiel als man Namen und Funktionalität gewisser Funktionen ausgewürfelt hat. sort() : sortiert ein array. array_xy sind Funktionen für Arrays. Es gibt aber arsort, das sort aber rückwärts, dann gibts array_multisort aber eben kein erwartetes array_sort. Ist das krank? Nein das ist behindert^3.
Oder echte Konstanten die halbgar umgesetzt sind wo man dann doch wieder auf define zurückgreifen muss. ....
Alles wirkt halbfertig und hält beim Entwickeln ständig auf, mit seinen Quirks und Gemurkse, verteilt auf unterschiedliche Versionen und Konfigurationen und dem Stand der Sterne.
Wer diese Sprache gut findet hat noch nie was anderes gesehen oder entwickelt nur Trivialkram und merkt gar nicht auf welchem Müllevel er sich bewegt (Dunning-Kruger).
Was soll da überraschen? Es gibt nur ein PHP Interpreter den man als Referenz hernimmt. Klar das da Facebook eine Spezifikation braucht, wenn sie diesen nicht nutzen. Alle anderen begnügen sich damit was der Interpreter macht.
Es ist ja richtig, dass PHP weit davon entfernt ist, perfekt zu sein und dass es tatsächlich auch höchst merkwürdige Macken hat, die ziemlich amateurhaft wirken.
Aber dennoch wird eben "Trivialkram" wie Mediawiki und WordPress damit entwickelt.
Man kann PHP durchaus produktiv benutzen, obwohl man weiß, dass es Macken hat. Und der Umstand, dass es bis heute kein einziges weit verbreitetes CMS in Python oder Java gibt, weist irgendwie darauf hin, dass es Gründe geben muss, warum diese besser gemachten Sprachen eben doch nicht an PHP vorbeiziehen können.
Weil die 0815 Hoster bis vor Kurzem (teilweise noch heute) keine alternativen neben einfachen CGI und PHP anbieten. Damit bleibt einem nur PHP wenn man die entwickelte Software nicht nur auf dem heimischen Server verwenden möchte.
Viele Hoster haben allerdings früher lange Jahre auch PHP als CGI laufen lassen (um die Prozesse mit Userrechten auszuführen. ), womit dies kein so großer Unterschied war. Später folgre Fast-CGI, dann andere Lösungen.
Am Anfang hatten also durchaus viele Lösungen eine Chance. Aber PHP ist eben dennoch einfacher, man musste sich um so wenig Kümmern. Eine HTML Datei mit PHP anreichern, hochladen, fertig.
Es gab wenig Lib-Mischmasch, alles wichtig war dabei, und zudem leicht lokal eingesetzt.
PHP war eben simpel
Sicher? Bei nahezu allen Hostern mit denen ich in den letzten Jahren zu tun hatte funktionierten PHP Dateien an beliebiger Stelle unter der DocRoot. Alternativen wie Perl müssen dagegen immer explizit im cgi-bin liegen. Das PHP nur aus cgi-bin funktioniert habe ich wirklich noch nie erlebt.
Ich kann natürlich nicht für alle Hoster sprechen, aber um 2000 herum, als PHP wirklich fahrt aufgenommen hat, war CGI-PHP weit verbreitet.
Anbieter wie 1und1 haben noch mind. bis 2010, danach war es mir egal, Fast-CGI Lösungen eingesetzt.
Dies bedeutet ja nicht, das die Dateien deswegen in einem cgi-Ordner liegen müssen
Das war für manche Sprachen zwar üblich, aber eigentlich nicht notwendig. Bei PHP ist mir dies nie begegnet, dennoch konnte man erkennen, das es CGI war (ließ sich ja aus den PHP Info Vars herauslesen, bei 1und1 mit SSH Zugang sogar sehen).
Doch, genau das ist der Unterschied. Vor 20 Jahren, als ich mit dem Kram angefangen habe, da gab es nur CGI und alle Skripte mussten in cgi-bin liegen. Irgendwann kam PHP und das funktionierte mit einmal überall. Man musste seine Seite nicht mehr über mehrere Ordner verteilen, nur weil man ein paar aktive Inhalte haben wollte. Das das eine Konfigrationssache des Webservers bzw. Hosters ist, darüber brauchen wir nicht reden. Das ist mir als Webentwickler oder Homepagebetreiber auch egal. Neben dieser Bevorzugung hatte PHP keine Vorteile. In allen Benchmarks lag PHP deutlich hinter Perl und später Python zurück. Gegen CPAN kam PEAR und PECL nicht an. Und als ausgewiesene Web-Sprache hatte PHP bis vor kurzem nicht mal einen Opcode-Cache an Board, das musste erst von außen ran gebastelt werden.
"Doch, genau das ist der Unterschied. Vor 20 Jahren, als ich mit dem Kram angefangen habe, da gab es nur CGI und alle Skripte mussten in cgi-bin liegen."
Du brichst hier einige Techniken sowie Konfiguration durcheinander (bzw. so verstehe ich deinen Text)
CGI ist erst einmal nur eine Art, wie der Webserver mit einem externen Programm kommuniziert, um eine Anfrage beantworten zu können.
Aus Sicherheitsgründen haben die meisten Webserver per Default einen cgi-bin Ordner vorgesehen.
ABER: Dies war nicht Teil dessen, was CGI ist, sondern nur eine Konvention, die man auch durchgehend ändern konnte.
Zudem geht es in diesem Fall um eine Lösung, bei der ein Interpreter als CGI aufgerufen wird, um einen Script auszuführen.
Das ist nicht identisch mit dem Ausführen eines Scriptes, der selbst den Interpreter definiert.
Beispiel:
Du hast einen Script mit shebang (#!...), der definiert das der Script als Interpreter Python zu nutzen hat. Du packst diesen Script in den cgi-bin Ordner, und markierst ihn als ausführbar.
Daneben legt du eine Binärdatei, die ebenfalls als CGI nutzbar ist.
Beide werden nun vom Webserver entsprechend ausgeführt, einer mit dem verlangten Interpreter, der andere direkt. Jeweils als CGI (also über Pipes und co. als Kommunikation)
PHP aber war als CGI meist anders konfiguriert. Hier wurde dem Webserver mitgeteilt, welcher Interpreter für die Dateiendung .php zuständig ist, sodass dieser mit der PHP Datei als Parameter aufgerufen wurde. Derlei ging auch mit so gut wie jedem anderen Interpreter, war aber seltener genutzt. Technisch möglich war es aber immer.
In diesem Fall hatte der hochladende Webmaster gar keine Wahl, welchen Interpreter er wählt. Der Script konnte überall liegen, und es konnte eben auch nur ein Script sein, und nicht z.B. eine Binärdatei.
Dies hat den Vorteil, das der Webserver-Betreiber bestimmen kann, was der Interpreter tun kann (durch Änderung dessen Config oder Quellcode).
Da der User den Interpreter nicht frei wählen kann, ist dies eine sicherere Lösung, und entsprechend gelten üblicherweise keine Einschränkungen auf den cgi-bin Ordner.
Wobei natürlich auch dort Sicherheitsvorkehrungen nötig sind. Insofern war es immer eine eher seltsame Konvention, die alleine nie ausreichend war.
Der cgi-bin Ordner war also eine Konvention, aber kein muss. Auch vorher schon konnte man das sehr wohl anders lösen, und diese wurde auch getan.
Andere Lösungen wie fast-cgi (aber nicht nur), bei denen Permanent ein Interpreter lief, gibt es bis heute im Einsatz. Diese verbinden die Vorteile von CGI (eigene Userprozesse getrennt vom Webserver), mit denen einer schnellen Ausführung.
Der Vorteil von PHP war, wenn man es als mod_php nutze, das man keinen Interpreter bei jedem Aufruf starten musste, was beim normalen CGI nötig war, und gut und gerne eine halbe Sekunde Ausführungszeit gekostet haben kann.
Aber es gab eben auch ein CGI-PHP, und dennoch waren dei Scripte nicth an cgi-bin gebunden.
Was soll dieses endlose Geschreibsel? Bitte lese doch mal, worauf die geantwortet hast. Mit
"Derlei ging auch mit so gut wie jedem anderen Interpreter, war aber seltener genutzt."
bestätigst Du meine Aussage. Der Rest ist komplett am Thema vorbei, außer Du willst mir unterstellen, dass ich nicht weiß was CGI ist.
btw: Kennst du einen prägnanten, kurzen und für jedermann verständlichen Begriff der den klassischen Weg ein CGI Skript zu starten beschreibt? Wenn ja, bitte her damit.
"Man kann PHP durchaus produktiv benutzen, obwohl man weiß, dass es Macken hat. Und der Umstand, dass es bis heute kein einziges weit verbreitetes CMS in Python oder Java gibt, weist irgendwie darauf hin, dass es Gründe geben muss, warum diese besser gemachten Sprachen eben doch nicht an PHP vorbeiziehen können."
Meiner Meinung nach basiert dies vor allem auf der Tatsache, das man einen PHP-Script einfach als Datei auf einen Server schmeißen kann, und alles klappt sofort.
Es ist simpel. Es läuft. Und wenn sich die Leute an etwas gewöhnt haben, bleiben sie dabei, selbst wenn es für ihre steigenden Anforderungen bessere Lösungen gäbe.
Allerdings sehe ich in PHP auch kein extremes Problem. Die Sprache ist nicht sooo schlimm, und die Libs werden sowieso meist über Wrapper benutzt.
Ohne Zweifel stören die Probleme bei den Basis-Funktionen wie den genannten Array (sowie u.a. String-)funktionen, aber das lernt man einmal, dann weiß man es.
Heute wird PHP auch einfach oft verwendet, weil es eben alle machen. Das ist kein guter Grund, aber einer, der nicht schwer zu erfassen ist. Dazu kommt deroben genannte einfache Einfache einstieg, und schon ist die Sprache immer noch erfolglos.
Stimmt und andere Programmiersprachen händeln das komplett anders. Hast du noch so Weisheiten?
Dein Text ist so beliebig, man könnte ihn praktisch auf alles anwenden. Fantastisch, das nenne ich noch mal eine universelle Kritik
> Ist das krank? Nein das ist behindert^3.
kannst du mal aufhören eine behinderung als beleidigung herzunehmen?
Vielleicht sind wir zu doof, aber wir können uns auf diesen Artikel keinen Reim machen.
Aber auf php.net gibt es zu jeder verdammten Funktion, Klasse und allem, was PHP sonst noch hat eine eigene Beschreibungsseite mit Infos, was das Ding kann, was es erwartet, und was es zurück gibt (und natürlich mit Links dazu, was das, was es erwartet und zurück gibt ist)
Dokumentation != Spezifikation
Was wäre dann zum Beispiel die Spezifikation von … hm … zum Beispiel substr()?
Lies mal String und denk darüber nach wie peinlich es noch für dich werden soll.
Es geht nicht um die Dokumentation von Funktionen sondern um die Spezifikation der Sprache PHP. Falls Du Dir darunter nichts vorstellen kannst, den aktuellen Stand der Spezifikation findest Du im GIT Repository von php.net und bei Github.
https://github.com/php/php-langspec/blob/master/spec/php-spec-draft.md
Andere Sprachen haben das selbstverständlich in ihrer Dokumentation mit integriert, wie z.B. Python: https://docs.python.org/3/reference/index.html
Es geht - wie ja bereits im Artikel und hier mehrfach erwähnt - um die Sprache und nicht um die Bibliotheken. Also z.B. welche Schlüsselwörter gibt es, welche Syntax-Elemente, was für Typen, usw.
Eine Spezifikation beinhaltet eigentlich eher mathematisch genau, welche Semantik sich hinter welchem Teil der Sprache befindet und Details zur Speicherverwaltung und Funktion eines Interpreters.
Ist halt eher nur für Implementatoren von PHP-Interpretern wichtig.
Ist aber alles sowieso für die Katz, da Zend sich wohl kaum daran aufhalten wird.
Abgesehen davon scheint die normale Doku ja nicht so gut zu sein, wenn es sowas http://www.phptherightway.com/ hier gibt.
"Abgesehen davon scheint die normale Doku ja nicht so gut zu sein, wenn es sowas http://www.phptherightway.com/ hier gibt."
Das Problem ist weniger die normale Dokumentation, als viel mehr die vielen anderen Seiten im Internet. Es gibt wohl Millionen Seiten im Netz, welche sich mit Lösungen von PHP Problemen beschäftigen, dabei aber fehlerhaften Code oder schlechte Lösungen propagieren.
Die offizielle Doku ist eigentlich ganz gut, die meisten Beispiele zeigen einen einfachen aber relativ guten Stil.
ABER: Auch dort beziehen sich die Beispiele natürlich immer rund um einzelne Funktionen, und können den Zusammenhang in einer komplexeren Anwendung kaum genau erklären. Zudem kann sie nicht auf jede externe Lib verweisen, die man statt einer direkten Funktion nutzen sollte (z.B. Doctrine anstelle der direkten mysql Funktionen).
Daher braucht es eben auch mal Seiten, die dies tun.
Wobei ich nicht weiß, wie gut die verlinkte Seite dies tut, ich kannte sie bisher nicht, und habe sie nur überflogen. Nicht genug für eine fundierte Meinung