Diskussion:PHP/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:PHP/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:PHP/Archiv#Thema_1

Sourcecode-Beispiele

Bin zwar Autodidakt, würde aber die Differenzierung zwischen einfachem (') und doppeltem (") Anführungszeichen anders erklären, sofern solche Details überhaupt vonnöten sind. Text in einfachen Anführungszeichen wird unverändert ausgegeben. Innerhalb doppelter Anführungszeichen wird der Text dahingehend interpretiert, dass Variablennamen (mit Einschränkungen) durch die Variableninhalte ersetzt werden. Letztere Anführungszeichen sind daher langsamer. 2006-10-29 timetraveller

Die IP 62.46.240.132 war der Auffassung, Teile der Diskussion Richtung /dev/nul zu verschieben. Hier das Recycling:

Der Artikel ist nunmehr überfrachtet von Source-Code-Beispielen. Diese gehören eigentlich nach faq.phpbar.de. Ich bin der Meinung, die Sources sollten hier verschwinden. Bei einem Artikel über DaimlerChrysler finde ich auch keine Beschreibung über dir Funktionsweise des Otto-Motors. --Hinrich ✉ 23:21, 24. Mär 2005 (CET)

Zustimmung, --norro 00:53, 25. Mär 2005 (CET)

Also wenn hier keine weiteren Kommentare kommen, werde ich die Beispiele entfernen und auf ein minimales Hello, World! reduzieren. Hinrich ✉ 10:45, 3. Apr 2005 (CEST)

Ich habe jetzt einmal als einen Kompromiss die vielen Code-Beispiele durch ein Einziges ersetzt. Dieses können wir noch erweitern. So viele Beispiele und insbesondere das über PHP5+OOP ist einfach zu speziell für eine Enzyklopädie. Bitte nicht einfach den vorigen Status wiederherstellen, sondern erst einmal hier diskutieren.

Ich glaube, es wäre besser, wenn wir im Code-Beispiel keine statische Methode main() verwenden würden. Dies könnte den Eindruck erwecken, dass das wie in z. B. Java zwangsläufig so sein muss, obwohl dieses Verfahren in PHP eher selten benutzt wird.

Weiters könnte es OOP-Neulinge verwirren, das man in der Klasse selbst eine Instanz der Klasse erzeugt. Dies hat nämlich meistens keinen Sinn, außer wenn man das Singleton-Design-Pattern implementiert.

Wenn jemand die anderen Code-Beispiele umbedingt irgendwo sehen will, kann er sie ja auch ins PHP-WikiBook posten.

--Aule 17:56, 5. Apr 2005 (CEST)

Ich habe main in init umbenannt zur Vermeidung der Verwechslungsgefahr. Die statische Methode zeigt sinnvollerweise die Möglichkeit auf wie man statische Methoden definiert und aufruft. Wen verwirrt denn die Instanzierung einer Klasse innerhalb der Klasse, das ist doch OO-Grundlage. Abgesehen davon würde ich vom Sinngehalt mal absehen, es gibt mehr als nur den genannten Grund so vorzugehen. Aber jedem seine Meinung. Zeig mal was du dir so vorstellst.--Haeber 19:37, 5. Apr 2005 (CEST)

Imho sollte im Beispiel erheblich mehr darauf abgestellt werden, dass PHP eine Skript-Sprache für HTML-Dokumente ist, bzw. daher kommt. Die vorgestellte Klasse ist schon zu komplex (und fehlerhaft obendrein). Hinrich ✉ 21:45, 5. Apr 2005 (CEST)

Ich füge nun ein bisschen HTML-Code ein --Aule 17:18, 6. Apr 2005 (CEST)

Welchen enzyklopädischen Wert hat hier das Sourcecode-Beispiel?

• Beispiel für OOP? - Gehört nicht in diesen Artikel
• Zeigen das PHP OOP beherrscht? - Dies macht ein Text sehr viel klarer als ein Beispiel
• Zeigen, wie PHP-Code aussieht? - Da genügt ein Hello World-Script

Sonst irgendwelche Gründe, die für ein solches Sourcecode-Beispiel sprechen? Sonst wäre ich dringend dafür, den ganzen Klassen-Quatsch durch ein kurzes knappes Script (siehe oben) zu ersetzen. Gruß, norro 19:14, 6. Apr 2005 (CEST)

Dieser Meinung bin ich auch. Ich habe nur deswegen nicht die ganzen Beispiele durch ein einziges HelloWorld ersetzt, sondern das zusammenfassende Beispiel gepostet, weil ich einen Kompromiss schließen wollte. Ich persönlich bin aber auch der Meinung, das so ein langes Beispiel in einer Enzyklopädie nichts zu suchen hat. --Aule 17:37, 7. Apr 2005 (CEST)

Mein Reden. Hinrich ✉ 23:07, 7. Apr 2005 (CEST)

Dann denke ich, lässt sich noch ein wenig abwarten, ob jmd. hier in der Diskussion ein triftiger Grund für eine ausgeweitete Ausgabe des Source-Code-Beispiels einfällt und sonst wech damit ... Gruß, norro 14:55, 8. Apr 2005 (CEST)

Ich denke, wir haben genug gewartet. Ich wede den Abschnitt mal verdammen. Hinrich ✉ 21:52, 19. Apr 2005 (CEST)

Ups! Sorry! Ich hab jetzt wieder ein Beispiel eingefügt und danach erst diese Diskussion gesehen. Was war das für alter Code? Ein kurzes Beispiel gehört hier auf jeden Fall rein (denke ich) (und kurz hab ich mein Beispie auch ausgefüht - höchstens das Klassen-Beispiel ist ein wenig lang :-( ). Wenn ich den Code aber wieder raus machen soll dann schreibt mir bitte und macht einen FETTEN Vermerk hier rein (so in etwa: Code-Beispiele unerwünscht WEIL ...) dammit die nach mir das auch noch wissen ;-) ! Vielen Dank und Sorry falls ich euch dazwischen gepfuscht habe. Hmilch 19:46, 14. Jan 2006 (CET)

Ich habe das eine Code-Beispiel zur rekursiven Funktion jetzt wieder rausgeschmissen. Schließlich ist das ein Enzyklopädie-Eintrag und kein PHP-Tutorial. Die beiden Beispiele reichen bei weitem, wobei ich fast finde, dass die schon zu viel sind. -- Raphael Haase 22:38, 15. Jan 2006 (CET)

Flache Lernkurve?

Müßte das nicht "steile Lernkurve" heißen? --XTaran | Talk 06:22, 11. Jul 2004 (CEST)

ich glaube schon ;), habs jetzt erstmal geändert --Progman 17:36, 11. Jul 2004 (CEST)

Ich kenne PERL nur oberflächlich, bin aber bisher davon ausgegangen, dass es schwieriger zu erlernen ist als PHP. Davon ausgehend ist die Aussage falsch: eine "extrem steile Lernkurve" bedeutet, dass etwas sehr schwer erlernbar ist und so wie es geschrieben ist muss man annehmen, dass PHP eine extrem steile Lernkurve hat, d.h. sehr schwer zu erlernen ist. Der Satz "PHP wurde mit der Zeit populärer als der vorherige De-facto-Standard Perl, welches mit der extrem steilen Lernkurve von PHP nicht konkurrieren konnte." müsste meiner Meinung nach z.B. wie folgt umgeschrieben werden: "...vorherige De-facto-Standard Perl, welches mit seiner extrem steilen Lernkurve mit PHP nicht konkurrieren konnte."

Stimmt. Dann mach das --Haeber 14:24, 10. Mai 2005 (CEST)

Ich entwickle seit ca. 10 Jahren mit Perl und seit sieben Jahren auch mit PHP. Tatsächlich ist die Lernkurve von PHP nicht weniger steil, und auch nicht steiler als die von Perl. Die meisten Anfängerprobleme mit Perl sind eine Folge seiner verwirrenden Syntax, insbesondere im Bereich der regulären Ausdrücke und der OOP. PHPs Lernkurve ist für Einsteiger anfänglich etwas flacher, jedoch nach kurzer Zeit deutlich steiler als die von Perl. Das liegt daran, daß PHP unglaubliche viele Funktionen im Sprachkern integriert, die zudem inkonsistent benannt und parametriert sind -- wo Perls Sprachkern mit weniger als 300 Funktionen arbeitet, hat eine PHP-Standardinstallation deutlich über 2000. PHP ist beliebt bei Einsteigern, weil sich damit schnell erste Ergebnisse erzielen (und ausführen) lassen -- aber PHP ist dennoch nicht für Anfänger geeignet. Neben der Überladung des globalen Namensaums resultiert das auch aus dem Konzept, PHP-Code in HTML-Code einzubetten. Ich rege daher an, die auf angebliche Einsteigerfreundlichkeit abzielenden Aussagen ersatzlos zu streichen.

Ich denke hier werden verschiedene Sachen durcheinander geworfen. Die Sprache Perl ist nicht schwerer zu erlernen als PHP. OOP benutzen Einsteiger sowieso nicht, RE ist für Einsteiger generell schwierig und mit der Syntax von Perl haben weniger Programmieranfänger als gestandene Programmierer Probleme. Was in PHP jedoch deutlich leichter ist, ist das erstellen vom dynamischen Webseiten, vor allem wenn es um das anreichern von ehemals statischen Seiten um ein paar dynamische Elemente, wie z.B. der Uhrzeit geht. Diese schnellen Erfolge ermutigen einen sehr.

Weblinks auf 5 Links belassen?

also ich hab jetzt trotzdem mal noch einen link zu zend hinzugefügt. Ich finde das ziemlich wichtig da Zend den core mitentwickelt, die besten tools hat(da diese mit dem core kommunizieren) und es dort auch super artikel und snippets gibt

Fristu hat die Weblinks auf eine Handvoll Links reduziert. Das Problem ist jetzt das wieder neue Links hinzukommen, was ja eigentlich nicht der Sinn von dieser Aktion war. Soll man nun die Links wieder löschen damit es wieder 5 Links bleiben oder soll man in den Bereich Weblinks Unterkapitel wie Tutorials und Portale hinzufügen? --Progman 17:44, 11. Jul 2004 (CEST)

Ich bin dafür Unterkapitel einzuführen. Für PHP gibt es so viele nützliche Seiten im Netz, eine Beschränkung auf 5 Links ist da nicht sinnvoll. --Gruß, Jürgen 16:56, 20. Jul 2004 (CEST)

Dann würden aber eine menge Links im Beitrag stehen, denn es gibt zig Portale, Tutorials und Foren. Da würde man den Überblick verlieren. Vielleicht könnte man eine Linksammlung machen, aber das hat dann wieder nix mit Wikipedia an sich zu tun denn eine Linksammlung finde ich auch im Open Directory Project.

Wenn jetzt nur 5 Links drinbleiben sollen, wer entscheidet welche Links da hinkommen und welche nicht? --Progman 11:55, 21. Jul 2004 (CEST)

Heute wurden wieder zwei Links gelöscht und einer hinzugefügt. Ich bin der Meinung der gelöschte Link zu http://tut.php-q.net sollte wieder rein da dieses Tutorial, besonders für Anfänger, viel nützlicher ist als das PHP-Wiki. Was meint ihr? --Gruß, Jürgen 16:56, 20. Jul 2004 (CEST)

Hab deswegen auch die alte Version wieder hinzugefügt. --Progman 11:55, 21. Jul 2004 (CEST)

Ich hab heute wieder einen Link zu einem Tutorial entfernt. Wir können hier doch nicht jedes Tutorial aufnehmen. Gruß, Jürgen 12:53, 30. Jul 2004 (CEST)

Vielleicht sollten wir nur die Links Homepage, FAQ, Tutorial und DMOZ dort stehen lassen. Desweiteren sollte man die Weblinks so umformen, dass dort erklärt wird das man im den DMOZ link weitere Links zu PHP findet und ein Bearbeitungskommentar mit <!-- --> hinzufügt wo steht, dass man keine Links mehr hinzufügen sollte. Mir kommt das vor, dass die Weblinks nix mit dem Artikel mehr zu tun haben sondern die Webmaster einzig und allein darauf aus sind, das sie Werbung für ihre Seiten haben. Dieses Verhalten kann man schon fast beim Artikel Cascading Style Sheets#Weblinks sehen. --Progman 13:19, 30. Jul 2004 (CEST)

Erneut wurde das http://tut.php-q.net-Tutorial gelöscht. Ich habe es wieder hinzugefügt aus folgendem Grunde: Dieses Tutorial wird in dem Ausschnitt der PHP-Szene, den ich wahrnehme als kompetent und sehr hilfreich betrachtet und gerne zum Einstieg empfohlen. Auch wenn es auf der DMOZ-Seite verlinkt ist, so denke ich, dass es hier trotzdem auftauchen sollte, da es einen wichtigen Beitrag zu diesem Thema leistet. - Norro 23:58, 29. Nov 2004 (CET)

Wikipedia ist aber keine Link-Sammlung und kein Tutorial. Links sollten auf das absolut Notwendige beschränkt bleiben. Gerade bei PHP und ähnlich stark frequentierten Themen wird es viele Web-Sites geben, die inhaltlich ohne jede Frage empfehlenswert sind. Dennoch sollten sie hier nichts zu suchen haben. Die FAQ ist dafür besser geeignet. --Hinrich ✉ 00:33, 30. Nov 2004 (CET)

Hm, und wie sieht es mit http://www.selfphp.org aus? Das Tierchen is ja noch im Aufbau, aber ich finde diese SELF-Sachen ganz interessant! C167 17:57, 27. Jan 2005

Bin nicht dafür, siehe Kommentare zu Selfphp hier in der Diskussionsseite. --Progman 21:43, 27. Jan 2005 (CET)

Lehne ich auch ab. SelfPHP ist seit einigen Jahren im Aufbau, so dass man an der Ernsthaftigkeit zweifel kann. --Hinrich ✉ 22:52, 27. Jan 2005 (CET)

Schon mal drüber Nachgedacht einfach (eine) neue Seite(n) einzufügen!? Im Zweifel mit der passenden Kategorie. Die Abgrenzung zwischen Lexikon, Link-Sammlung und Tutorial würde so dem Leser überlassen bleiben und nicht erzwungen. -- g, could 29.1.05

dagegen, denn Wikipedia ist keine Linksammlung und auch keine Art von Tutorial. Siehe Wikipedia:Was_Wikipedia_nicht_ist --Progman 17:32, 30. Jan 2005 (CET)

PHP-Editoren

Mir ist grade aufgefallen, dass es Links auf in PHP geschriebene Portalseiten gibt. Über den Sinn möchte ich hier nicht streiten. Vielleicht sollte man auch eine Liste verfügbarer PHP Editoren bereitstellen, und falls dies zuviel Platz in Anspruch nimmt könnte man ja auf http://www.dynamicwebpages.de/18.editoren.php (wobei diese Seite wohl nicht mehr aktuell ist) verweisen. --Jens 11:56, 16. Aug 2004 (CEST)

Ein Verweis auf z.B. diese oder anderen Seiten mit einer Liste von PHP-Editoren ist besser als selbst die Editoren aufzulisten. Wer weiß wie viele PHP-Editoren es gibt. Oder es wie in Texteditor lösen und auf http://dmoz.org/World/Deutsch/Computer/Software/Editoren/ linken. --Progman 18:27, 16. Aug 2004 (CEST)

Ich finde die Links zu PECL und PEAR sollten etwas hervorgehoben werden udn vielelcith mit einer kurzen beschreibung versehen werden da sie ja Projekte von php sind. WooDWorkeR 15:49, 2. Sep 2004 (CEST)

Ich bin dafür mehr Links zuzulassen. [SelfPHP sollte auf jeden Fall noch dazu]

Lehne ich ab. Die bisherigen Links reichen vollkommen aus. Wer mehr möchte, kann sich faq.php-bar.de bedienen. Dabei handelt es sich auch um ein Wiki. --Hinrich 17:24, 15. Sep 2004 (CEST)

Bin auch dagegn vorallem weil selfphp eine nicht wirklich gute seite ist nur weil etwas self<irgendwas> heist muss es nicht gleich mit dem wirklich gutem SelfHTML mithalten. Ich finde die offizielle Doku ist hier immer noch die beste WooDWorkeR 19:17, 22. Sep 2004 (CEST)

Bin leider neu hier, finde aber dass man sehrwohl in diesem Lexikon die Editoren einfügen sollte, nicht nur dass jemand sich mal fragt was ist eine editor, eine IDE oder eine Entwicklungsumgebung. Auch wenn die Namen der Firmen da stehen (siehe engl. Version) hat der Nutzer den NUTZEN eines Lexikons, zu dem doch dies hier ist. Sämtliche informationen sollen erläutert werden und das Lexikon muss wachsen. Den Grund anzugeben, dass kein Platz dann ist, was macht Brockhaus zum Beispiel???Infos aufgrund Platz zu verbergen zu hindern ist nicht das Ziel dieses beeindruckenden Projekts. Der Aktualität hinzufügen kann nur dieses coole Projekt beitragen, denn bis eine Suchmaschine oder eine andere Seite etwas listet kann man oft lange warten und der Nutzer erhält obsolete Informationen. Also ich bin für die Listung der Editoren, hierzu kann doch jeder sein Wissen und erfahrungen miteinbringen!

Wissen ist Macht! Unwissenheit ist Faulheit!

Name Alexander Comploj

Gegen weiterführende Hinweis auf andere Artikel in Wikipedia, wie IDE oder Editor ist wohl nichts einzuwenden und die Verweise sind auch vielfach vorhanden. Die namentliche Nennung einiger Produkte halte ich aber für falsch. Zum einen könnten Leser diese Information, die immer unvollständig sein würde, als Überfrachtung ansehen, wobei der Informationsnutzen eher gering sein dürfte, zum anderen wird dieses Thema unter faq.php-bar.de aufgegriffen, wo es sicher besser aufgehoben ist.

Externe Links auf Homepages von Produkten sind aber aus meiner Sicht hier in jedem Fall abzulehnen. Da fast jeder Artikel in Wikipedia über Links auf vertiefende Web-Sites enthält, stellt diese Einschränkung auch keine Behinderung, sondern eine wesentliche Hilfe bei der Konzentration auf die Kernelemente dar. --Hinrich ✉ 20:18, 8. Dez 2004 (CET)

Hmm Ja, verstehe, meinte nur dieses lexikon, genial in der Idee, als lebendes wandelndes Informations"Buch" zu "füttern". Glaube dies ist wichtig und bin davon auch überzeugt. Mir liegt es nur am Herzen Informationen weiter zugeben, dieanderen auch zugute kommt. Denn meine Erfahrung hat mir gezeigt, dass man Informationen weiter geben soll, damit auch andere daran teilhaben können. Viel Erfolg und auf dass es wächst!

---

Alexander 21. Dec 2004 (CEST)

Vielleicht sollte man auch erwähnen das man keinen dieser meist überfrachteten und sinnlosen Spezial-PHP-Editoren braucht um PHP-Skripte zu entwickeln, lediglich einen Texteditor seiner Wahl der mit jedem Betriebssystem mitgeliefert wird. Entwicklungszeit spart man mit diesen Dingern nämlich überhaupt nix, da meist ein mehrtägige Einarbeitung in den Editor notwendig ist, und in dieser Zeit ist die komplette Umsetzung eines Projekts möglich. Aber das muss jeder selber wissen wie mans angeht.

Da muss ich dir wiedersprechen, die Einbearbeitungszeit dieser Spezial-Editoren ist geringer als man erwartet, des Weiteren wird durch Code-Vorschläge, Syntax-Hervorhebung, unterstützendes Debugging usw. der Entwicklungsprozess viel effizienter, soll heißen man kann besseren Code in schnellerem Tempo erzeugen. --Haeber 14:06, 4. Aug 2005 (CEST)

Verbreitete PHP-Applikationen

Diese sollten, wenngleich es Wikilinks sind, ebenfalls auf eine kleine Anzahl begrenzt sein. Es scheint mir bald so, dass Subs angelegt werden, nur um dann hier einen Link setzen zu können; irgendwie Werbung... --Hinrich 17:05, 23. Sep 2004 (CEST)

Hmm Ja, verstehe, meinte nur dieses lexikon, genial in der Idee, als lebendes wandelndes Informations"Buch" zu "füttern". Glaube dies ist wichtig und bin davon auch überzeugt. Mir liegt es nur am Herzen Informationen weiter zugeben, dieanderen auch zugute kommt. Denn meine Erfahrung hat mir gezeigt, dass man Informationen weiter geben soll, damit auch andere daran teilhaben können. Viel Erfolg und auf dass es wächst!

---

Alexander 21. Dec 2004 (CEST)

Historische Daten von PHP

Sollte man im Artikel unter Geschichte nicht vielleicht auch die Datumsangaben der Majorversionen anführen:

• PHP 4.0.0: 22. Mai 2000
• PHP 5.0.0: 13. Juli 2004

Daten sind aus:

• http://de.php.net/ChangeLog-4.php#4.0.0
• http://de.php.net/ChangeLog-5.php#5.0.0

Wäre natürlich schön, solch ein Datum auch von PHP 3.0.0 zu haben, allerdings konnte ich da keinen ChangeLog finden, evtl. ist aber noch einer im CVS vorhanden. --Gast 17:24, 4. August 2004 (CEST)

Ja, aber wirklich nur die Majorversionen, mit links auf die Changelogs. Eine Aufzählung für jede Version, die es gab, find ich hingegen nicht so sinnvoll. Bei jeder Majorversion sollte man auch angeben was Hauptsächlich gegeüber der anderen Version geändert hat. --Progman 19:32, 4. Aug 2004 (CEST)

Hier sind noch ein paar Release-Termine:

• PHP 3.0.0: 06. Juni 1998
• PHP 2.0.0 (aka PHP/FI): 12. November 1997

Quelle ist das "PHP-Museum" unter http://museum.php.net/

Impulz 21:32, 11. Aug 2004 (CEST)

