PHP Eine Seite mit mehreren Inhalten

[Daaron]

Der Unterschied ist, dass man include nur verwenden soll, wenn in dem einzubindenden "Text" wiederum php-Code drinsteckt. Wenn nicht, nimmt man file_get_contents, weil es schneller ist.

Gerade diese Erweiterbarkeit macht aber den Vorteil von Include aus. Geschwindigkeit spielt hier gar keine Rolle, sondern ausschließlich Funktionalität und Flexibilität.

PHP war da und man hat einen Weg gefunden, weiter darauf zu setzen.

Wenn die Ruby-Trolle Recht hätten, dann hätte FB ja von 0 an auf Ruby setzen können...

Und was sagt das jetzt aus? Firmen versuchen Lösungen für ihre Bedürfnisse zu finden. Wer mit PHP klar kommt, so be it!

Eben... und es kommen weit mehr Menschen (und Firmen) mit PHP klar als mit diesen ganzen Hipster-Sprachen. Im mitteleuropäischen Wirtschaftsraum haben Ruby, Perl und Python im Web gar keine Bedeutung. Da ist sogar ASP.NET noch deutlich wichtiger. Am Ende läuft es quasi immer auf PHP hinaus....
Und weil PHP so weit verbreitet ist, gibt es auch entsprechend umfangreiche Dokumentationen und Forenbeiträge. Was wiederum dafür sorgt, dass PHP sich weiter verbreitet. PHP mag Schwächen haben, aber die schiere Menge an Anwendungen und Entwicklern sorgt dafür, dass es trotzdem die bessere Wahl ist.

 

[Tuxman]

Also arbeiten bei Facebook nur Vollpfosten?

Ja, aber das hat nix mit PHP zu tun.

 

[Rossie]

Wenn die Ruby-Trolle Recht hätten, dann hätte FB ja von 0 an auf Ruby setzen können...

Ruby on Rails war damals wohl noch zu neu. Ansonsten hätte Facebook vielleicht ähnliche Erfahrungen gemacht wie Twitter. Die haben sich ja auch einen eigenen Garbage Collector geschrieben, um die Performance-Ziele zu erreichen, aber irgendwann die Vorteile von statisch typisierten Sprachen erkannt und das Backend weitgehend migriert.

 

[Tuxman]

Übrigens beherrscht auch PHP statische Typisierung.

 

[Rossie]

Übrigens beherrscht auch PHP statische Typisierung.

Von welchem PHP sprichst Du?

 

[Tuxman]

Es gibt nur eines.

 

[Rossie]

Dann muss ich was verpasst haben. Seit wann kann PHP statische Typisierung?

Ergänzung (15. September 2013)

Es gibt nur eines.

Was übrigens nicht korrekt ist

 

[F_GXdx]

na dann solltest du dich von Facebook anstellen lassen und den Vollidioten zeigen, wie es richtig geht.

No way, dann werden sie ja erst richtig erfolgreich. Nene, ich häng lieber hier mit Hartz IV ab und bin glücklich

Für meine programming skillz ist die Welt noch nicht bereit.

 

[Daaron]

tja, siehste... Wenn du statt dessen PHP sprechen würdest, könntest du zwischen den Jobs wählen.

 

[F_GXdx]

Naja, eines Tages mache ich meinen Hauptschulabschluss nach und lerne PHP, dann gehts ab. Oder bin ich dann schon überqualifiziert im Vergleich zu anderen PHP-Programmierern?

Ne, im Ernst, der TE soll halt mal schreiben, wofür er sich jetzt entschieden hat. XAMPP ist auch schnell installiert, dann kann er auch mit einer DB mal rumfuhrwerken.

 

[rephluX]

Hach, bestimmte Dinge wiederholen sich irgendwie immer ;-)

