 Die Wunder der Technik. Hallo, herzlich willkommen. Versteht ihr mich ab da oben? Perfekt, schön. Wunderbar, die Wunder der Technik überzeugen immer wieder. Ich heiße euch recht herzlich willkommen. Zum meinem Vortrag WordPress als App Framework. Mein Name ist Birgit Olsson und ich bin hauptsächlich tätig als WordPress-Webdesignerin in einer kleinen Agentur in der wunderschönen Eifel. Und habe WordPress für mich schon vor etlichen Jahren entdeckt und vor allen Dingen die Möglichkeiten, die man mit WordPress mittlerweile umsetzen kann. Wer von euch setzt WordPress ein für mehr als nur zum Bloggen oder eine Website erstellen? Oh ja, klingt ja schon gut. Ich bin mal gespannt, ob ich euch noch was Neues erzählen kann. Gut, ich würde gerne damit starten, wenn mein Presenter laufen wird. Da haben wir es. WordPress kennen wir ja eigentlich als ursprüngliche Software zum Bloggen. Und die Frage ist, ist WordPress auch eventuell als MVC zu nutzen? Wer von euch kennt den Begriff MVC? Oh ja, also erzähle ich euch ja echt nicht viel Neues. Noch mal ganz kurz, MVC ist eine Abkürzung für Controller, View und Model. Und wir können WordPress einsetzen als MVC, indem wir WordPress als Model sehen. Und wir haben praktisch unser Endgerät. Jeder von euch kennt hier Smartphone und so weiter, das ist unser Client. Unsere App, die wir hier drauf haben, ist praktisch unser Dispatcher und Controller in einem. Und fragt praktisch die Daten ab vom Model und sendet auch die Daten praktisch zum View. Ihr merkt, ich bin keine Entwicklerin, deswegen... Kann es sein, dass ich mich vielleicht in manchen Termini nicht so gut bewege, wie man die anderen von euch. Und hier habe ich mir ein paar Gedanken gemacht, wie man WordPress praktisch als MVC darstellen könnte. Model beispielsweise wäre, wir speichern die Benutzerinformationen in der Datenbank. Das View ist praktisch unser neues Formular. Formular für Benutzerregisterung beispielsweise. Und der Controller sammelt halt die Daten, verarbeitet die Daten und schickt sie dann praktisch wieder zurück, so wie wir uns vorstellen. Was bringt das jetzt nun? Wir haben natürlich, WordPress kennen wir, ist im Prinzip immer auf dem Webserver. Wir haben PHP, PHP verarbeitet die Daten. PHP speichert die Daten letztendlich in der Datenbank und bietet halt wirklich nur die Logik und passt halt eben PHP in HTML. Und unser Webserver ist natürlich auch für verantwortlich, dass das auch ordentlich als HTML ausgeliefert wird. Und natürlich auch für die Ausgabe zuständig. Haben wir jetzt aber einen Klienten, also praktischen Smartphone, Endgeräte, eine andere Applikation, brauchen wir natürlich einen ganz anderen Weg. Da gehen wir natürlich wieder auf den Server, der empfängt und speichert die Daten als Queries. Das Server gibt halt eben dann diese Daten als JSON-Objekt aus. Und der Klient ist verantwortlich für die Datenverarbeitung und der Klient ist verantwortlich für die Ausgabe. Das ist natürlich ein ganz anderer Ansatzpunkt. Wir haben zwar immer noch WordPress als Backend-Lösung, aber im Frontend können wir es ganz anders darstellen. Und dafür brauchen wir ein kopfloses CMS. Kopfloses CMS, auch Headless genannt, wird zur Datenaufnahme, zur Datenspeicherung und zur Auslieferung von strukturierten Daten fürs Frontend genutzt. Was heißt das? Wir haben praktisch nur unsere Backend-Lösung, also unsere Redakteure und Autoren haben die Möglichkeit, WordPress ganz normal zu benutzen, ihre Artikel einzupflegen, aber wir geben die Daten halt komplett unabhängig davon in einem anderen Bereich aus. Wir sehen hier, das Frontend im traditionellen CMS hat eine direkte Verbindung zur Datenbank und im Headless CMS sind wir abgekoppelt. Das heißt, wir haben wirklich die Möglichkeit, die Ausgabe von der Datenspeicherung zu trennen. Somit haben wir natürlich auch die Möglichkeit, die Anforderungen auch nochmal ganz anders zu deklarieren. Wie viele von euch sind ausgewiesene JavaScript-Entwicklerinnen? Kennst du die sehr gut mit WordPress PHP-Entwicklung aus? Auch gut. Das heißt also, wenn du jetzt zum Beispiel eine Funktion bekommst, WordPress liefert dir praktisch alle Daten als JSON-Feed aus. Was würdest du damit machen? Wenn du jetzt eine App entwickeln willst oder eine andere Frontend-Technologie nutzen möchtest, was würde dir das bringen, wenn du Daten aus WordPress ziehen kannst, um die anderweitig darzustellen, unabhängig jetzt vom WordPress-Seam beispielsweise? Hast du so was schon bis jetzt umgesetzt? Hier ist genau das, was ich eben meinte. Wir haben WordPress als Backend und haben die multiple Ausgabemöglichkeit. Wir können es einfach ganz normal auf dem Desktop ausgeben, wie wir es gewöhnt sind, entweder mit einem WordPress-Seam, ganz klassisch. Wir können es natürlich aber auch die Daten strukturiert verarbeitet auf dem Smartphone ausgeben, auf dem Tablet, Smartwatch oder halt eine komplett andere eigene Web-Anwendung. Ich habe mir so ein paar Gedanken gemacht, was könnten die Gründe sein, WordPress als ein sogenanntes Headless-CMS einzusetzen und vorhaltigen. Was mich halt fasziniert an der WordPress-API, wollte ich euch hiermit zeigen. Entschuldige, ich bin gerade ein bisschen mir fehlen meine Notizen. Im Prinzip haben wir schon mal die Möglichkeit, kontextspezifische Lösungen zu entwickeln. Das heißt, wenn ich jetzt sage, ich möchte eine App entwickeln und brauche aber praktisch meine Daten in der Backend-Lösung und kann dann meine Daten praktisch genau für diese Lösung zusammenstellen, ohne dass ich letztendlich was komplett Eigenes programmieren müsste. Dann habe ich die Möglichkeit, diese Inhalte, die einmal zentral gespeichert sind, auch immer wieder zu verwenden in anderen Formen und habe halt auch die Möglichkeit, diese Inhalte auch mobil darzustellen oder auszuliefern. Und dann auch der Punkt, wir haben die Anforderungen, was ich eben angesprochen habe. Das heißt, ein WordPress-Entwickler muss nicht mehr zwingend Javascript lernen oder so tief lernen, dass man damit auch Apps entwickeln kann. Und ein Javascript-Entwickler muss jetzt nicht mehr zwingend die Backend-Möglichkeiten von WordPress vollumfänglich nutzen, verstehen, PHP lernen und so weiter. Hier können Verantwortlichkeiten und Fähigkeiten kombiniert werden. Das heißt also, wenn ich jetzt die Daten, die ich in WordPress habe und als sogenannte strukturierte Daten-Jasen-Feed ausgebe, kann derjenige, der fit in der App-Entwicklung ist, die Daten einfach nehmen. Und der WordPress-Backend-Spezialist stellt die halt eben auf eine andere Art und Weise dann zur Verfügung. Und daher haben wir aber auch noch die Möglichkeit, für Autoren und Redakteure wirklich eine gewohnte Umgebung zu erhalten. Das heißt, das Backend, unser klassisches Dashboard kann trotzdem bestehen bleiben, aber die Daten, die in der Datenbank gespeichert sind, werden einfach gut und strukturiert ausgegeben. Zum Beispiel auch als Single-Page-Application. Mit der Single-Page-Application haben wir die Möglichkeit, auch die Daten auszugeben, jeder kennt das, Ajax, ohne dass wir die Saate nochmal neu laden. So, wie kann jetzt WordPress zu einem Headless CMS werden? Natürlich mit der WordPress-Rest-API. Wir haben in der WordPress-Rest-API auch sogenannte Datenbank-Operationen, CRUD genannt, ich denke mal viele von euch kennen das. Zur Verfügung stehen einmal die Möglichkeit, also Post-Meter, Post-Revision, Pages, Media-Comments, Taxonomies, Terms und Users auch bearbeiten können. Das heißt, wir können all diese Elemente bearbeiten, wir können erstellen, wir können sie lesen, wir können sie aktualisieren und auch löschen. Das heißt, wenn ich jetzt eine App habe und habe mich verknüpft in meinem WordPress-System, habe ich die Möglichkeit, direkt meine Inhalte zu verändern. Wir sammeln die Daten über den JSON-Feed. Und das ist, dass wir WPJSON slash WP slash V2, somit der aktuelle Domain-Aufruf, die WPE API ist im Moment auch in WordPress im Core. Und dadurch haben wir schon einige Möglichkeiten zur Verfügung, die wir dann halt erweitern können. Wir haben zum Beispiel die Möglichkeit, die bestehende WordPress-API auch zu modifizieren. Das sieht man hier sehr schön. Wir haben hier den EdFilter und nutzen den Filter RestPreparePost und sagen, ich möchte zum Beispiel die Daten vom Sticky. Alle, die in der Postmeter drin sind, Sticky möchte ich nicht in meinem JSON-Feed haben, also nehme ich die raus. Oder ich kann halt Daten ergänzen mit einem ganz kurzen Code Snip bit. Ich sage, ich möchte hier ein neues API-Feld registrieren, randomisierte Info beispielsweise und dann habe ich hier mein Callback. Und das Gleiche gilt natürlich auch für Daten zu entfernen. Hier kann ich halt diverse Endpunkte, in dem Fall jetzt die Media und Comments, kann ich hier einfach rausleschen aus meinem JSON-Ergebnis. Was jetzt auch die Macht von der WordPress-API ist, ich habe die Möglichkeit natürlich auch eigene Endpunkte zu registrieren. Und das ist letztendlich auch das Schöne dabei. Das heißt, ich habe jetzt beispielsweise eine Restaurant-App, die hat ein Custom-Post-Type mit Menü und Speisekarte. Und wenn ich diese Endpunkte einfach in meinem JSON-Feed haben möchte, kann ich die halt hier rüber erstellen und registrieren. Das Gleiche gilt dann auch dazu, neue Routen zu den Endpunkten zu kreieren, um dann auch noch mehr Einfluss auf die Darstellung im Feud zu haben. Bitte. Hier kam jetzt die Frage, was es bedeutet, Endpunkte und Routen zu haben. Endpunkte heißt, du hast den allgemeinen Aufruf, entweder musst du dann in einem Aufruf, hast du ja WPV2, also WPJSON, und dann hast du POST und dann musst du deinen Query hinten dranhängen. Also immer mit eckiger Klammer, was willst du haben? Also praktisch dann kompletten WordPress Query in einzelnen Punkten. Und hier kannst du darüber schon direkt diese Queries in einer Funktion packen und als eigenen Endpunkt definieren. Und dann brauchst du nachher im Endpunkt um dann WPJSON slash, was weiß ich in dem Fall, CBV2 aufzurufen. Und bei den Routen siehst du das ja auch, dass du dementsprechend auch sagen kannst, ich kann definieren wie viele Beiträge möchte ich pro Ausgabe haben oder welchen POST-Status und so weiter. Das heißt, ich habe da die Möglichkeit, ganz klar zu definieren, was will ich in meiner JSON Ausgabe haben. Welche Daten, welche strukturierten Daten will ich überhaupt? Welche brauche ich überhaupt? Welche brauche ich nicht? Und das ist halt eben, was mir daran so gut gefällt, dass du wirklich ganz klar für dich sagen kannst, die Daten will ich in meiner Anwendung ausgeben und modifizieren und so weiter. Dann kommen wir noch zum Thema Sicherheit. Ich meine, wir können zwar viele Inhalte lesen, aber auch bearbeiten, können wir die nur mit Authentifizierung. Und es gibt halt auch mehrere Möglichkeiten, wie halt im Seams Plugins. Wir können natürlich auch die Basic Authentifizierung nehmen oder OAuth 1, das ist das Moment, was in der Production ist. Das heißt also, wenn ihr euch mit Daten, also dass ihr Daten in die WordPress-Datenbank schreien schreiben wollt über die API, solltet ihr euch mit dem Thema auf jeden Fall näher auseinandersetzen. Ich habe ein paar Anwendungsbeispiele gesammelt, aber nicht so viele. Ein Beispiel ist zum Beispiel die Nomadbase. Ich weiß nicht, wer von euch hat sich da schon registriert. Nomadbase ist ein Projekt von HumanMate und die ist praktisch eine Live-Map, wo ich mich einloggen kann und sagen, ich bin jetzt, hey, ich bin jetzt in Nürnberg und meine Freunde sind entweder in der Nähe oder werden jetzt als digitale Nomaden, wer ist gerade wo. Das ist halt eben auch komplett mit WPI umgesetzt und zieht eben auch Daten aus Facebook, Instagram, Swarm und Twitter und es ist eigentlich ganz interessant gelöst. Also, wenn noch kein Invasion-Code hat und schnell ist, hier sind zwei Stück, schreibt es euch auf, wenn ihr da Zugriff haben wollt. Was auch noch ein schönes Beispiel ist, ist das Plug-in-WP-Live-Search. Das greift auch praktisch auf die WPAP zu. Das heißt, wir können damit auch direkt mit AJAX-Squareys direkt unsere Inhalte auch im Frontend darstellen. Ein recht beliebtes Plug-in ist das App-Presser bzw. Reactor-Core. App-Presser ist ein Online-Service, ein Anzess. Die bieten an, dass man eigene Apps praktisch über die eigene WordPress-Installation füttern kann. Für meine empfinden zu wenig Leistungsumfang für das, was es kostet. Aber die Core-Version ist kostenfreie und man kann sie auf jeden Fall für sich schon mal als Beispiel als Erweiterung nutzen. Dann gibt es noch das Plug-in-ACF zu WPAP. Ich sprache davon, dass man die WPAP mit eigenen Endrouten bestücken kann. Ich weiß nicht, wer von euch setzt das Plug-in als WPAP ein. Der wird sicherlich schon gemerkt haben, dass es nicht so einfach ist, die Rest-AP reinzuholen. Du nutzt das Plug-in auch. Vielleicht magst du berichten, welche Erfahrungen du damit gemacht hast. Man hat die Möglichkeit, die Felder, die man mit dem WPAP Plug-in in der Backend-Installation eingelegt hat, auch dadurch einen JSON-Feed auszugeben. Eine ganz interessante Variante ist auch das WPAP zu AngularJS. Vereinfacht vor allen Dingen den Zugriff, wenn man mehr mit AngularJS arbeiten möchte, Front-End-Applikation mit AngularJS umzusetzen. Hier haben wir schon praktisch eine vorgefertigte Lösung, ohne dass man selbst noch was programmieren muss. Eines meiner Lieblings-Applikationen ist der WordPress Hybrid Client. Mit dem experimentiere ich jetzt auch schon eine Zeit lang. Leider lässt mein Windows-System das nicht so zu, wie ich es gerne hätte. Deswegen bin ich noch nicht an dem Punkt, wo ich gerne angekommen wäre. Linux und Mac sind für Entwicklung mit Node.js auf jeden Fall besser geeignet als meine Windows-Maschinen. Hier sind ganz interessante Ressourcen für Apps mit der WPAP, wo es gerade so Thema Ionic Framework geht, womit man wirklich Apps auch cross-platform entwickeln kann. Hier hätte ich noch ein kleines Live-Beispiel, wie ich mit dem Food-and-Drink-Menu die JSON-API ein wenig aufgebohrt habe. Jetzt muss ich aber mal ganz kurz hier ran. Ich habe hier jetzt eine kleine Beispielseite von meinem befreundeten Lieblings-Italiener. Die habe ich jetzt einfach nur zu Demo-Zwecken aufgebaut. Seine Webseite sieht natürlich ganz anders aus. Aber hier habe ich jetzt beispielsweise das Plug-in-FTM-Menu, also Food-and-Drink-Menu eingesetzt. Man sieht letztendlich, dass man hier die ganzen Gerichte, Pasta, Vegetarisch und so weiter, zwar im Frontend darstellen ganz klassisch mit einem WordPress-Seam. Jetzt möchte ich aber diese Daten in eine App verpacken, dass man praktisch auf dem mobilen Endgerät auch einen Zugriff auf die Speisekarte hat. Dazu habe ich mir einen Plug-in geschrieben, womit ich praktisch meine FTM-Menu-Elemente auch als eigene Routen- und Endpunkte definiere. Die links zu den Plug-in und so weiter gebe ich euch gerne später durch. Und hier sieht man, wie der JSON-Feed aufgebaut ist. Ich habe hier oben praktisch den Namen, Pizzeria, Costa Verde App, Demo, meine URL und hier sind die Namespaces. Da finden wir übrigens die Endpunkte wieder. Und dann siehst du hier die Routen. An dem Methode ist in dem Fall Get. Und hier könnte ich dann praktisch die ganzen Elemente noch mal weiter strukturieren und aufbauen. Wenn ich jetzt weiter runter scroll, haben wir dann hier auch die ganzen Elemente. Und ich will jetzt aber in Speisekarte. Und hier sehe ich auch direkt meine Endpunkte-Speisekarte. Und hier komme ich zum Beispiel auch in meine Menü-Elemente. Hier habe ich meine Menü-Kategorien-Kategories und hier ist das Beispiel für meine benutzerdefinierten Endpunkte und Routen. Ich habe hier ganz kleinen Schäden. Ich möchte nur die Kategorien ausgeben. Den Namen, die Beschreibung und auch die Termorder. Ich habe jetzt in dem Fall auch einen Plug-in eingesetzt. Custom Post Type Order. Und habe gesagt, ich möchte in der bestimmten Reihenfolge die Taxonomy ausgeben. Zum Beispiel die Kategories. Und hier unten kommen dann schon direkt meine Items. Item ID-Kategorie halt eben als ID. Mein Titel, die Description, den Preis und halt auch den reduzierten Preis. Das heißt, ich habe hier vollständig strukturierte Daten im Endformat, so wie ich sie brauche, wenn ich sie in eine App einfügen möchte. Fragen bis hierher? Okay, wunderbar. Vielen Dank. Nein. Wie gesagt, es ist für mich als Querensteigerin, das ist immer sehr interessant, was man alles mit dieser Wordpress Rest API machen kann. Ich finde es halt sehr schade, dass noch nicht alles im Koordin ist. Auf der anderen Seite bietet es auch wieder die Möglichkeit, da eigene Ideen zu entwickeln und vor allen Dingen eigene Endpunkte und Routen zu generieren. Welche Einsatzmöglichkeiten man auch damit überhaupt umsetzen kann. Also wie gesagt, ich persönlich bin halt Querensteigerin. Ich baue täglich Webseiten für Kunden im normalen Bereich. Aber das ist halt mein Hobby. Ich interessiere mich unwahrscheinlich dafür, was ich damit machen kann. Und ich freue mich jetzt über Austausch mit euch. Welche Ideen habt ihr oder welche Erfahrungen habt ihr bis jetzt mit der Wordpress API gemacht? Also die Frage war, dass es für den ersten Blick sehr umfangreich und verwirrend sein kann. Ist das richtig? Und dass man nicht direkt weiß, was ist jetzt schon im Core in der Funktionalität drin und was nicht. Habe ich das richtig verstanden? Also im Prinzip brauchst du in der Core-Installation einfach nur WP-JSON einzugeben. Und dann siehst du schon direkt, was im Core letztendlich schon verfügbar ist. Wenn ich das Richtige im Kopf habe, Post und Pages. Und dann halt eben die üblichen Postpages Queries, die du nutzen kannst. Die müssten jetzt eigentlich meines Erachtens im Core schon mit dran sein. Da installierst du letztendlich auch nochmal, dass du die Taxonomies, die Terms, alles auch noch mal als eigener Endpunkt dann bekommst. Also praktisch die Funktionalität. Aber das findest du wunderbar, auch auf WP-API.org. Da ist eigentlich auch sehr gut erklärt. Auch gerade unter der V2 hast du eine sehr gute Dokumentation, was eigentlich das Plug-in noch mitbringt an Möglichkeiten. Und da ist auch auch sehr gut erklärt, wie man Custom Endpoints und Custom Roots einrichtet. Jetzt arbeiten ja noch mehr von euch. Wer hat denn sonst noch Erfahrung? Sören? Hm, okay. Also Sören hat jetzt wie gesagt bis jetzt nur ein wenig experimentiert. Also mit AngularJS und Ionic, sagst du, mit dem Framework. Also das bietet sehr viel. Ja, es gibt viele englischsprachige Tutorials. Also hier kam ja die Frage nach Tutorials. Der Scott Bollinger, ich glaube, der ist auch der Betreiber von AppPressor. Der schreibt viele Tutorials. Allerdings müsst ihr bitte aufpassen, wenn ihr recherchiert. Viele Tutorials basieren noch auf der Version 1 der WordPress API. In der Version 2 gibt es eben auch neue Namespaces, die man beachten muss. Aber ich denke mal Tutorials wird es in Zukunft noch mehr geben. Hoffe ich zumindest. Also die Empfehlung für weitere Tutorials ist Smashing Magazine und Tutsplus. T-U-T-T-S. Ja, genau. Ja. Wie gesagt, es ist ja nicht nur so, dass man mobile Apps damit entwickeln kann oder die Daten nutzen kann, sondern halt eben auch für Frontend Anwendungen. Es gibt jetzt ... HumanMate hat ein ganz tolles White Paper rausgebracht. Das ist auch hier unten verlinkt. HumanMate WordPress Rest API White Paper. Das geht noch ein bisschen ... noch ein bisschen detaillierter in die Thematik ein. Da findet ihr auch noch mehr Beispiele. Ja, also wer einfach nach WordPress Rest API sucht und Anwendungsbeispiele bzw. Tutorials findet mittlerweile einiges. Aber die beste Empfehlung ist wirklich, sich Gedanken zu machen, welche Daten will ich überhaupt arbeiten haben und dementsprechend sich dann die eigenen Endpunkte definieren, damit man sie dann ausgeben kann. Die Frage, ob es ein Team gibt, dass es schon die Rest API als Single-Page-Application ausgibt. Ich weiß, es gibt ein Team, das nennt sich Picard, Pilot der Captain der Enterprise. Entschuldigung, ich bin kein Schrecki. Das setzt tatsächlich Rest API ein. Dann ist dieses Feeling Rest Tule. Es ist auch glaube ich ein HumanMate Projekt gewesen für diesen Rest Tule Day. Das ist auch ein Single-Page-Application und das ist auch Open Source. Es gibt es auch ... von Feeling Rest Tule, von diesem Projekt. Wenn man bei HumanMate im Gitarrepo guckt, findet man auch einiges. Die arbeiten auch sehr viel. Scott Bollinger ist eigentlich ein ganz guter Referent. HumanMate arbeitet viel damit. Das ist das, was ich jetzt gefunden habe, auch auf meinen Recherchen. Weil ich bei auch immer auf Tutorialsuche unterwegs bin. Sonst noch Fragen? Ideen? Anregungen? Es ist insofern so. Die Frage ist, ob man auch weiter Plugins einsetzen kann, anstatt jetzt nur dem klassischen WordPress-Installation. Meine Erfahrung ist, du kannst normal deine Funktionalität aufbauen mit den Plugins, die du brauchst. Wenn dein Plugin noch nicht die Rest-API unterstützt, könnte man das über ein eigenes Plugin noch erweitern, indem man einfach diesem Plugin diese Funktionalität gibt. Man kann, wenn man das eigene Custom-Post-Tapes anlegt, auch direkt sagen, ich möchte diesen Custom-Post-Tap der Rest-API zur Verfügung stellen. Also Support. In dem Argument Support. Es gibt viele Plugins, die schon eine Schnittstelle für API mitliefern. Das siehst du aber auch in den Beschreibungen. Zum Beispiel WooCommerce bietet auch eigentlich eine eigene Schnittstelle, aber mittlerweile auch, meines Erachtens auch mittlerweile auch, kompatibel mit der WP-Rest-API. Im Prinzip baust du dir für die Plugins, von denen du jetzt keine Daten sonst geliefert bekommst, einfach über ein eigenes Plugin die Funktionalität, welche Daten willst du aus der Datenbank haben. Weil es ist ja alles im WordPress gespeichert. Du musst es einfach nur als ein eigenes Plugin, also ich nenn es immer WPJs und Add-ons, die dann selbst einfach noch zusammenschreiben, damit du deine strukturierten Daten dann auch bekommst. Sonst noch Fragen? Anregungen? Ideen? Wie man diskutieren könnte? Okay, dann sage ich nochmal recht herzlichen Dank. Ihr seid dann jetzt, was früher in die Kaffeepause entlassen. Ansonsten, ich stehe gerne sonst noch für Fragen draußen zur Verfügung. Dankeschön.