Ich habe eben die Daten in die Seite eingepflegt, bin mit der Textgestaltung aber noch nicht zufrieden, wäre schön, wenn dort einmal jemand drüber schauen könnte. --Jens 11:59, 16. Aug 2004 (CEST)

Ich find das so eigentlich gar nicht so schlecht. Kann von mir aus gern so bleiben. Statt "Veröffentlichungsdaten" vllt "Meilensteine"? Impulz 14:04, 16. Aug 2004 (CEST)

Ich hab mal "Veröffentlichungsdaten" in "Meilensteine" geändert und eine Tabelle draus gemacht. Was da noch fehlt sind die großen Neuerungen. --Progman 14:25, 16. Aug 2004 (CEST)

Vielleicht sollte man das Feld mit den Neuerungen wieder weg machen, es kam ja viel mehr dazu, was erwähnenswert wäre. Ausserdem kann man sich wohl auch gut darüber streiten ob "Extensions" wie die neuen SOAP- und XML-Erweiterungen auch zu PHP selbst gehören. Denn gerade diese sind in meinen Augen ein gewichtiger Grund um von 4.x zu 5.0 zu migriren.

Weiterhin denke ich, dass "OOP verbessert" nicht der Tragweite der neuen OOP Features gerecht wird. Vielleicht reicht der Link auf die jeweiligen ChangeLogs ja auch schon. --Jens 17:48, 16. Aug 2004 (CEST)

Akronym?

Wieso soll PHP ein Akronym sein? Ich spreche es jedenfalls Peh-Ha-Peh, nicht als ein Wort Php. Falls mir das keiner erklärt, werde ich das demnächst noch einmal ändern, diesmal mit Verweis nach hier in der Bemerkung. --Tian 16:11, 11. Okt 2004 (CEST)

PHP (recursive acronym for "PHP: Hypertext Preprocessor")...

von http://www.php.net/manual/en/introduction.php

So steht es auch im Artikel, das PHP ein rekursives Akronym ist. Dies impliziert dass es ein (normales) Akronym ist. Die Frage ist nun, wann eine Abkürzung als Akronym gilt, denn diese Definition ist nicht festgelegt. Einige sagen Akronyme sind vorlesbare Abkürzungen, andere sagen wieder dass Akronym Abkürzungen sind, die aus den Anfangsbuchstaben gebildet wurden (siehe Definition im Duden). Ich will hier keine Diskussion starten was ein Akronym oder eine Abkürzung ist, aber solange auf der Homepage von php steht, dass PHP ein rekursives Akronym ist sollte es imo auch im Artikel so stehen und auch als (normales) Akronym gelten. --Progman 22:51, 11. Okt 2004 (CEST)

Angesichts des NPOV-Prinzips halte ich die Beschreibung auf einer PHP-Seite für ein nur schwaches Argument. Aber gegen die Beschreibung als rekursives Akronym habe ich gar nichts. Im dortigen Wikipedia-Eintrag steht allerdings etwas, was deiner naheliegenden Implikation widerspricht: "Der Begriff wird auch für Abkürzungen gebraucht, die eigentlich keine Akronyme sind." Akronym ist in Wikipedia aber so definiert, wie ich es meine, deshalb finde ich den Link dahin unpassend. Und im Duden lese ich, ein Akronym ist ein "aus den Anfangsbuchstaben mehrerer Wörter gebildetes Wort".

Wie wäre es mit einer ganz anderen Formulierung im Geschichtsteil, etwa: "Dabei wurde auch die jetzige Deutung von „PHP“ als rekursives Akronym eingeführt."? --Tian 16:19, 12. Okt 2004 (CEST)

WTF ist eine steile Lernkurve

Sorry, aber mir fehlt absolut die Ahnung, was eine steile oder flache Lernkurve sein soll. Bitte bitte erklären. "php besitzt eine steile lernkurve" ... hä? es wäre schön, den artikel daraufhin zu bearbeiten.

danke, --Abdull 22:09, 15. Jan 2005 (CET)

Gemeint ist hier sicherlich das man PHP schnell erlernen kann auf Grund der Anfangs simplen Syntax sowie der dem Anwendungsgebiet (Internetprogrammierung) angepassten Funktionen. Dadurch kann man schon mit wenigen Befehlen eine dynamische Website erstellen im Vergleich zu Java kann das für eine simple echo-Ausgabe um den Faktor 10 kleineren Quellcode bedeuten. Es ist mir natürlich klar das bei komplexeren Programmen PHP an seine Grenzen stoßen kann. --Haeber 23:58, 15. Jan 2005 (CET)

Hier was zur Lernkurve: Die Lernkurve stellt diesen Zusammenhang zwischen erlerntem Stoff und der dafür benötigten Zeit dar. "Steil" stimmt also schon. :-) Da die Formulierung aber auch bei mir für Innehalten und Verwirrung gesorgt hat, würde ich vorschlagen, die "Lernkurve" ganz zu kicken und vielleicht von einem "extrem einfachen Einstieg" zu sprechen. Was sagt ihr? -Florian

Ich halte die Bezeichnung "steile Lernkurve" eigentlich für gut. Schließlich finde man sie auch in vielen Büchern zu anderen Programmiersprachen. Ich würde vorschlagen, dass man sowas schreibt wie "PHP hat eine steile Lernkurve, d.h. der Einstieg ist sehr einfach.". --Raphael Haase 17:34, 24. Mär 2005 (CET)

Ich find das irreführend und grundfalsch da php eigendlich ein subset von perl ist kann es keine steilere lerkurve haben solang man nur vom syntax ausgeht. der grund warum für viele es einfacher war in PHP statt in perl zu programmieren, war weil sie nur HTML konnten oder weil es bequemer war alles in einer datei zu haben und es sowas wie maypole un co noch nicht gab. es liegt daran das in php (und auch nur solang das programm nicht zu gross wird) sich die logik der html daten struktur unterordnet und in perl sich das html der funktionsstruktur des scriptes unterordnet. html ist eine auszeichnungssprache die eine zustandsmaschiene beschreibt. php erleicherte lediglich den sprung auf imperative/funktionale denkweise weil sie ein anderes embedden erlaubte, was im kleineren masstab auch zweckmässig ist. die bemerkung in jetziger form ist wunschdenken der PHP fans.Lichtkind 22:28, 24. Mär 2005 (CET)

Klammersetzung von echo/print

Die offizielle PHP-Dokumentation besagt

Die echo und print-Anweisungen werden nicht als Funktionen behandelt sondern sind Teil der PHP-Sprache (englisch zu echo: "... Because this is a language construct and not a function ..." [1]).

Bitte macht die schöne einfache PHP-Sprache nicht zu einem zweiten Java - damit ist niemanden geholfen. Erfahrene Cross-Language-Programmierer wissen das es umso komplizierter werden kann unterschiedliche Sprachen zu beherrschen je mehr sie sich ähneln. --Haeber 20:18, 1. Mär 2005 (CET)

is aber trotzdem sauberer.

fragen tut gut 17:28, 2. Mär 2005 (CET)

Du musst wohl immer das letzte Wort haben. der echo-Befehl ist integraler Bestandteil der PHP-Syntax ähnlich den Schleifen, Bedingungen usw. Er wird vornehmlich ohne Klammern verwendet. Unter anderem ist es nur so möglich die here-document-Syntax anzuwenden (<<<END ... END;). Des Weiteren kann man ohne die Klammer auch mehrere Strings per Kommata aneinanderhängen (echo "jop2", "jop2";) was mit der Klammersetzung nur über eine verhunzte Methode möglich ist (echo ("jop2"), ("jop2");), sag mir nicht das das "sauber" ist. Und nun noch ein weiteres Zitat aus der PHP-Dokumentation "echo() is not actually a function (it is a language construct) so you are not required to use parentheses with it. In fact, if you want to pass more than one parameter to echo, you must not enclose the parameters within parentheses." [2]

Da scheiden sich wohl die Geister...Ich hab da so n buch aus der Stadtbibliothek gehavbt in dem ECHO MIT klammern gewesen ist.

Wenn ichs wiederfinde geb ich dir die ISBN

fragen tut gut 11:51, 10. Mär 2005 (CET)

Es ist unwichtig, wenn die offizielle Dokumentation es ohne Klammern macht, machen wir das auch so -- da didi | Diskussion 13:30, 10. Mär 2005 (CET)

Der Klügere gibt nach...;-)

fragen tut gut 15:41, 11. Mär 2005 (CET)

Anmerkung und Fragen

• Der Teil mit der "Lernkurve" ist unklar.

Dann noch mal konkret: PHP konkuriert nicht mit der Lernkurve von Perl. Eine solche Formulierung ist einfach schlecht. Vielleicht kann man sagen, dass PHP eine größere Entwicklergemeinde hatte, oder einfach leichter zu benutzen war. Wenn ich wüste, was hier gemeint ist, hätte ich das selbst korrigiert. --Zahnstein 13:30, 4. Apr 2005 (CEST)

• Die Geschichte mit der Performance kommt zweimal im Text vor. Vielleicht oben knapper formulieren und unten etwas ausführlicher? So sollte da noch rein, dass bei einer dynamischen Sprache ja auch immer dynamischer content dazu kommt und der nicht auf Dauer gecacht werden kann. Entweder unterteilt man dann eine Seite in dynamich und statisch oder der code ist nicht so dynamisch, dass der cash sich dennoch lohnt. (Hoffe das stimmt so)
• Die code-Beispiele finde ich ganz gut. Nur der objektorientierte ist im Verhältnis zu den anderen Textteilen sehr lang. Aus eigener Erfahrung weiß ich aber wie nützlich ein funktionierendes Programm-Beispiel ist.

Mir gefällt der Text wie er jetzt ist. Gruß, --Zahnstein 01:28, 3. Apr 2005 (CEST)

Frage von ClausVB (gestellt am Donnerstag, 3. November 2005 um 10:58 Uhr): Unter C++ gibt es einen Artikel über Templates bzw. Schablonen und Klassentemplates. Der Begriff 'Templates' bzw. 'Template Engines' fehlt hier im deutschen Wikipedia völlig, während er auf den englischen Seiten existiert. Ich habe mich jetzt nicht getraut, hier etwas zu ergänzen, weil es bei englischen Wikipedia ein eigener Begriff ist. Soll ich lieber einen neuen (umfassenden) Artikel schreiben oder hier unter PHP nur eine Überschrift mit 2 bis 4 Sätzen Erläuterung einfügen? In meinen Augen macht es am meisten Sinn den Artikel Template abzuändern bzw. eine neue, kurze Begriffsdefinition dort zu hinterlegen und diesen dann auf einen neuen Artikel zu verweisen. --ClausVB

aus dem Review

Sehr guter Artikel, sollte dann in die Exzellente Artikel-Ecke aufgenommen werden... "Nur wer fragt wird klüger" Benutzer_Diskussion:Fragenmensch 16:37, 12. Mär 2005 (CET)

ein paar Unklarheiten im sprachlichen Ausdruck: "Perl kann mit der steilen Lernkurve von PHP nicht konkurrieren" ? 'Fußzeichen' und "Zollzeichen" sind etwas ungebräuchliche Ausdrücke, ich würde eher einfache und doppelte Anführungszeichen sagen, wie es in der IT-Literatur wohl auch üblich ist. Abschnitt "Datenbankanbindung" geht nur auf MySQL ein, wie siehts mit anderen Datenbanken aus? Vererbung: Ist Mehrfachvererbung möglich? Wie siehts mit Polymorphie aus? Wird der Typ eines Objektes statisch oder dynamisch festgelegt? Welche Entwicklungsumgebungen gibt es für die Sprache? --Kurt seebauer 14:43, 13. Mär 2005 (CET)

Abschnitt 0 ist zu lang und Abschnitt 1 ist zu kurz. Zuviel Code. --Pjacobi 14:51, 13. Mär 2005 (CET)

meine Meinung, besteht aus zu viel Codebeispielen, Geschichte zu kurz gehalten MReinke 12:04, 17. Mär 2005 (CET)

• Guter Artikel, aber wie schon erwähnt bei weitem zu viele Code-Beispiele (Links zu entsprechenden Seiten sind vorhanden, das sollte genügen). Wie Kurt seebauer schon erwähnt hat, wären mehr Infos rund-herum interessant. (Syntaktisch/Semantische Probleme von PHP, Entwicklungsumgebungen (Debugger?), Vor/Nachteile von PHP, evtl. ein Kapitel über Module ..) --Bari 17:34, 17. Mär 2005 (CET)

Zu obigen Fragen: Datenbankanbindungen gibt es für viele Datenbanken, unter anderem PostgreSQL, Microsoft SQL und Oracle, sowie beliebige ODBC-Datenbanken. Mehrfachvererbung gibt es nicht, Klassen können aber 0..n Interfaces implementieren (Ähnlich wie in Java). Was mit statischen und dynamischen Typen gemeint ist weiß ich nicht - vielleicht hilft folgendes: mit $foo = new Classname; wird eine neue Klasse instanziiert, $foo ist hierbei einfach eine Variable. Mit $foo = "test"; wird aus der ehemaligen Instanz von Classname ein String, und mit $foo = new Classname2; wird wieder eine Instanz der Klasse Classname2 daraus. Eine Vordefinierung wie z.b. in C++ (Classname *test; test = new Classname;) ist nicht nötig. --Timohummel

Bei den Datenbankanbindungen wäre unter Umständen auch die Zusammenarbeit zwischen Zend und MySQL AB bzw. Oracle und Sleepycat anzumerken -> Backups sind bei Open-Source Projekten wichtig. Auch kann PHP JDBC nutzen, lange Zeit war der Erhalt eines Thread Pools über diesen Umweg auch der performanteste Weg für z.B. oci8. Bei PHP5 OO könnte ein Exkurs in die Variablenverwaltung der Zend Engine 2 alle Fragen der Typisierung auf einmal klären. Der "Typ eines Objekts" ist in diesem Zusammenhang widersprüchlich, da es als eigentlicher Typ (Ziel des zval) nur "object" ist und auch bleibt, bis der Referenzzähler 0 erreicht. Eine Variable, die zwischenzeitlich auf das Objekt zeigen kann, kann sich vom Typ her aber ändern, das Objekt dahinter (sofern anders gecastet oder konvertiert) nicht. Im Gegensatz zu Java muss ein Objekt aber nicht serializable implementiern, um in einen String serialisiert werden zu können.

Was noch offen war: Polymorphie- nein. Mehrfachvererbung- bei Klassen nicht, aber bei Interfaces. IDEs: eclipse, Zend Studio. Da die meisten gängigen Editoren (einschliesslich vim) PHP Syntax Highlighting und Case Folding implementieren spielt die IDE eine eher untergeordnete Rolle. Dork 02:07, 19. Jul 2006 (CEST)

Cache-Erweiterungen

Irgendwie sind die Cache-Erweiterungen doppellt erwähnt; einmal im Allgemein Teil und einmal bei der Performence... --Saerdnaer 20:07, 10. Jun 2005 (CEST)

IMHO haben beide Nennungen durchaus ihre Berechtigung. Ich würde diese drinlassen. --Qbi 12:22, 4. Aug 2005 (CEST)

APC fehlt, ausserdem sind es IMHO ByteCode- und keine OpCode caches!

sie sind zwangsläufig beides. da zur laufzeit zend vm opcodes generiert werden, die dann in ihrer gesamtheit als bytecode bezeichnet werden können. "opcode cache" hat sich eher eingebürgert - ist also imho vorzuziehen. letztens hat es sich auf der mailing list so gelesen, als ob die von rasmus lerdorf vorgeschlagene integration von APC in die PHP6 main distribution nun durch sei. der performance part wird also im herbst so oder so einer überarbeitung bedürfen. Dork 04:52, 10. Apr 2006 (CEST)

ISBN-Links

Hallo Michael,
ich habe mir mal erlaubt, deine Bearbeitung zu revertieren. Mit Bindestrichen finde ich die ISBNs deutlich besser lesbar. Die Striche werden von der MediaWiki-ISBN-Suche so behandelt, als wären sie nicht da, und ihre Anordnung hat durchaus eine Bedeutung. (Der Aufbau einer ISBN ist ja: Sprachgruppe-Verlagsnummer-Buchnummer-Prüfziffer.)
Viele Grüße, Langec ☎ 23:56, 28. Sep 2005 (CEST)

Für Wikipress u.ä. mussten überall die Bindestreiche entfernt werden, deswegen mache ich das jetzt überall, wo ich sowas sehe. -- da didi | Diskussion 00:01, 29. Sep 2005 (CEST)

Äh, wie bitte???? Warum denn? Und überhaupt, gibt's irgendwo eine grundsätzliche Diskussion bzw. ein Meinungsbild darüber? Sonst wäre ich sehr dafür, so was zu beginnen, denn ich finde hier die Lesbarkeit schon wichtig. Und für WikiPress könnte man mit einem kurzen Skript die Bindestriche automatisch entfernen. (Soll ich eines schreiben?) Gruß, Langec ☎ 00:30, 29. Sep 2005 (CEST)

dynamisch?

PHP … ist eine Skriptsprache …, die hauptsächlich zur Erstellung dynamischer Webseiten … verwendet wird. Diese Behauptung liest man sehr oft, aber sie ist falsch. Durch Php wird eine Seite nicht dynamisch. Dynamisch ist eine Seite, wenn sich etwas bewegt. Dafür ist dHtml (dynamisches Html) gedacht und geeignet. Durch Php kann eine Seite interaktiv werden, aber nicht dynamisch. Eine Php-Seite ist ebenso statisch wie eine Htmlseite und sie kann wie eine Htmlseite durch den Einsatz von dHtml dynamisch sein. Dynamik kann nur im Client erzeugt stattfinden, sonst wäre sie nicht sichtbar. Imho sollte man aber auch nicht schreiben, dass Php zur Erzeugung interaktiver Seiten benutzt wird (schon gar nicht "hauptsächlich"). Man kann sowas machen, muss es aber nicht. Mit Php erzeugt man Webseiten. (←Punkt). Sie können dynamisch oder statisch, interaktiv oder passiv sein. Eine Seite bekommt durch den Einsatz von Php keine dieser Eigenschaften. Allerdings gilt die Umkehr der Aussage für die Eigenschaft "interaktiv". Um eine interaktive Seite zu erzeugen braucht man eine Sprache die auf dem Server interpretiert wird, wie Php. Für die Eigenschaft "dynamisch" gilt dagegen nur, dass Php kein Hindernis bei der Erzeugung dynamischer Seiten ist.--friedels-home.com 22:16, 30. Apr 2006 (CEST)

Und unter welchen Begriff fallen dann simple Dinge wie Server-Zeitanzeige oder Besuchercounter, ist das etwas interaktives, dynamisches, statisches oder passives? --Haeber 18:39, 30. Apr 2006 (CEST)

Ein Besuchercounter ist in der Regel statisch. Wenn eine Seite angezeigt wird, zeigt sie immer den selben Zählerstannd an, solange sie angezeigt wir. Auch wenn in der Zwischenzeit viele andere User die Seite besuchen. Außerdem ist diese Anzeige interaktiv, denn sie interagiert. Sie reagiert auf andere Besucher. Natürlich könnte man die Anzeige auch dynamisch verändern. Dann würde sich der angezeigte Zählerstand ändern wahrend die Seite angezeigt wird (ohne dass dazu die Seite neu geladen wird), wenn weitere Besucher die Seite öffnen. Das ist zwar möglich, aber recht aufwändig. Es belastet den Server und den PC des Betrachters, denn der Browser de Betrachters muss den Zählerstand immer wieder abfragen. Es gibt zwar Anwendungen wo sowas gemacht wird, aber bei einem Besuchercounter ist so ein Aufwand nicht üblich. Aber so ein Counter wäre interaktiv und dynamisch. Entsprechendes gilt für die Zeitanzeige. Eine statische Zeitanzeige verändert sich nicht während die Seite angezeigt wird. Eine dynamische Zeitanzeige, die sich jede Sekunde (oder Minute) verändert während die Seite angezeigt wird, lässt sich mit Php ohne dHtml nicht realisieren. Sie lässt sich ohne dHtml gar nicht realisieren, wohl aber ohne Php. Die Frage ist eigentlich schon beantwortet, wenn man untersucht was die Begriffe "interaktiv" und "dynamisch" übersetzt heißen.--friedels-home.com 22:16, 30. Apr 2006 (CEST)

Meinst du nicht, dass du den Begriff Dynamisch ein wenig zu wichtig nimmst. In der Webentwicklung hat es sich mittlerweile eingebürgert, dass man solche serverseitigen Programmiersprachen als dynamisch oder aktiv bezeichnet. Die Sprache wandelt sich mit der Zeit und ebenso die Begriffsdeutung. In den Artikeln zu JSP, Perl oder ASP.NET wird auch von dynamisch gesprochen, ohne eine in diesem Zusammenhang explizite Nennung von Javascript bzw. DHTML. Der Begriff Aktiv ist in diesem Zusammenhang sogar in den Namen der Sprache ASP (Active Server Pages) eingeflossen. Ich will ja nichts gegen selbsternannte Sprachhüter sagen, aber die Sprache lebt nun einmal. --Haeber 21:32, 30. Apr 2006 (CEST)

Wichtig oder nicht. Jedenfalls ist es falsch. Wenn viele Leute etwas falsches sagen wird es dadurch nicht richtig. Ich denke, dass die Wikipedia nicht wiedergeben sollte was viele Leute sagen, sondern was richtig ist. ASP ist, wie Php, sehr gut geeignet um (inter-)aktive Seiten zu erzeugen. Und ASP ist, wie Php, nicht in der Lage Dynamik zu erzeugen. Ich habe mir übrigens erlaubt das Wort "dynamisch" aus dem Link zu nehmen. Der Link führt zum Begriff "Webseite" und nicht zu "dynamischen Webseiten". Wie gesagt sollte man das Wort "dynamischer" imho durch das Wort "von" ersetzen.--friedels-home.com 22:11, 30. Apr 2006 (CEST)

