 Es gibt hier ein eigenes Team, es ist auch ein Team, das ich selbst entwickle und dann auf Team Forest verkloppe. Mir geht es aber hier um Custom Teams, die also speziell für einen Projekt, für einen Kunden entwickelt wurden. Kurz zu meiner Person, mein Name ist Stefan Fröhlich. Ich bin seit 1995 freiberuflicher Entwickler. Zu WordPress habe ich dann 2012 gefunden. Zunächst habe ich auch das Thema hatten wir gerade im Vorgängervortrag mit Premium Teams und Pluckins gearbeitet. Das habe ich aber genau zwei Mal gemacht in zwei Projekten, weil ich dann festgestellt habe, für mich funktioniert das nicht. Und habe dann eben angefangen, Kunden spezifische Teams zu entwickeln. Wozu ein Custom Team? Viele Gründe haben jetzt, ich weiß nicht wie viele von euch haben den Vortrag von Jan gehört, im Slotter vor. Na ja, doch einige, gut. Meine Erfahrungen haben Premium Teams und Team Frameworks eins gemeinsam, oder mehrere Dinge gemeinsam. Sie bringen viel unnötige Funktionalität mit sich, aufgeblähten Code. Und trotz all dieser Vielfalt an Funktionen fehlt es oft an einigen Features, die ich einfach für ein aktuelles Projekt brauche. Dann kann ich natürlich hergehen und dafür ergänzende Pluckins installieren. Die haben aber auch oft das gleiche Problem. Auch hier gibt es wieder viele Features, oft nicht die, die ich brauche. Und damit stehe ich wieder am Anfang. Außerdem haben eigentlich alle Premium Teams und auch wieder jedes einzelne Pluckin, was ich zusätzlich einsetze, ein großes Problem der aufgeblähten Code. Und außerdem werden viele CSS und JavaScript Dateien enqueued. Und die meisten Pluckins und auch die meisten Teams kümmern sich auch überhaupt nicht darum, welche Seite genau angezeigt wird. Man installiert ein Kontaktformular und plötzlich ist auf jeder Seite und jeder Unterseite wird das JavaScript und das CSS für das Kontaktformular geladen. Obwohl ich das Formular auf genau einer Seite darstelle. Und auch bei vielen Teams, zum Beispiel heute nehme ich ein bisschen das Avada-Team auseinander, weil ich das gut kennengelernt habe auf einer Webseite, die ich für den Kunden administriere. Da werden auch unzählige CSS und JavaScript Dateien auf jeden Seiten-Template geladen. Das benötigt wird auf der Seite oder nicht. Hier zum Beispiel eine der Seiten im Chrome-Inspector angeschaut. Man sieht immens viele JavaScript und CSS Dateien. Und wir wissen auch alle, was das bedeutet. Es wirkt sich schlecht auf die Performance aus. Denn jede JavaScript Datei, jede CSS Datei muss geladen werden, bevor die Seite gerendert wird. Und entsprechend lange dauert es, bis die Seite auch wirklich für den Website-Besucher sichtbar ist. Damit das Ergebnis performancemäßig sehr unerfreulich. Hier zum Beispiel eben mit dem Avada-Team bei Google Page-Speed Insight sind dann immerhin 27 von 100 Punkten. Damit möchte der durchschnittliche Website-Bezweiber wahrscheinlich nicht leben. Dann werden immer verschiedene Lösungssätze angepriesen. Spezielle Hosting-Pakete mit Mod-Page-Speed oder Warnish-Cache. Oder verschiedenste Plugins, die die gesamten Dateien zusammenfassen in ein CSS und in eine JavaScript-Datei. Das Ganze minifizieren. Ich habe es tatsächlich bei einer Seite mal geschafft, die Performance wirklich hochzuschrauben. Da haben diese Plugins das geschafft, was sie versprechen. Da macht man wirklich eine CSS-Datei und eine JavaScript-Datei da. Und die Seite wurde noch dargestellt. Weil man kann die natürlich alle wunderbar konkatenieren und minifizieren. Aber wenn danach nichts mehr funktioniert, habe ich auch nichts davon. Funktioniert also sehr begrenzt. Fazit demnach. Ein Premium-Team ist sehr günstig in der Anschaffung für die, was weiß ich, 50 Dollar bei Team Forest oder wo auch immer. Verursacht aber auch Folgekosten. Eben, um unnötige Features auszublenken. Der Kunde ist im Normalfall nicht sonderlich glücklich, wenn er nur einen Custom-Post-Type braucht. Aber im Backend auch noch die Testimonials und irgendwelche Quotes und was auch immer. Ich meine, das ist ein Backup mit so einer langen Latte an Einstellungsmöglichkeiten, die geheimen Menschen benötigt. Also muss ich die entfernen. Darüber hinaus muss ich zusätzliche Features implementieren, die ich für das Projekt brauche. Das Design sollte ja auch nach Möglichkeit noch angepasst werden. Entsprechend habe ich auch noch Aufwand für Backfixing. Ich muss testen. Hab eventuell Kosten für zusätzliche Plugins. Hab Kosten für entsprechendes Housing. Aber ich hab dann vielleicht verbessert, dass das Ergebnis, das geht aber auch nur bis zum gewissen Punkt. Ich administriere ca. 40 Webseiten für eine Agentur. Davon sind nur zwei von mir entwickelt. Und natürlich ist da immer der Wunsch noch Optimierung da. Und diese 79 von 100 ist anscheinend so eine Magic-Number. Das ist ein Punkt, da kann man hinkommen durch entsprechende Plugins. Mod-Page-Speed auf einem entsprechenden Server kann natürlich noch mal einen gewaltigen Unterschied machen, ist aber auch mit Kosten verbunden. Ich brauche eine entsprechende Server-Umgebung. Entweder ist es ein Server, den ich dann selbst verwalten muss, dann habe ich damit entsprechenden Aufwand. Oder ich kaufe die Leistung ein. Hab entsprechende Rostingkosten. Sicherheit ist auch noch ein Thema. Hab ich sehr oft erlebt, auch jetzt während dieses Wordcams sind bei solcher Seiten gehackt worden. Denn beliebte Seams haben auch beliebte Sicherheitslücken. Und das große Problem sind oftmals dann auch die Plugins, die diese Seams integrieren. Die tauchen also in der Plugin über sich den WordPress selbst ja nicht auf. Die kann ich nur über das verwendete Seam aktualisieren. Ich habe das jetzt in drei Fällen erlebt, dass ein Webdesigner eben für schmales Geld mit Avada oder X eine Website gemacht hat. Dann aber vergessen wurde, den Lizenzschlüssel einzuspielen, sodass die Auto-Updates von dem Seam deaktiviert sind. Und in den Fällen haben die Kunden zwar schon versucht, WordPress aktuell zu halten. Das Problem ist aber, dass die in einen Seam integrierten Plugins gar nicht in der Aktualisierungsübersicht auftauchen oftmals, je nachdem wie die das Seam einbindet. In dem Fall wird dann zwar WordPress aktualisiert, das hier nicht. Und solche Lücken durch veraltete Plugins oder veraltete Teams lassen sich nun wirklich leicht ausbeuten. Hier habe ich zum Beispiel ein Screenshot beigeflückt von WPScan. Das ist ein Ruby-basiertes Kommando-Zeientool, mit dem ich WordPress-Installationen einfach auch Sicherheitslücken scannen kann. Sehr praktisch, man gibt einen WPScan, dann die URL, gibt noch ein paar andere Optionen, aber das reicht schon. Und dann erhalt ich es um Sicherheitsscan. Man kann es jetzt hier nicht lesen, aber es wird letztendlich werden alle Plugins aufgelistet und auch die entsprechenden Sicherheitslücken ausgegeben. Und ich erhalte da immer noch eine ganze Litanei an URLs, wo ich auch nachlesen kann, wie man diese Sicherheitslücke ausnutzen kann. Also wer sich die Zeit und Mühe machen möchte, hat da ein ganz leichtes Spiel. Wie gesagt, es ist kein Problem, wenn alles regelmäßig aktualisiert wird, aber in der Praxis sieht es halt auch mal anders aus. So, welche Vorteile bietet nun ein eigenes Theme oder ein Custom Theme? Zum einen, es ist ein individuelles Design, denn wenn der Agentur 10 Seiten mit X macht, können noch so viele Paddings und Fonts und Farben ändern, irgendwie sieht es halt auch immer aus nach X. Ein eigenes Theme bietet genau die Funktionalität, die ich brauche für ein Projekt, nicht zu viel, nicht zu wenig. Und ich habe dadurch auch ein übersichtliches Backend, was wesentlich benutzerfreundlicher ist, für diejenigen, die dann in die Inhalte einpflegen. Außerdem gibt es keine bekannten Sicherheitslücken. Ich habe schlanken Code, denn ich habe selbst den Einfluss drauf, wie ich ihn programmiere. Ich komme mit wenigen CSS und Javascript-Dateien aus und habe dadurch eine deutlich bessere Performance. Ein Theme, das ich selbst entwickle, hat einfach nur eine CSS-Datei und eine Javascript-Datei. Aber das ist dann ganz leicht, auch zum Beispiel auf diese 100 von 100 zu kommen, die er rechts im Screenshot zieht. Das schaffe ich zum Beispiel mit meiner eigenen Website, ohne Verwendung irgendwelcher Plugins, selbst ohne Caching-Plugins. Was ich natürlich dann doch verwende, weil ich natürlich lieber statisches HTML ausspucke wegen der Response-Zeiten. Aber Randon tut das Ganze ohne jede Blockade. Natürlich, wenn man jetzt Google Analytics einsetzen möchte, schafft man es nicht auf die 100, weil Google eben immer eine Penalty vergibt von zwei Punkten wegen der Caching-Richtlinie für das Google Analytics Script. Da kann man dann nichts machen. Ganz kurz möchte ich auch auf die Anatomie eines Seams eingehen. Das wird allerdings jetzt nicht so technisch, keine Angst. Wenn man ein eigenes Seam erstellt und mit HTML und CSS gut vertraut ist, muss man jetzt zunächst kein PHP-Gurus sein, um ein Seam zu programmieren. Man braucht relativ wenige Bausteine, um das Ganze zu starten. Zum einen braucht man ein neues leeres Verzeichnis für das Seam. Das muss in www.contents.seams liegen, standardmäßig. Natürlich war ich zu unserem Verzeichnis noch nicht aus. Man kann, wenn man dieses Verzeichnis einfach mal anlegt im Seams Verzeichnis und im WordPress Backend sich die zur Verfügung stehenden Teams anzeigt. Beobachtet man schon was? Also WordPress sieht schon, es gibt ein Seam, aber leider wird es als beschädigtes Seam erkannt. Mit dem Hinweis eben, im linken Teil sieht man, es wird schon Name vermutet anhand des Dateinahmens, dem man dem Verzeichnis gegeben hat. Aber dann kommt die Fehlermeldung, das jeden Style-Sheet. Dieses Style-Sheet ist die Style-CSS, die ihr wahrscheinlich alle gut kennt. Hier einfach mal nur ein Beispiel für ein Style-CSS. Ganz wichtig ist, dass die auf jeden Fall den CSS-Commentar-Block oben aufweist. Denn daraus zieht WordPress verschiedene Informationen, wie zum Beispiel den Namen des Seams, die Seam-URI, eine Beschreibung, also auch die Daten, die ich dann letztendlich im Backend in der Seam-Beschreibung anzeigen kann. Darüber hinaus muss die Style-CSS nichts enthalten. Also ich verwende zum Beispiel überhaupt keine CSS-Regeln in der Style-CSS. Ich mache das in der gesonderten Datei, die man entsprechend enqueued wird. Die dient jetzt in diesem Fall auch nur der Beschreibung. Wenn man jetzt eine Style-CSS in dem Verzeichnis hinterlegt hat, dann ist das Seam leider immer noch beschädigt. Man sieht allerdings, bei Name steht jetzt hier schon Scratch, das ist das, was hier unter Seam-Name in der ersten Zeile des Commentar-Blocks steht. Also wir sind ein klein Stück weiter. Allerdings wird hier eben noch angemahnt, dass mindestens eine Index-PHP-Datei da sein muss. Außer man macht ein Schall-Seam, dann muss wenigstens in der Style-CSS noch oft das Pairing-Seam das zu verwenden ist, verwiesen werden. Also brauchen wir noch eine Index-PHP. Hier ein ganz kleiner Ausschnitt. Ich will jetzt nicht naja, allzu tief eingehen auf die PHP-Programmierung des Seams, aber nur mal hier rot hervorgehoben. Seht ihr, es gibt einen großen If-Block, If-Half-Posts. Das ist eine Funktion aus dem WordPress-Core. Da kann ich eben fragen, gibt es denn Beiträge oder Inhalte, die ich jetzt auf dieser Seite darstellen kann? Wenn ja, dann kommen wir zu dem berühmten Loop. Falls nein, das ist dann der unterste Teil. Die untersten drei Zahlen wird eine entsprechende Fehlermeldung ausgegeben, dass nichts gefunden wurde. Ja, und in dem Loop wird dann eben, werden dann eben die verschiedenen Beiträge, falls es mehr als einer sind, dabei nachdurchlaufen und entsprechend ausgegeben. Dafür gibt es dann verschiedene PHP-Funktionen aus dem WordPress-Core, wie zum Beispiel der Permalink, gibt den Permalink der Seite oder das Artikel aus der Content. Das denke ich selbst erklären, was die Funktionen machen. Nicht zwingend erforderlich, aber ganz praktisch, ist auf jeden Fall noch die Screenshot-PNG. Das ist nämlich das Bildchen, was WordPress im Backend in der Siebenübersicht anzeigt. Sonst wird da nur so ein Quadrat, was mit Weißen und Glocken Quadraten gefüllt ist, angezeigt. Also wenn wir jetzt in das Verzeichnis die Style-CSS und eine Screenshot-PNG legen, wird das Ganze von WordPress schon als Team erkannt und ich kann aktivieren klicken. Somit ist sozusagen der Rahmen geschaffen und ich kann das Ganze mit der nötigen Funktionalität füllen. Ein wichtiger Punkt, auf den ich noch eingehen möchte, ist, dass man natürlich unbedingt auch in den eigenen Templates den Header und den Futter einbinden sollte. Header ist also alles, was vor dem Loop kommt. Futter ist alles, was nach dem Loop kommt. Das ist einzubinden über die Funktionen GetHeader hier rot hervorgehoben im oberen Teil bzw. GetFutter weiter unten. Das heißt WordPress an eben die entsprechenden Dateien einzubinden. Erstrangig wird von GetHeader dann meine eigene Header PHP eingebunden und von GetFutter meine eigene Futter PHP. Zeige ich auch noch kurz. Willkürliches Beispiel für eine Header PHP. Da wird der DocType definiert. Das HTML-Tag geöffnet. Der Heads. Ein Style sheet eingebunden. Und hier jetzt auch wieder rot hervorgehoben. Ein ganz wichtiger Punkt. Ich muss die Funktion WPHat aufrufen. Damit eben auch noch alle anderen Funktionen oder Methoden, die für diesen Hook registriert sind, aufrufen werden. Ganz wichtig, zum Beispiel die Achmin-Basein möchte die Schmarrzimmer hin und her schalten zwischen Backend und Frontend. Wenn ich den WPHat hier raus lasse gibt es die einfach nicht mehr. Komm ich nicht mehr zurück oder auch Plugins funktionieren einfach nicht. Noch kurz zur Futter PHP. Das ist also das, was quasi nach dem Content Teil und nach dem Loop dargestellt wird. Wir sehen hier einen kurzen HTML-Futter. Und dann eben ganz wichtig unten vor dem Schließenden BodyTag der Aufsucht der Funktion WP-Futter. Die eben hier auch zum Beispiel Plugins die Möglichkeit gibt vor dem Schließenden BodyTag entsprechenden Code zu injizieren. Darüber hinaus gibt es natürlich eine riesige Anzahl von Template-Dateien, die man noch schreiben und in Siem integrieren kann. Hier einfach mal nur ein paar am Rande genannt. Zum Beispiel die Sidebar PHP. Das ist das Template für die A. Zum Einflügen der Seiten leisten. Ganz wichtig die Functions-PHP wo ich verschiedene Einstellungen definieren kann. Styles und Scripts N-Cune oder D-Cune. Front-Page-PHP ist zum Beispiel das Template für die Darstellung der Startseite. Sowohl für die letzten Beiträge als auch für die Statische Seite. Unabhängig davon, was im Customizer ausgewählt wurde. Page-PHP ist das Template für die Darstellung von Statischen Seiten, wenn es keine Speziellen gibt. Single-PHP ist ein Template für die Darstellung einzelner Beiträge. Und entsprechend dazu noch Category-PHP, Archive-PHP eben für die Darstellung von Kategorien und Archiven. Und das Ganze kann ich natürlich, wenn ich Custom-Post-Types verwende, noch entsprechend erweitern für die Einzeldarstellung oder für die Archiv- und Kategoriedarstellung von Custom-Post-Types. Ich habe euch hier auch noch zwei Links zu den einzelnen Templates. Da wird die Template hier in Wordpress ganz genau erklärt und noch einen anderen Link zu den einzelnen Templates. Da könnt ihr das nachlesen. Unter dem Sprich werdet ihr je nachdem, wie kompliziert die Seite aufgebaut ist, nicht allzu viele Template-Dateien brauchen. Hängt aber natürlich auch vom eigenen Programmierstil ab. Eins, was ich noch zeigen möchte, was man ja kennt von den Templates. Ich erstelle eine neue Seite und habe dann unter den Artributen eine Dropdown-Liste, wo ich wählen kann zwischen dem Standard-Template und verschiedenen anderen Templates. Das erreiche ich dadurch, dass ich in meinen PHP-Templates, die die jeweilige Funktionalität zur Verfügung stellen, einen entsprechenden Kommentarblock einfüge. Der ist hier Word vorgehoben. Es steht einfach Template-Name. Danach, alles was danach kommt, ist der Name, den ich dann auch später sehen kann, um dieses Template auszudellen. Normalerweise brauchen wir dann natürlich noch weitere Komponenten, um das Projekt umzusetzen. Das ist relativ schnell erklärt. Das sind Custom Post-Tibes mit entsprechenden Taxonomien, Custom Fields und so weit gewünscht eben auch noch verschiedene Plugins, die ich natürlich auch mit einem Custom Team beliebig einsetzen kann. Custom Post-Tibes und Taxonomien kann ich entweder einfügen mit einem Custom Team, in dem ich die entsprechenden Codesahlen selbst schreibe. Wer es ein bisschen bequemer haben möchte, wird auch von vielen gerne gemacht. Es gibt verschiedene Generatoren. Eine bekannte Website ist zum Beispiel Generate WP.com. Da kann ich verschiedene Kriterien und Einstellungen für meinen Post-Halb eingeben. Drückt dann auf den grünen Button und dann wird mir unten ein Codesnippet ausgegeben. Also ich einfach Copy-Based in die Functions PHP oder in der anderen PHP Datei einfügen kann. Schon ist der Custom Post-Tib definiert. Manche verwenden dafür auch Plugins. Ein bekanntes ist WP-Types. Bei den Custom Fields gibt es ähnliche Möglichkeiten, auch hier wieder Code oder Generate WP und viele andere natürlich. Ein Plug-In, was ich fast ausschließlich dafür verwende, ist Advanced Custom Fields Pro. Denn das Plug-In wird sehr gut gepflegt. Ich hatte noch nie Probleme damit und kann damit wirklich komfortabel und umfangreiche GUIs aufbauen. Natürlich kann man mit entsprechenden Bibliotheken, die es auch bei Github zuhauf gibt oder auch mit selbst entwickelten, das auch alles selbst bauen. Aber ich muss ganz ehrlich sagen, ich finde, das ist ein sehr gutes Plug-In, womit man auch umfangreiche GUIs schneller aufbauen kann. Dann zeige ich mal zu den eigentlichen Komponenten, die man für ein Team braucht und welche Vorteile dann Custom Teams bietet. Was ich euch noch zeigen möchte, sind einfach ein paar Tools für den effizienten Workflow bei der Entwicklung, ohne die ich persönlich nicht mehr auskommen möchte. Das eine ist, ist eben die lokale Entwicklungsumgebung, die Versionsverwaltung und Deployment mit Gith und die Automatisierung mit Grand. Die lokale Entwicklungsumgebung ist relativ übersichtlich. Man braucht einen Webserver plus PHP plus MySQL als Webserver entweder Apache oder EngineX. Weil man unter OSX arbeitet oder Ionix oder Linux, ist es ein leichtes in den Apache zu installieren plus PHP plus MySQL. Windows-Juice oder auch OSX-Juice, die jetzt nicht so scharf daraus sind auf der Command Line sich zu bewegen, zum Beispiel MAMP installieren. Da ist also der Apache, MySQL und PHP schon gekapselt in ein Download-Paket, bietet verschiedene Konfigurationsmöglichkeiten. Mir persönlich ist hier die bordeigene Ausstattung unter OX, X, Viva. Jetzt habe ich also eine lokale Entwicklungsumgebung. Ich habe ein Team, was ich gerade entwickle. Empfiehlt sich dann natürlich die Dateien auch zu versionieren. Mit Git, das ist ganz klar. Und was eben sehr vorteilhaft ist, man kann die Dateien damit auch deployen, zum Beispiel auf einem Staging-Server oder auf die Produktionsumgebung auch. Hier noch kurz, für Git natürlich, ihr könnt eure Projekte auf Git unterbringen. Da gibt es die kostenlose Möglichkeit, die Projekte öffentlich zu schalten. Man kann die Repositories natürlich auch privat dort unterbringen. Ist dann kostenpflichtig. Ander Möglichkeit wäre zum Beispiel verzauberliche Projekte auf Bitbucket.org unterzubringen. Zum Deployment mit Git. Ich habe jetzt also hier meinen lokalen Rechner ganz links. Mit meinem Repository. Ich habe jetzt gerade einen neuen Bild von meinem Team gemacht. Ich möchte das auf dem Staging-Server über das Web ausprobieren. Dann pushe ich meinen Repository in dem Fall auf Bitbucket. Und Bitbucket und natürlich auch die ganzen anderen Anbieter bieten die Möglichkeit, dass man Hux definiert. Ich kann also sagen, in dem Moment, wo ich auf den Server etwas pushe in mein Repository für diese oder jene Aktion aus. Ein sehr nützliches Tool ist dann in diesem Fall eben den Hux zu definieren. Dann schuhe ich auf den Server-Pusche. Ein Skript auf meinem Staging-Server ausführt, was automatisch den Git-Pull ausführt. Sprech in dem Moment, wo ich lokal meine Änderungen committe, die auf den Server-Pusche löst der Huck auf meinem Staging-Server ein Skript aus, was automatisch den neuesten Stand der Dateien auf den Staging-Server heult. Mit einmal Apple S ist das Ganze auch schon sichtbar im Web. In der Produktionsumgebung würde ich das natürlich nach wie vor manuell machen, damit ich da mehr Kontrolle habe, wie das Ganze abläuft. Der letzte Punkt, auf den ich noch zu sprechen kommen möchte, ist die Automatisierung mit Grunt. Die bietet nämlich sehr viele angenehme Möglichkeiten. Grunt ist ein JavaScript-Taskrunner, also eine Möglichkeit vorgängebar der Entwicklung zu automatisieren und für mich die Element-Task wir sehen also hier unten mein Team besteht aus verschiedenen Dateien, jetzt mal exemplarisch SCSS, PHP, JPEG, SVG, pass auch über. Grunt beobachtet die Verzeichnisse, die ich provisiert habe mit der Watchtask und schaut einfach, ändert sich was. Jetzt mal hier exemplarisch für SCSS ich habe das an meiner Main-SCSS gearbeitet, geändert. Grunt erkennt die Datei, hat sich verändert, kompiliert automatisch die SCSS-Datei zu CSS. In dem nächsten Schritt lasse ich das Ganze dann vom Auto-Prefixer mit den Vendoren spezifischen prefixen versehen bzw. falls ich auf Prifixes eingeschlichen habe, die da nicht hingehören, entfernt der Auto-Prefixer, die auch. Danach wird im nächsten Schritt die CSS-Datei mit den prefixes minimiert und schon habe ich ein perfekt minimiziertes CSS, was absolut Browser kompatibel ist. Wenn es mir dann noch zusätzlich um Performance-Tuning geht, kann ich auch gleichzeitig mit Grunt auch noch das kritische CSS aus dem Gesamt-CSS errechnen lassen für die jeweilige URL. Ich habe also da auch die Möglichkeit, das dann noch zu injizieren in den Head-on der Seite, wenn ich das möchte. Und dann, ganz oben der Live-Reload immer, wenn sich was geändert hat an den Dateien und in dem Fall dann zum Beispiel nach dem ganzen Processing nach dem Processing der SCSS-Datei bis hin zu den fertigen CSS-Dateien werden, wird die Seite auf allen Geräten, die jetzt lokal bei mir im Netzwerk hängen, über den Live-Reload neu geladen. Das heißt, ich habe hier eine Windows-Maschine stehen, ein altes MacBook, ein iMac, verschiedene Android-Geräte, iOS-Geräte und in dem Moment wo der Live-Reload ausgelöst wird, bap, bap, bap, wird es auf allen Geräten neu geladen, diese Reite, ungeheuer praktisch. Damit bin ich dann auch schon am Ende mal des Vortrags. Gibt es noch Fragen, ja, gleich hier? Wie funktioniert es mit dem Live-Reload oder muss es ja auch in den Geräten was auch dort sein, am Mindest das ähnliche Begriff, oder? Also es gibt mehrere, also die Frage war, wie das mit dem Live-Reload funktioniert, muss da auf den Geräten jemals was installiert sein. Es gibt für die verschiedensten Desktop-Browser Plugins, die ich einfach installiere, dann wird automatisch auf der Live-Reload-Schnittstelle gelauscht, ob da was kommt. Also verbindet sich automatisch mit dem Grant. Es gibt natürlich auch viele Geräte, für die es kein solches Plug-in gibt. In dem Fall müsste ich dann einfach in den Header der HTML-Datei ein kurzes Script einfügen, was den Browser eben anweist darauf zu reagieren. Das funktioniert auch sehr gut. Muss man dann natürlich in der Produktionsumgebung so auslassen. Sonst noch fragen? Du meinst, in dem Beispiel Header PHP? Ja, das war einfach ein willkürliches Beispiel. Enqueun würde ich, wie ich dann auch kurz gesagt habe, Enqueun würde ich in der Functions PHP natürlich. Genau, also bei mir geht es um diesen Punkt. Ja, genau. Hier in der Header PHP, malte Bernhard erst dieses Link-Tag für die Einbittung der Main CSS oder Main CSS natürlich nicht erforderlich ist. In dem Moment, wo ich das Ganze über die Functions PHP enqueun. Das stimmt. Sonst noch mehr? Der Hinweis war, dass es natürlich auch die Möglichkeit gibt, jetzt nicht unbedingt Grant selbst zu installieren mit den Modulen, sondern eben auch entsprechende Anwendungen. Bernhard, mal die Code Kit, kenn ich jetzt persönlich nicht. Da gibt es auch Live Reload. Das gibt es eben auch im App Store für schmales Geld, was letztendlich eine kleine Grant-Entwicklung einrichtet, wo ich dann eben mit einer GUI, mit der Maus das Ganze entsprechend konfigurieren kann. Sehr viel bequemer, schneller eingerichtet, bietet aber natürlich auch weniger Möglichkeiten. Die Frage war welches Tool ich einsetze, um die Datenbanken synchron zu halten von den verschiedenen Entwicklungsstages eigentlich keines. Also, lokal habe ich einfach Testdaten, um die Funktionalität des Teams zu testen und meistens lasse ich die je nachdem welchen Zeitplan das Projekt auch hat, meistens lasse ich einfach den Kunden schon mal auf der Staging Umgebung anfangen, einen gewissen Datenbestand einzugeben und spiegle mir den dann einfach lokal, falls ich ihn tatsächlich mal brauche und wenn dann der Datenbestand da ist wird der auf die Produktionsumgebung eingespielt und der Kunden kann von dort aus weiter pflegen. Dann sind wir am Ende meines Vortrags. Herzlichen Dank für eure Aufmerksamkeit. Die Folien