Entweder, der Vorschlag, immer direkt ein CMS zu verwenden. Bringt natürlich absolut keinen Overhead mit und ist auch sehr sicher. Oder aber die immer gleiche Diskussion, welche Programmiersprache nun besser ist. Oder anders formuliert: Welche Sprachen alle besser sind als PHP. Aus diesem Grund gibts ja auch massig Stellenanzeigen für Ruby/Rails-Entwickler.

 

[Daaron]

Entweder, der Vorschlag, immer direkt ein CMS zu verwenden. Bringt natürlich absolut keinen Overhead mit und ist auch sehr sicher.

Der Overhead ist zu vernachlässigen. Die guten CMS erstellen Cache-Files, durch die weitestgehend statische Ressourcen ausgeliefert werden können. Wenn das CMS dann noch einen guten Autoloader hat und insgesamt gut geschrieben wurde, ist es trotz seiner Komplexität immer noch pfeilschnell.

Und was die Sicherheit angeht: Ein gutes CMS ist trotz seiner Komplexität immer noch deutlich sicherer als eine von einem Laien dahingeschluderte Bastellösung. Spätestens wenn Laien mal mit einer Datenbank reden müssen, z.B. bei der Suche, wars das. Da haste fast immer direkt die Injection-Lücken.

 

[carom]

Übrigens beherrscht auch PHP statische Typisierung.

Sehr interessant

 

[rephluX]

Der Overhead ist zu vernachlässigen. Die guten CMS erstellen Cache-Files, durch die weitestgehend statische Ressourcen ausgeliefert werden können. Wenn das CMS dann noch einen guten Autoloader hat und insgesamt gut geschrieben wurde, ist es trotz seiner Komplexität immer noch pfeilschnell.

Und was die Sicherheit angeht: Ein gutes CMS ist trotz seiner Komplexität immer noch deutlich sicherer als eine von einem Laien dahingeschluderte Bastellösung. Spätestens wenn Laien mal mit einer Datenbank reden müssen, z.B. bei der Suche, wars das. Da haste fast immer direkt die Injection-Lücken.

Ich will Dir da gar nicht groß widersprechen. Stimmt alles was Du schreibst. Aber: Im aktuellen Beispiel gehts gar nicht um DBs. Und auch nicht um Caching-Mechanismen. Warum dann einem "Laien" direkt ein CMS vor die Füße werfen, wo er a) gar nix mit lernt (sofern er das natürlich will) und b) wohl auch überfordert mit ist? Mir gehts eher um die Verallgemeinerung vieler Fragen. "Ich will xyz in PHP machen, wie geht das? - Blabla, NIMM AUF JEDENFALL EIN CMS!"

Für viele ist als CMS immer die Superduper-Lösung für alles, ohne überhaupt zu wissen, was genau umgesetzt werden soll. Und ja, natürlich kann man mit einem CMS alles schön schnell ändern. Aber braucht der TE das? Weiß man nicht

 

[F_GXdx]

Naja man lernt nix mit einem CMS würd ich nicht sagen. Ich hab meine PHP-Kenntnisse fast ausschließlich erworben, indem ich ein Template für Wordpress gebaut habe und dabei gegen die Wordpress API gearbeitet habe. Das macht einen nicht zum Experten, aber es macht Spaß und man schafft was.

Auf jeden Fall besser als Typo3 mit seinem Typoscript Blödsinn.

 

[Daaron]

...gegen die Wordpress-API kann man nicht arbeiten, da kann man nur kämpfen. Ich weiß nicht, ob ich dich für deine Taten achten oder bemitleiden soll.
Und ja, TypoScript ist totaler Schwachsinn. TS existiert glaub ich nur zur Kundenbindung. So nach dem Motto: Damit unser neuer Entwickler mit T3 arbeiten kann, müssen wir ihn für n paar hundert € in einen T3-Kurs schicken... Oh, jetzt haben wir hunderte Euro investiert, jetzt müssen wir für jeden Furz TYPO3 benutzen.... So. Jetzt hat der alles mit T3 gemacht, verlässt aber die Firma. Damit unser neuer Entwickler die alten Seiten pflegen und erweitern kann, müssen wir ihn für ein paar hundert Euro in einen Kurs schicken....