Du scheinst das Prinzip der lebenden Sprache noch nicht verinnerlicht zu haben. Wenn es viele sagen ist es automatisch richtig, insbesondere da es sich um eine Art Fach-Slang handelt. „Im Gegensatz dazu steht z. B. deine von Dir vorgebrachte Schreibweise von PHP und DHTML. Da du der einzigste bist der dies so ungewöhnlich schreibt, geht es nicht in die Sprache als korrekte Schreibweise ein und verdeutlicht, dass du es nur auf das Wörtchen dynamisch anlegst statt Dir zuerst selbst an die Nase zu fassen.“ --Haeber 22:35, 30. Apr 2006 (CEST)

Mir scheint, du verwechselst clientseitige (Javascript/DHTML) mit serverseitiger (PHP, ASP, Perl usw.) Dynamik. PHP ist definitiv dynamisch, Seiten werden nicht statisch sondern onthefly, also dynamisch, erzeugt. --MarkGGN D 22:59, 30. Apr 2006 (CEST)

Bei Google nach PHP suchen

Hallo, weiß jemand wie ich bei google was zu einem speziellen PHP-Problem z.B. "Webcam Einbindung" finde? Da die Hälfte der Internetseiten auf .php endet kommt da immer viel zu viel Murks. Gibt es da einen Trick? Kolossos 21:09, 3. Jan. 2007 (CET)

Kommt auf den Suchbegriff an, und wie du deine Webcam "einbinden" möchtest. Notfalls in einem PHP-Forum fragen. Denk dran, Google beantwortet nicht deine Fragen, sondern liefert nur Webseiten, die deinen Suchbegriffen möglichst nahe kommen. Grüße, --Timohummel 03:17, 4. Jan. 2007 (CET)

Dazu müßte man erstmal das richtige PHP-Forum finden. Man müßte Google doch nur sagen können, dass er die Dateiendung nicht berücksichtigen soll. Ich dachte an so was wie http://www.google.de/linux ,welches nur relevate Seiten berücksichtigt, aber so was scheint es für PHP nicht zu geben. Kolossos 10:45, 4. Jan. 2007 (CET)

kleines Google-Tutorial :-) Suchparameter "-filetype:php" sollte "Suche nach Ergebnissen, deren Dateityp nicht PHP ist" bedeuten. Ob das stabil funktioniert, kann ich aber nicht sagen, da PHP kein offiziell von Google unterstützter Dateityp ist, viel Glück! netelk

Danke erstmal. Auch wenn deine Lösung natürlich auch die *.PHP-Seiten weg nimmt, bei dennen es um die Anwendung von PHP geht. Kolossos 09:34, 25. Jan. 2007 (CET)

Verbreitete PHP-Applikationen: Portalsoftware

Mambo / Joomla! und PostNuke – PortalSoftware
Täusche ich mich, oder sind das nicht auch Content Management Systeme? --Alti 14:13, 28. Apr. 2007 (CEST)

Es wird zwar Content gemanaged im weitesten Sinn. Ein CMS im definierten Sinn ist aber was anderes. Wobei ich joomla als Grenzfall definieren würde. Lassen wirs lieber mal als Portallösung --Dachris^blubber 14:37, 28. Apr. 2007 (CEST)

Na gut, Einverstanden --Alti 17:15, 28. Apr. 2007 (CEST)

Unverhältnismäßig lange Mängel-Liste

Die Aufzählung über die Mängel von PHP ist etwa so lang, wie der gesamte restliche Artikel über PHP. Dadurch entsteht der Eindruck, PHP wäre insgesamt minderwertig. Sofern das nicht der Fall ist, sollte der Schwerpunkt des Artikels auch quantitativ etwas mehr in Richtung wohlwollender Darstellung der Sprache gehen! Wick

IMO ist PHP wirklich so schlecht. Vor allem in puncto Sicherheit. Das ist übrigens mein Lieblingsfehler: http://www.heise.de/security/news/meldung/90697 --Andreas86 21:16, 20. Sep. 2007 (CEST)

<POV> PHP hat Vor- und Nachteile, vielleicht mehr Nachteile als andere Sprachen. PHP ist aber auch am besten für kurzlebige Webanwendungen in einer kurzlebigen Zeit geeignet. Selbst größere Projekte können realisiert werden, vielleicht sogar in jüngster Zeit besser als mit anderen Sprachen, wenn man statt nach PHP-Programmierern, nach C- oder Java-Entwicklern sucht, selbst wenn die noch nie was in PHP programmiert haben. :</POV> Alauda 22:00, 20. Sep. 2007 (CEST)

Es gibt aber auch Leute wie mich, die PHP für die beste Programmiersprache der Welt halten. Schließlich bekommt man schnell und ohne Informatikstudium was auf einem Server hin, somit hat man im Vergleich zu klassischen Programmen viel weniger Arbeit bei der Verteilung und Installation der Software. Es kommt wohl immer auf den Anwendungsfall an, die aufgeführten Mängel haben mich bis jetzt jedensfalls nie sonderlich gestört. --Kolossos 17:57, 21. Sep. 2007 (CEST)

Alauda, sorry, dein Argument kann ich nicht so ganz nachvollziehen. Andere Programmiersprachen haben auch Fehler in ihren Libraries, und nicht selten gab es Patches, die fehlerhaft waren. Version 5.2.4 ist mittlerweile auch erhältlich, der diese Lücke schliesst. So what?

Die Mängelliste sollte wirklich dringend überarbeitet werden. Hier ein paar Dinge in Stichpunktform, um es dem Änderer etwas einfacher zu machen:

- So funktioniert der Zugriff auf eine Datenbank mittels der MySQL-Funktionen anders als über ODBC,

Ist in anderen Programmiersprachen teilweise auch nicht anders, gerade wenn es um Libraries der Datenbankhersteller geht. C ist das wohl krasseste Beispiel, dort ist die Implementation pro Datenbank auch *immer* anders.

- noch deutlicher wird dies beispielsweise bei Inkonsistenzen der Funktionen zur String-Verarbeitung

Was wird dort noch deutlicher? Die Parameterreihenfolge ist, mit Verlaub, doch keine eine Inkonsistenz, sondern eine Vorgabe. Auch in der glibc finden sich ähnliche Dinge. Im Gegensatz zu PHP werden diese aber in der glibc NIE geändert werden, da man sonst eine Menge Quellcode umschreiben müsste.

- Viele Funktionen existieren unter mehreren Namen und zusammenhängende Funktionen wurden oft sehr unterschiedlich benannt.

Das lasse ich mal als Information so stehen, ist aber IMHO auch kein Nachteil. PHP ist gewachsen, und bietet dafür auch eine Menge Funktionen von Haus aus.

- Zwar unterstützt PHP bereits seit Version 3 grundlegend objektorientiertes Programmieren (in den Versionen 4 und 5 verbessert und erweitert), aber die gesamte Standardbibliothek von PHP 4 und der Großteil derer von PHP 5 sind noch prozedural angelegt.

Das ist teilweise korrekt, aber daß hier noch auf Version 3 eingegangen wird, finde ich etwas seltsam. Das wäre so, als ob jemand die Aussage machen würde, daß ein Fernsehhersteller früher mal Schwarz-Weiß-Fernseher hergestellt hat. Eine Wertung darf in dieser Art und Weise nicht gemacht werden.

- Auch bei objektorientierten Sprachen übliche Features wie Kapselung der Daten (z. B. private Variablen), Destruktoren oder Fehlerbehandlung per Exceptions sind erst in PHP 5 hinzugekommen.

Dieser Absatz gehört meiner Meinung nach in die Vorteile, da eben diese Features jetzt da (und zwar nicht erst seit gestern, sondern seit ca. 3 Jahren(!). Seitdem gibt es nämlich PHP5.)

Und das war nur der erste Absatz. Hier muß ganz dringend etwas getan werden. Ich helfe auch gerne aus, nur für die Umformulierung der kompletten "Mängelliste" fehlt mir im Moment die Zeit. Außerdem würde ich es nicht als "Mängelliste" bezeichnen, da ein "Mangel" etwas ist, was vom Sollzustand abweicht. "Nachteile" würde dem Absatz besser stehen, jedoch muß hier ganz klar abgezeichnet werden, gegenüber "WAS" ein Nachteil entsteht. Und wenn ich recht drüber nachdenke: In diesem Zustand ist diese Liste rein PPOV und sollte komplett entfernt werden. --Timohummel 00:42, 4. Okt. 2007 (CEST)

OOP

Da ich auf meiner Benutzerdisk angesprochen wurde warum ich die Kat: Objektorientierte Sprache rausgenommen habe. (Anbei die Kopie der Anfrage und meine Antwort)

moin! darf ich fragen, welche kriterien von http://www.paulgraham.com/reesoo.html für dich erfüllt sein müssen, damit eine sprache sich OO auf die fahne schreiben kann? -- ∂ 23:17, 30. Sep. 2007 (CEST)

Naja OO heisst prinzipiell das jedes "Objekt" auch ein Objekt sein muss. Das ist sowohl bei PHP als auch bei Javascript nicht gegeben. PHP unterstützt nur Objekte. Es arbeitet aber nicht in Objekten.Die meisten Funktionen arbeiten auch nicht instanziiert. Hier kann man den Vergleich mit Datenbanken sehen. In einer Textdatei kann man Daten speichern, das ist aber noch lange keine Datenbank :-). Wenn man die Katgeorie natürlich ausrichten will nach "Sprachen die auch Objekte unterstützen" wehre ich mich natürlich nicht gegen einen Revert (will also keine Grundsatzfrage draus machen :-)). Mir sind halt nur massenhafte Einträge in die Kat aufgefallen von Sprachen die halt auch gerne Hochsprachen wären :-) --Bitsandbytes 10:31, 1. Okt. 2007 (CEST)

--Bitsandbytes 10:33, 1. Okt. 2007 (CEST)

Also ich will damit nicht sagen das nur noch SmallTalk o.ä. in die Liste soll. Auc hwenn die Kritierien für objektorientierte Sprachen doch etwas lax sind, halte ich PHP nicht für eine objektorientierte Sprache. WeilH einfach der Ansatz der Objektorientierung sehr niedrig bei PP angesetzt wird --Bitsandbytes 10:51, 1. Okt. 2007 (CEST)

Naja, ich weiß nicht so recht. Laut http://www.paulgraham.com/reesoo.html dürfte dann C++ auch keine Objektorientierte Programmiersprache sein, da C++ schon bei Punkt 1 auf die Mütze fällt. Wie Paul Graham aber auch schon selbst feststellt, gibt es keine eindeutige Definition, was genau Objektorientierung ist. Ich selbst reduziere die Objektorientierung auf Punkte 1, 3, 7 und 9. Ich würde auch PHP den OO-Status nicht absprechen, denn ich programmiere nicht prodezural, wenn ich Klassen und Objekte in PHP verwende. Das wäre auch ziemlich schwer zu vermitteln (Q: "Programmieren Sie Objektorientiert? A: Nö. Q: Programmieren Sie Prozedural? A: Nö. Q: Was programmieren Sie denn? A: Maoam / darf ich nicht sagen / Betriebsgeheimnis / etc.). PHP ist wohl mittlerweile wieder in der Liste drin, da bin ich dafür. Der großteil der Programmierer, die PHP verwenden, werden dies auch bejahen. --Timohummel 00:29, 4. Okt. 2007 (CEST)

Ich setze den Status eher da an (ohne jetzt eine Wertung gegenüber php zu machen welches bestimmt auch seine Berechtigung hat) ob eine PS ausschliesslich objektorientiert agiert oder ob ich eine prozedurale Sprache mit der Möglichkeit einer OOP habe. Alleine das schon alle Funktionen welche php bietet als Funktionen agieren spricht für mich gegen eine OOP. Soll heissen schon die Grundkonzeption von php ist nicht OOP.(und es fehlt auch die Möglichkeit). Aber wie gesagt mir ist es ziemlich unwichtig ob php nun in der Kategorie drin ist oder nicht. Ich habe die Einfügung ja auch nur die unbegründete Einfügung revertiert. --Bitsandbytes 00:44, 4. Okt. 2007 (CEST)

Interpretiert oder kompiliert

Ich lese überall auf der Seite und auch hier im Archiv, dass PHP interpretiert wird. Wenn man es genau betrachtet, wird doch aber ein PHP-Script beim Aufruf erst kompiliert und dann ausgeführt. Interpretieren bedeutet für mich, dass der Computer das Script à la BASIC als Textdatei öffnet, Zeile für Zeile durch geht und ausführt. Aber eben nicht, dass er es vorher kompiliert.

Misel 16:51, 8. Feb. 2007 (CET)

Einleitung

Der einleitende Satz ist verwirrend, da PHP eine Skriptsprache darstellt. Außerdem ist die Gleichstellung von C und Perl mittels "bzw." nicht korrekt. Ich bin mir zwar nicht sicher, aber IMHO sind auch Java-Anleihen vorhanden...

ACK. Bei Siehe auch vermisse ich irgendwie Perl, da beides Skriptsprachen sind und als CGI eingesetzt werden. --Dkoelle 14:02, 18. Sep 2004 (CEST)

Vorschlag: PHP (Rekursives Akronym für "PHP: Hypertext Preprocessor") ist eine Skriptsprache, die hauptsächlich zur Erstellung dynamischer Webseiten verwendet wird und sich in ihrer Syntax an C, Java und Perl anlehnt.

Bedenke: Sollte nicht ebenfalls erwähnt werden, dass PHP hauptsächlich auch für das Extrahieren von Daten von Datenbanken genutzt wird.

und vor allem auch zur Formularverarbeitung

PHP5

Man könnte noch eine kurze Klasse als Source-Code-Beispiel hinzufügen.

Find ich auch.

Mir tät da schon eine vorschweben...

fragen tut gut 14:49, 27. Feb 2005 (CET)

Objektorientierter Ansatz

Ich habe mal ein Code-Beispiel hinzugefügt. Es ist lauffähig und soll folgende Möglichkeiten kurz zeigen:

• OOP
• Klassen
• Abstrakte Klassen
• Interfaces
• Exceptioption Handling
• AutoLoad von Klassen
• Magic __get Funktion
• Konstruktor/Destruktor
• Statischer Aufruf von Klassenmethoden

Jetzt müsste man das Ganze nur noch erklären und evtl. direkt im Code mit Kommentaren versehen.

Gerade wer mit PEAR arbeitet wird sofort merken, dass die oben erwähnten Möglichkeiten dringen in PHP einfliessen müssen. PHP5 zielt genau auf diese Philosophie und nähert sich somit Sprachen wie Java oder C# an. Wem diese Konstrukte jedoch zu kompliziert sind oder nicht objektorientiert arbeiten will, kann weiterhin mit dem "schönen und einfachen PHP" programmieren. --pascal hurni 17:20, 1. Mär 2005 (CET)

hm, bei mir läuft es irgentwie nicht so ganz muss man noch etwas besonderes berücksichtigen? Diego! 23:07, 11. Mär 2005 (CET)

Essenziell ist natürlich ein PHP5 Interpreter. Unter PHP4 läuft natürlich gar nichts. Das Beispiel erzeugt folgende Ausgabe:

Katze mit dem Namen "Pfötli" wird erstellt.
Hund mit dem Namen "Bello" wird erstellt.
Wurm mit dem Namen "Hans" wird erstellt.
Ich heisse Pfötli und bin gerade am Gehen...
Ich heiße Pfötli und bin gerade am Fressen...
Ich heisse Bello und bin gerade am Gehen...
Ich heiße Bello und bin gerade am Fressen...
Ich heisse Hans und bin gerade am Gehen...
Ich heiße Hans und bin gerade am Fressen...
Ich heiße Pfötli und mache Miau
Ich heiße Bello und mache Wauwau
Das Tier Hans kann kein Geräusch von sich geben!
Ich heiße Pfötli und muss jetzt sterben...
Ich heiße Bello und muss jetzt sterben...
Ich heiße Hans und muss jetzt sterben...

--pascal hurni 08:37, 12. Mär 2005 (CET)

Komisch, ich hatte schon php5 drauf weiß aber nicht mehr genau welche Version. Hab mir jetzt nochmal die neuste Version gesaugt und jetzt läufts auch.

Diego! 23:55, 12. Mär 2005 (CET)

Ich wollte nur mal darauf hinweisen das ein Destruktor kein wichtiges Merkmal einer OO-Sprache ist, das sollte im Artikel reflektiert werden (derzeit wird dies als wichtiges merkmal deklariert). Siehe zB. Java oder .NET, in denen Garbage Collection diese Aufgabe übernimmt.

D.A.N.K.E.

Ein herzliches dankeschön an den User, der hier grad das class-Beispiel reingetan hat.... fragen tut gut 17:05, 1. Mär 2005 (CET)

Grafikerzeugung statt GTK im ersten Abschnitt erwähnt

Ich habe das dahingehend geändert, weil "GTK-Anwendung" dem Laien IMHO unverständlich ist, trotz Verlinkung. Im ersten Absatz sollten wir uns auf das Kerngebiet von PHP konzentrieren, also Webseiten. Da finde ich als zusätzliche Bibliothek irgendwas zur Grafikerzeugung (z.B. GD) passender. (GTK wird ja weiter unten im Artikel immer noch genannt.) Gibt's irgendwo einen Artikel zu GD? Dann könnte ich das in einem Nebensatz noch genauer ausführen. --Langec ☎ 19:52, 10. Aug 2005 (CEST)

Performancegewinn von einigen hundert Prozent

Wie muss man sich einen Performancegewinn von über 100% vorstellen?

eine Steigerung der Geschwindigkeit um mehr als das Doppelte? --Kurt seebauer 01:58, 29. Okt 2005 (CEST)

Zend Engine 1, ein "Herz" für PHP?

"Die von Gutmans und Suraski gegründete Firma Zend Technologies Ltd. entwickelte in der Folge die Zend Engine 1, das "Herz" von PHP 4." - warum das Kind nicht beim Namen nennen: die Zend Engine ist, wenn auch eine sehr einfache, Virtual Machine (die auch gegen andere getauscht werden kann, siehe Portierungen auf parrot oder mono). Dork 23:47, 4. Aug 2006 (CEST)

Hardened PHP?

Habe ich es einfach nur überlesen oder gibt es tatsächlich nicht einmal die geringste Erwähnung des Hardened-PHP-Projektes [3]? --Haeber 23:15, 3. Mai 2006 (CEST)

Literaturliste

Die Literaturliste wird immer unüberschaubarer, da ist einzugreifen! --Haeber 02:06, 5. Jul 2006 (CEST)

Ich bin der Meinung die sollte man nach Anfänger, Fortgeschrittene und Profis sortiert werden. -- TruckerB 11:52, 13. März 2007

PHP-Tutorials

Habe hier mal zwei Links angehängt, die den Einstieg für Anfänger erleichtern wollen:

• Design Nation - PHP lernen (Tutorials)
  

Dort sind auch einige Code-Schnipsel zu finden.

• SELFPHP

Dieses Nachschlagewerk ist ähnlich wie SELFHTML aufgebaut. Neben einer Befehlsreferenz enthält dies auch Grundlagen zum Verständnis.

Deutschsprachige PHP Wiki
Hier eine deutschsprachige PHP Wiki. Ist aber noch im Wachsen..:-)Joli Tambour 15:24, 30. Jan. 2008 (CET)

---

Tutorial von #PHP im Quakenet
Meineserachtens das mit Abstand genialste Tutorial... Hat auch mir PHP beigebracht, ist jedoch noch auf Basis von PHP4 verfasst. --Rudi 19:07, 30. Jan. 2008 (CET)

Nicht ganz korrekte Aussage

