Diskussion:PHP/Archiv

message: 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)
thread_title:  Verbreitete PHP-Applikationen 

message: * 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)
thread_title:  Anmerkung und Fragen 

message: 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)
replies: text: 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)
replies: text: Ä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)
thread_title:  ISBN-Links 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  dynamisch? 

message: Mambo / Joomla! und PostNuke – PortalSoftware
Täusche ich mich, oder sind das nicht auch Content Management Systeme? --Alti 14:13, 28. Apr. 2007 (CEST)
replies: text: 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 --Dachrisblubber 14:37, 28. Apr. 2007 (CEST)
replies: text:  Na gut, Einverstanden --Alti 17:15, 28. Apr. 2007 (CEST)
thread_title:  Verbreitete PHP-Applikationen: Portalsoftware 

message: 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)
replies: text: 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)

text: 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)
replies: text: 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)
thread_title:  OOP 

message: 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)
thread_title:  Interpretiert oder kompiliert 

message: 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)
thread_title:  Einleitung 

message: 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)
thread_title:  PHP5 

message: 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)
thread_title:  Objektorientierter Ansatz 

message: 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)
thread_title:  D.A.N.K.E. 

message: 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)
thread_title:  Grafikerzeugung statt GTK im ersten Abschnitt erwähnt 

message: 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)
thread_title:  Performancegewinn von einigen hundert Prozent 

message: "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)
thread_title:  Zend Engine 1, ein "Herz" für PHP? 

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

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

message: Habe hier mal zwei Links angehängt, die den Einstieg für Anfänger erleichtern wollen:
*Design Nation - PHP lernen (Tutorials)<BR>
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<BR>
Hier eine deutschsprachige PHP Wiki. Ist aber noch im Wachsen..:-)Joli Tambour 15:24, 30. Jan. 2008 (CET)
thread_title:  PHP-Tutorials 

message: > 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)
thread_title:  Nicht ganz korrekte Aussage 

message: 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)
thread_title:  Implizite Deklaration von Variablen 

message: 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)
replies: text: 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)
thread_title:  Zeitschriften 

message: 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)
replies: text: 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)

text: 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)
replies: text:  dann muss ich mich auch mal bedanken ;-) danke :-) --Dutch damager 19:42, 22. Dez. 2007 (CET)
thread_title:  Mängel 

message: 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)
replies: text: Ganz einfach es macht keinen Sinn wenn Anwender (und das sind Nutzer in einem Livesystem) irgendwelche Fehlermeldungen des Systems lesen.Sommerville, Ian (2005): Software Engineering Erstens hat man so Schwachpunkte welche ausgenutzt werden können und 2.tens gibt man einen Einblick in das System.Stallings (2006): Network SecurityPHPGroup 2007: Error logging 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...Sommerville, Ian (2005): Software EngineeringBalzert (2004): Software Technik 1 + 2)...Aber das ist ein anderes Thema --Bitsandbytes 11:36, 27. Dez. 2007 (CET)
replies: text:  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)
replies: text: 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)
replies: text:  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)
replies: text: 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)
replies: text:  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)
replies: text: Habs eingefügt --Bitsandbytes 12:16, 27. Dez. 2007 (CET)
thread_title:  Zum Thema E_NOTICE und Programmierer 

message: 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)
replies: text: 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)
replies: text:  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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Maintainers 

message: sollte man nicht auch erwähnen, dass Wiki in PHP geschrieben ist?  --Rudi 14:21, 11. Feb. 2008 (CET)
replies: text: Hi, steht bereits im Artikel unter PHP#Verbreitete_PHP-Applikationen. --Rudi 14:21, 11. Feb. 2008 (CET)
thread_title:  Wiki <-> PHP 

message: 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)
replies: text:  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)
thread_title:  Zu den Einzeländerungen 

message: Schreibfehler in "Geschichte" korrigiert.
: kann archiviert werden --Tobiask 16:15, 20. Mai 2008 (CEST)
thread_title:  Lerndorf -> Lerdorf 

message: 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)
thread_title:  Toter Link 

message: 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)
thread_title:  Deutsches Handbuch 

message: 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)
replies: text: 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)
thread_title:  Performance - "Shootout" -> unklare Formulierung 

message: 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)
replies: text: 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)
thread_title:  Geschichte - Widerspruch bei OOP 

message: Seit wann beherscht PHP denn Ducktyping? Wäre mir neu!
:Wo steht denn was davon? --Rohieb 会話 +/- 23:08, 9. Jan. 2009 (CET)
replies: text: 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)
thread_title:  Ducktyping 