Meiner Erfahrung nach wollen die meisten Leute nichts tiefgreifendes lernen. Sie wollen nur wissen, was sie zum Ziel führt: Ne Webseite, die leidlich einfach zu administrieren und erweitern ist.... und hier ist es eben deutlich einfacher, einfach ein CMS auf das Problem zu werfen jede Kleinigkeit haarklein zu erklären. Heute isses die Unkenntnis der Funktionsweise von include/require (und dem jeweiligen _once), beim nächsten Mal soll eine ganz einfache Datenbankverbindung aufgebaut werden. Danach sind Umlaute auf einmal komisch... als nächstes sollen Inhalte "wie in Word" gepflegt werden. Es soll eine Möglichkeit geben, dass jemand anderes auch mal Inhalte erweitert....

Willst du wirklich jeden User erst zum professionellen Webentwickler ausbilden, nur damit seine Frickel-Lösung nicht zu 90% aus Sicherheitslücken besteht? Da es viele gute, stabile und schnelle CMS auf dem Markt gibt, die teilweise absolut intuitiv sind oder wenigstens nur ne Woche leidlich intensive Einarbeitung für sehr ordentliche Ergebnisse erfordern, ist es einfach nicht der Mühe wert, eine Programmiersprache von Grund auf zu lernen.... nur um dann das zu können, was man mit 20 Klicks in einem CMS auch gemacht hätte.

 

[rephluX]

Willst du wirklich jeden User erst zum professionellen Webentwickler ausbilden, nur damit seine Frickel-Lösung nicht zu 90% aus Sicherheitslücken besteht?

Natürlich nicht. Hab ich auch nirgendwo behauptet.

Da es viele gute, stabile und schnelle CMS auf dem Markt gibt, die teilweise absolut intuitiv sind oder wenigstens nur ne Woche leidlich intensive Einarbeitung für sehr ordentliche Ergebnisse erfordern, ist es einfach nicht der Mühe wert, eine Programmiersprache von Grund auf zu lernen.... nur um dann das zu können, was man mit 20 Klicks in einem CMS auch gemacht hätte.

Vielleicht willst Du mich auch nicht verstehen

Ich wollte lediglich zum Ausdruck bringen, dass für viele oft der "Nimm auf jedenfall ein CMS"-Spruch eine Allgemeinlösung für jedes noch so kleines Problem darstellt. Ein sicherer Include ist mit ein paar wenigen Zeilen Code umgesetzt. Warum soll man sich dafür in ein CMS einarbeiten? Du musst mir jetzt nicht schon wieder die Vorteile eins CMS runterbeten. Aber im aktuellen Beispiel hat der TE doch nur nach einem Include gefragt. Natürlich kann man ihm nahelegen, vielleicht doch ein CMS zu verwenden. Aber für die Ausgangsfrage ist das meiner Meinung nach mit Kanonen auf Spatzen geschossen.

 

[Daaron]

Ich hab auch ursprünglich auf einen einfachen include-Ansatz hingewiesen. Selbiger hört dann aber ratzfatz auf wirklich toll zu sein, z.B. wenn es um "hübsche" URLs geht, um einen angepassten <head>, um effiziente Erweiterbarkeit,....

Wie ich schon sagte, die meisten Kunden bleiben nicht bei "4 Seiten + Galerie". Spätestens wenn ein einfaches Kontaktformular dazu soll (is ja eigentlich Standard) musst du dich mit dem PHP-Mailing, idealerweise über SMTP, beschäftigen, dazu musst du noch einen Sanitizer schreiben, damit dir böse Buben nicht die Seite zerballern. Machst du dir wirklich den Aufwand?