> Anmerkung: Das „echo“ kann auch durch „print“ ersetzt werden, und es können auch einfache Anführungszeichen (') statt doppelten (") verwendet werden. Da echo als Funktion betrachtet werden kann, kann auch echo ('Hallo Welt') verwendet werden. Die Unterscheidung der einfachen von den doppelten Anführungszeichen entscheidet darüber, ob in der Zeichenkette auftauchende Variablennamen unverändert zu übernehmen oder durch den entsprechenden Variableninhalt zu ersetzen sind. Das stimmt so nicht ganz. Echo ist ein Statement, keine Funktion. PHP erlaubt es aber wie jede andere Sprache Klammern zu verwenden um Ausdrücke zu Gruppieren. Von daher kann ist echo (foo) equivalent zu echo foo. Selbiges gilt auch für das print Statement in Python oder anderen Sprachen. Ich änder das mal auf der Seite.ArminRonacher 15:25, 4. Sep. 2007 (CEST)

Implizite Deklaration von Variablen

In PHP ist es nicht möglich, eine förmliche Deklaration von Variablen zu erzwingen. Variablen werden vielmehr automatisch angelegt, wenn sie erstmals verwendet werden. Das ist zwar bequem, hat aber zur Folge, dass insbesondere Tippfehler bei Variablennamen zu nur schwer auffindbaren Programmfehlern führen können.

Das stimmt so nicht. Das initialisieren von Variablen geschieht über explizites zuweisen eines Wertes, dieser kann auch NULL sein und jeder erfahrende PHP-Programmierer macht das denn wenn das error_level E_NOTICE enthält wirft jedes zugreifen auf nicht existente Variablen einen Fehler. Im übrigen führt das Programmieren ohne E_NOTICE nicht nur eher zu Programmierfehlern sondern auch zu schlechterer Performance da für jeden Zugriff auf eine nicht existierende Variable das Error-Handling anspringt, wenn man einen Userland-implementierten Error-Handler hat verstärkt sich das Problem nochmal.

Doch, das stimmt m. E. schon. Man kann PHP nicht sagen, dass es bei dem Verwenden einer undeklarierten Variable eine Fehlermeldung ausgeben soll, wie z. B. mit Option Explicit in VB6. Zwar wird eine Notice ausgegeben (das Konzept der Notices, die standardmäßig nicht ausgegeben werden, ist ansich schon pervers, aber das ist ein anderes Thema), sobald ich eine undeklarierte Variable auslese - aber was ist, wenn ich mich beim Zuweisen verschreibe?

$myvar = "bla";
echo $mvyar; // führt zu einer "Notice"
$mvyar = "nicht bla"; // führt zu gar nichts, außer einem schwer zu findenden Fehler

--Martin von Wittich 23:35, 13. Sep. 2007 (CEST)

Zeitschriften

Ich wäre sehr dafür, die Links zu den Zeitschriften zu entfernen. Die Zeitschriften selber sind natürlich durchaus relevant, allerdings hat man ohne Abo nicht wirklich viel vom Besuch der Seiten. Daher sehe ich in diesen Links nicht den Mehrwert, den sie nach WP:WEB aber bringen sollten. Was meint ihr? -- Onee 13:34, 5. Nov. 2007 (CET)

Nein, das ist allerdings richtig, der Punkt hat mich auch schon gestört. Ich würde einfach sagen, dass man einfache Wiklinks statt Weblinks draus macht. --Rohieb 会話 +/- 10:13, 21. Dez. 2007 (CET)

Mängel

habe heute viel dort zusammengestrichen und vereinfacht. dennoch würde es helfen, wenn nicht auf die nicht behobenen Mängel in PHP <= 4 eingegangen würde, sondern auf deren verbesserung in PHP 5 + 6 (was logisch bedeuetet, dass diese probleme in früheren versionen vorhanden sind, aber nun nicht mehr. somit spart man sich doppeltes). jede sprache hat ihren höhen und tiefen die mit späteren versionen behoben würden. zudem sollte wirklich beachtet werden, dass PHP 4 mittlerweile zum alteisen gehört. so wie ich das "gelöst" habe, wird sicherlich nicht von allen gern gesehen. doch die unterscheidung ist wichtig, denn, wie gesagt, php befindet sich in einem wandel. deswegen sollte im ersten abschnitt (vor "Behebung von Mängeln") allgemein stehen was in PHP ein wirklicher Mangel ist. was behoben worden ist bzw. was bekannt ist was behoben wird (und als snap bereits verfügbar ist) sollte unter PHP5 bzw. PHP6 stehen.

• PHP 5.3 wird late static binding sowie namespaces unterstützen.
• PHP 6 wird zudem UNICODE voll unterstützen.

--Dutch damager 23:06, 20. Dez. 2007 (CET)

Die Vereinfachung fand ich aber dann doch etwas zu radikal, die Kritikpunkte waren mir nicht genug ausgeführt. Dass PHP 4 zum „Alteisen“ gehört, sehe ich auch so, ich finde aber doch, dass die wesentlichen Kritikpunkte von früheren Versionen (also vor allem unzureichende Objektorientierung und chaotisches Wachstum) in der „Einleitung“ zum Mängel-Abschnitt genannt werden sollten. Ich denke, dein Vorschlag über die Aufteilung in Abschnitte PHP 5 und PHP 6 wäre machbar, dort kann man ja dann erwähnen, dass PHP 5 schon verbesserte Objektorienrierung hat. Gruß, Rohieb 会話 +/- 10:12, 21. Dez. 2007 (CET)

unterlassen werden könnte zum einen die benutzung von eingeklammertem, das stört den lesefluss. zum anderen ist es nicht wirklich hilfreich beispiele (wie andere sprachen) zu nennen, wenn ein (internes) verlinken zum weiterlesen möglich ist (vgl. Bytecode-Cache) --Dutch damager 17:40, 22. Dez. 2007 (CET)

Also ich finde die Arbeit schonmal sehr gut, das, was da vorher stand, war ja wirklich extremst-PPOV und nicht wirklich neutral. Jetzt ist das ganze sachlich und fachlich sehr gut (man muß ja auch mal loben :)). Ich werde mal sehen, ob ich noch etwas dazu beitragen kann, aber leider ist meine Zeit derzeit sehr beschränkt :( Grüße, --Timohummel 18:29, 22. Dez. 2007 (CET)

dann muss ich mich auch mal bedanken ;-) danke :-) --Dutch damager 19:42, 22. Dez. 2007 (CET)

"...mit einer an C bzw. C# oder C++ angelehnten Syntax..."

C# gibs soweit ich weiß erst seit 2001, PHP schon seit 1995. Also kann man doch nicht sagen, der PHP-Syntax ist an C# angelehnt... Oder gabs irgendwann eine neue Version die an C# angelehnt ist? Jiu Bua 14:44, 23. Dez. 2007 (CET)

Da C# ja im weitesten Sinne an C/C++ angelehnt ist, kann man es ja syntaktisch mit PHP vergleichen, zumindest die Kontrollstrukturen ähneln sich stark.

Ich weiß, was du damit sagen willst, einerseits stimmts, andererseits auch wieder nicht. Bei Erhöhtem Aufkommen von Gegenstimmen, bitte meinen Kommentar löschen und die Textstelle abändern ;-). Vorheriger nicht signierter Beitrag stammt von XraYSoLo

entfernt, in C# steht:

C# greift Konzepte der Programmiersprachen Java, C++, PHP, SQL, der Microsoft-eigenen Sprache Visual Basic sowie der Programmiersprache Delphi auf.

--Dutch damager 08:21, 26. Dez. 2007 (CET)

Und php ist nun im C#-Artikel rausgeflogen. --Bitsandbytes 11:55, 26. Dez. 2007 (CET)

Source Code beispiele

ich will jetzt wirklich den größeren sinn hinter "Bitte keine langen Source-Code-Beispiele einfügen. Ein Hello-World sollte reichen." wissen. Natürlich soll hier kein tutorial hin, logisch. aber es sollte beachtet werden, dass eine programmiersprache eben daraus besteht. sowas kann ich nicht durch text darstellen aber vor allem kann kein einfaches hallo welt dies darstellen.
gut, gehen wir aber mal weiter: schauen wir in Javascript, Ruby und auch in den Lesenswerten artikeln Perl und Python dann finden wir eine menge (in diesem umfang unnötige und schon tutorial nahe quellcode) beispiele. warum wird hier 2 mal maßgenommen? gut, wer hat das auch entschieden? (falls es wirklich irgendwo entschieden wurde, werde ich gerne bei den genannten artikeln den rotstift ansetzen.) oder muss es, wie eben in diesen artikeln, nicht unter "quellcode beispiele" sondern unter unterüberschriften wie "Prozeduales Programmieren" "Objectorientiertes Programmieren" schreiben? --Dutch damager 08:30, 26. Dez. 2007 (CET)

Ich bin da etwas gespalten. Einerseits hilft es, wie du schon sagtest, die Programmiersprache ein wenig besser zu illustrieren, allerdings finde ich solche Beschreibungen der Kontrollstrukturen (switch, while, if-else…, wie bei JavaScript, Perl) oder ausführliche Beschreibung des Prinzips der Objektorientierung (wie bei Ruby) oder sogar die Auflistung der halben Klassenbibliothek (JavaScript, ich hab das da übrigens gleich mal rausgeschmissen) wirklich unsinnig. Sowas ist im Artikel zur Sprache wirklich unnötig und sollte dann in Pseudocode in dem jeweiligen eigenen Artikel dargestellt werden.

Was ich dagegen spannender finde, sind Codebeispiele, die Besonderheiten der Sprache selber dokumentieren, die sonst in keiner anderen Sprache auftauchen. Bei Perl wäre zum Beispiel das Prinzip der nachgestellten Kontrollstrukturen, oder das Listing zum Obfuscated Perl Contest. Leider fällt mir da grad nix äquivalentes zu PHP ein… --Rohieb 会話 +/- 16:02, 26. Dez. 2007 (CET)

Ich denke Quelltextblöcke machen nur insoweit Sinn als das ein grundlegend syntaktisches Muster gezeigt wird. Ob Hallo Welt dazu geeignet ist sei mal dahingestellt aber viel länger sollte es auch nicht sein. Maximal noch Besonderheiten in der Syntax welche alleinstehend vorhanden sind sollten zusätzlich dargestellt werden... Alles andere kann in ein wikibook o.ä. --Bitsandbytes 11:42, 27. Dez. 2007 (CET)

besonderheit wäre zum beispiel das einbinden von html code zwischen und abhängig von kontrollstrukturen:

<?php
$array=Array(1,2,3,4,5);
foreach($array as $key=>$value):
?>
<p><?php echo $value ?></p>
<?php endforeach; ?>

--Dutch damager 09:40, 30. Dez. 2007 (CET)

Zum Thema E_NOTICE und Programmierer

Gerade wurde mein Edit revertiert. Damit habe ich ein Problem, denn die Argumentation lautet "kann, sollte aber nicht". Seit wann bewegen wir uns in der Wikipedia auf "sollte"-Niveau? Fakt ist, daß E_NOTICE auf Livesystemen aktiv sein kann (und sei es als Fehlerausgabe in ein Logfile, wie ich es z.B. bei meinen Projekten handhabe). Fakt ist auch, daß diese Warnungen nicht nur von Programmierern gelesen werden, sondern unter anderem durch die QA, Serveradministratoren etc. Bitte um Diskussion. Grüße, --Timohummel 21:21, 26. Dez. 2007 (CET)

Ganz einfach es macht keinen Sinn wenn Anwender (und das sind Nutzer in einem Livesystem) irgendwelche Fehlermeldungen des Systems lesen. Erstens hat man so Schwachpunkte welche ausgenutzt werden können und 2.tens gibt man einen Einblick in das System. Was anderes ist natürlich wenn man die Errors in ein Log schreibt welches eben nur von obigen Gruppen ausgelesen wird. Aber das ist ja nicht die Kernaussage des revertierten Satzes gewesen. (siehe "...bei der Skriptausführung hingewiesen..."). Abgesehen davon das eine Software zwar niemals fehlerfrei sein kann, aber dennoch sollten in einem Livesystem die Designschwächen rausgetestet worden sein (und das ist kein sollte-Argument, sondern in jedem Erstsemestereinsteigerbuch SoEng nachzlesen...)...Aber das ist ein anderes Thema --Bitsandbytes 11:36, 27. Dez. 2007 (CET)

Nein, das war eben nicht die Kernaussage. Auf meinen Systemen ist E_NOTICE auf Livesystemen aktiv UND diese Meldungen werden nicht von Endanwendern gelesen, sondern landen im Log...was nun? Weiterhin werden die E_NOTICE-Meldungen bei meinen Projekten nie von den Entwicklern selbst gelesen...was nun? Dein Revert verfälscht übrigens die Wahrheit, die Wikipedia mag zwar best-practice-Advisements bieten, dann müssen solche aber auch gekennzeichnet sein. Sollte das nicht der Fall sein, nehme ich mir in 2 Tagen das Recht heraus, deinen Revert zu revertieren und den damit richtigen Zustand herzustellen. Wenn du Probleme hast, meinen Edit nachzuvollziehen, frage mich einfach. Ich werde es dir gerne noch einmal erläutern. Und denke immer daran, daß wir bei der Wikipedia Fakten und keine Meinungen darstellen. Grüße, --Timohummel 11:53, 27. Dez. 2007 (CET)

In der Aussage stand klar (...zur Skriptausführung...) und das ist wenn ausgeführt wird und impliziert damit den Nutzer. Wenn du das in Richtung Logging wie ich das ja auch in meinem Statement beschrieben habe umwandelst dann ist gut....PS: Kannst du den richtigen Zustand auch mit einer Quelle belegen?. Wir reden momentan nur um den Punkt ob ein Endanwender also Nutzer Fehler lesen darf oder nicht.....Wir reden hier nicht von Leuten die das lesen müssen (also Entwickler, QS-ler usw). Mach doch mal einen Vorschlag wie man das umformulieren kann sodass auch das da steht was du meinst. PS: Best Practice-methoden basieren immer auf Wissen und Messung, daher ist es durchaus Aufgabe aus meiner Sicht einer Enzyklopädie auch das momentane Wissen darzusetllen. Und noch ein PS :-) Du schreibst von deinen Systemen mir ist das schon klar und du beschreibst dich ja auch als Entwickler...Hast du auch neutrale und wissenschaftliche belastbare Quellen für die Aussage? (ich meine wie es die meisten machen?)--Bitsandbytes 11:59, 27. Dez. 2007 (CET)

Es geht mir nicht darum, welches die "richtige" Methode ist. Im Moment steht dort einfach: "Dieser Mangel kann zumindest während der Entwicklung ...". Es geht mir um das "während der Entwicklung", was dem Leser suggertiert, E_NOTICE kann nur während der Entwicklung aktiv sein. Und genau das ist eben falsch. Weiterhin geht es um "so dass der Programmierer", was suggeriert, daß die E_NOTICE-Meldungen nur durch den Programmierer gelesen werden können. Und genau das ist eben auch falsch. Durch meinen Edit habe ich diese beiden Knackpunkte entfernt. Natürlich können wir den Absatz etwas ausweiten, sodaß deine Argumente (die natürlich in einer normalen Softwareentwicklung vollkommen gerechtfertigt sind) einbringen können, aber im Moment fehlt mir dazu die "schöpferische" Kraft. Grüße, --Timohummel 12:04, 27. Dez. 2007 (CET)

Wie wärs mit "Mithilfe von E-NOTICE können Designschwächen abgefangen und erkannt werden". Dann ist das komplett neutral. Mir gings nur darum das nicht suggeriert wird das in der Liveumgebung Fehler angezeigt werden sollen die den Nutzer nix angehen :-) --Bitsandbytes 12:08, 27. Dez. 2007 (CET)

Das ist super. Eventuell kann man zu einem späteren Zeitpunkt noch erläutern, welche Faktoren E_NOTICE genau beeinflusst, aber das können wir so einbauen. Bei meinen Projekten ist display_errors immer grundsätzlich aus, deshalb hat mich das so nicht tangiert. Grüße, --Timohummel 12:10, 27. Dez. 2007 (CET)

Habs eingefügt --Bitsandbytes 12:16, 27. Dez. 2007 (CET)

Maintainers

Es wäre gut die aktuellen Maintainer hinzuzufügen.

• Für 5.2 ist das Ilia Alshanetsky
• Für 5.3 ist das Johannes Schlüter
• Für 4.8 ist es Derick Rethans

Warum? Ich sehe darin keine Relevanz, sorry. Dafür ist ja die PHP-Homepage da, die über so spezielle Fragen informiert. --Timohummel 22:56, 5. Jan. 2008 (CET)

Es gibt Aufschluss über die Entwicklungsmethodik. Deshalb denke ich, ist es sinnvoll es einzuarbeiten, genauso wie bei Emacs beispielsweise Stallman als aktueller Maintainer gelistet ist. --87.174.229.157 23:03, 5. Jan. 2008 (CET)

Ist die Entwicklungsmethodik für diesen Artikel relevant? Wikipedia-Artikel sollten allgemein sein, nicht so speziell, daß allgemeine Teile des Artikels nur für "Fachpersonal" interessant sind... Grüße, --Timohummel 00:50, 6. Jan. 2008 (CET)

M.E.: dies ist der Artikel über PHP schön zu erfahren welche Version wann erschien. Der Support für PHP 4 ist eingestellt (aktuelle Mitteilung) wäre auch noch interessant hier zu lesen. Ich glaube WP ersetzt immer mehr andere Nachschlagequellen, jedenfalls war dies die Diskussion auf unserem Stammtisch... ABER Entwicklungsmethodik: gibt es da keinen Artikel mit Literatur und Weblinks?? --Paule Boonekamp - eine Silbersonne 12:33, 6. Jan. 2008 (CET)

Maintainer sind voll und ganz uninteressant für eine Enzyklopädie. Wikipedia ist und bleibt eine Enzyklopädie deshalb werden auch nur allgemeine Informationen aufgenommen. Solche Informationen holt man sich wenn man sie benötigt aus der PHP Website - Somit: Weg --Rudi 12:44, 6. Jan. 2008 (CET)

Dasselbe gilt dann jedoch auch fuer "Steigerung der Performance" und andere Teile aus dem Artikel --87.174.209.49 23:46, 6. Jan. 2008 (CET)

Nein. Fast jeder, der in PHP entwickelt, steht irgendwann einmal vor der Notwendigkeit, die Performance zu steigern. Ich habe in meinen 10 Jahren PHP-Erfahrung noch NIE die Liste der Maintainer benötigt. Außerdem: Bitte begründe, warum du die Liste der Maintainer im Artikel haben möchtest und argumentiere nicht gegen die "Steigerung der Performance", dies kann seperat abgehandelt werden. Grüße, --Timohummel 23:47, 6. Jan. 2008 (CET)

Einflüsse: C, C++

Als Einflüsse werden bei PHP C und C++ genannt. Ich würde noch Java hinzufügen wollen, denn gerade die Objektorientierung in PHP 5 wurde wohl sehr stark bei Java abgeguckt. Kommentare? Einwände? Steinigungen? --Rabus 15:40, 27. Jan. 2008 (CET)

Naja, bei der Objektorientierung kann man auch genausogut Parallelen zu C++ ziehen. Ich denke bei Java eher an Konstrukte wie foreach. Ja, vielleicht ist PHP leicht davon beeinflusst. --Rohieb 会話 +/- 16:06, 27. Jan. 2008 (CET)

@Rabus...Halte ich für falsch. Da keinerlei Ähnlichkeiten Behandlung des Objekts in php mit der Behandlung eines Objekts in Java bestehen. Allenfalls kann eine syntaktische Ähnlichkeit erkannt werden, allerdings ist die wohl eher an C++ angelehnt....--Bitsandbytes 16:38, 3. Apr. 2008 (CEST)

Tag, http://developers.slashdot.org/article.pl?sid=04/08/05/1915255

Darüberhinaus hat sich ein PHP Mitentwickler zum Thema geäußert und entsprechende Einflüsse bestätigt und die Aussage getroffen, dass weitere Parallelen und Einflüsse zu Java ausgebaut werden sollen. Leider ist mir die Quelle momentan abtrünnig und ich bin am suchen, dementsprechend wird diese leider kaum zu werten sein... Auch müsste es nach meinen Erinnerungen schon einmal eine etwas längere Diskussion zum Thema gegeben haben, aber nicht auf der Diskussionsseite von PHP. Ich werde mich mal auf die Suche begeben sofern dir Slashdot nicht ausreicht. --Rudi 17:03, 3. Apr. 2008 (CEST)

Finde ich gut wenn du das raussuchst, dann bleibt natürlich auch die Aussage mit den Einflüssen von Java hier drin. Der momentane Stand ist halt der das es quellenlos ist und damit nicht überprüfbar. Und hier handelt es sich nunmal um eine Kernaussage --Bitsandbytes 17:28, 3. Apr. 2008 (CEST)

Ich bin mal so frech und frage nach der Relevanz :). Wenn es wirklich so wichtig ist, ob PHP Einflüsse von Java hat, sollte man Rasmus fragen - er ist vermutlich der einzige, der das treffend beantworten kann. Grüße, --Timohummel 18:19, 3. Apr. 2008 (CEST)

Änderungen am 30. Jan 2008

Was zum war denn heute los? Was sollte das werden, ein Editwar? Nach Diskussion bleiben die Maintainer im Artikel, Suhosin hat seine Daseinsberechtigung als bekanntes Sicherheitssystem. Diskussion gewünscht, keine Re-Revert ohne Diskussion. Übrigens: Links sollte man nur kurzzeitig auskommentieren und nicht dauerhaft. Eine Diskussion läuft momentan - wenn diese abgeschlossen ist, können die Links gerne wieder hinzugefügt werden. --Rudi 19:20, 30. Jan. 2008 (CET)

Ähm, Maintainer-Diskussion? Wo? Ich habe nur die obige Diskussion gesehen und auch geführt, ich hatte damals die Maintainer-Liste nicht als Notwendig erachtet, die IP jedoch schon, ergo 1:1 unentschieden. Oder gab es irgendwo eine Diskussion, die ich übersehen habe? Grüße, --Timohummel 09:13, 1. Feb. 2008 (CET)

Selbst wenn wir die Maintainer rausnehmen müssten die übrigen Informationen in den Beitrag allgemein eingearbeitet werden. In der Änderung war für 2 Sätze ein eigener Abschnitt vorgesehen was um es mal konkret auszudrücken irgendwie etwas sinnentfreit wäre. Suhosin sollte im Artikel bleiben da es durchaus ein wichtiger Punkt zum Thema PHP darstellt. Dass es zu viel Aufmerksamkeit im Artikel erhält kann ich nicht ganz nachvollziehen. --Rudi 13:31, 1. Feb. 2008 (CET)

Quelle? also das es ein wichtiger Punkt darstellt?--Bitsandbytes 15:17, 1. Feb. 2008 (CET)

Es gibt keine "Quelle" das erschließt sich aus einer logischen Schlussfolgerung. PHP hat allgemein Probleme beim Thema Sicherheit und Suhosin ist momentan die am weitesten verbreitete Möglichkeit um sein PHP effektiv stärker abzusichern. Suhosin ersetzt zwar keine sichere Programmierung der eigenen Programme aber sichert das System gegen noch ungestopfte und unbekannte Sicherheitslücken in PHP ab. --Rudi 15:30, 1. Feb. 2008 (CET)

Das ist ja alles richtig und gut, aber die Aussagen sind nicht nachprüfbar....An welchem Faktum machst du das Wissen fest das es die am weitesten verbreitete Möglichkeit ist, woher willst du wissen das es nicht gestopfte Löcher (welche denn) stopft. Das muss belegt sein, dann kanns auch rein. --Bitsandbytes 16:09, 1. Feb. 2008 (CET)

Zunächst zu den "ungestopften Löchern": Dir ist bekannt dass es in jeder Software die aktiv entwickelt wird immer auch Lücken gibt? Man benötigt keine Quelle um auszusagen dass es Lücken gibt, die besten Quellen sind die zurückliegenden Changelogs in denen Lücken á mass gestopft wurden. [4] und [5]

Zum Thema "Suhosin": Es besitzt seine Daseinsberechtigung auch schon daran dass es von Stefan Esser entwickelt wird. Dieser hat lange Zeit an PHP direkt mitgearbeitet bis er aufgrund dem nach seiner Ansicht zu laschem Umgehen mit Sicherheitslücken das Entwicklerteam verlassen hat [6]. Auch weiterhin ist er ein Sicherheitsexperte in Sachen PHP. Dass Suhosin aktiv Sicherheitslücken, auch unbekannte, schließt erkennt man an folgenden News (Auszug): [7], [8] und [9]. --Rudi 18:21, 1. Feb. 2008 (CET)

