 Willkommen zu meinem Talk über WordPress-Verwaltung mit Composer und Git. Vorab will ich sagen, es wird keine Einführung in Git sein. Also ich gehe von da, dass die Leute in Git kennen. Ich werde nur darauf eingehen, wie man es mit Composer kombiniert. Frage bitte am Anschluss, weil ich weiß nicht, ob ich schnell genug durch meine Folien kommen werde. Erst mal zu mir. Mein Name ist Walter Ebert, ich bin Freier Webentwickler aus Frankfurt am Main. Ich werde später auch die Folien aufs Slide Share hochladen. Und ich mache WordPress. Wenn man das WordPress nutzt, dann hat man natürlich immer mal am Projekt arbeitet, dass man Plugins installiert, man entwickelt, man probiert ein paar Sachen aus. Dann hat man immer das Problem, welche Plugins habe ich jetzt installiert und nicht. Und wenn man mit anderen Leuten zusammen arbeitet, die auch am Projekt arbeiten und uns daran entwickeln, dass man austauschen muss, welche Plugins verwenden wir jetzt und welche nicht. Vorteil, dass man explizit sagt, was aktiv ist, was nicht. Weil es passiert auch mal, dass man Plugins installiert, mal ausprobiert. Und dann später nicht mehr weiß von, brauche ich das jetzt oder brauche ich das nicht. Ich habe es mal getestet. Und mit Composer kann man halt sagen, welche Abhängigkeiten man hat. Natürlich, wenn man Plugins installiert, es gibt ja immer ständig Aktualisierungen. SEO ist ein Plugin, wo ganz viele Updates kommen. Und dann muss man auch wissen, welche Version habe ich jetzt in Produktion installiert und mit welcher Version arbeite ich jetzt in der Entwicklung. Composer kann da halt Abhilfe leisten. Composer ist ein Dependency Manager, wie Sie es selber nennen. Es ist eigentlich so, dass Standard-Tools in der PHP-Erwärts geworden sind, um als PHP-Komponenten zu verwalten und zu installieren. Und das kann man auch für WordPress nutzen. Installation ist eigentlich ganz einfach. Man lädt sich den Installer runter, führt den Installer aus und sagt, wo man Composer hininstallieren will. Ich mache es immer so, dass ich es so installiere, dass ich über eine Quantizeile überall aufrufen kann und das halt global verfügbar ist. Man kann jeder selber entscheiden, ob er das will oder nicht. Man kann es auch pro Projekt machen. Aber ich benutze halt immer die neueste Composer-Version und das will ich halt auch global haben. Wenn man es einmal installiert hat, sollte man eigentlich ständig aktualisieren. Es gibt jetzt die Version 1.0, also jetzt Stable. Composer Self-Update aktualisiert halt Composer. Das ist jetzt die Stable-Version. Es gibt jetzt Varianten, dass man auch die Preview-Version oder ein Snapshot, also Snapshot heißt, der aktuellste Stand sich installieren lassen kann. Es ist mehr so für Leute, die auch am Composer mitarbeiten, um das halt zu testen oder die neuesten Funktionen brauchen. Der Pakete installieren geht eigentlich ganz einfach. Composer ist halt ein Kommando-Zeilentool. Wenn man sagt Composer, Require und das ist halt das Paket, das man installieren will. Es gibt halt so eine Konvention, dass man Fender-Namen hat und dann Paket-Namen. Man kann zum Beispiel eine IP-CLI installieren auf der Art. Das wird automatisch die stabile Version installiert. Man kann auch die Entwicklungs-Version, das heißt Def-Master installieren. Das braucht man im Moment bei WPCLi, weil die funktionierten nicht mit Composer 1.0, die World Composer 1 Alpha haben. An die Def-Master ist das jetzt gepickt. Also ist eigentlich die Ausnahme, dass man den Master-Version benutzt. Alle Pakete, die in Composer verfügbar sind, kann man auf Packages.org finden. Wenn man ein Paket sucht, kann man da suchen und dann wird auch angezeigt, wie der Fender-Namen und Paket-Name ist. Wenn man Composer ausführt, werden ein paar Sachen installiert. Das erste, was er macht, ist ein Composer JSON erstellen. Da drin steht, welche Pakete man definiert hat. Die kann man auch bearbeiten später. Composer Lock sagt, welche Pakete installiert wurden und in welcher Version. Das sind auch die Sachen, die man später in Git beide mitnehmen sollte. Und Fender ist halt das Verzeichnis, wo alle Pakete installiert werden. Das ist halt Standard Fender. Man kann es auch umbenennen, wenn man will. Aber ich benutze immer den Standard. Die Composer.json ist halt die Name sagt. Das ist ein JSON-Datei, wo man die Pakete definiert. Ich benutze eigentlich immer JSON-Datei, um Sachen zu installieren. Man hat so ein Basis-Setup, die man in Composer JSON definiert, die ich dann immer für Projekte verwende. Und dann halt eine Abwandlung machen für jedes Projekt. Und das wollte man nutzen. Wenn man einmal ein Composer JSON hat, kann man über Composer install dann alle Pakete installieren, die da definiert sind. Man liest die Composer JSON out, ist nicht die ganze Wahrheit. Es wird erst geguckt, ob es eine Composer Lock-Datei gibt. Und wenn es die gibt, wird die genommen beim Composer install. Und wenn es die nicht gibt, wird die Composer JSON genommen. Was man auch noch machen kann, ist, an der Stelle schon einen eigenen Workflow bereitstellen. Man kann sagen, Composer install no dev. Heißt, dass man nur die Pakete installiert, die im Require definiert sind. Und die Entwicklungspakete nicht installiert. Also kann man für Produktion und Entwicklungsstand unterschiedliche Pakete installieren. Bei Entwicklung, dass man oft Test-Tools mitinstalliert, also PRP-Unit, oder dass man den Coding-Standards installiert, weil jeder macht Unit-Tests und programmiert gegen den WordPress-Standards. Hoffentlich. Was man noch machen kann, ist ein Minus O zu nutzen. Das heißt, dass den Autoloder von Composer optimiert, erstellt wird. Das bringt den Performance-Gewinn von ungefähr 10% in Produktion. Bei WordPress ist das nicht so dringend, weil WordPress halt nicht mit Composer arbeiten und den Autoloder auch nicht nutzt. Das bringt nur für, wenn man ganz viele PRP-Pakete nutzt. Wenn man Änderungen in Composer JSON macht, kann man die Änderungen übernehmen und über den Composer Update. Bei Composer Update werden auch immer die neueste Versionen genommen, die definiert sind. Man kann auch Dry Run machen, um zu sehen, was neu geladen wird, wenn man nicht sicher ist, dass der Composer irgendwie komische Sachen lädt. Man kann auch explizit sagen, von bestimmten Paketen nur aktualisieren, weil man zum Beispiel ein Security Update für ein Plug-in oder ein Paket hat und dass man nur die Variante nutzen will. Bei Composer ist es halt so, dass man meistens PRP Bibliotheken installiert, aber es gibt auch die Möglichkeit, Kommando-Zeilen-Programme zu installieren wie WPCLI, die wir dann halt im Verzeichnis Fender bin, abgelegt. Ich nutze gerne die WPCLI, die installiere ich eigentlich bei jedem Projekt mit, weil in Composer kann man auch Skripte ausführen und das ist insbesondere interessant, wenn man Composer benutzt, um Updates zu machen. Und man kann halt die Skripte-Definition nutzen, um WPCLI auszuführen, um zum Beispiel die Datenbank zu aktualisieren, wenn neue WordPress-Versionen rausgekommen sind und da Datenbank schon mal was geändert wurde. Oder wenn neue Übersetzungen da sind, dass man das automatisch, wenn man Composer Updates macht, dass automatisch WPCLI aufgerufen wird, um da die Updates zu ziehen. In Composer kann man auch Version definieren. Man hat das erste ist halt ein Astgerechter, das heißt, dass man immer die neueste stabile Version installiert. Man kann auch explizit sagen, welche Version man haben will. Man kann auch so das Carrots-Symbol, das kann nicht was das auf Deutsch, wie das auf Deutsch heißt. Das definiert man, dass man halt in diesem Beispiel 0.22.0 oder neuer, aber alles was dann unter 1.0 noch ist, beim Tildezeichen wird es etwas detaillierter gemacht und das heißt, alles was unter 0.23 läuft. Man kann auch kleiner oder größer Zeichen nutzen oder halt auch zum Beispiel Dev Master, wenn man den aktuellen Entwicklungsstand nutzen will. Die beste Version oder kleiner, größer Zeichen und Dev Master sollte man eigentlich vermeiden. Das sind halt die Punkte, die man so standard nutzen sollte. Wichterer Punkt bei Composer ist, dass es die sementische Versionierung nutzt. Das heißt, die Versionsnummer sagt was aus, was in der Software oder in die Bibliothek gemacht wird. Die Pet Version heißt, da werden halt Sachen gefixt, aber keine neuen Funktionen. Das heißt, alte Funktionen beibehalten bleiben, aber es gibt dann eine neue Version und Major Versionsnummer. Das heißt, dass sich Funktionalität ändert und dass die Compatibilität nicht mehr gegeben ist. WordPress nutzt keine sementische Versionierung. Nicht komplett, also WordPress Core selber hat nur Batch Versionnummer und in meiner Version Major Version gibt es bei WordPress nicht, weil alles ist rückwärts kompatibel. Es werden halt Funktionen deprecated, aber nicht komplett abgeschalten. Bei Blockins ist das anders. Da kann man irgendwie Versionsnummer nehmen, wie man will. Und das ändert sich auch manchmal. Da muss man halt drauf achten, wenn man bestimmte Plugins nutzt. Man kann auch nicht nur PHP-Bibliotheken installieren, man kann auch definieren, welche PHP-Version genutzt werden soll. Hier ist 532, die älteste Version, die von Composer unterstützt wird. Natürlich, WordPress funktioniert auch mit 532, aber Composer-Standard nicht. Man kann auch z.B. PHP-Extensions definieren, die benötigt werden. Z.B. hier die GD Bibliothek, die für die Medienverwaltung genutzt wird. Manchmal ist es so, dass Bibliotheken nicht in Stable-Version freigegeben wurden. Da muss halt die Entwicklungsversion nutzen und das muss man definieren, damit Composer die Version auch installiert. Sonst macht er das nicht. Natürlich sind hier WordCamp, man will natürlich WordPress installieren. Composer wird nicht offiziell unterstützt vom WordPress-Projekt. Hier hat John Block, Composer repositive bereitgestellt, wo 1 zu 1 WordPress übernommen wird. Über sein Paket kann man WordPress installieren. Ich glaube, dass er das handisch macht. Es kann sein, wenn die neueste Version raus ist, dass es ein paar Stunden dauert, bis die Composer verfügbar sind. Was man machen sollte, ist ein eigenes Verzeichnis definieren für WordPress. Ansonsten ist Standard im Fender, Verzeichnis installiert. Standard wird eigentlich üblicherweise komplett außerhalb der Document-Root genutzt, damit es nicht erreichbar sind, weil das halt meist Bibliotheken sind, die man nicht öffentlich aufrufbar haben will. Nacktes WordPress ist natürlich langweilig. Man will natürlich auch Plugins und Teams installieren. Es gibt das WP-Packages.org. Da werden alle Plugins und Teams, die auf WordPress.org verfügbar sind, als Composer-Paket zur Verfügung gestellt. Da kann es auch halt sein, dass es nicht die neue Version nicht direkt verfügbar sind. Also muss man auch ein bisschen gucken, dass es auch mit ein paar Stunden Spätung verfügbar ist. Sonderigkeit mit den ganzen Plugins und Teams, dass man das getrennt macht von den WordPress Core. Weil es ist halt so, wenn ein WordPress Update kommt, wird erstmal alles gelöscht. Und dann die aktuellen Pakete installiert. Das heißt dann, wenn man Plugins installiert hat im WordPress-Verzeichnis und man kriegt ein WordPress Update, das erstmal alles gelöscht wird und die Plugins sind dann halt auch weg. Deswegen sollten das in separatem Verzeichnis gemacht werden. Am Anfang ist mir das passiert. Ich habe erst mal gedacht, warum sind die Plugins jetzt weg? Das ist halt der Grund. Man kann es halt definieren, wo es installiert wird. Natürlich, wenn man die Struktur ändert, muss man das WordPress Bescheid geben, dass sich die Struktur geändert hat. Das macht man halt über Konstanten wie WP Home, Site URL, Content URL. Damit man halt sagt, wo die Startseite liegt, wo WordPress Core liegt und wo die ganzen Content Sachen liegen. Wenn man Composer nutzt, kann man auch das Auto-Loading nutzen. Aber das braucht man nur, wenn man tatsächlich PAP-Pakete da nutzt. Also optional. Wenn man Composer nutzt, um alles zu verwalten, sollte man das Allow File Mods auf True setzen. Das heißt, dass man im Backend keine Aktualisieren mehr machen kann, weil man das über Composer macht. Man kann Composer halt nur ums zu installieren, dass man danach, wie man wohnt, das über das Backend eine Aktualisierung machen muss. Man muss natürlich gucken, was man machen will. Man muss natürlich eine neue Index per P haben, um zu sagen, wo das WordPress Core liegt. Dann hat man halt so eine Struktur, wo alles liegt. Man kann natürlich auch sagen, dass man das anders machen will. Manche sagen von WP Content will ich nicht, weil das ist ja ein Standard-Wertpress, irgendwie eine Sicherheit, weil sie einen anderen Namen haben. WP ist irgendwie so das übliche, aber manchen ist halt der App oder CMS. Das kann man halt frei wählen. Und das Fender Verzeichnis, ich war halt immer den Standards bei. Es gibt auch viel deutlich, wie sie das WP Content Verzeichnis legen. Ich mach das halt nichts, weil es Fender Verzeichnis eigentlich nicht erreichbar sein sollte. Wenn man Composer nutzt, um seine Webseite zu verwalten, kann man auch für die Sicherheit noch was Extras tun. Man kann die Dateirechte über zwei Benutzer verteilen. Einmal den Webserver benutzen, das hier WBW Data ist. Und im Prinzip braucht nur das Uploadsverzeichnis, Schreibrechte für den Webserver. Die anderen Verzeichn werden dann über den SSH-User verwalten, aktualisieren. Vorteil ist halt, dass WordPress selber da nicht schreiben kann, weil es einen anderen Benutzer gehört. Also wird man weniger schnell gehackt. Weil WordPress halt in den Verzeichnen, Blockins und Teamverzeichnungen nicht schreiben darf. Natürlich, es gibt so Standard-Pakete, aber bei jedem Projekt ist es ja üblich, dass man auch selber Sachen programmiert. Das kann man halt auch über Composer abdecken, dass man halt geht, repository definiert. Und sagt, von da liegt mein Plug-in und bindet das über Composer ein. Man kann auch kommerzielle Pakete einbinden. Da muss halt das Plug-in halt erreichbar sein über eine URL, hier zum Beispiel Advanced Costs and Fields Pro. Da muss man halt seine Lizenzschlüssel eingeben und dann kann man das direkt über Composer einbinden. Das machen nicht alle kommerziellen Anbieter. Bei Advanced Costs and Fields Pro hatte man das Problem, dass man das nur über HDTP erreichbar ist. Der Standard ist Composer, das hat TPS, also muss man abschalten, die arbeiten daran, hoffentlich schnell. Aber wenn man es nicht öffentlich aufrufen kann, dann muss man halt ein eigenes Composer-Repository erstellen. Das geht mit Satis. Das ist ein Quando-Zeilenprogramm, wo man die Pakete definieren kann und der generiert dann handisch so ein Repository. Wenn man etwas komfortabel haben will, kann man Torrand-Proxy nehmen. Der macht alles automatisch. Der ist für persönliche Nutzung kostenlos. Der Kommatelle-Nutzung muss man in die Lizenz kaufen. Mit Torrand-Proxy wird auch das Hosting von Packages bezahlt und die Entwicklung von Composer. Also es hilft das Projekt auch weiter, wenn man da eine Lizenz kauft. Man kann gucken, ob sich alle Pakete über ein Proxy laufen lassen oder nicht. Man definiert halt so ein Composer-Repository und man sagt Packages Falls. Das heißt, dass man Packages des Standard-Repositories komplett abschalten, alles über das Repository laufen lässt. Der Vorteil von so einem Repository ist, dass man auch eigene Pakete einbinden kann und alles dann halt über eine URL im Prinzip erreichbar ist. Wenn man ganz viele Pakete hat, dann kann es natürlich passieren, dass es immer langsamer wird. Hier gibt es ein Paket für Composer, das Prestissimo heißt, das dafür sorgt, dass man Pakete parallel installieren kann und das bringt noch einen performant Schub. Es ist interessant, wenn man halt ganz viele PRP-Pakete über Composer installiert. Natürlich mit Composer hat man definiert, was wie sein Setup ist und das macht natürlich Sinn, das zu versionieren, weil man halt ständig weiterentwickelt und natürlich seine Änderungen zeilen will, wenn man in einem Team arbeitet, dass jeder irgendwie über Git alles verfolgen kann und alle Änderungen, die eine Person macht, halt auch mitbekommt. Composer unterstützt auch Subversion und Mercurial out of the box, aber ich glaube, dass alle Git nutzen. Gibt es Leute, die was anderes nutzen? Ja, stimmt. WordPress ist dann auf Subversion, obwohl die natürlich auf GitHub jetzt mirrored werden. Also geht es irgendwie das Standard-Tool. Ich benutze das immer, die Kommandezeile auf der Git-Website stehen, auch eine Liste von Clients, die man nutzen kann, wenn man nicht so gerne über die Kommandezeile arbeitet. Muss man mal schauen. Natürlich, wenn man Git nutzt, muss man gucken, was wird im Git Repositiv eingecheckt und im Git Ignore sagt man halt, was man nicht einchecken will. Was man nicht einchecken sollte, ist das ganze Fender-Verzeichnis, weil das sind alle Bibliotheken, die man in Composer halt definiert hat und über die Composer-Datei weiß man, was man braucht und das braucht man halt nicht, in Git einzuchecken. Was man auch nicht einchecken braucht, ist das ganze WordPress Core und das ganze Content-Verzeichnis, die Plankins, Teams und über Composer definiert und Uploads, also ich kenn keinen, der die Uploads auch in Git eincheckt, weil das ist ja auch der Produktivschein, wenn Sachen hochgeladen, das kriegt man ja eh nicht mit, was da hochgeladen wird. Das sollte man halt nicht einchecken. Es kann aber sein, dass man halt Composer nimmt, hat ein Projekt, halt Arbeit und bestimmte Sachen, halt im Content-Verzeichnis-Plugins. Ich mach, oft dass ich so ein Must-Use-Plugins nutze, um für die Seite bestimmte Sachen zu definieren. Weil natürlich sagt man, Content-Verzeichnis nicht mitnehmen, kann man nochmal explizit den Ausrufe zeigen, halt definieren, alles ignorieren, außer dass M.O. das soll mit Git aufgenommen werden. So kann man halt selektiv Sachen auswählen, die Git-Reponse, die mitgenommen werden oder nicht. So die einfachste Weg, um mit Git zu arbeiten. Wenn man Git hat, kann man halt so unterschiedliche Strategien fahren. Das Einfache ist, dass man halt ein Dev-Master-Branch hat, also die einzige Branch, die man am Anfang hat. So fängt eigentlich jeder an, so kann man auch arbeiten, dass man halt alle Änderungen in den Master-Branch eincheckt und halt so arbeitet. Wenn man alleine arbeitet, ist das eigentlich kein Problem. Wenn man ein Team arbeitet, ist natürlich klar getrennt, Bereich hat, wo jemand arbeitet. Dann funktioniert das auch eigentlich ganz gut. Wenn man ein Schritt weitergehen will, kann man Git-Tags nutzen, um bestimmte Versionen zu definieren. Wenn man zum Beispiel ein Paket abgearbeitet hat mit allen Entwickler, kann man sagen, von jetzt ist es eine Version, die wir jetzt releasing, die man dann auch später mit Kompose zum Beispiel auschecken kann. Man kann natürlich auch sagen, ich benutze Branches. Branches haben halt ein Vorteil, dass man als Arbeiten getrennt abarbeiten kann. Dass man ein bestimmtes Feature arbeitet oder ein bestimmtes Plugin. Wenn die fertig sind, dann als Master-Branch merged. Git ist eigentlich egal, ob man lokal Branches macht oder remote Branches. Das muss halt definieren. Remote Branches haben halt den Vorteil, dass man komplett getrennte Repositories definieren kann. Das heißt auch, dass man mit unterschiedlichen Freiburg-Lufler oder unterschiedliche Agenturen arbeiten kann. Und sozusagen von, dass man eine Repository nimmt, um die Website zu verwalten. Ein separates Git Repository für das Team, für das Frontend-Entwickler und die Designer dran arbeiten und ein separates Repository für Plugins. Dass halt die Backends und Entwickler nur am Plugin arbeiten, dass das alles getrennt wird. Vorteil natürlich am Plugins separat. Repository installiert, dass man das auch in anderen Projekten dann einfach wiederverwenden kann. Was manche Leute auch machen, dass man halt die komplette Umgebung und separaten Git Repos nutzt und so auch so ein Deployment Workflow macht. Weil man hat ein Dev Repository, wo man z.B. jede Änderung automatisch die Tests anstößt, um zu gucken, ob alles noch funktioniert. Dass man halt auf Staging-Bereich ein Repository macht. Und zu gucken, dass der Kunden das freigeben soll. Und weil es freigegeben ist, dass man als Produktionsrepository shape damit man komplett nachverfolgen kann, wie in Produktionen der Verlauf war. Man kann natürlich ein Feature-Clone machen, wenn man ein neues Feature, dass man ein eigenes Repository macht. Das ist was man bei GitHub halt macht. Man hat GitHub Repository, man forkt das Repository und dann macht man Pool-Request und muss dann wieder zurück zu versionen. Und das sind komplett getrennte Git Repositories. Dann muss man halt gucken, wie man ein Team arbeitet, was im Projekt Sinn macht. Ich arbeite meistens mit der Dev-Master-Struktur, weil ich dann irgendwie alle Änderungen einsammle und das dann einchecke. Ist bei den Designern noch nicht überall so angekommen, gibt es zu arbeiten, weil das irgendwie ungewohnt ist. Deswegen mache ich das meistens dann. Die ganzen Tags-Geschichten sind wichtig, um die Version zu definieren. Mit GitHub Tag tagt man die Version und das ist die Version, die Composer auch auswerten kann. Also das ist schon wichtig, dass man sich damit vertraut macht und Composer halt auch so nutzen kann, dass man bestimmte Versionen installieren kann. Was zum Beispiel sinnvoll ist, wenn man sagt von Stage, dass man da eine Version installiert und eine Produktion eine andere Version hat, bis der Kunde es freigegeben hat, dass man halt weiß, okay, der Kunde hat die und die Version jetzt freigegeben und die kann ich dann jetzt in Produktion deployen. Was für Composer auch interessant ist, die Git Attributes. Hier hat man Text Auto, das ist irgendwie so eine allgemeine Definition für Entwickler, die halt sagen, manche Entwickler arbeiten mit Windows, andere mit Mac und andere mit Linux und das Problem ist halt, dass auf Windows die Zahlenunbrüchen anders sind als auf Mac und Linux. Und das ist, damit vermeint man, dass die Zahlenunbrüche jedes Mal bei jeder Erderung alle geändert werden, weil dann hat man irgendwie, wenn man Diff macht, sagen wir mal, wo sind jetzt die Änderungen und der Datei hat sich geändert, weil die Zahlen unbrüche ausgetauscht werden, das ist halt so ein Ding, den man vermeiden sollte. Und man kann auch explizit einen Exportignor definieren. Da kann man halt Sachen sagen, die Composer nicht exportieren soll, wenn er es in Git Repository auscheckt. Zum Beispiel, wenn man Plugin installiert über Composer, die Composer JSON Git Ignore ist nicht relevant für WordPress, weil der macht damit überhaupt nichts. Damit kann man halt definieren, dass das nicht mitinstalliert wird, wenn man es über Composer installiert. Das ist halt so eine eigene Git-Sache. Was man auch noch machen kann, ist Git Hux nutzen. Das habe ich selber noch nicht gemacht. Aber es ist interessant, wenn man so ein Continuous-Delivery-Workflow machen will. Mit Git Hux kann man halt sagen, wenn etwas in Git Repository gepusht wird, dass automatische Aktionen ausgeführt wird. Das ist interessant. Zum Beispiel bei Continuous Integrations, sagt man, ein Entwickler macht ein Git Push, und dann werden automatisch alle Unities ausgeführt. Man kann halt sehen, von was da passiert. Man kann sich dann Schritt weitergehen, wenn man ein Produktionsrepository hat. Alle Änderungen werden in das Repository gepusht, dass ein automatisches Deployment gestartet wird. Es ist nicht ganz ohne, um so etwas aufzusetzen, weil automatisiert heißt auch, es muss funktionieren. Das muss man halt vorher alles durchtessen. Was da interessant ist, wenn man so etwas angehen will, die 12-Factor-App-Methodologie, sich mal durchzulesen. Das wurde extra entwickelt für Continuous-Delivery, weil immer mehr Unternehmen und Projekte sagen, jede Änderung soll komplett automatisch in Produktion gepusht werden. Das ist halt so eine Methodologie, womit man das machen kann, das ganz hilfreich sein kann, das zu befolgen. Das wurde von Leuten von Heroku entwickelt, ursprünglich. Das ist halt so eine Cloud-Lösung, wo Continuous-Delivery halt ein wichtiges Thema ist. Wenn man das Projekt starten wird, gibt es halt Leute, die schon etwas gemacht haben, irgendwie Backrock ist das bekannteste Projekt. Wir haben also ein Setup, alles vorgekonfiguriert, was man nutzen kann. Andreas Heigel hat auch was gemacht, um mit Fagrants automatisch was zu machen. Hollow Tree ist von Joss Pollack, die Caldera-Forms macht. Das ist eine neue Webseite, die aktuell daran arbeiten, und er hat alles veröffentlicht, wie er das nutzt. Also ein Praxisbeispiel. David Zulke hat für Heroku sein WordPress eröffentlicht. Interessant natürlich, wenn man irgendwie mit Heroku arbeitet, habe ich keine Erfahrungen mit, aber das wäre eine gute Basis. Letzte Punkt ist halt so ein Setup, was ich mache, was meine Basis-Konfiguration, die ich nutze, und da stehen halt alle Plugins, die ich mal irgendwo eingesetzt habe, weil ich immer vergessen habe, bei welchem Projekt habe ich jetzt welches Plugin genutzt. Und ob man halt auf WordPress Org sucht, dann findet man irgendwie für jedes Ding 20 Plugins, und dann muss man gucken, welches war es jetzt, was ich für ein bestimmtes Projekt genutzt habe. Ein ganz letztes Feature von Composer ist, dass man halt Projekt definieren kann, dann über Composer Create a Project starten und komplett automatisch und komplett das WordPress Setup generiert wird. Da kann man auch selber definieren, Bedrocknis ist halt auf Packages verfügbar, man kann sich also ein eigenes Repo erstellen und so einfach sagen, wenn ein neuer Entwickler kommt von, okay, hier ist unser Projekt, gibt das Composer Create a Project, an einem Projektname, und dann mit Inhalte von Minuten wird ein komplettes WordPress-Projekt installiert. Da kann man natürlich über Composer Script so weit treiben, wie man will, dass man auch eine komplette Fagalboxen zur Verfügung stellt. Ich mache es meistens noch irgendwie lokal. Und das geht ganz einfach, man kommt bei jason datum und sagt Type Script und dann kann man als Composer Create Project nutzen. Und damit bin ich auch am Ende von meinem Vortrag und ich will sagen, ich hoffe, dass es irgendwie interessante Ansätze für euch gegeben hat und es jetzt nutzen wollte und sagt legt los. Ich will es, wie gesagt, bei Schleitscher hochladen und danke fürs Zuhören. Gibt es Fragen? Die Anmerkung war, dass Sternen, dass es problematisch sein kann. Es ist korrekt, weil man natürlich, wenn man eine Majorversion hat, dann sind halt Änderungen, die nicht kompatibel sind. Im WordPress-Unfeld ist es meistens nicht so problematisch, weil irgendwie alles rückwärtskompatibel ist. Ich mag es halt so, dass ich immer den Asterisk halt nehme für WordPress-Projekte und dann, wenn es irgendwo Probleme geht, dass ich dann erst eine Version definiere, muss man halt gucken und testen, bei welchen Sachen es Probleme gibt und nur da definiere ich eine Versionsnummer. Das ist halt so, wie ich es mache. Die Frage war, wenn Plugins installieren, ob die Abhängigkeiten mitinstalliert werden. Die Antwort ist ja, alle Abhängigkeiten, wenn mitinstalliert, wenn die halt in der Composer Jason von den Plugins richtig definiert sind. Ich benutze Composer nicht, um Plugins zu entwickeln. Natürlich, die Leute, die das machen, zum Beispiel Yoast SEO benutze Composer, um Yoast SEO zu entwickeln. Ich mache das immer händisch und ich definiere meinen Autoloder im Plugin über die SPL Autoloderfunktion in PHP. Bald Composer an sich nicht ausgelegt ist, um mit Composer zu arbeiten. Es gibt ja Diskussionen, dass WordPress mehr mit Composer funktionieren soll, aber das wird irgendwie rückgestellt und ich glaube nicht, dass es irgendwann kommen wird. Ich benutze das halt auch, um... Das Fender-Verzeichnis benutze ich um alle Packetsabhängigkeiten dazu installieren und nicht im Plugin, wie ich es halt mache, aber muss man halt gucken, wie die anderen Plugins das kann passieren, dass man Konflikte kriegt, weil ein Plugin in bestimmte Versionen von Bibliothek benutzt und ein anderes Plugin ist gleich Bibliothek, aber in einer anderen Version, aber das ist ein allgemeines Problem, was man mit Composer nicht umgehen kann, weil man zweimal das gleiche Paket nutzt an unterschiedliche Versionen. Ganz hinten. Die Anmerkung war halt, es sind Get Attributes, dass den Autolorder das dann alles lesen kann und die richtige Version dann installieren kann. Danke. Ich mache... Die Frage war halt, wenn man Plugins installiert, wie man die Aktivierung macht. Ich benutze halt die Composer-Skrips, um über die WPC-Lei dann die Plugins zu aktivieren, aber das mache ich auch nicht, ich habe auch, dass ich die Plugins dann installiere, damit ich halt weise welche Plugins genutze und dann alles klassisch über das WordPress Backends mache. Das ist natürlich abhängig von, wie bei Kunden die Arbeitsweise ist. Ist schon so, wenn man Composer für alles nutzt, dann müssen auch alle Leute wissen, was man so arbeitet. Als paar Leute halt die so klassisch irgendwie im WordPress Backends Sachen ändern, kann das halt zu Problemen führen. Man muss halt dann einen klaren Workflow haben, um alles komplett zu automatisieren. Das muss man sich halt im Team absprechen. Keine Fragen mehr. Also ich benutze Thoran Proxy, um das Problem halt zu vermeiden. Also es kommt vor, das geht auch manchmal nicht erreichbar ist, und dann halt man halt das Problem, wenn es nicht erreichbar ist, dass man es nicht runterladen kann. Also bei den ganzen WordPress Plugins, die, wenn ich meine, jetzt nicht sicher, ob die von GitHub oder direkt von WordPress.org über das Version geladen werden. Also der ruft es auf und man muss natürlich vorher schon mal aufgerufen, während es damit das Paket verfügbar ist. Halt auch den Vorteil, wenn man es halt in der Firma verfügbar hat, dass es auch viel schneller geht, weil man es nicht über das Internet holen muss. Und hat auch irgendwie dasenschutz- rechtlich noch Vorteile, weil GitHub ja sieht ja jedes Paket, was du dir installierst und was vielleicht in Deutschland irgendwie so interessant ist. Okay, dann vielen Dank.