Der folgende Beitrag ist ein Gastbeitrag von Zachary Brady. Zachary nimmt uns mit auf eine Reise für Anfänger, um mit PHP einige Dinge zu erledigen, die wir Frontend-Entwickler manchmal tun müssen. Meiner Meinung nach macht uns diese Art von Dingen nicht zu Backend-Entwicklern, sondern zu ressourcenstärkeren Frontend-Entwicklern. Zachary konzentriert sich hier auch auf PHP, aber die gleichen Konzepte sind in jeder Backend-Sprache verfügbar.
PHP hat manchmal einen schlechten Ruf, doch es besteht fort und gedeiht nicht nur in einigen der beliebtesten CMSs, sondern auch in aufkommenden Strategien wie Responsive Design mit serverseitigen Komponenten (RESS). Ich habe festgestellt, dass das Einbringen einer kleinen Menge PHP in meinen Frontend-Entwicklungs-Workflow den Code stärkt und den Entwicklungsprozess beschleunigt.
Es ist weder sehr schwierig noch zeitaufwendig, genug Grundlagen von PHP zu erlernen, um es in Ihre Werkzeugkasten aufzunehmen. Lassen Sie uns gleich entdecken, wie das Mischen von serverseitigen Skripten in Ihre Frontend-Entwicklung sowohl einfach als auch lohnend sein kann.
Erste Schritte mit einigen PHP-Grundlagen
Wenn Sie sich mit den Grundlagen von PHP auskennen, springen Sie ruhig zum nächsten Teil. Für den Rest von uns kann es gut sein, sich ein wenig aufzufrischen.
Als serverseitige Sprache wird eine PHP-Datei (wie index.php oder myAwesomeCatPhotos.php) von Ihrem Server in HTML verarbeitet, bevor sie an den Browser gesendet wird. Aus diesem Grund **müssen** Sie Ihre PHP-Dateien auf einem Server hosten, während Sie mit ihnen arbeiten. Dies kann entweder ein Remote-Server oder ein lokaler Server sein, der sich auf Ihrem Computer befindet. Dies ist dank Software wie MAMP tatsächlich recht einfach einzurichten. (Ein Starter-Video gibt es hier auf CSS-Tricks).
Eines der großartigen Dinge an PHP ist, dass Sie es innerhalb einer PHP-Datei mit normalem HTML mischen können.
Die <?php und <? Tags definieren, wo Sie PHP in Ihrer Datei verwenden. **Profi-Tipp**: Wenn Ihre Seiten leer erscheinen, überprüfen Sie zuerst, ob Sie nicht irgendwo ein schließendes PHP-Tag vergessen haben. Die echo-Funktion gibt alles aus, was danach kommt, direkt in das Markup. In diesem Fall wird ein String mit den Worten „Hello World“ „ausgegeben“. In PHP ist das Beenden einer Anweisung mit einem Semikolon **zwingend erforderlich**; fehlende Semikolons sind eine weitere häufige Ursache für fehlschlagende Skripte. Dieses einfache PHP wird übersetzt in
<code>
<code>
Variablen in PHP können als $einWort, $vieleWorte, $sehrVieleZahlen, $a4 usw. geschrieben werden. Die wichtigste Zutat ist das **$** am Anfang des Variablennamens.
<code>
Mit Variablen könnten wir den vorherigen Code so schreiben
<code>
<code>
PHP hat auch for-Schleifen und if-Anweisungen. Eine if-Anweisung stellt eine Frage und führt eine Aufgabe aus, wenn die Frage wahr ist, und kann mit einer else-Anweisung gekoppelt werden, die eine Aufgabe ausführt, wenn die Frage falsch war.
<code>
<code>
Wenn $a gleich 7 ist, wird der erste String ausgegeben, aber wenn $a etwas albernes wie 5 ist, wird die zweite Anweisung ausgegeben.
<code>
Eine for-Schleife wird verwendet, um einen Codeblock zu wiederholen, solange eine bestimmte Bedingung erfüllt ist.
<code>
<code>
Dies besagt, dass wir eine Variable namens $d auf 0 setzen, dass wir den Wert von $d ausgeben, solange er kleiner als 7 ist, und dass wir $d am Ende jeder Iteration um eins erhöhen. Dies ergibt „0123456“.
<code>
Wir werden auch die Funktion include() verwenden, die den relativen Pfad einer anderen PHP-Datei nimmt, die durch den Pfad angegebene Datei findet und ihren Inhalt in die Datei einfügt, aus der sie aufgerufen wird.
<code>
Es gibt noch viel mehr zu PHP als das, aber diese Grundlagen werden uns durch den Rest des Artikels führen. Wenn Sie sich bei PHP noch etwas unsicher sind, empfehle ich, zuerst weiterzulesen und sich dann noch ein wenig aufzufrischen. Das Sehen dieser Konzepte im Kontext kann Ihnen helfen, sie besser zu verstehen.
<code>
Einfaches PHP-Templating
<code>
Sie werden feststellen, dass beim Erstellen Ihres Markups für jede Seite Ihres Projekts bestimmte Teile sich wiederholen. Die am häufigsten wiederholten Teile in einem Webprojekt sind der **Header** und der **Footer**.
<code>
Typischerweise müssten wir, wenn wir etwas im Header unserer Website ändern müssen, den Header manuell in jeder Datei unseres Projekts bearbeiten. Hier tritt PHP auf, um unsere Arbeit zu erleichtern. Mit PHP können wir das Markup für den Header unseres Projekts in einer eigenen Datei speichern und die Funktion include() verwenden, um den Code zu unseren Dateien hinzuzufügen. Wir können natürlich dasselbe mit dem Footer-Element und jedem anderen Schnipsel tun, den wir auf mehreren Seiten verwenden möchten.
<code>
<code>
In diesem Beispiel sind header.php und footer.php in einem Verzeichnis namens „includes“ gespeichert und werden jeweils in der Datei referenziert. Stellen Sie sich vor, wie viel Entwicklungszeit allein mit diesem Trick gespart werden kann.
<code>
Auslieferung unterschiedlicher Dateien je nach Seite
<code>
Ein Nachteil der Auslieferung desselben Headers und Footers auf jeder Seite ist, dass wir standardmäßig weniger Kontrolle darüber haben, welche Dateien für die verschiedenen Seiten ausgeliefert werden. Wir haben möglicherweise eine JavaScript-Datei für einen Bildschieberegler, die wir nur auf der Homepage benötigen, oder ein Skript für die Formularvalidierung auf der Kontaktseite. Glücklicherweise gibt es einen weiteren einfachen Trick, der uns dabei helfen kann.
<code>
Um diesen Trick auszuführen, muss ich zuerst den Namen der aktuellen Datei ermitteln und die Dateierweiterung davon entfernen.
<code>
<code>
Die erste Zeile ruft den Namen der Datei vom Server ab, während die zweite Zeile die Dateierweiterung davon entfernt (die zweite Zeile ist eher kosmetisch, um Ihren Code etwas sauberer zu machen, aber ich empfehle sie trotzdem). Ich pflege, diese Codezeile ganz oben in meine Dateien zu schreiben, noch bevor ich meinen <?php-Tag öffne; dies ermöglicht es mir, diese Daten für eine Vielzahl von Zwecken zu verwenden, wie z. B. die Generierung von Klassennamen.
<code>
Der zweite Teil dieses Tricks, die Entscheidung, welche Skripte für welche Seite ausgeliefert werden, kommt in den Footer vor dem schließenden Body-Tag. Wir verwenden eine Kombination aus if/else-Anweisung, um zu prüfen, ob die aktuelle Seite die **Kontaktseite** ist. Wenn es sich um eine solche handelt, wird ein Skript-Tag mit meinem contact.min.js-Datei ausgegeben, wenn nicht, geben wir die Datei global.min.js aus.
<code>
';
} else {
echo '<script src="js/global.min.js"></script>';
}
?>
Diese Technik kann mit jeder Art von externer Datei verwendet werden, die Sie einschließen möchten. Ich verwende sogar gerne Grunt, um mein JavaScript in seiten- oder abschnittsspezifische Dateien zu organisieren und dann diese Technik zu verwenden.
Ein wenig RESS kann viel bewirken
Wir können das obige Beispiel noch weiterführen und eine ähnliche Technik verwenden, um unterschiedliche Dateien je nach Gerätekontext bereitzustellen. Dies ist ein sehr einfaches Beispiel für eine RESS-Lösung. RESS, Responsive Design mit serverseitigen Komponenten, bedeutet einfach, dass Sie ein wenig serverseitige Logik in Ihr Responsive-Design-Toolkit einbauen, um fantastische Dinge zu tun, wie z. B. das Reduzieren des Seitengewichts.
Dafür benötigen wir eine PHP-Bibliothek namens Mobile Detect, die eine einfache Möglichkeit bietet, den Gerätetyp Ihrer Benutzer zu ermitteln. Fügen Sie die Bibliothek irgendwo in Ihr Projekt ein, ich lege sie gerne in ein Verzeichnis „scripts“ und verwende dann die Funktion require_once, um sie einzubinden. Sie müssen auch eine Instanz der Klasse Mobile_Detect initialisieren, was ich gerne direkt nach dem Include in meiner Header-Datei mache.
<code>
Nun kann ich im Footer ein if/else-Paar verwenden, um zu entscheiden, ob der Benutzer ein mobiles Gerät verwendet oder nicht, und die entsprechende JavaScript-Datei auszuliefern. **HINWEIS**: Da Mobile Detect Tablets als mobile Geräte betrachtet, überprüfe ich auch, ob das Gerät kein Tablet ist.
<code>
isMobile() && !$detect->isTablet()) {
echo '<script src="js/global-mobile.min.js"></script>';
} else{
echo '<script src="js/global.min.js"></script>';
}
?>
<code>
Mit dieser Technik können wir JavaScript erstellen, das besser für ein mobiles Erlebnis geeignet ist, und all das zusätzliche Seitengewicht vermeiden, das von großbildschirmbezogenem JavaScript stammen kann.
<code>
Automatische Markup-Muster
<code>
Sie stellen möglicherweise fest, dass Sie bestimmte Markup-Muster haben, die zwar nicht denselben Inhalt teilen, aber einander sehr ähnlich sind. Eine häufige Situation kann das Anzeigen einer Gruppe von Bildern sein, die zum selben Galerieobjekt gehören. Glücklicherweise zeigte Lara Schenck kürzlich eine solche Lösung in einem wunderbaren Vortrag, den sie auf der Smashing Conference NYC Jam Session hielt.
<code>
// Function to print images
function printGalleryItem($path, $alt) {
echo '
';
}
// Loop through image directory and printGalleryItem markup for each
function printGallery($dir, $alt) {
echo '
';
}
<code>
In PHP ist es, wie in anderen Sprachen auch, möglich, eigene benutzerdefinierte Funktionen zu erstellen, um die Wiederverwendung Ihres Codes zu erleichtern.
<code>
Die erste Funktion, printGalleryItem(), nimmt einen relativen Pfad zu einem Bild und Text für seinen Alt-Tag und gibt einen Bild-Tag mit einem Div-Container aus. Die zweite Funktion, printGallery(), nimmt den relativen Pfad zu einem Verzeichnis, das Bilder enthält, und einen String, der für die Alt-Tags der Bilder verwendet werden soll. Die Funktion gibt zuerst einen Container für die Galerie aus und verwendet dann eine Variante der for-Schleife namens foreach, um durch ein Array von Bildpfaden zu iterieren, die von der glob-Funktion abgerufen wurden, und sie auf unsere printGalleryItem()-Funktion anzuwenden. Die foreach-Funktion ist sehr nützlich, wenn Sie durch ein Array von Variablen iterieren und mit den Werten jedes einzelnen etwas tun müssen.
<code>
Es gibt einige fortgeschrittenere Konzepte, die ich in diesem Beispiel nur oberflächlich erwähne. Vorerst reicht es aus, zu verstehen, was diese Funktionen tun und wie sie bei Ihrer Produktion helfen können. Es wäre jedoch gut, sich auch die foreach- und glob-Funktionen anzusehen, wenn Sie die Gelegenheit dazu haben. Versuchen Sie, eigene Funktionen zu erstellen, um einige der redundanteren Aspekte Ihres Markups zu automatisieren.
<code>
Das ist nur die Spitze des Eisbergs
<code>
Es gibt eine ganze Welt von Möglichkeiten, was Sie mit ein wenig PHP in Ihrer Entwicklung tun können. Die meisten der nützlichsten Code-Schnipsel sind auch recht einfach zu verstehen, und je mehr Sie sich PHP aussetzen, desto einfacher wird es. Etwas Logik auf dem Server auszuführen, bevor eine Seite an den Browser gesendet wird, kann Ihnen Entwicklungszeit sparen, Ihrem Code mehr Robustheit verleihen und sogar Ihre Seiten leichter machen.
<code>
Die in diesem Artikel erwähnten Techniken sollten ein guter Ausgangspunkt für Sie sein, egal ob Sie neu in PHP sind oder nur neu in der Verwendung von PHP auf diese Weise. Ich empfehle dringend, natürlich noch ein wenig weiter zu graben und sich nie zu scheuen, zu experimentieren; kaputter Code kann immer repariert werden. Und hey, vielleicht stellen Sie am Ende fest, dass Sie PHP lieben.
Ich glaube nicht, dass PHP für Frontend-Aufgaben wie mobile Erkennung verwendet werden sollte. Dafür haben wir Media Queries. PHP mag für serverseitiges Tempting nützlich sein. Node.js könnte eine bessere Technologie sein, da es keine neue Sprache für Frontend-Entwickler ist und eine bessere Leistung bietet.
Ich stimme zu, alles, was die Seite je nach Gerät ändert, sollte im Frontend geschehen, sonst... Caching wird Sie durcheinander bringen. Wenn Sie ein mobiles Gerät erkennen und ein Server diese Antwort cacht, sehen alle Anfragen, die über diesen Server laufen, die mobile Version.
Man könnte argumentieren, dass die Geräterkennung eigentlich keine Rolle spielen sollte. Vielmehr sollten es Dinge wie Leistung, Bildschirmplatz und Funktionsunterstützung sein.
Eine serverseitige Sprache kann jedoch Inhalte manipulieren, bevor sie für den Client gerendert werden. Das bedeutet, Sie erhalten ein konsistentes Ergebnis, auch wenn der Benutzer kein JavaScript aktiviert hat, da Sie dies wahrscheinlich ohnehin verwenden würden, um zu manipulieren, wo Dinge auf dem Bildschirm erscheinen.
Ich würde jedoch gegen Node.js als bessere Technologie dafür argumentieren. Wir sprechen hier nicht über riesige Aufgaben, daher stelle ich mir keine Leistungsprobleme vor. Hosting-Unterstützung für Node ist möglicherweise nicht verfügbar – ich weiß, dass dies bei mir, wo ich arbeite, sicherlich der Fall ist. PHP ist für Dinge wie das Einbinden eines Headers und eines Footers, wie im Artikel gezeigt, ziemlich unkompliziert.
Für fast alle nicht-interaktiven Elemente sollten Sie wirklich versuchen, kein JavaScript zu verwenden, um sie zu positionieren. CSS kann die meisten Dinge handhaben.
Was Node.js betrifft, so kann man Hosting für 5–10 $/Monat bekommen. Die Arbeit mit JavaScript ist schneller als mit PHP, da man nicht zwei Sprachen auswendig lernen muss und Zugriff auf Dinge wie Handlebars hat. Wie Martin sagte, ist einfaches Templating mit PHP kein gutes Muster.
Das stimmt für einige Dinge. Aber beim lokalen Testen habe ich PHP verwendet, um im Grunde Bereiche zu entwerfen, die spezifisch für Mobilgeräte sind, und andere für Desktops.
// Prüfen, ob der Benutzer auf einem PHONE ist
if ( $detect -> isMobile( ) ) {
// Ein einfacher rein CSS-basierter Karussell mit kleinen Bildern
include(“simple-slider.php”); }
else{
// Ein Karussell mit großen Bildern
include(“fancy-slider.php”); }
Mobile Benutzer erhalten also ein sehr einfaches Karussell mit kleinen Bildern und ohne JavaScript. Desktop-Benutzer erhalten hingegen das mit allen Extras.
#FACEPALM
Wow. An serverseitiges Caching hatte ich nicht gedacht.
Nun, bisher war es kein Problem. Werde mich ändern, falls/wenn es eines wird.
Es könnte fair sein zu sagen, dass Sie hier persönliche Vorurteile walten lassen – klar, Node.js ist technisch JavaScript, aber die Konventionen sind völlig anders als die, die ein Frontend-Entwickler beim Interagieren mit einer Vielzahl von JS-Bibliotheken zur DOM-Manipulation und -Interaktion verwendet.
Dass Node.js „nur JavaScript“ ist, scheint ein fehlgeleitetes Verkaufsargument zu sein. Zu Ihrem späteren Punkt in der Diskussion – jeder Entwickler sollte mehr als eine Sprache lernen. Als jemand, der täglich mit PHP und JavaScript arbeitet, scheint die Behauptung, man müsse eine Sprache „auswendig lernen“, um sie nutzen zu können, etwas vermessen. Wer hat die Spezifikation für *irgendeine* Sprache auswendig gelernt? Dafür gibt es Dokumentation.
Nebenbei bemerkt, PHP hat Templating-Sprachen (ich weiß nicht, woher Sie etwas anderes gehört haben). Siehe Twig zum Beispiel, wie andere erwähnt haben.
Nur meine zwei Cent!
Das Googeln von Dingen wie „javascript indexof php equivalent“ verschwendet nur Zeit, die mit Node.js gespart werden könnte.
Ich habe nie gesagt, dass PHP keine Templating-Sprachen hat. Hogan (wie Mustache) ist gut, aber Handlebars.js ist besser.
Während Sie Media Queries und JS verwenden können, um bestehenden Inhalt zu ändern, stimme ich TJ zu, dass serverseitige Sprachen den Vorteil haben, Inhalte zu manipulieren und zu ändern, bevor sie die Client-Seite erreichen. Ich habe PHP-Mobile-Erkennung bei fast jeder Website verwendet, die ich gebaut habe, ohne größere Probleme.
Und was das Caching angeht, kann dies leicht gelöst werden, indem separate Caches für mobile und Desktop-Geräte erstellt werden. Für WordPress-Benutzer bietet W3 Total Cache eine einfache Option dafür: https://wordpress.org/plugins/w3-total-cache/
@Ben B,
Das W3-Plugin erstellt einen mobilen Cache, indem es UA-Strings analysiert. Es kann schwierig sein, mit den UA-Strings, die mobil sind/nicht mobil sind, auf dem neuesten Stand zu bleiben, was diese Methode der Cache-Steuerung unzuverlässig macht. Sie müssten diese Einstellungen mit den UA-Strings in Ihrem PHP-Code synchronisieren.
Unabhängig davon ist die Erstellung von zwei separaten Caches für meinen Geschmack zu nicht-DRY (Don't Repeat Yourself). Ich denke, der beste Weg ist, Ihren Designer und Kunden über die Mobile-First-Mentalität aufzuklären und anzustreben, allen Geräten denselben Inhalt zu liefern.
Dieser Artikel gibt ein gutes Beispiel für PHP-Geräteerkennung: http://www.smashingmagazine.com/2014/07/22/responsive-web-design-should-not-be-your-only-mobile-strategy/
Auto-Korrektur hat mich bei „server-side TEMPLATING“ in meinem ursprünglichen Kommentar oben erwischt. Entschuldigung dafür.
Sehr enttäuscht. Erwartete Backend-basierte LESS/SASS-Kompilierung oder ähnliche „Frontend-Aufgaben“ wie diese
https://github.com/kriswallsmith/assetic
„Es gibt eine ganze Welt von Möglichkeiten, was Sie mit ein wenig PHP in Ihrer Entwicklung tun können.“
Ich glaube, der Autor fühlt sich sehr schlau, da er nur Ratschläge zu offensichtlichen Dingen gibt.
Diese „Techniken“ sind eher alt. Nichts, womit ein FE-Entwickler nicht schon beim Bearbeiten einer WordPress-Seite oder Ähnlichem zu tun gehabt hätte.
Was schlimmer ist, ist, dass schlechte Praktiken von css-tricks unterstützt werden.
Wie lange sind Sie schon Frontend-Entwickler oder beschäftigen sich generell mit dem Web?
Sicher, PHP ist nicht für alles gut. Vielleicht glänzt es nicht einmal in irgendetwas. Aber es funktioniert. Auf praktisch jeder Plattform.
Es gibt also wirklich keinen Grund, es zu hassen, und es hat einige wirklich großartige Anwendungen, wie z. B. das Erstellen von Vorlagen, Benutzerkonten usw.
Wenn sich jemand „sehr schlau“ fühlt, dann sind Sie es. Ich muss Sie leider enttäuschen, aber obwohl die verschiedenen CSS-Varianten gut für vieles sein mögen, laufen sie doch alle auf CSS hinaus. Mit anderen Worten, Sie werden damit keine Backend-Aufgaben erledigen können, wie z. B. die Interaktion mit SQL und Ähnlichem.
Wenn ich Sie wäre, würde ich nicht anfangen, relative Experten zu kritisieren (nicht, dass ich einer wäre, ich lerne auch noch), bis ich mehr Erfahrung hätte.
Zu „Einfaches PHP-Templating“
Ich bevorzuge eine Templating-Engine wie Smarty/Twig/Dwoo. Weil es oft schwierig ist, Backend- und Frontend-Sachen zu entkoppeln.
Templating-Engines stellen sicher, dass Sie das Backend vom Frontend trennen.
echo “Die Variable $a ist derzeit 7.”;
In diesem Fall, da Sie doppelte Anführungszeichen verwenden, werden Sie nicht drucken
Stattdessen werden Sie drucken
Wahrscheinlich sollten Sie das ändern ;)
Das ist mir beim Bearbeiten aufgefallen und ich habe es drin gelassen, weil ich dachte, jemand würde es ansprechen und es wäre eine gute Lernerfahrung. Es ist technisch nicht falsch, es ist nur so, dass die Variable interpoliert wird =).
Verstanden ;)
Weitere Profi-Tipps / Klarstellungen
Das ist **falsch**. Variablennamen müssen mit einem
$beginnen, gefolgt von einem Buchstaben oder einem Unterstrich (nicht einer Zahl), und dann null oder mehr Buchstaben, Zahlen oder Unterstriche. Das Beispiel$a-lot-of-numberswürde als$aminuslotminusofminusnumbersinterpretiert werden, was, wie Sie sich vorstellen können, wahrscheinlich keinen Sinn ergibt und zu Fehlern führt.**Leere Seiten** sind tatsächlich das Ergebnis eines Parse-Fehlers, wenn PHP so konfiguriert ist, dass es keine Fehler auf der Webseite anzeigt (was für „Live“-Sites gut ist). Fehlende schließende Tags oder Semikolons sind häufige Syntaxfehler, aber auch falsch verschachtelte Klammern und viele andere Dinge. Anstatt zu versuchen, zu „raten“, was falsch ist, finden Sie die PHP-Fehlerprotokolle auf Ihrem Server (normalerweise im Verzeichnis über Ihrem Web-Root, oder **fragen Sie Ihren Webhoster**). PHP-Fehlermeldungen sind tatsächlich sehr geradlinig, sobald man sie zu lesen gelernt hat, und das wird **unzählige Stunden Fehlersuche** (und Frustration) sparen. Wenn Sie eine Fehlermeldung nicht verstehen, kopieren Sie sie einfach und fügen Sie sie in Google ein.
PHP und HTML (CSS, JavaScript usw.) **„mischen“ sich nicht tatsächlich**. Das mag wie eine geringfügige Unterscheidung erscheinen, ist aber sehr wichtig, um zu verstehen, was tatsächlich vor sich geht. Wenn Sie die Dateiendung in
.phpändern, ist es **keine HTML-Datei mehr**. Selbst wenn es sich *nur* um HTML-Markup handelt, ohne PHP-Tags. PHP verarbeitet die Datei auf Ihrem Server und **gibt die Ergebnisse** (einschließlich Inline-HTML) an den Browser **aus**. Zum Beispiel, in einem PHP-Skript, macht diesgenau das Gleiche wie
**
include** (undrequireusw.) verwenden Dateisystempfade, um die gewünschte Datei zu finden, was eine **sehr häufige** Quelle der Verwirrung ist. Beachten Sie, dass Dateisystempfade **keine** URLs sind. Dateisystempfade befinden sich **auf Ihrem Server**; URLs befinden sich **im Internet**. In vielen Fällen scheint es eine direkte Beziehung zwischen den beiden zu geben, aber das ist nicht tatsächlich der Fall.Wie oben erwähnt, würde ich davon abraten, mobile Browser vom Server aus zu „erkennen“. Dies ist Browser-Sniffing (hauptsächlich über den User-Agent-Header), was im Allgemeinen verpönt ist, da es fragil, schnell veraltet und manchmal einfach **falsch** ist.
Abhängig von der Art des Inhalts ist serverseitiges Browser-Sniffing in Ordnung.
Ich würde auch den Tipp hinzufügen
was eine Menge Tipparbeit spart.
Nun, ich sage Ihnen nicht, dass Sie es **nicht** verwenden können oder dass es **nie** eine Situation geben wird, in der es angemessen ist. Mir fällt jedoch keine ein. Meiner Erfahrung nach ist Browser-Sniffing viel Arbeit zu implementieren und schwer zu warten. Selbst wenn es „korrekt“ durchgeführt wird, schafft es tendenziell mehr Möglichkeiten für Probleme, als es löst. Im Gegensatz dazu erfordert ein Ansatz wie Capability Detection weniger Arbeit, ist äußerst wartbar und weniger fehleranfällig.
Es gibt viele Ressourcen, die dieses Thema im Internet diskutieren. css-tricks hat einen Artikel, der ein guter Ausgangspunkt ist.
Bezüglich der Verwendung von
<?= $stuff ?>anstelle von<?php echo $stuff; ?>stimme ich zu. Es gibt die Einschränkung, dass diese Funktion in PHP-Versionen vor 5.4 möglicherweise nicht verfügbar ist (abhängig von den PHP-Konfigurationseinstellungen). Nur etwas, worauf man achten sollte.Sie können keine Bindestriche in Variablennamen in PHP verwenden ($a-lot-of-numbers ist nicht gültig). PHP interpretiert Bindestriche als Minuszeichen und versucht, lot von $a zu subtrahieren.
Sie können jedoch Unterstriche verwenden
http://www.php.net/manual/en/language.variables.basics.php
Viele Kluge kommentieren hier, und wenn Sie dann ihr Portfolio überprüfen, lachen Sie so sehr, dass Sie sich einnässen
Denken Sie daran, dass viele von uns sogenannten Klugen keine Zeit haben, ihre Portfolios auf dem neuesten Stand zu halten, weil wir zu beschäftigt mit der Arbeit sind. Meine Website ist 3 Jahre alt und das Portfolio etwa 1 Jahr.
Darüber hinaus sind, wie in meinem Fall, einige von uns keine Designer (leider kann ich das nicht), daher sind unsere Portfolios eine Darstellung unserer Designer ebenso wie von uns selbst.
Obwohl ich bei den bisherigen Kommentaren kein vernünftiges Beispiel für responsives Design gefunden habe. Daher stimme ich Ihnen zu, es ist seltsam, über Best Practices für responsives Design zu sprechen, ohne responsive Designs zu erstellen.
Ich bin sowohl Backend-Entwickler als auch Frontend-Entwickler und würde PHP niemals für die mobile Erkennung verwenden.
Für mich ist es einfach falsch und es ist unmöglich, jemandem nicht den falschen Code zu liefern.
Es ist viel besser, jemandem ein verstecktes Element zu liefern (solange es keine Bilder enthält), als zu hoffen, dass die Erkennung wie erwartet funktioniert hat.
Allerdings habe ich keine responsive Website mit einem drastisch anderen Design für Mobilgeräte im Vergleich zu großen Bildschirmen erstellt, aber ist das nicht der Sinn der Sache?
Die einzige Zeit, in der dies fragwürdig oder unklar werden kann, ist der Versuch, ein CMS dazu zu bringen, Code für Ihre Kunden zu schreiben, der den Standards des responsiven Designs entspricht. Ansonsten verwenden Sie so viel CSS wie möglich und dann JavaScript, wenn CSS nicht ganz ausreicht oder um die Benutzererfahrung zu verbessern.
Das Backend sollte nicht für die Geräteerkennung verwendet werden.
Sehen Sie sich die Website meines Unternehmens an: http://www.suits-sandals.com. Für Desktop- und „Tablet“-Geräte verwende ich JavaScript-Feature-Erkennung, um ein HTML5-Video auf der Homepage auszuliefern, wenn es unterstützt wird. Für einen mobilen Kontext ergab jedoch selbst die Auslieferung von JavaScript für die Erkennung dieser Features keinen Sinn.
Nun, wenn, wie Scott Fennell anmerkt, mein Server-Sniffing fehlschlägt, wird nichts wirklich kaputtgehen. Stattdessen sieht der Benutzer nur das „Lade“-Symbol und die Website-Kopfzeile; das reicht aus, um den Benutzer auf die Website zu bringen.
Server-seitiges Sniffing war für einige meiner Projekte sinnvoll. Nicht alle, aber viele. Wie jede Technologie ist es jedoch am besten, sie so anzuwenden, dass sie wichtige Inhalte oder die Benutzerfreundlichkeit nicht beeinträchtigt.
Und wegen des Trollens! Manche Kommentare sind so lahm, dass ich nicht anders kann.
Alle meine Entschuldiguuuuung
Ehrlich gesagt, Mann, obwohl du dich selbst in ein schlechtes Licht rückst, indem du online Leute beschimpfst, stimme ich deinem grundlegenden Punkt zu. Die Leute sind oft sehr dogmatisch, was Server-seitiges Sniffing angeht. Es hört man viel häufiger Leute es verurteilen, als dass man hört, wie sie die Gründe für ihre Position erklären.
(das heißt, ich stimme zu, dass es schlecht ist, dogmatisch über Server-seitiges Sniffing zu sein – aber das macht es noch nicht zu einer guten Idee, es zu tun, wie ich oben erklärt habe)
Wow, viel Drama um dieses Thema. Wie wäre es, wenn wir uns darauf einigen, uns zu widersprechen und einfach „Es kommt darauf an“ für all diese Techniken sagen? Alles hier *könnte* für Ihre Umstände richtig sein, oder es könnte komplett falsch sein. Verwechseln wir nicht unsere individuellen Perspektiven mit denen aller anderen.
Das gesagt, gutes Round-up, Chris! Die meisten dieser Techniken werden für meine speziellen Umstände nicht nützlich sein, aber es ist trotzdem gut zu wissen.
Genau, für die meisten meiner Websites und wie ich diese Techniken verwende, macht es Sinn. Vertrau mir, ich würde sie vermeiden, wenn sie es nicht täten. Aber ja, der Kontext ist wichtig.
Ich habe gerade ein neues Projekt mit Hilfe von Twig (PHP-Template-Engine) abgeschlossen und ich muss sagen, es hat mir viel Zeit gespart. Die Tatsache, dass ich meinen Inhalt von meiner Markup trenne, durch ein Array loopen kann, Snippets einbinden kann, HTML-Snippets usw. ist einfach fantastisch! Und man kann es sofort in WordPress integrieren, indem man das Timber-Plugin verwendet. Oh, und um eine Build-Version der Website zu erstellen, verwendet man PHP's Output Buffering in Kombination mit Grunt oder Gulp.
basename akzeptiert einen zweiten Parameter
Obwohl ich PHP nicht zur Erkennung mobiler Geräte verwendet habe, habe ich es auf ähnliche Weise wie Assetic verwendet (Danke fürs Teilen, Martin). Der Leistungsschub, den ich durch die Zusammenfassung all meiner JS-Dateien zu einer einzigen Datei erzielte, verbesserte die Leistung so sehr. Wir haben eine komplette Angular-App entwickelt, die nur eine einzige Datei für den gesamten JS-Code geladen hat. Sicher, wir hätten es intelligenter machen können, aber es ist erstaunlich, was das im Vergleich zum Laden von über 40 JS-Dateien in einer großen Anwendung ausmacht. Wir haben dies für andere Front-End-Entwickler vollständig transparent gemacht, sie mussten die Datei nur in eine Include-Datei einfügen (nicht anders als das Hinzufügen eines Tags) und sie wurde in die kombinierte Datei aufgenommen. Sicher, das Debugging der Live-Version konnte unübersichtlich werden, aber dafür sollte man ohnehin die Entwicklungsumgebung nutzen.
Ich verstehe, was Sie tun, und ich muss sagen, dass das Bereitstellen einer einzigen kombinierten PHP-Datei schneller ist als über 40 kleinere Skripte. Sie verlieren jedoch die Vorteile des Browser-Cachings, indem Sie sie mit PHP kombinieren.
Sie wären viel besser dran, sie in einer Build-Phase mit Grunt oder einem anderen Task-Runner zu kombinieren. Dann haben Sie auch die Möglichkeit, die Datei vorzukomprimieren, um die Serverlast zu reduzieren und die Dateigröße noch weiter zu verkleinern. Dies gibt Ihnen auch die Möglichkeit, Source Maps zu verwenden, um das Debugging erheblich zu erleichtern. Das Beste daran ist, dass Sie einfach eine neue JS-Datei in das Quellverzeichnis legen und Grunt kümmert sich darum und baut die kombinierte Datei neu, wann immer Sie eine der Quellen bearbeiten.
@JacobPeters, ich stimme dieser Aussage zu 100% zu. Das einzige Problem ist, dass ich diese Woche gerade mit Leuten zu kämpfen hatte, die sich beschwerten, dass ein Upgrade des Systems nicht funktionierte. Ich fand heraus, dass die HTML-Vorlagen und sogar einige der JS-Dateien in ihren Browsern nicht aktualisiert wurden (auch nach einem STRG-F5). Sicher, es hat sich irgendwann geklärt, aber es war frustrierend, eine Menge unnötiger Support-Anrufe zu erhalten.
Ich nehme an, die Verwendung von Grunt mit einer gewissen Versionsverwaltung für Dateien würde das sicherlich lösen. Und glaub mir, ich weiß schon lange, dass ich mich damit beschäftigen muss. Die Realität zwingt dich leider dazu, zwischen der Arbeit, für die du bezahlt wirst, und der Infrastrukturarbeit zu wählen. Ich bin sicher, dass es irgendwann zu einer Verlangsamung kommt, die es mir ermöglicht, ein paar Tage damit zu verbringen, eine bessere Build-/Deployment-Strategie zu untersuchen und zu implementieren.
Danke für die Antwort!
Ich mache beides. Sowohl Frontend als auch Backend. Meistens Backend. Ich habe das kürzlich mit Mobile Detect für 4 Projekte gemacht. Beim fünften war ich zu genervt von der Tatsache, dass man nur richtig auf einem echten Gerät oder Simulator oder mit einem guten UA-Spoofer-Plugin testen kann. Ich habe alles, wofür ich Mobile Detect verwendet habe, in Client-seitigen Code refaktorisiert und ich bevorzuge es.
Dieser Artikel handelt von dem, woran ich bei RESS mitgewirkt habe
http://www.cotonti.mobi/page.php?al=Mobile_web_Slots
Das ist mein Artikel über den Detektor für Handys
http://www.cotonti.mobi/page.php?al=model_style_css
HTML und RES ist eine kompatible harte Aufgabe. Ich habe ein bekanntes CMF angewendet. CMF für die Verarbeitung dauerte etwa 4 Jahre
Gibt es nicht schon ein „media“-Attribut für CSS-Links, um das zu tun? Obwohl ich gehört habe, dass nicht alle Geräte sie unterstützen =\ Ich mag es wirklich nicht, Frontend und Backend zu vermischen, außer um Handys auf eine mobile Website umzuleiten, andere auf die normale.
Theoretisch stimme ich zu, dass ein wenig SS-Logik hilfreich sein kann und in bestimmten Fällen keine schlechte Option ist. Aber im Allgemeinen bin ich der Meinung, dass die Vorteile nicht groß genug sind, um dies im täglichen Produktionsbetrieb zu unterstützen.
Interessante Idee und eine gute Möglichkeit, ein wenig PHP zu lernen!
Das eine große Problem dabei ist, dass dies nur auf einem PHP-Server funktioniert. Ich würde einen Ansatz mit einer Template-Sprache (Jade, Haml etc.) und einem Build-System (Grunt, Gulp etc.) empfehlen. So erhalten Sie HTML, das Sie überall verwenden können.
Danke fürs Posten, Chris. Ich fange gerade an, mich mit PHP zu beschäftigen, das wird also sehr hilfreich sein.
Tolles Tutorial für den Einstieg in PHP.