Ob eine Software Designfehler enthält oder nicht ist nicht das Thema. Die Frage ist nach dem Nachweis das Suhosin das auch wirklich entfernt. Deine Links sind reine Exploitmeldungen vom Entwickler mit Eigenwerbung :-). Sorry aber das sind keine wirklich belastbaren Aussagen. Das einzige was es halbwegs relevant machen kann, ist das ein ehemaliger Mitentwickler eines Projekts das geschrieben hat. Ein Versuch wäre daher einen Artikel über Suhosin zu schreiben und denn dann auch verlinken. Wenn der Text die Relevanzhürde schafft und ausreichend mit Quellen versehen ist, dann ist es auch zu verlinken. So ist das im Text eine unbelegte, nicht nachprüfbare Aussage die so nicht in einem Projekt stehen kann welches halbwegs den Anschein von wissenschaftlichen Arbeiten haben will. Und sorry aber ein paar Golem Quicklinks sind einfach nunmal keine Quelle....Die Aussagekraft wäre folgende: "Laut Eigenveröffentlichung des Entwicklers von Suhosin, kann Suhosin möglicherweise ein paar Sicherheitlücken beheben. Es finden sich jedoch keine Belege für die Aussage ihr müsst da meinem Urteil trauen" :-). Ums klar zu sagen, natürlich wird Suhosin da hilfreich sein, aber die Aussage muss auch nachprüfbar sein. Naja und zum Verbreitungsgrad, da finde ich nunmal gar nichts --Bitsandbytes 20:54, 1. Feb. 2008 (CET)

Ich weiß nicht ob du vielleicht etwas verwechselst aber Golem ist eine News-Seite und keine Seite von Stefan Esser. Dass die in den News angesprochenen Lücken durch Suhosin geschlossen wurden, eben noch lange vor dem Release der neuen Version, ist eine Tatsache und kann ich auch persönlich nachvollziehen da bei Bekanntwerden der Exploits eben diese bei mir mit Suhosin nicht funktionsfähig waren. Dass man Texte auf anerkannten News-Seiten als Eigenwerbung des Entwicklers abtut ist mir neu und eine sehr zweifelhafte Ansichtsweise oder bist du tatsächlich der Ansicht Golem druckt bzw. postet derartiges ohne redaktionelle Prüfung? Für Suhosin ist definitiv keine eigenständige Relevanz gegeben um es in einen eigenen Artikel auszulagern, im Zusammenhang mit PHP sehrwohl. Die Aussagen sind nachprüfbar du tust nur lediglich die Quellen als nicht relevanzträchtig ab, das sind sie aber. --Rudi 22:19, 1. Feb. 2008 (CET)

Erstmal stehen meine persönliche Ansichten, oder was auch immer ich verwechseln mag usw, auch eine Bewertung meiner Ansichtsweisen steht hier nicht zur Diskussion. Ich bevorzuge fachliche Diskussionen. Desweiteren ist deine Erfahrung ja ganz ok wenns bei dir funktioniert aber nunmal eben nur eine Erfahrung. Nun zum Thema: Wenn für Suhosin keine Relevanz erkennbar ist, warum soll es dann hier rein? Die Golemlinks beziehen sich nur auf einige Exploits, welche durch einen Patch in Suhosin geschlossen wurden. das ist gut,aber nunmal kein Beleg dafür das unbekannte Löcher gestopft werden. Verstehe mich nicht falsch, aber ich bin der Meinung das Aussagen die nicht absolutes Allgemeinwissen sind, auch belegt sein sollten. Ausserdem steht auch imemr noch aus inwieweit das System verbreitet ist und welche Relevanz es im Betrieb hat. Und das in Fachliteratur über ein Allgeminthema die eigenen Produkte erwähnt werden ist logisch und auch klar. Das ist allgemeiner Usus und auch gut so. Allerdings kann man es halt dann nicht als unabhängige Quelle nehmen. Und beim wissenschaftlichen Arbeiten gehts genau darum. Wie gesagt, wenn Suhosin wirklich eine so herausragende und wichtige Rolle im Securitybereich hat, dann sehe ich auch kein Problem für einen eigenen Artikel --Bitsandbytes 02:20, 2. Feb. 2008 (CET)

Dass Suhosin unbekannte Sicherheitslücken patcht ist sehr wohl aus den Golem-News zu erkennen. Mit Suhosin existierten die Exploits faktisch nicht und wurden nicht erst durch ein Patch in Suhosin gestopft. Wenn du das anzweifelst dann steht momentan die Beweislast bei dir - Momentan kann ich meine eigenen Erfahrungen und Golem bieten, du momentan nichts. Du ziehst aktuell ein Verhältnis zwischen Golem und Stefan Esser, Beziehungen existieren hier jedoch nicht. Golem ist von Stefan Esser als Person als auch von PHP Allgemein neutral angesiedelt und hat keinerlei Interesse Produkte Dritter in Artikeln anzuwerben. Eine eigene Relevanz ist nach den Relevanzkriterien nun mal nicht gegeben, das heißt aber noch lange nicht dass keine Relevanz im Hauptthema PHP gegeben ist. --Rudi 21:25, 7. Feb. 2008 (CET)

Ich gebs auf. Schreibt rein was ihr wollt. Meinetwegen auch komplett ohne Quellen. (Seite in der Beobachtungsliste gelöscht und EOD von mir aus). Ich habe keine Lust dauernd zu erklären was eine Quelle ist und was nicht...Anscheinend gibt es hier Diskrepanzen zwischen meiner Auffassung von Quellen und der von den Autoren hier. Vor allem möchte ich mir nicht Argumente im Mund umdrehen lassen. Viel Spass noch, ich muss jetzt weiter Arbeiten korrigieren.--Bitsandbytes 04:02, 8. Feb. 2008 (CET)

Ich schließe mich Bitsandbytes an und fordere hiermit eine Quellenangabe. Grüße, --Timohummel 18:16, 9. Feb. 2008 (CET)

Eine Quelle wurde genannt, wenn dann müsstet ihr vorher Gründe nennen inwieweit diese Quelle nicht zutreffend sein sollte. Dies wurde nicht getan, lediglich mit dem nicht wirklich nachvollziehbaren Hinweis dass Golem die persönliche Meinung von Stefan Esser vertritt und Golem somit keine redaktionelle Prüfung durchführt. --Rudi 19:20, 9. Feb. 2008 (CET)

Ich behandle hiermit deine Verweise mit Numero 5,6 und 7. Ich bitte um Antwort bezüglich jeder einzelnen, bitte keine allgemeingültigen Antworten, sonst kommen wir auf keinen Konsens. Die Quelle mit Numero 5 ist eine Sicherheitslücke in phpProjekt, also nicht in PHP selbst. Daher ist hier keine Relevanz gegeben. Die Quellen mit Numero 6 und 7 wurden gefixt - dafür sind ja Releases da. Das verhält sich genauso wie bei Linux, KDE usw. Der Punkt dabei ist, daß Suhojin zwar sicherlich seine daseinsberechtigung als Projekt hat, aber ich nicht finde, daß das den Leser des Artikels PHP interessieren muß. Mein Standpunkt war (und ich entschuldige mich, wenn meine Forderung nach einer unbestimmten Quelle eben unbestimmt war), eine Quelle zu erhalten, die definiert, daß Suhojin so wichtig ist, daß es im Artikel seinen Platz finden soll. Grüße, --Timohummel 21:44, 9. Feb. 2008 (CET)

Eigentlich wollte ich mich nicht mehr äussern, aber a) kann ich Timo nur recht geben, und b) @ Rudi, ich wehre mich gegen die Aussage die du triffst, das irgendwo behauptet wird, das Golem News nicht redaktionell prüft. Ich mag es gar nicht wenn mir Dinge unterstellt werden, noch dazu wenn Sie eine Aussage umdrehen die so niemals getätigt wurde. Das ist a) Polemik und b) bringt so ein persönlicher Angriff und als das fasse ich das auf niemand weiter. Nimm bitte von solche Aussagen Absatnd und stelle das richtig. Wenn du meine Aussagen so auffassen solltests, dann lies dir bitte nochmal exakt meinen Wortlaut durch. --Bitsandbytes 08:25, 10. Feb. 2008 (CET)

Die Berechtigung dass Suhosin im Artikel von PHP genannt wird erhält es (meineserachtens) durch zwei Punkte: 1. Suhosin wurde und wird von Stefan Esser entwickelt welcher ein ehemaliges Mitglied des „PHP Security Response Team“ ist und auch selbst PHP mitentwickelt hat [10]. Darüberhinaus war er einer der Initiatoren des „Month of PHP Bugs“ [11]. 2. Suhosin schützt effektiv vor unbekannten Lücken in PHP. Als Nachweis dass es überhaupt unbekannte Lücken in PHP gibt, seien die Changelogs ([12] und [13]) von PHP genannt. Natürlich sind diese Lücken inzwischen geschlossen, dass sie geschlossen wurden bedeudet aber automatisch dass sie vor ihrer Schließung bereits existierten und somit unbekannte Lücken waren. Dass es momentan unbekannte Lücken in PHP gibt lässt sich nicht nachweisen (sonst wären sie nicht "unbekannt"), es ergibt sich aber Sinngemäß und Bedarf keiner Quelle. Man kann lediglich auf die Vergangenheit verweisen ([14] und [15]) in der es bereits mehrfach unbekannte Lücken gab die selbstverständlich nachträglich geschlossen wurden. Dass Suhosin manche unbekannten Lücken in PHP von Haus aus schließt lässt sich an der Struktur und den Features von Suhosin erkennen: Einige Lücken in PHP entstehen durch einen zu offenen Umgang mit Limits in der Programmiersprache, Suhosin setzt hier Limits. Durch diese Limits werden einige Lücken geschlossen (Siehe den letzten Absatz von [16]). Die Aussagen in den Golem-News kann ich auch durch persönliche Erfahrungen untermauern, viele aufgedeckte Sicherheitslücken die in neuen Versionen geschlossen wurden, existierten bei mir aufgrund des Einsatzes von Suhosin nicht. @Bitsandbytes: Zumindest habe ich aus deiner Argumentation oben genanntes herausgelesen. Wenn du dies nicht so gemeint hast dann entschuldige ich mich hierfür. Es ist nicht mein Ziel dich persönlich anzugreifen. Grüße, --Rudi 13:50, 10. Feb. 2008 (CET)

Wiki <-> PHP

sollte man nicht auch erwähnen, dass Wiki in PHP geschrieben ist? (nicht signierter Beitrag von Zergling (Diskussion | Beiträge) 11. Feb. 2008, 01:20:09) --Rudi 14:21, 11. Feb. 2008 (CET)

Hi, steht bereits im Artikel unter PHP#Verbreitete_PHP-Applikationen. --Rudi 14:21, 11. Feb. 2008 (CET)

Mal ne kleine Zwischenfrage

Wieso löschen hier Leute, die offensichtlich keine Ahnung von PHP und dessen Möglichkeiten haben, hier munter Erweiterungen des Artikels? (Bezug: Quercus und Performancesteigerung) (nicht signierter Beitrag von franzbranntwein (Diskussion | Beiträge) 14. Mär. 2008, 15:58:59)

Weil hier nur noch wissenschaftlich fundierte Aussagen reinfinden....Du hast keine Quellen angegeben und wir Ahnungslosen wollen nicht immer einem Guru wie dir die Quellen hinterher pflegen...--Bitsandbytes 18:08, 14. Mär. 2008 (CET)

Was ist mit WP:AGF? Ich hab da mal etwas gegoogelt: [17], [18] (ab Absatz „Eingebautes“) und schließlich [19]. So wie ich das jetzt aber verstanden habe, scheint das eine Java-Implementation des PHP-Parsers zu sein, der zusätzlich Java-Imports im PHP-Code erlaubt [20], ist wohl aber noch im Beta-Stadium... --Rohieb 会話 +/- 22:41, 14. Mär. 2008 (CET)

Korrekt, Quercus kann auf Klassen, die in Java programmiert wurden, zugreifen. Aber die Aussage, daß eine Performancesteigerung erfolgt, weil der PHP-Quellcode in Servlets umgewandelt wird, finde ich Interessant - dafür möchte ich eine Quelle. Lieber Autor, bitte erleuchte mich, ich habe nämlich, als ich deinen Edit revertiert habe, nichts darüber gefunden. Und die Aussage "offensichtlich keine Ahnung" trägt nicht gerade zur Symphathie deiner Person bei. Mal davon abgesehen, selbst wenn alles so stimmen mag: Warum muß man jede Möglichkeit der Performancesteigerung in den Artikel einbauen? Halte ich nicht für sinnvoll. Grüße, --Timohummel 00:23, 15. Mär. 2008 (CET)

1) Ich habe nicht die Absicht hier Sympathiepunkte zu erlangen, noch habe ich das nötig 2) diese Art der Performancesteigerung ist schon wichtig, denn PHP goes Enterprise bzw. ist auf dem besten Weg dahin. Eine immer wichtiger werdende "Schnittstelle" zu anderen enterprisefähigen Plattformen ist nunmal Quercus, auch wenn die üblichen PHP-Clan-Board Programmierer das noch nicht mitbekommen haben. Man könnte ja auch auf die Idee kommen, den Artikel z.B. um Java Schnittstellen zu erweitern und in dem Kontext macht der Performancehinweis endgültig Sinn. 3) Du brauchst Dir nur das Performanceverhalten von Servlets eines stinknormalen Webcontainers wie Tomcat anzugucken und entsprechende Vergleiche zur Zend-Plattform heranzuziehen, dann merkst Du schon was schneller ist. Und ausserdem sehe ich in dem Artikel auch kein Beleg dafür was die Bytecode Caches genau bringen. Kann nach Deiner Argumentation also auch rausfliegen. Wenn Du anführen solltest, dass ja Verweise zu den einzelnen Cache-Anbietern vorliegen, nun, nichts spricht dagegen den noch roten Verweis zu Quercus zu bläuen und DORT evtl. Measurements bzgl. Performance anzugeben. Ich wollte es nicht glauben, aber die deutsche Wikipedia scheint in der Tat etwas "seltsam" mit den eigenen urspünglichen Absichten umzugehen (nicht signierter Beitrag von franzbranntwein (Diskussion | Beiträge) 15. Mär. 2008, 18:06:59)

Quercus ist mitnichten Beta, der PHP Code wird ausserdem nur vorinterpretiert analog zu JSPs und dann zu Servlets umgewandelt. Ab dem Moment, wenn die PHP Skripte zu Servlets konvertiert sind, nimmt der ganze Java-Ansatz seinen gewohnten Lauf. Wobei nach erstmaligem Lauf die Skripte letztendlich als Bytecode vorliegen. (nicht signierter Beitrag von franzbranntwein (Diskussion | Beiträge) 15. Mär. 2008, 18:06:59)

Ohne Quelle kein Einbau und EOD von meiner Seite. Grüße, --Timohummel 04:46, 16. Mär. 2008 (CET)

Habe gestern noch gelesen, dass das Quellenargument gerne verwendet wird, um Änderungen abzuwehren (ist ja schliesslich auch Dein Artikel). Ich werde mir jedenfalls nicht die Arbeit machen und hier Quellen angeben, die dann doch nicht akzeptiert werden (zumal ohnehin weitaus wichtigere Quellen im Artikel fehlen). Schliesse dann mal meinen kurzen Ausflug in die Wikipedia damit ab und wünsche den Admins und Artikelbetreuern viel Glück, Ihr könnts brauchen. (nicht signierter Beitrag von franzbranntwein (Diskussion | Beiträge) 16. Mär. 2008, 22:48:32)

Zu den Einzeländerungen

Das php 1994 entwickelt wurde, da fehlt jede Quelle, irgendein Seminar ist keine nachprüfbare Quelle....Zu Suhosin: Eine Relevanz sollte belegt werden, das sie hier so eine prominente Stellung einnimmt (wenigstens ein eigener Artikel sollte vorhanden sein und der muss sich auch halten), zu den Maintainer...das wird oben schon diekutiert, ist aber komplett irrelevant (ausser die Maintainer hätten eigene Artikel welche als behaltenswert betrachtet werden)..Bitsandbytes 09:31, 1. Feb. 2008 (CET)

PHP WORKSHOP von Cristian Wenz, Andreas Kordwig, Tobias Hauser. Erschienen im ADDISON-WESLEY Verlang. ISBN 3-8273-1816-5 ...Sypho... 88.73.51.205 11:07, 20. Mai 2008 (CEST)

Lerndorf -> Lerdorf

Schreibfehler in "Geschichte" korrigiert.

kann archiviert werden --Tobiask 16:15, 20. Mai 2008 (CEST)

Toter Link

http://www.plat-forms.org/2007/results/ geht nicht. Falls das nicht temporär ist, sollte man es rausnehmen, ebenso den Verweis darauf.

kann archiviert werden --Tobiask 16:15, 20. Mai 2008 (CEST)

Deutsches Handbuch

Mir geht die ganze Deutschtümelei auch auf den Senkel. Ist es aber ein Grund ins Gegenextrem zu verfallen ? Es gibt Leute die wollen die Programiersprache einfach nur benutzen und sich nicht mit Herrschaftswissen in manirierten Berkley-Englisch herumaschlagen. Deshalb der Extra-Überschrift: Schnell und leicht für Praktiker ohne Sprachtick aufzufinden - und fertig.

(Ich würde meinen Diskussionsbeitrag ja auch gerne mit IP-Adresse signieren, aber wenn der Formatierungsknöpfe dafür vergessen oder wegprogramiert wurden ... vieleicht mangelnde PHP-Kenntnisse ? ? ;) ) Von Hand nachgetragen : 77.20.205.53

Das deutsche Handbuch gehört auf jeden Fall verlinkt, aber ich sehe keinen Grund, warum das nicht unter "Weblinks", sondern unter einer eigenen Überschrift geschehen sollte. --YMS 15:31, 14. Jul. 2008 (CEST)

Performance - "Shootout" -> unklare Formulierung

Hier steht, dass PHP beim Resourcenverbrauch deutlich hinter Perl und Python liegen soll - soll das heißen, dass PHP weniger Resourcen braucht, oder schlechter ist, also mehr Resourcen braucht? 193.170.32.23 17:19, 6. Aug. 2008 (CEST)

Also für mich ist klar, dass wenn PHP hinter bzgl. der Performance zB hinter Python liegt, dass es dann schlechter liegt, also "später ins Ziel kommt" und somit im Ranking nicht auf den ersten sondern auf einem hinteren Platz ist. --Bountin 13:55, 9. Aug. 2008 (CEST)

Geschichte - Widerspruch bei OOP

Hier steht, dass seit PHP 5.0 erstmals "durch viele hinzugefügte Sprachkonstrukte objektorientiertes Programmieren möglich" sei. Das steht in Widerspruch dazu, dass einfache OOP-Unterstützung bereits mit PHP 4 eingeführt wurde, wie auch in dem Abschnitt erwähnt wird. Korrekt wäre vielmehr, dass mit PHP 5.0 die Unterstützung für OOP massiv verbessert, aber nicht erst eingeführt wurde. 193.170.32.23 17:19, 6. Aug. 2008 (CEST)