message: Am 24. März 2009 wurde PHP 5.3.0 Released.
Man sollte evtl. die Versionstabelle aktualisieren und diese PHP-Version als aktuelle aufnehmen.
[]
--79.230.110.199 14:15, 31. Mär. 2009 (CEST)
replies: text: 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)
thread_title:  PHP 5.3.0 RC1 

message: 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)
thread_title:  Überladung 

message: 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. 
: 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)
replies: text: Richtig. WP ist schließlich auch nicht da, um irgendwelche Mutmaßungen oder Verschwörungstheorien zu verbreiten. -- net 09:34, 30. Apr. 2009 (CEST)
replies: text: 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)
thread_title:  Sicherheit 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text:  Lieber Snapper, bist du mit dem jetzigen Link einverstanden? Grüße, --Timohummel 17:33, 19. Mai 2009 (CEST)
thread_title:  Zum Thema "Datenpaket" oder nicht 

message: 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)
thread_title:  Überarbeitung des Artikels / Reihenfolge 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text:  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)
replies: text:  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)
thread_title:  Unterstützung von PHP 5.3 

message: 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)
replies: text: Das hab ich mich auch gefragt. Sollte geändert werden. -88.130.75.186 14:16, 15. Jul. 2010 (CEST)
replies: text:  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)
thread_title:  Allgemeines -> Vorteile der serverseitigen Ausführung? 

message: 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)
replies: text: Ich habe das in den Satz mit dem PHP-GTK eingebaut - Hoo man (Diskussion) 12:58, 20. Feb. 2011 (CET)
thread_title:  PHP-Qt 

message: Bereits am Artikelanfang fehlt die Differenzierung:
</br>- "PHP ist eine Skriptsprache"
</br>- "PHP wird als freie Software unter der PHP-Lizenz verbreitet"
Unter Funktionsweise findet man dann:
</br>- "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:
</br>- "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:
</br>- "Da PHP normalerweise in einer Webserver-Umgebung läuft, unterliegt es auch dem zustandslosen HTTP."
Die Aussage ist in mehrerer Hinsicht problematisch:
</br>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.
</br>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:
</br>- gibt es eine Standardisierung ?
</br>- wer spezifiziert PHP ?, Zend Techn. alleine ?
</br>- Spracheigenschaften, -Paradigmen ?
</br>- gibt es Übersetzer in andere Sprachen ?
</br>- welche Compiler gibts ?, und für welche Zielplattformen ?
</br>- 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)
thread_title:  Bitte zwischen Sprache, Laufzeitsystem und Architektur unterscheiden: 

message: 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)
replies: text: 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)

text: 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)
thread_title:  Verbreitung von PHP 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  PHP auf Mac OS X 

message: 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)
thread_title:  Maintainer PHP > 5.3 

message: "PHTML" leitet auf PHP weiter, es wird aber nicht darauf eingegangen. Bitte um Ergänzung. --Seth Cohen 23:35, 18. Okt. 2011 (CEST)
replies: text: 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)
replies: text: Die Weiterleitung ist inzwischen gelöscht. --Baumfreund-FFM (Diskussion) 23:12, 5. Dez. 2012 (CET)
thread_title:  PHTML 

message: 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)
thread_title:  Implementierungen 

message: 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)
thread_title:  PHP funktionsweise.svg 

message: 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)
replies: text: Die letzte Version ist vom Januar 2012. Es geht also weiter. Gruß --kgh (Diskussion) 17:27, 21. Aug. 2012 (CEST)
thread_title:  Suhosin 

message: 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)
replies: text: Das hättest du auch einfach selbst anpassen können. ;-) Erledigt. --88.130.112.223 14:08, 29. Jun. 2013 (CEST)
thread_title:  integrierter Bytecode-Cach in PHP 5.5 

message: 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  13:46, 4. Sep. 2013 (CEST)
replies: text: 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)
replies: text: 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  15:24, 4. Sep. 2013 (CEST)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  XAMPP 

message: "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)
thread_title:  Threading in PHP 

message: 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)
replies: text: Ich bin ebenfalls der Meinung. Anyone else? --Nightfly | Disk 20:52, 12. Sep. 2014 (CEST)

text: 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)
replies: text: Zustimmung. --Sassenburger (Diskussion) 12:06, 13. Sep. 2014 (CEST)
thread_title:  Kritik an älteren Versionen 

message: 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)
thread_title:  Verbreitung 

message: 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)
thread_title:  Beeinflusst von 

message: 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)
replies: text: Ich verstehe nicht, was daran ein Problem sein soll. Bitte näher erläutern. --Saliwo (Diskussion) 11:26, 4. Dez. 2015 (CET)

text: 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)
thread_title:  Code in HTML 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
thread_title:  Änderung im Abschnitt Code-Beispiel