das problem von OOP ist, das es "experten" gibt, die sagen dies und das ist OOP. einen standard gibt es nicht. dennoch ist diese aussage zutreffend, da objecte in PHP4 im grunde nichts weiteres als nicht abgeschottbare namensräume sind (ich kann jede variable von überall verändern auch benötige ich keine instanz um eine methode aufzurufen). von daher ist seit PHP5 erst, wie in der versionsübersicht steht, OOP möglich. (übrigens steht dort auch zu PHP 4.0 wörtlich "Einfache objektorientierte Programmierung hinzugefügt)... Alarm fuer die galaxis 12:29, 9. Aug. 2008 (CEST)

Ducktyping

Seit wann beherscht PHP denn Ducktyping? Wäre mir neu!

Wo steht denn was davon? --Rohieb 会話 +/- 23:08, 9. Jan. 2009 (CET)

Inzwischen nirgendwo mehr. Die Frage stamm vom September 2008, ist also schon uralt und die betroffene Stelle ist damals auch rausgeflogen. --BSDev 23:46, 9. Jan. 2009 (CET)

PHP 5.3.0 RC1

Am 24. März 2009 wurde PHP 5.3.0 Released. Man sollte evtl. die Versionstabelle aktualisieren und diese PHP-Version als aktuelle aufnehmen. [[21]] --79.230.110.199 14:15, 31. Mär. 2009 (CEST)

Nein. PHP 5.3.0 ist noch nicht erschienen - am 24. ist lediglich der erste RC herausgekommen nicht aber die endgültige Version. --Tobiask 17:23, 31. Mär. 2009 (CEST)

"plattformunabhängig"

Seit neuestem lese ich das Wort für so ziemlich alles und jedem obwohl es tatsächlich nur selten zutrifft. Plattformunabhängigkeit impliziert zwingend eine Lauffähigkeit auf allen gängigen System; so zb. auch Macintosh. Ist bei PHP (offiziell) nicht gegegen - ich lasse irgendwelche zusammengeklebten Communityprojekte mal aussen vor. Diese Bezeichnung ist also für PHP falsch - mein Vorschlag: ausnahmslos von der Seite löschen, da unwahr. Solange MacOS nicht offiziell (!) unterstützt wird stimmt es nicht, so einfach ist das. http://de.php.net/downloads.php --> kein MacOS.

Den Source-Code sollte man besser auch nicht als "unterstützt alles" zählen, denn zweifellos müssten auf vielen Exoten-Systemen umfangreiche Änderungen durchgeführt werden - wenn der Anwender selbst programmieren muss um das eigentliche Produkt verwenden zu können kann man von keiner offiziellen Unterstützung (ergo: precompiled Binary) reden

Schon mal auf der Download-Seite links unter „Binaries for other systems“ geschaut? PHP läuft auf so ziemlich jeder Plattform und nur weil einige systemspezifischen Anpassungen vielleicht nicht von den PHP-Entwicklern kommen, heißt das noch lange nicht, dass PHP nicht plattformunabhängig ist. -- net 01:03, 18. Mär. 2009 (CET)

Nun, dann treffe ich hiermit folgende Aussage: "Windows-Spiele sind grundsätzlich plattformunabhängig, man muss nur ein paar plattformspezifische Anpassungen vornehmen" - hoffentlich merkst du an diesem Satz wie unsinnig deine Aussage war und ist. (nicht signierter Beitrag von 92.75.158.214 (Diskussion) )

Ich zitiere dich mal: „Plattformunabhängigkeit impliziert zwingend eine Lauffähigkeit auf allen gängigen System“. Das ist gegeben und damit können wir hoffentlich diese unsinnige Diskussion beenden. -- net 11:04, 18. Mär. 2009 (CET)

Ich stimme net zu. Plattformunabhängigkeit bei PHP ist gegeben. Da MacOS X posix-kompatibel ist, ist PHP auch auf MacOS X lauffähig. "Offizielle Unterstützung" und "Plattformunabhängigkeit" sind 2 verschiedene Dinge. Nur so nebenbei: Leopard enthält bereits PHP. Grüße, --Timohummel 16:42, 18. Mär. 2009 (CET)

Mann muß das mit der Plattformunabhängigkeit schon einmal genauer definieren. Ein PHP-Skript ist plattformunabhängig, weil es auch jedem PHP-System unabhängig der darunterliegeneden Platform läuft. Das was plattformabhängig ist, ist die Laufzeitumgebung selbst - die PHP Programme sind es jedoch definitiv. Wenn du der Meinung bist, das Platformunabhängigkeit damit zu definieren sei, dass der code auf jedem System ohne platfformspezifische Elemente laufen müßte, dann gibt es de facto keine Plattformunabhängigkeit. Das gilt analog für Java: Pure Java ist platformunabhängig - Java Bytecode läuft unverändert auf jedem System, das eine Java VM bereitstellt. Wird bei Java das native Interface verwendet, wird auch Java platformabhängig. Auch C ist plattformunabhängig - auch wenn es für eine neue Plattform erst neu kompiliert werden muss - der Sourcecode jedoch nicht verändert werden muss. Für ein Softwareprodukt im Sourcecode gilt: Muss ich den Code anpassen wenn ich auf eine andere Plattform wechsle? Ja = platformabhängig; Nein = platformunabhängig. --80.129.252.131 20:49, 26. Mär. 2009 (CET)

PHP (der Interpreter) lässt sich auf Mac OS problemlos kompilieren und wird teilweise sogar darauf entwickelt, ist also nicht einmal ein Fork oder ähnliches. Eine sinnvolle Anpassung ist das Packaging um die Bequemlichkeit zu unterstützen, ebenso wie es unter debian, fedora, Solaris und anderen System mit Paketverwaltung auch dort Pakete gibt. Ich verstehe nicht was der Aufstand hier soll. Dork 02:39, 6. Mai 2009 (CEST)

Überladung

In dem Artikel wird mehrmals erwähnt das in PHP5 nun Überladung möglich ist. PHP versteht aber unter Überladung keinen Polymorphismus(!). Der Link 'Überladung' führt zur Seite Überladung im Sinne von Polymorphismus. Dies ist definitv falsch. Es sollte Überladung im Sinne von PHP5 erklärt werden (wäre wohl sinnvoll), zumindest jedoch der Link entfernt werden. --89.57.175.87 21:34, 2. Apr. 2009 (CEST)

Sicherheit

Nicht dass ich hier falsch verstanden werde, aber wie vertrauenswürdig ist die ZEND Engine, ich meine damit: wie hoch ist die Gefahr einer in php eingebauten Hintertür mit der kommerzielle Seiten ausgespäht werden könnten?. Sollte die Möglichkeit nicht auszuschliessen sein gehört das IMHO in den Beitrag. (nicht signierter Beitrag von 91.36.149.204 (Diskussion) )

Nein, gehört es nicht. Erstens ist das ein allgemeines Problem von Closed-Source. Zweitens ist wäre das bei irgendeiner Firma mit halbwegs vernünftiger Netzwerküberwachung aufgefallen und drittens ist das hier nicht der Artikel der Zend Engine --P.C. ✉ 09:12, 30. Apr. 2009 (CEST)

Richtig. WP ist schließlich auch nicht da, um irgendwelche Mutmaßungen oder Verschwörungstheorien zu verbreiten. -- net 09:34, 30. Apr. 2009 (CEST)

Zend Engine 1 und 2 sind beide Open Source und auch nicht besonders schwer durchzulesen. Also selbst wenn die Alufolienfraktion irgendwo ihr Forum bekommt ist eine fingierte Mondlandung dagegen relativ einfach vertuschbar. Dork 02:28, 6. Mai 2009 (CEST)

Zum Thema "Datenpaket" oder nicht

Ich habe die Revertiererei mit angesehen - und frage mich, ob das wirklich euer Ernst ist. Wie wäre es, bevor ihr da eine Endlos-revertiererei macht, mal hier zu diskutieren? Die Textstelle bezieht sich auf ein Paket im Sinne eines Programmes, nicht auf ein Datenpaket im allgemeinen oder speziellen, welches mit Sender und Empfänger spezifiziert wird (vgl. auch den verlinkten Artikel Datenpaket). Und wenn es schon eine Verlinkung sein muß, dann bitte auch die richtige (nämlich Programmpaket und nicht Datenpaket). Ich habe die Verlinkung zunächst einmal auf Programmpaket gesetzt - bitte diskutiert, ob die Verlinkung bleiben soll oder nicht. Grüße, --Timohummel 23:19, 18. Mai 2009 (CEST)

Es ist doch wohl nicht dein Ernst, über den Unsinn jetzt auch noch zu diskutieren. Die Verlinkung auf Datenpaket ist Nonsense und bleibt draußen. Und beim nächsten mal liest Norro sich durch, was er da wiedereinfügt, sonst gibt es eine Meldung auf VM wegen Beteiligung an einem Editwar. --Snapper007 15:13, 19. Mai 2009 (CEST)

Datenpaket ist wirklich Unsinn. Mein Erstrevert bezog sich auf die Performance-->Ausführungsgeschwindigkeit. Das sind 2 unterschiedliche Dinge --Bitsandbytes 15:53, 19. Mai 2009 (CEST)

Lieber Snapper, bist du mit dem jetzigen Link einverstanden? Grüße, --Timohummel 17:33, 19. Mai 2009 (CEST)

Überarbeitung des Artikels / Reihenfolge

Das sind zwei Punkte, über die man diskutieren kann:

• a) Die Reihenfolge der Abschnitte
• b) Die anderen Änderungen

Zu a: Die Reihenfolge, so wie ich sie eingeführt habe, halte ich für sinnvoller, da so zunächst der Artikelgegenstand erklärt wird, was ja auch der Sinn von Wikipedia-Artikeln ist. --Sunks 21:03, 1. Aug. 2009 (CEST)

Code-Beispiele

Der Abschnitt bedarf in meinen Augen eventuell einer Überarbeitung, da stimmt einiges nicht so ganz. Ein PHP-Script kann bei passenden Einstellungen auch mit <? geöffnet werden, der schließende Tag ?> wird außerdem oft ganz weggelassen, um zu verhindern, dass bei Projekten mit vielen Abhängigkeiten unerwünschte Whitespaces entstehen. Das darauf folgende Codebeispiel ist so auch nicht ganz richtig: Hier wird PHP nicht in HTML, sondern HTML (das außernrum) in eine PHP-Datei integriert. Außerdem wird nicht 'Hallo Welt!' ausgegeben, sondern es wird dieses komplette HTML-Gerüst an den Browser gesendet. Der Unterschied ist zwar nicht groß, vielleicht sollte man es aber doch erwähnen. --Amgon 18:35, 5. Sep. 2009 (CEST)

Naja, auch <? stimmt nicht ganz. Es gibt insgesamt vier Möglichkeiten, einen Scriptteil zu beginnen:

• <?php /* ... */ ?>
  

• <script language="php"> /* ... */ <script>
  

  die beide immer funktionieren

• <?  /* ... */ ?>
  

  wenn short_open_tag in der php.ini gesetzt ist

• <%  /* ... */ %>
  

  wenn asp_tags gesetzt ist

Und das PHP in HTML integriert wird stimmt schon, es steht ja nicht da, dass es in einer HTML-Datei steht. Auch steht nicht nur da, das Hallo Welt! ausgegeben wird, sondern es in der Webseite ausgegeben wird.

Gruß --Steef ³⁸⁹ 20:56, 5. Sep. 2009 (CEST)

Nagut, das mit PHP und HTML stimmt, ist letztendlich ja auch nicht so wichtig - vielleicht sollte man mit einbringen, dass HTML-Tags vom Browser verarbeitet werden, also dass

• <?php echo '<b>Hallo,</b> Welt!'; ?>
  

  zu 'Hallo, Welt!' wird.

<script> und <% sind mir persönlich jetzt nicht so oft begegnet, da gäbe es ja auch noch

<?= 'test' ?>

Trotzdem wäre ich dafür, diese vier bzw. fünf Varianten zu erwähnen, da sie ja auch recht gängig - zumindest die zwei - sind. Könnte man auch in einen anderen Abschnitt packen. --Amgon 21:21, 5. Sep. 2009 (CEST)

wann gelang PhP der durchbruch?

...was hier fehlt, iss eine jahresangabe. 1995 war es bestimmt nicht! meines wissens existiert PhP als ernstgenommene web-programmiersprache erst seit 2002. das sollte genauer angegeben werden. fest steht, daß Php in keinem bekannten web-kompendium vor dem jahr 2000 überhaupt erwähnt wird... der abschnitt "geschichte" wird dadurch stark verzerrt--ulli purwin _fragen? 05:03, 20. Okt. 2009 (CEST)

Und als was definierst du "ernstgenommene web-programmiersprache"? Am besten einfach eine Jahresangabe ausdenken und reinschreiben, stimmts? ... --Vanger ^!–!? 09:03, 20. Okt. 2009 (CEST)

...ich hab z.b. noch eine engl. ausgabe des kompendiums "Webpublishing Unleashed"(William R. Stanek, >1.500 seiten stark) aus dem jahr 1997. im gegensatz zu Perl oder Java kein einziger hinweis auf PHP... ebenso das deutsche standardwerk von Stefan Münz (1999): auf den 29 seiten des stichworverzeichnis jede menge zu Perl, JScript, Java, VBScript usw. - aber PHP null.

...ok, hier ein paar zahlen zur geschichte dieser scriptsprache:

• november 1997: PHP/FI 2.0 ist auf etwa 1% aller domains weltweit installiert
• ab juni 1998 - mitte 1999: PHP 3.0/4.0 -anteil gestiegen auf ~10% weltweit.
• ab Juli 2004: PHP 5 -> ~20%

...eine stolze steigerungsrate der verbreitung im internet - aber eben nicht gleich zu anfang. neun jahre sind eine ewigkeit in der EDV... gruß, --ulli purwin _fragen? 19:22, 20. Okt. 2009 (CEST)

Unterstützung von PHP 5.3

Wieso steht hier, dass PHP 5.3 nicht mehr unterstützt wird während es in der englischen Wikipedia grün markiert ist? — 89.186.154.128 18:02, 24. Mär. 2010 (CET)

Das bedeutet lediglich das die Version 5.3.0 keine Updates mehr erhält, nicht jedoch das es keine Updates für den Entwicklungszweig 5.3 allgemein mehr gibt. - Hoo man (Diskussion) 20:07, 24. Mär. 2010 (CET)

Das ist doch irgendwie sinnlos: Für den Entwicklungszweig gibt es noch Support, aber er ist rot hinterlegt. Dann sollte man wenigstens 5.3.0 statt 5.3 schreiben, damit explizit diese konkrete Version gemeint ist. Im Augenblick ist die Tabelle doch eher so zu verstehen, dass 5.3 <=> Entwicklungszweig 5.3.x. --Johndoe17 18:42, 28. Mär. 2010 (CEST)

bei allen früheren Versionen bei denen die dritte Stelle eine 0 ist, wurde diese weggelassen - wenn müsste schon überall ein .0 angehängt werden. btw: in der englischen WP ist die 5.3.0 inzwischen auch rot. --Tobiask 19:41, 28. Mär. 2010 (CEST)

Natürlich müsste man das dann bei allen Einträgen so machen. Sonst ergäbe es ja noch weniger Sinn. --Johndoe17 01:11, 30. Mär. 2010 (CEST)

Kritik -> Threading

Zitat: "Threading fehle in PHP völlig, und einige PHP-Module sind nicht threadsicher."

Wieso sollen Module threadsicher sein, wenn es kein Threading gibt? Außerdem: Inwiefern kann man PHP die Nicht-Unterstützung von Threading zum Vorwurf machen, da PHP doch hauptsächlich für die Webseiten-Entwicklung gedacht ist? Der Abschnitt mit dem Threading ergibt so erstmal keinen Sinn für mich. -- 92.50.90.86 22:17, 14. Mär. 2010 (CET)

Ich glaube ich habe herausgefunden, was es damit auf sich hat. Offenbar kann PHP nicht in Verbindung mit Servern eingesetzt werden, die multithreading betreiben (?!). --Johndoe17 14:08, 20. Mär. 2010 (CET)

Nachlesen, was Threadsicherheit bedeutet. Nicht Threadsicher zu sein heisst nicht, das die Software nicht in einer Multithreaded Umgebung eingesetzt werden kann, es sind nur eventuell Nebeneffekte zu erwarten, wenn 2 Threads sich konkurieren (klassisches Beispiel ist der dead lock beim Anfordern von Resourcen. Eine MT-sichere Software steuert den Zugriff auf kritische Resourcen mit entsprechende Synchronisationsmechanismen wie Mutexen/Semaphoren, so das ein anderer MT-sicherer Thread, der auf die gleiche Resource zugreifen möchte, nicht den dead lock verursacht)--213.61.162.161 12:34, 7. Apr. 2010 (CEST)

Bitte allgemeinverständlich erklären, wozu man Threadsicherheit braucht, wenn es gar keine Threads gibt, die sich gegenseitig in die Quere kommen könnten. Ich weiß, was Threads sind und was Threadsicherheit bedeutet. Ich behaupte auch PHP recht gut zu kennen. Aber obige Aussage (das Zitat eingangs) kann ich mir mit diesem Wissen immer noch nicht erklären. Die Mutmaßung mit den Servern hat sich darauf bezogen, dass PHP mit dem Apache2-Worker-Modul zum Beispiel nicht so ohne Weiteres zum Laufen gekriegt werden kann. Das geht offenbar nur, wenn man bei der Kompilierung von PHP all jene Module ausschließt, die nicht threadsicher sind, sodass also nur noch Module verwendet werden können, die threadsicher sind.

Ich glaube aber ich bekomme so langsam eine Vorstellung davon wo das Problem liegt. Das Zitat ist einfach irreführend, weil in einem Satz 2 verschiedene Probleme kritisiert werden, die einzig gemeinsam haben, dass es um Threading geht. Die bemängelte Threadsicherheit einiger Module bezieht sich offenbar nicht auf Threadsicherheit innerhalb der Ausführung eines PHP-Skriptes (denn es gibt in PHP gar keine Threads, wie auch im gleichen Satz gesagt wird!), sondern auf Worker(-Prozesse), bei welchen sich mehrere Threads eine PHP-Interpreter-Instanz teilen.

Der Satz verbindet also irreführenderweise die Nicht-Unterstützung von Threads innerhalb von PHP-Skripts mit der unvollständigen Threadsicherheit bei den PHP-Modulen. Dabei betrifft der erste Kritikpunkt PHP allgemein, während der zweite nur in Zusammenhang mit einem teilweise oder gänzlich threadorientierten Webserver einen Sinn ergibt. --Johndoe17 21:46, 10. Apr. 2010 (CEST)

Ich versuche es mal etwas anschaulicher anhand von Beispielen zu erklären. Zunächst einmal das PHP keine Threads beherscht. Das bedeutet nur, das von PHP Seite keine Threads erstellt werden können. Maximal das Forken des momentanen Prozesses ist über eine Erweiterung möglich. Nun aber zur Threadsicherheit. Ein sinnvoll konfigurierter Webserver ermöglicht es (zb. über fastCGI) das mehrere Anfragen die PHP Scripte auslösen gleichzeitig abgearbeitet werden können. PHP Selbst hat damit zunächst erst mal keine Probleme. Jedoch gibt es zum Beispiel die gettext Erweiterung für die Internationalisierung. Gettext ist dabei ein Programm, was die momentane Sprache anhand der eingestellten Locales des Systems/Systemnutzers bestimmt. Dies ist eine Art globale Variable. Und wenn nun zwei PHP-Scripte gleichzeitig laufen, wird während der Laufzeit des einen, die Variable womöglich umgestellt und somit mischen sich die Sprachen. Auf solche Effekte bezieht sich der Hinweis auf unvollständige Threadsicherheit, auch wenn dies eher ein Problem in Gettext als in PHP darstellen würde(wenn gettext für solche Fälle denn geschaffen worden wäre) --Flyingmana 21:57, 4. Okt. 2010 (CEST)

"Skriptsprache mit breiter Unterstützung für Datenbanken"

Im Artikel stand, PHP sei eine Skriptsprache mit "breiter Unterstützung für Datenbanken". Ich sehe nicht, inwiefern die Sprache PHP Datenbanken unterstützt. --Schlu32 13:03, 31. Mär. 2010 (CEST)

PHP enthält Funktionen, um auf MySql-Datenbanken und abhängig von der Installation auch auf MS Sql Server-Datenbanken zuzugreifen. --Gaussianer (Diskussion | Beiträge) 21:53, 10. Apr. 2010 (CEST)

Ich habe ja neulich wie gewünscht entsprechende Einzelnachweise hinzugefügt. Ich finde man kann dort schon eine sehr breite Datenbankunterstützung erkennen. Und wie ich auch schon in der Edit-Notiz geschrieben habe: Ich finds nicht so prickelnd wenn man erst löscht und dann fragt. Die bisherigen Autoren werden sich schon irgendwas dabei gedacht haben (und haben sie ja auch offenbar in diesem Fall). ;) --Johndoe17 22:02, 10. Apr. 2010 (CEST)

Hier sind alle von PHP unterstützten DBMS aufgelistet: http://www.php.net/manual/de/refs.database.vendors.php, das sollte wohl für die "breite" Unterstützung reichen. Des Weiteren gibt es noch zahlreiche Abstraktionsebenen: http://www.php.net/manual/de/refs.database.abstract.php (vor allem PDO finde ich selbst sehr gut und nutze es inzwischen eigentlich immer wenn es verfügbar ist) - Hoo man (Diskussion) 13:09, 11. Apr. 2010 (CEST)

Weder Funktionen noch Treiber sind eine Unterstützung durch die Skriptprache. Ihr verwechselt Sprache mit Bibliothek oder Plattform. Es bleibt dabei: Es gibt keine Unterstützung von Datenbanken durch die Sprache PHP. (So etwas gibt es aber z.B. bei C#) --Schlu32 13:56, 17. Apr. 2010 (CEST)

Wo hat den bitte C# eine eingebaute Datenbankunterstützung, die nicht auf die .NET-Plattform und die dahinter liegenden Treiber zugreifen? Belege bitte außerdem deine persönliche Meinung, dass die eingebauten Datenbankfunktionen von PHP keine Datenbankunterstützung sind! --net 21:46, 17. Apr. 2010 (CEST)

Also sorry Schlu32, aber so eine Klugsch******* hab ich ja selten gesehen. Ich denke nicht, dass es sinnvoll ist wie bei Java strikt zwischen Sprache und Plattform/Libraries zu unterscheiden. Natürlich kann man über solche Ansichten diskutieren, aber ich bezweifle, dass das mit DIR möglich ist, da du bisher einfach gelöscht hast, was dir nicht gepasst hat. Und dann sei doch wenigstens konsequent und lösche auch noch in den Artikeln Python (Programmiersprache), Ruby (Programmiersprache) usw. herum. Da wird beispielsweise von Pythons Standardbibliothek geredet oder von Rubys (interaktiver) Shell etc. Das ist deiner Meinung nach ja offensichtlich auch alles total falsch und wird besser erstmal gelöscht.

Du hast übrigens selbst geschrieben "Ich sehe keine "breite Sprachunterstützung" für Datenbanken, Protokoll usw. in der Skriptsprache PHP. Bitte belegen." Das nenne ich guten Gewissens Ahnungslosigkeit. Würde jeder erstmal löschen, was er nicht nachvollziehen kann, dann könnte man dieses ganze Projekt hier ganz sein lassen. Wozu gibt es wohl die Diskussions-Seite? Nur um Editwars zu diskutieren? Nein, ganz sicher nicht! Die sind primär dazu da um Fragen zu stellen etc., um Editwars und anderes zu vermeiden.

Abschließend denke ich, dass es das beste wäre man würde die Einleitung ändern von "PHP ist eine Skriptsprache..." in "PHP ist eine Skriptsprache und Plattform..." o.ä. Denn mit einer Sache hat Schlu32 Recht: die SPRACHE ist nicht dasselbe wie das, was sich drum herum gebildet hat (Module, Libraries, ...). Dann aber inkonsequent x-beliebige Stellen zu löschen ist der falsche Weg um dieses vermeintliche Problem anzugehen. --Johndoe17 12:24, 19. Apr. 2010 (CEST)

Grammatik

Bei indirekter Rede wird der Konjunktiv verwendet. --Schlu32 14:00, 17. Apr. 2010 (CEST)

Ok, wenn du lieber eine unbegründete VM machst, als auf deiner Disk zu antworten dann eben hier weiter. Schau dir doch bitte mal den Artikel zu Indirekten Rede an. Der fängt damit an:

„Die indirekte Rede ist ein Mittel zur distanzierten, berichtenden Wiedergabe von Äußerungen.“

Die von dir bemängelte Aussage:

„ Zudem sind trotz vorhandener Objektorientierung die meisten Standardbibliotheken noch prozedural angelegt.“

… ist jedoch weder eine „berichtenden Wiedergabe von Äußerungen“, noch muss man sich im Artikel davon distanzierten. Wie kommst du also darauf, dass hier Indirekte Rede in verschäfter Form mit Konjunktiv eingesetzt werden muss? --net 21:40, 17. Apr. 2010 (CEST)

Ich würde dir empfehlen, dich in dieser Angelegenheit bei der Redaktion Germanistik zu informieren (gibt es die überhaupt?), oder einfach die Finger von dem Thema zu lassen. Ich könnte mir vorstellen, dass du dich mit Technik ganz gut auskennst. Da kannst du dich wahrscheinlich besser einbringen. n.f.u. --Schlu32 16:57, 30. Apr. 2010 (CEST)

Danke für den Rat aber ich kenne mich da schon ganz gut aus. --net 00:08, 1. Mai 2010 (CEST)

Allgemeines -> Vorteile der serverseitigen Ausführung?

Der Sinn dieses Abschnitts ist mir nicht ganz klar. Wann hat man denn schon die Wahl, den Code serverseitig oder clientseitig laufen zu lassen? Sobald's interaktiv wird, benötigt man u.a. aus Performancegründen doch ohnehin auch clientseitiges JS bzw. eine clientseitige Sprache, und PHP ist für den interaktiven Teil recht nutzlos. Wenn man umgekehrt Daten verschiedener Nutzer lagern und verwalten muss (Weblogs, Wikis, Webmail, soz. Plattformen usw.), ist Javascript ohnehin keine Option, da die Daten nur clientseitig gespeichert werden können. Was soll also der vergleichende Teil?

"Ein Nachteil ist, dass jede Aktion des Benutzers erst beim erneuten Aufruf der Seite erfasst wird."

Oder halt per Ajax_(Programmierung), Flash Remoting etc., was PHP auf der Serverseite durchaus übernehmen kann. Nachteil also gegenüber welcher Technologie?

Ich kann auch gerne entsprechende Änderungen am Artikel machen, wollte davor aber sichergehen, dass ich nicht nur den entsprechenden Absatz missverstehe...

--Wolfgang Noichl 00:04, 18. Mai 2010 (CEST)

Das hab ich mich auch gefragt. Sollte geändert werden. -88.130.75.186 14:16, 15. Jul. 2010 (CEST)

Der Satz "Ein Nachteil ist..." ist mir auch sofort seltsam vorgekommen. Ist so, als würde man schreiben, der Nachteil des Auto-Modells XY ist, dass es nicht fliegen kann. -- Hannes Schmiderer 20:54, 19. Feb. 2011 (CET)

Ich habe das jetzt mal soweit entfernt, wenn man so was wirklich braucht dann wohl im Skriptsprachen Artikel, da das definitiv auf alle serverseitigen Skriptsprachen zutrifft. - Hoo man (Diskussion) 12:56, 20. Feb. 2011 (CET)

PHP-Qt

PhP-Gtk wird erwähnt, PHP-Qt aber nicht. Auch wenn es auf der PHP Seite nicht erwähnt oder verlinkt wird, ist es denke ich doch eine interessante Information. Zumal es im [Qt] Artikel auch erwähnt wird. --Flyingmana 22:01, 4. Okt. 2010 (CEST)

Ich habe das in den Satz mit dem PHP-GTK eingebaut - Hoo man (Diskussion) 12:58, 20. Feb. 2011 (CET)

Ausblick: PHP6

Unter "Ausblick" steht die Entwicklung zu PHP6. Die darin dargestellten Details stimmen zwar, allerdings ist die Entwicklung von PHP6 bis auf Weiteres aus Eis. Es ist unklar, ob die nächste Version 5.4, oder 6 sein wird und (falls 5.4), ob und welche der eigentlich für 6 vorgesehenen Features schon dort einfließen werden (vgl. "Namespaces", die in 5.3 zurück geportet wurden). (nicht signierter Beitrag von 95.88.196.127 (Diskussion) 16:06, 23. Feb. 2011 (CET))

Hört sich interessant an. Kannst du eine Quelle dafür nennen?

Wenn ja, dann schreib das doch in den Artikel! --88.130.89.194 20:53, 17. Mär. 2011 (CET)

Bitte zwischen Sprache, Laufzeitsystem und Architektur unterscheiden:

Bereits am Artikelanfang fehlt die Differenzierung:
- "PHP ist eine Skriptsprache"
- "PHP wird als freie Software unter der PHP-Lizenz verbreitet"

Unter Funktionsweise findet man dann:
- "PHP ist ein System, das PHP-Code serverseitig verarbeitet"

Wie ist das zu verstehen ?, vermutlich nicht als weitere Definition, sondern so, dass PHP die Eigenschaft hat, ein System zu sein, welches PHP-Code serverseitig verarbeitet. Gemeint ist die typische Verwendung in einer Webserverarchitektur.

Der Widerspruch kommt (zu recht) ein paar Zeilen tiefer:
- "Mit PHP lassen sich auch kommandozeilenorientierte Skripte schreiben, die vom Internet unabhängig sind. Die Qt-Erweiterung und die GTK-Erweiterung stellen sogar eine Programmierschnittstelle für eine grafische Oberfläche zur Verfügung, für die weder ein Webserver noch ein Browser benötigt werden."

Es lassen sich offensichtlich auch ganz normale standalone Anwendungen programmieren und ausführen. Aus der Formulierung "kommandozeilenorientierte Skripte" schliesse ich mal auf die Existenz einer "PHP-Shell".

Im selben Abschnitt:
- "Da PHP normalerweise in einer Webserver-Umgebung läuft, unterliegt es auch dem zustandslosen HTTP."

Die Aussage ist in mehrerer Hinsicht problematisch:
a) Nur HTTP an sich ist zustandslos, der Webserver und die Zendengine müssten es prinzipiel nicht sein, Gegenbeispiel Apache Tomcat mit Sessionkontext. Die Sprache PHP berührt das garnicht.
b) Webserver == HTTP-Server ???, prinzipiel kann ein (Web)Server auch andere Protokolle benutzen, sind die Zendengine und/oder die Sprache PHP explizit an HTTP geknüpft ? Das dieses das 99.99%-ige Anwendungsszenario ist möchte ich garnicht bezweifeln.

Insgesamt vermisse ich eine saubere Unterscheidung zwischen Sprache, Laufzeitsystem und Anwendungsarchitektur (=> 3 verschiedene Artikel).

Zur Sprache selbst vermisse ich Informationen wie:
- gibt es eine Standardisierung ?
- wer spezifiziert PHP ?, Zend Techn. alleine ?
- Spracheigenschaften, -Paradigmen ?
- gibt es Übersetzer in andere Sprachen ?
- welche Compiler gibts ?, und für welche Zielplattformen ?
- welche Interpreter gibts ?

Und welche Laufzeitumgebungen gibt es ?, unter welchen Lizenzen ? (Laufzeitumgebungen wofür ?, PHP-Code ?, irgendwelchen Byte-Code ?, für welche Architekturen ?)

Ich hoffe das war konstruktiv und hilft euch den Artikel zu verbessern ;-) (nicht signierter Beitrag von 84.60.96.129 (Diskussion) 10:37, 13. Jun. 2011 (CEST))

Verbreitung von PHP

Meiner Meinung nach sind die 75% die in der Einleitung aufgeführt sind totaler Quatsch. Die referenzierte Webseite zählt vermutlich nur die Dateierweiterungen. Die ist bei PHP nunmal meisten *.php. Andere Technologien wie Java generieren aber meistens ganz normale html oder xhtml Dateien denen man auch im HTML-Quelltext nicht entnehmen kann wer sie generiert hat.

Ich würde diese Zahl daher entfernen. Realistisch gesehen dürfte PHP an 3. Stelle nach Java und .NET kommen. Aber das kann man wie gesagt nicht messen. --matrixx 12:55, 25. Aug. 2011 (CEST)

ich glaube nicht dass da nur die Dateiendung gezählt wird - sonst könnte die Statistik (die Quellenangabe hast du ja gefunden, oder?) nicht nach Version aufgeschlüsselt werden. Mal abgesehen davon, dass *alle* Sprachen ganz normale (x)html-Dateien erzeugen: auch einer mit PHP erzeugten Seite sieht man das nicht zwangsläufig an. Den Satz könnte man vielleicht etwas umformulieren und die Zahl entfernen - so ganz falsch dürfte die Zahl aber wohl eher nicht sein, dass PHP erst nach Java und .NET kommt halte ich für ein Gerücht. --Tobiask 17:01, 25. Aug. 2011 (CEST)

Sehe ich genauso wie mein Vorredner. Dass lediglich die Dateierweiterung gezählt wurde, ist, wie du schon sagtest, nur eine Vermutung. PHP kann ebenfalls reguläre html-Dateien erzeugen. --_{Nightfly85 | Disk} 00:23, 12. Nov. 2011 (CET)

PHP auf Mac OS X

Seit wann ist PHP auf OS X von Hause aus dabei? Ich musste es bisher immer selber installieren :/ (nicht signierter Beitrag von 2called-chaos (Diskussion | Beiträge) 12:21, 19. Sep. 2011 (CEST))

Zumindest seit Snow Leopard ist PHP von Haus aus als CLI und Apache Module mit dabei. Unter Lion wird bspw. PHP 5.3.6 mitgeliefert. --net 14:02, 19. Sep. 2011 (CEST)

Hier ist ein Artikel aus dem Jahr 2003, da war es offenbar auch schon dabei: Using Apache and PHP on Mac OS X --MatthiasGutfeldt 16:56, 19. Sep. 2011 (CEST)

Maintainer PHP > 5.3

Im Artikel ist der Satz zu finden:

Aktuell ist ausschließlich den Zweigen für PHP 5.2.x und PHP 5.3.x ein Maintainer zugeordnet.

Was ist mit 5.4? --_{Nightfly85 | Disk} 00:24, 12. Nov. 2011 (CET)

PHTML

"PHTML" leitet auf PHP weiter, es wird aber nicht darauf eingegangen. Bitte um Ergänzung. --Seth Cohen 23:35, 18. Okt. 2011 (CEST)

Ich denke, dass es besser ist, diesen irreführenden Redirect zu entfernen. Der Redirect ist seit Jahren tot, ohne dass es jemanden gestört hätte. Der Begriff PHTML wird hier nicht erläutert und ich wüsste auch nicht, wie das sinnvoll möglich wäre. Die Dateiendung PHTML allein sagt nichts darüber aus, ob in den Dateien auch tatsächlich PHP-Code enthalten ist; dem muss nicht so sein. Sie können auch nur einfaches HTML enthalten. Wenn jemand was zu PHTML-Dateien sagen kann, kann er dazu ja einen Text unter "PHTML" schreiben. --88.130.82.61 23:14, 5. Dez. 2012 (CET)

Die Weiterleitung ist inzwischen gelöscht. --Baumfreund-FFM (Diskussion) 23:12, 5. Dez. 2012 (CET)

Inkonsistenz bei Versionshistorie

Im Abschnitt "Wichtige Versionen" wird die Version 5.2.17 auf den 6. Januar 2011 datiert. Die neuere Version 5.3 erschien aber angeblich schon am 30. Juni 2009. Von der chronologischen Abfolge kann doch dort etwas nicht stimmen? (nicht signierter Beitrag von 79.227.153.54 (Diskussion) )

Doch, das stimmt so. --net 14:03, 30. Nov. 2011 (CET)

Sollte dann nicht eine Erklärung für diese auf den ersten Blick irreführenden Angaben geliefert werden? (nicht signierter Beitrag von 79.219.110.131 (Diskussion) )

Steht doch vom Prinzip da. Es handelt sich um den Entwicklungszweig 5.2, der natürlich auch mit Erscheinen der 5.3 noch eine Weile weitergepflegt wurde. So wurde das bisher immer bei PHP gemacht und auch wenn die 5.4 erscheint, wird die 5.3 mit Sicherheit noch Updates bekommen. --net 20:08, 30. Nov. 2011 (CET)

Implementierungen

Vielleicht sollte man auch die verschiedenen Implementierungen der Sprache erwähnen, wie z.B. Quercus, HipHopVM, PHP4Mono, Phalanger usw. (nicht signierter Beitrag von 85.176.13.115 (Diskussion) 15:46, 26. Apr. 2013 (CEST))

PHP funktionsweise.svg

Damit auch M-J es versteht: Die Basisgröße einer SVG-Grafik gibt an, in welcher Standardgröße die Grafik ausgegeben wird. Die Basisgröße dient hierbei insbesondere dazu, einen Anhaltspunkt zu bieten, welche Skalierung der Autor als die bestmögliche vorgesehen hat. Wikipedia nutzt diese Information um zwecks Abwärtskompatibilität zu älteren Browsern aus SVG-Grafiken eine Grafik im PNG-Format zu generieren. Als Skalierung hierfür wird besagte Basisgröße verwendet. Das ist in MediaWiki fest einprogrammiert und kann vom Benutzer auch nicht ohne Weiteres in irgend einer Weise beeinflusst werden, da es sich um kein Thumbnail handelt, findet nichtmal die Thumbnail-Einstellung in den Benutzereinstellungen Anwendung. Die ausgelieferte Grafik ist bei jedem Benutzer der Wikipedia somit erstmal immer eine 780x195 Pixel große Grafik.
Es gibt nun drei grundsätzliche Möglichkeiten die Größe der Grafik zu verändern:

• indem die Grafik als Thumbnail eingebunden wird; die tatsächliche Größe richtet sich nach den Benutzereinstellungen (und ggf. einem Multiplikator mittels hochkant-Parameter)
• indem der Nutzer mittels JavaScript die Standardgröße von SVG-Grafiken verändert
• indem im Artikel eine feste Größe für die Grafik angegeben wird

Eine Darstellung als Thumbnail ist nicht sinnvoll da dadurch die Informationen schwerer zugänglich werden und benutzerspezifisches JavaScript wird grundsätzlich niemals berücksichtigt. Auch das Festlegen einer absoluten Größe ist in der Wikipedia im Allgemeinen weder üblich noch erwünscht.^{[Hilfe:Bilder: „eine feste Größenangabe ist im Allgemeinen nicht erwünscht“]} Hinzu kommt die Tatsache, dass eine allgemein massive Probleme verursachende Vorlage, wie es Vorlage:Panorama ist, vermieden werden sollte wo nur irgendwie möglich - so führt die Vorlage zu massiven Problemen in der Druckversion der Seite, die auf Grund des von der Vorlage eingestellten Scroll-Overflows vom Browser nicht behoben werden kann. Und zu guter Letzt hat sich der Autor der Grafik mit der Basisgröße etwas gedacht - die Grafik ist mit einer Breite von 780 Pixeln wunderbar lesbar, mal vollkommen davon abgesehen dass sie schon in einer Auflösung mit 1024 Pixeln Breite (die für Artikel zu berücksichtigende Mindestauflösung) Platz findet. Die Vorlage ist schlichtweg unnötig: eine Verbreiterung der Grafik um 20 Pixel bringt absolut gar nichts, im Gegenteil wird sie, neben den zahlreichen vorangegangen genannten Gründen, auf großen Bildschirmauflösungen, bedingt durch den fehlenden Textumfluss, zur Platzverschwendung. --Vanger ^!–!? 00:19, 30. Mai 2012 (CEST)

Suhosin

Die Suhosin Webseite wurde letztmalig 2010 geändertm das Forum dort ist geschlossen. Wird Suhosin noch weiter entwickelt, ist es noch aktuell? Sonst Verweis aus dem Artikel streichen bzw. als veraltet kennzeichnen. 85.181.0.175 14:28, 19. Aug. 2012 (CEST)

Die letzte Version ist vom Januar 2012. Es geht also weiter. Gruß --[[kgh]] (Diskussion) 17:27, 21. Aug. 2012 (CEST)

Versionsgeschichte auslagern

...die Versionsgeschichte in der jetztigen Form sollte ausgelagert werden. Viel zu oft sind nur allgemeine Angaben zu finden, die den Artikel unnötig aufblähen. Vorschlag: Tabelle in einen eigenen Artikel setzen (z.B. PHP/Versionsgeschichte) und in diesem Artikel hier in einem Fließtext markante Versionssprünge deutlich machen (z.B. "Ab der PHP-Version 5.3 wurden Namespaces eingeführt [...]") Einwände dagegen? --Nightfly | _Disk 08:28, 1. Feb. 2013 (CET)

Ich würde grds. bei der Tabellenform bleiben. Ich hab vor einiger Zeit mal den Artikel MySQL überarbeitet und da steht noch keine Tabelle. Folge ist, dass man nicht mal eben sehen kann, wann genau welche Majorversion rauskam oder welche die nächste Majorversion war. Das ist deutlich unübersichtlicher; eine Tabelle bietet sich für diese Art von Daten einfach an.

Nein, komplett entfernen würde ich sie hier nicht; die wichtigsten Versionen sollten weiter auch hier in einer Tabelle erwähnt werden. Nur wenig hilfreich sind aber Versionen, bei denen ausschließlich "Diverse Fehlerbehebungen." steht. "Diverse Fehlerbehebungen?" Was ist das schon? Das ist selbstverständlich bzw. nichtssagend! Natürlich wurde da irgendwas geändert, sonst wär es keine neue Minorversion, sondern noch die alte. Und natürlich gibt es Bugfixes und keine riesigen Features, sonst wäre es eine Majorversion. --88.130.72.133 01:38, 13. Feb. 2013 (CET)

Habe die Versionsgeschichte verschoben nach Versionsgeschichte von PHP. --Trustable (Diskussion) 13:55, 27. Feb. 2013 (CET)

Alles klar. --Nightfly | _Disk 14:01, 27. Feb. 2013 (CET)

Dieser Abschnitt kann archiviert werden. Nightfly | _Disk 14:01, 27. Feb. 2013 (CET)

integrierter Bytecode-Cach in PHP 5.5

Ab Version 5.5 ist Zend Optimizer+ ein fester Bestandteil von PHP. Der Bereich Bytecode-Caching, insbesondere der Satz "PHP besitzt aktuell keinen integrierten Bytecode-Cache", sollte daher geändert bzw. angepasst werden. (Quelle: http://www.golem.de/news/opcode-cache-zend-optimizer-wird-in-php-5-5-integriert-1303-98069.html)

--!aoniug (Diskussion) 20:03, 11. Jun. 2013 (CEST)

Das hättest du auch einfach selbst anpassen können. ;-) Erledigt. --88.130.112.223 14:08, 29. Jun. 2013 (CEST)

Dieser Abschnitt kann archiviert werden. 88.130.112.223 14:08, 29. Jun. 2013 (CEST)

XAMPP

Den Abschnit zu den XAMPP-Versionen habe ich heraus genommen da es bei diesen um reine Testumgebungen handelt die niemals nie für einen produktiven Einsatz gemacht wurden und auch tunlichst vermieden werden muss diese so zu benutzen. Daher keine Relevanz im Artikel. --Codc ^Disk Chemie _{Mentorenprogramm} 13:46, 4. Sep. 2013 (CEST)

Und was ist jetzt deine Begründung zum Entfernen des Abschnitts? Entwickeln und Testen gehört genauso zu PHP wie der produktive Einsatz und daher ist XAMPP sehr wohl relevant für den Artikel und kann mit erwähnt werden. --net (Diskussion) 14:35, 4. Sep. 2013 (CEST)

Dann sollte das so im Artikel stehen dass es nicht produktiv genutzt werden darf und nicht so dass es eine bequeme Methode ist einen XAMP aufzusetzen. Einen Grund das im Artikel zu haben sehe ich immer noch nicht und wurde auch noch nicht dargelegt. Es reicht wenn PHP in XAMP Erwähnung findet was auch der Fall und richtig ist. --Codc ^Disk Chemie _{Mentorenprogramm} 15:24, 4. Sep. 2013 (CEST) PS: Bitte beachten und die WP:ZQ nutzen.

Warum sollte man das nicht dürfen? Kannst du das mal irgendwie belegen? Man kann XAMPP auch sicher konfigurieren und ein von Hand installiertes PHP nebst Webserver auch unsicher machen. Ich habe nichts dagegen, wenn noch dazugeschrieben wird, dass diese Systeme eher zum Testen und weniger für den produktiven Einsatz gedacht sind aber das sollte dann auch irgendwie noch belegt werden. --net (Diskussion) 15:33, 4. Sep. 2013 (CEST)

Ich bin auch der Ansicht, dass weitergehende Infos zu XAMPP im Artikel PHP nichts zu suchen haben. XAMPP ist eine Zusammenstellung von freier Software, u.a. mit PHP. Die dortigen Sicherheitslücken basieren auch nicht auf Mängeln im PHP-Code. Im Artikel XAMPP wurde ja bereits erwähnt, dass es nicht als Produktivsystem gedacht ist. --HHE99 (Diskussion) 14:12, 5. Sep. 2013 (CEST)

Im Artikel gibt es ja auch keine weiterführenden Infos zu XAMPP. Es wird nur erwähnt, dass es das gibt und ich habe dann noch ergänzt, dass diese Systeme eigentlich nur für Testumgebungen gedacht sind. Sicherheitslücken gab es darin ja sowieso nicht, sondern nur lockere Standardeinstellungen, die nicht für Produktivsysteme geeignet sind. Wie ich schon schrieb, kann man aber auch XAMPP ohne Probleme sicher konfigurieren und dann produktiv einsetzen. --net (Diskussion) 17:30, 5. Sep. 2013 (CEST)

Threading in PHP

"Threading fehlt in PHP völlig" ist nicht mehr ganz korrekt, denn mit pthreads und der PHP-Klasse Thread werden sie doch unterstützt.

http://www.php.net/manual/de/class.thread.php http://www.phpgangsta.de/richtige-threads-in-php-einfach-erstellen-mit-pthreads

--212.255.45.245 13:03, 25. Okt. 2013 (CEST)

Kritik

Die Existenz von "Kritik"-Abschnitten hat ja schon einige Kritik gesehen, aber da sie nunmal existieren, möchte ich hier mal auf diesen Rant hinweisen. (Besonders schockierend finde ich, dass der ternäre Operator linksassoziativ ist. ("Unlike (literally!) every other language with a similar operator, ?: is left associative.") Das Code-Beispiel spricht für sich...) Können Teile davon evtl. in den Kritik-Abschnitt wandern? -- 77.21.78.154 07:03, 18. Feb. 2014 (CET)

Trinitäts-Operatoren müssen richtig geklammert werden, damit sie verkettet funktionieren:

$arg = 'T';
$vehicle = ($arg == 'B' ? 'bus' :
	   ($arg == 'A' ? 'airplane' :
	   ($arg == 'T' ? 'train' :
	   ($arg == 'C' ? 'car' :
	   ($arg == 'H' ? 'horse' :
	   'feet')))));
	
echo $vehicle;

// gibt train aus

Dann funktioniert der auch richtig. --net (Diskussion) 08:17, 18. Feb. 2014 (CET)

Fraglos, dennoch ist die implizite Defaultklammerung

$arg = 'T';
$vehicle = ((((($arg == 'B' ? 'bus' :
	   $arg == 'A') ? 'airplane' :
	   $arg == 'T') ? 'train' :
	   $arg == 'C') ? 'car' :
	   $arg == 'H') ? 'horse' :
	   'feet');

so sinnvoll, als würde eine Sprache Strichrechnung vor Punktrechnung durchführen. Da hilft kein Verweis auf die Möglichkeit Klammern zu setzen, es geht um 'sane defaults'. Aber ich höre dein "Nein". Too bad. -- 77.21.78.154 10:00, 20. Feb. 2014 (CET)

Ein generelles »nein« war das von mir nicht. Ich halte nur Kritik in der Art „PHP macht irgendwas anders als andere Programmiersprachen“ nicht direkt für sinnvoll. Auch denke ich nicht, dass der Kritik-Abschnitt hier zu sehr ausgebaut werden sollte – insbesondere die Kritik an der Sprache selbst sollte in Sinne einer Enzyklopädie nicht zu sehr ins Detail gehen. --net (Diskussion) 11:25, 20. Feb. 2014 (CET)

Wenn man mal weiss, wie das in PHP funktioniert, kann man es richtig machen. Das ist kein Ding. IMHO sollte man sich in der Kritik eher auf wesentliche konzeptionelle Schwächen konzentrieren, die man als Programmierer nicht so einfach kompensieren kann. --MatthiasGutfeldt (Diskussion) 11:35, 20. Feb. 2014 (CET)

Der verlinkte "Rant" ist keine Kritik, sondern Gequengel eines mehr oder minder begabten Programmierers, der es für eine gute Idee hält, seine Argumentation mit dem Hinweis auf seine enorme Erfahrung zu untermauern. Ein guter Autofahrer kann sowohl in Deutschland als auch in England fahren, und ein guter Programmierer kann ... Ihr wißt schon. Kritik an einer Programmiersprache muß in der Sache begründet sein und darf sich nicht auf "Ich finde PHP/Java/Erlang/Prolog/Ada/Fortran/... doof" beschränken.

Funktionsweise - Die Antwort kann bereits kommen, während ein PHP läuft

Ich beschäftige mich seit kurzem mit PHP. In allen Texten über die Grundlagen von PHP, die ich auf diversen Internetseiten gelesen hatte, wurde die Funktionsweise wie folgt dargestellt: Man ruft ein PHP auf einem Server auf, dieser berechnet etwas und erzeugt dabei eine Datei mit dem Ergebnis, das dann auf dem Browser angezeigt werden soll. Wenn das PHP fertig ist, dann wird diese Datei mit dem Ergebnis zum Browser übertragen und angezeigt. So wird es auch im Artikel unter Funktionsweise in der Grafik dargestellt. Bisher war das auch immer so, wenn ich mit PHP experimentiert habe.

Gestern habe ich ein PHP erstellt, das den Geschwindigkeitsunterschied des Aufrufs einer Funktion, mit der eines Unterprogramms vergleicht, das mit GOTO aufgerufen wird. (Über den Sinn hiervon geht es in dieser Diskussion übrigens nicht!) Das Ergebnis kam ebenfalls nach Abschluss der Berechnung des PHP's. Weil ich noch eine Domain bei einem anderen Provider habe, wollte ich das PHP auch dort mal ablaufen lassen, um vergleichen zu können, wie schnell die Server des anderen Providers sind. Die erste Erkenntnis war, dass das PHP auf dem Server dieses Providers rund 13 Mal schneller ablief. Die zweite Erkenntnis war, dass dieser schnellere Server das Ergebnis des PHP bereits sendete, noch während das PHP arbeitete. Ich konnte also bereits die ersten Daten auf dem Browser sehen, als das PHP noch am rechnen war. Ist das normal?

Anregung zum Artikel: Man sollte auf jeden Fall im Artikel eine verständliche Erklärung hinzufügen, dass das Ergebnis eines PHP's in Normalfall erst dann zu sehen ist, wenn das PHP abgearbeitet ist. Mit dem Hinweis natürlich, dass es auch Server gibt, die das Ergebnis bereits senden, noch während das PHP läuft. --Sassenburger (Diskussion) 20:52, 23. Mär. 2014 (CET)

So wie ich das einschätze, gibt der PHP Interpreter Stück für Stück die Ausgabe zurück. Sobald er (z. B. via echo) etwas ausgeben soll, gibt er das aus und leitet diese Ausgabe bereits an den Benutzer weiter.

Verwendest Du nun einen PHP-Buffer und speicherst die Ausgabe zwischen, wird erst mit dem Leeren bzw. Ausgeben des Buffers der gesamte Inhalt ausgegeben. Da zwischen den einzelnen Ausgaben dann kein Code mehr "liegt", sondern davor ausgeführt wird, kommt Dir das vermutlich langsamer vor. Erklärt das deine Frage? -- Blauvogel101 (Diskussion) 10:55, 8. Jul. 2014 (CEST)

Nein, das scheint anders zu sein. Der schnelle Server scheint in der Tat immer bei einem Leerzeichen zu senden. Beim normalen Server kommt die Antwort auch trotz Leerzeichen immer erst dann, wenn das PHP komplett fertig ist.

Vergleiche:

schneller Server mit Echtzeitantwort

normaler Server

Bei beiden Beispielen mehrmals auf aktualisieren klicken. Beim ersten Aufruf ist noch kein Unterschied zu sehen.

<?php

function zeit() {

$zeit = time();

echo date("G:i:s",$zeit),"
\n";

}

function variable() {

$text = $text;

}

$bis = 1000;

$bis = $bis * $bis * 4;

$text = "Test";

echo "Wiederholungen: $bis
\n";

echo "
\n";

// ---- GOSUB ----

echo "GOSUB:
\n";

echo " Start: ";

zeit();

$x = 0;

gosubschleife:

$x = $x + 1;

goto gosubaktion;

gosubzurueck:

if ( $x <= $bis )

{

goto gosubschleife;

}

goto gosubende;

gosubaktion:

$text = $text;

goto gosubzurueck;

gosubende:

echo "Ende: ";

zeit();

echo "
\n";

// ---- FUNKTION ----

echo "FUNKTION:
\n";

echo " Start: ";

zeit();

$x = 0;

funktionschleife:

$x = $x + 1;

if ( $x <= $bis )

{

variable();

goto funktionschleife;

}

echo "Ende: ";

zeit();

?>

--Sassenburger (Diskussion) 12:48, 8. Jul. 2014 (CEST)

Ich selbst kann auch nach mehrfachen Tests dieses Phänomen bei mir nicht beobachten. Beide senden erst, wenn sie fertig sind. Gut, wenn es bei dir anders, solltest Du dir mal die Konfiguration angucken: FastCGI? Accelerator aktiv? Andere Zusatzmodule? -- Blauvogel101 (Diskussion) 14:31, 8. Jul. 2014 (CEST)

Ich habe eben beide Links mal mit Firefox, Opera und Safari getestet. Hier kommt in der Tat auch beim schnellen Server alles auf einmal. Den von mir beschriebene Zustand, hatte ich mit dem "Microsoft Internet Explorer" festgestellt. Vielleicht ist das eine besondere Situation, die nur dann zustande kommt, wenn man den schnellen Server mit dem "Microsoft Internet Explorer" besucht?

"FastCGI", "Accelerator" und "Zusatzmodule" sagen mir nichts. Alles ist so, wie es im Paket der beiden Provider (Strato und Loomes) vorhanden ist. Ich lade nur die PHP's hoch und kann scheinbar die Ausführung nicht weiter beeinflussen. --Sassenburger (Diskussion) 14:46, 8. Jul. 2014 (CEST)

Das würde mich bei dem Internet-Explorer nicht wundern. Wenn es unter anderen Browsern nicht reproduzierbar ist, dann können wir den Artikel je so belassen. Bzw. die Grafik schließt ja auch eine Ausgabe "stückweise" nicht aus, sodass sie den Vorgang angemessen visualisiert. -- Blauvogel101 (Diskussion) 15:23, 8. Jul. 2014 (CEST)

Ok --Sassenburger (Diskussion) 15:39, 8. Jul. 2014 (CEST)

Die grundsätzliche Arbeitsweise von PHP ist, dass die Ausgabe eines PHP-Skripts zunächst gepuffert und nach Abschluss der Berechnung an die nächst höhere Ebene (i. d. R. der Webserver) weitergereicht wird. Dieses Standardverhalten von PHP lässt sich mittels der Ausgabekontrolle an die eigenen Bedürfnisse anpassen. So ist es möglich, die Weitergabe des Ausgaepuffers per flush() manuell anzustoßen oder dies mit ob_implicit_flush() implizit mit jeder Ausgabe erzeugenden Funktion (z. B. print()) zu tun. Dabei ist zu beachten, dass die nächst höhere Ebene abweichende Routinen besitzen kann wann die Ausgabe tatsächlich an den Client/Browser gesendet wird. Bspw. bei der Verwendung des Apache-Moduls mod_gzip wird die Ausgabe in jedem Fall zunächst vollständig gepuffert und erst dann an den Client/Browser gesendet. Je nach Konfiguration des Webservers und von PHP kann sich das Verhalten so von Webserver zu Webserver unterscheiden. Bei reiner Betrachtung von PHP und dessen Standardkonfiguration ist der Artikel aber vollkommen korrekt.

Übrigens: Die Wikipedia ist kein Forum. Bitte beschränkt euch auf Diskussionen zum Artikel. Für Fragen könnt ihr euch an WP:Auskunft wenden. --Vanger ^!–!? 17:16, 8. Jul. 2014 (CEST)

Es ging ja um den Artikel, weil ich vermutet hatte, dass man etwas ergänzen muss. --Sassenburger (Diskussion) 17:37, 8. Jul. 2014 (CEST)

Kritik an älteren Versionen

Ich finde man sollte die Kritik zu älteren PHP-Versionen entfernen, da diese Probleme prinzipiell gelöst sind. Wer die entsprechende Probleme mit PHP kann diese durch ein Update einfach lösen. Das Ganze muss aber nicht in einer Enzyklopädie dokumentiert werden. (nicht signierter Beitrag von 93.221.122.63 (Diskussion) 16:55, 20. Jul 2014 (CEST))

Ich bin ebenfalls der Meinung. Anyone else? --Nightfly | _Disk 20:52, 12. Sep. 2014 (CEST)

Ich finde, die Kritik an älteren Versionen kann im Abschnitt Geschichte zu den jeweiligen Versionen geschrieben werden, damit lässt sich dann die Geschichte ein wenig besser verfolgen. Im Abschnitt Kritik gehért jedoch nur Kritik zur aktuellen Version rein. --Sevku (Diskussion) 10:21, 13. Sep. 2014 (CEST)

Zustimmung. --Sassenburger (Diskussion) 12:06, 13. Sep. 2014 (CEST)

Verbreitung

Das kann so absolut nicht stehen bleiben. Die Formulierung ist inkorrekt und die Fakten sind auch fragwürdig. Buildwith gibt völlig andere Zahlen her. Eine einzige Quelle ist längst nicht repräsentativ. Der Satz "PHP ist die am häufigsten verwendete Programmiersprache zum Erstellen von Websites." ist unglücklich formuliert. Dieser Abschnitt ist veraltet und muss aktualisiert werden. (nicht signierter Beitrag von Fresh0razoR (Diskussion | Beiträge) 13:38, 11. Jan. 2017 (CET))

Beeinflusst von

Bitte um Belege, dass PHP von Perl, C/C++, Java beeinflusst wurde. Gerade bei C++ & Java sehe ich keine Gemeinsamkeiten --Sebastian.Dietrich ✉ 13:31, 28. Jan. 2015 (CET)

Code in HTML

Ich vermisse im Abschnitt Kritik ein Grundproblem von PHP. Nämlich, dass PHP-Code innerhalb von HTML- Dokumenten steht. Ich halte diese systemimmanente Fehlerquelle für kritisierenswert. Warum steht da nichts im Artikel? Sollte das Sinn machen, soll ich dann einen Vorschlag zur Ergänzung machen? (Wollte lieber vorher fragen, wäre recht neu hier) Kalle Schmidt (nicht signierter Beitrag von 93.215.34.250 (Diskussion) 22:06, 10. Sep. 2015 (CEST))

Ich verstehe nicht, was daran ein Problem sein soll. Bitte näher erläutern. --Saliwo (Diskussion) 11:26, 4. Dez. 2015 (CET)

Die Formulierung "PHP-Code [steht] innerhalb von HTML-Dokumenten" ist ja wohl auch eher irreführend und beschreibt nur das äußere Erscheinungsbild des PHP-Sourcecodes. Technisch kann man es auch so sehen, dass HTML-Code innerhalb des PHP-Sourcecodes steht und in diesem Sinne einfach ein Bestandteil der PHP-Programmierung darstellt. Inwiefern das zu kritisieren wäre, erschließt sich mir auch nicht. Es ist einfach nur ein sehr pragmatischer Syntax. --92.213.11.156 12:19, 18. Okt. 2016 (CEST)

Änderung im Abschnitt Code-Beispiel

Im o.g. Abschnitt wurde das abschließende "?>" Tag entfernt, weil eine Webseite behauptet, dass in ein Script, dass nur aus PHP-Code besteht, ein solches nicht enthalten darf. Ich bin der Meinung, dass das imho nicht stimmt. Ein abschließendes Tag stört auch in einem ausschließlich auf PHP basierenden Script nicht. Im Gegenteil: Ich finde es falsch, das abschließende Tag zu entfernen, denn ein Anfänger würde in einem HTML-Element der aus mehreren PHP Abschnitten besteht, auf diese Art und Weise nur Parse-Errors erhalten. Oder was sagt ihr? Wenn nichts gegenteiliges kommt, werde ich in ein paar Tagen das "?>" wieder einfügen. --Saliwo (Diskussion) 11:30, 4. Dez. 2015 (CET)

Dass das abschließende PHP-Tag nicht enthalten sein darf stimmt für den PSR-2-Standard. In meinem eigenen Code lasse ich den schließenden Tag auch weg. Aber das heißt ja nichts. Wo stehen soll, dass Wikipedia diesen Standard in Beispielen verwenden müsste, erschließt sich mir auch nicht, noch dazu, wenn - so wie du das ausführst - es mit abschließendem Tag in diesem Fall sinnvoller ist. Wenn du das korrigierst, kannst du vll. auch direkt die fehlende Einrückung der Codezeile ergänzen. --88.130.88.113 13:09, 9. Dez. 2015 (CET)

Es kommt auf die Definition an. Wann funktioniert ein Script, wann funktioniert es nicht. PSR-2 ist lediglich eine Definition, mehr nicht. PHP an sich, funktioniert selbstverständlich mit einem abschließenden "?>"-Tag. Entsprechend füge ich das nun wieder ein. --Saliwo (Diskussion) 20:04, 9. Dez. 2015 (CET)

Ein Hinweis dazu findet sich im Manual:Der schließende Tag eines PHP-Blocks am Ende einer Datei ist optional, und in einigen Fällen ist das Weglassen hilfreich, wenn Sie include oder require verwenden, so dass ungewollte Whitespaces nicht am Ende einer Datei auftreten und Sie noch im Stande sind, später weitere Header an die Response hinzuzufügen. Es ist ebenfalls praktisch, wenn Sie Output Buffering verwenden und keine ungewollten Whitespaces am Ende eines durch die eingebundenen Dateien erzeugten Parts sehen wollen. Aber aus gewohnheit mache ich die abschließenden "?>"-Tags dennoch. Gruß --Lrwx------ (Diskussion) 23:03, 9. Dez. 2015 (CET)

Ein anderer Aspekt ist auch die Benutzerbarkeit. Je nachdem, wer die Dateien mit dem PHP-Code drin bearbeitet, ist es oft sinnvoll, diese Dateien sehr ...dau-sicher zu machen. Ich seh oft genug Support-Anfragen, in denen der Benutzer Code wie er sollte in einer PHP-Datei eingefügt hat - nur leider hinter dem abschließenden PHP-Tag. Dieses Problem hat man definitiv nicht, wenn so ein Tag gar nicht erst drinsteht. Mit dem hier gewählten Beispiel hat das freilich erstmal nicht viel zu tun. --88.130.123.15 00:12, 10. Dez. 2015 (CET)

Dieses Problem hat man auch nicht, wenn man, sobald man PHP-Code in ein HTML-Dokument einfügt, mit "<?php" einleitet und danach mit "?>" ausleitet. So habe ich es gelernt und funktioniert einfach.--Saliwo (Diskussion) 08:53, 10. Dez. 2015 (CET)

Kein abschließendes ?> ist nicht nur in PSR2 vorgeschrieben (PSR = relevant, weil quasi aller aktueller Code darauf aufbaut, speziell in Verbindung mit Autoloading/Composer), sondern wird von jedem ernsthaften Entwickler so gemacht (solange er nicht vor 10 Jahren Alzheimer bekommen hat), siehe u.a. Drupal, Zend 1 (Zend 3 ist PSR-kompatibel) oder auch offizielle PHP-Projekte. Es gibt nur noch vereinzelte Projekte, die das nicht so handhaben, abe die kann man an einer Hand abzählen und sind bekannt für ihren schlechten Code (bspw. Wordpress) oder dafür, dass sich seit zehn Jahren keiner mehr dafür interessiert (PEAR). Abgesehen davon ist Code und HTML mischen eh noch mal eine ganz andere Sache, die man heute eigentlich auch nicht mehr sieht bzw. tunlichst auch keinem Anfänger zeigen sollte. Meiner Meinung nach sollte man das Beispiel aus dem Artikel verbannen oder zumindest drastisch kürzen und mit Warnung versehen. --21:13, 24. Okt. 2016 (CEST) (ohne Benutzername signierter Beitrag von 185.76.98.8 (Diskussion))

Backronym

Bevor sich ein Editwar einstellt: Ich finde, dass es sich bei "PHP" um kein Backronym handelt, da, wie die Einleitung bei Backronym schon sagt, es sich dabei um ein Wort handelt. Und PHP ist imho kein Wort, sondern eine Abkürzung. --Saliwo (Diskussion) 20:14, 18. Dez. 2015 (CET)

Sehr schön mal wieder auf jemanden zutreffen der die Netiquette einhalten kann, vielen Dank dafür.

Ich lehne mich mal aus dem Fenster und behaupte du scheinst damit einverstanden zu sein, dass es ein "rekursives Akronym" ist. Ein Akronym ist aber auch ein Wort, wie du hier nachschauen kannst. Außerdem vertraue ich in diesem besonderen Fall dem Englischen Artikel in dem ebenfalls ausdrücklich von "Backronym" die Rede ist und finde es deswegen durchaus angebracht dies hier zu verwenden. MfG --Dnepro.. (schnaken?) 21:00, 18. Dez. 2015 (CET)

Zunächst vielen Dank für dein Lob. Ich bin mir halt nicht sicher, deswegen meinte ich "imho". Programmieren kann ich, aber mit der Deutschen Sprache in all ihren tieferen Facetten hapert es manchmal. Wenn PHP zunächst nur eine Abkürzung ist, aber kein Wort, wird es dann ein Wort, wenn es ein rekursives Akronym ist? Oder dreht man sich da im Kreis? Vielleicht liegt es auch nur daran, dass es sich bei "PHP", "Backronym" und "Akronym" um fremdsprachige Begriffe handelt, die man sowieso niemals zu 100 % korrekt in die deutsche Sprache integrieren kann.--Saliwo (Diskussion) 22:11, 18. Dez. 2015 (CET)

Ja bitte. Genau dafür diese Diskussion. Also sobald ich den Artikel Wort und insbesondere Wort#Charakterisierung richtig verstehe ist "Wort" ein sehr schwer zu definierender Begriff. Aber es ist grundsätzlich eine "Zeichenkette mit Bedeutung", die "durch Trennzeichen (Leerzeichen, Punkte und Kommas) getrennt werden". Insofern hätte ich kein Problem bei "PHP" von einem Wort zu sprechen. Meiner Auffassungen waren Akronyme immer eine Form der Abkürzungen, aber nicht alle Abkürzungen sind Wörter (vergleiche "z.B.") aber alle Akronyme können als Wörter angesehen werden. Nein, diese Wörter sind gut in die deutsche Sprache integrierbar, da sie sprachwissenschaftliche Konzepte behandeln. Backronym ist eine besonderheit des Akronyms, bei der ein Wort wie "PHP" - ("Personal Home Page Tools") nachträglich uminterpretiert wird, PHP ("PHP: Hypertext Preprocessor") und es ist ein rekursives Akronym da es sich selbst als Teil des Akronyms einschließt (siehe auch YAML). MfG --Dnepro.. (schnaken?) 12:14, 19. Dez. 2015 (CET)