Vorwort

Bei diesem Beitrag möchte wir euch näher bringen, wie man die beiden Technologien WordPress und AngularJS für eine Webseite miteinander verlötet. Zur Abgrenzung, es geht hierbei nicht darum, dass komplette Frontend (Seiten, Beiträge, …) von WordPress in AngularJS zu laden, sondern nur einzelne vorher definierte Seiten. Zwischen diesen Seiten wird dann das Routing von Angular verwendet und der Wechsel zu den normalen WordPress Seiten und Beiträgen soll weiterhin funktionieren. Die unterschiedliche Technologien sollen für die jeweiligen Seiten Ihre Stärken ausspielen. Beispielsweise ist für die SEO (Suchmaschinen-Optimierung) es sehr vom Vorteil, dass die Webseite schon vorgerendert vom Webserver ausgeliefert wird. Der Vorteil beim dem Angular Teil ist, dass dort die große Datenmengen mit weniger Overhead geladen werden und somit die Seite dort auch deutlich schneller reagiert.

ToDo’s

Folgende kleine Teilaufgaben waren für die Verschmelzung zu erledigen. Das „ng-app“-Attribut muss in das WordPress Template integrieren werden, sonst kennt Angular nicht seinen Startpunkt innerhalb des DOM. Angular benötigt für das Routing das „ng-view“-Attribut, damit es weißt an welchen Ort die neue View geladen werden soll. Das Attribut haben wir über das WordPress Backend den einzelnen Seiten zugeordnet. Anschließend müssen die Angular seine Templates bereitgestellt werden. Dazu haben wir ein eigenes Plugin geschrieben, in diesem sich diese Templates bereitzustellen. Als nächstes geht es um das Routing. Da die Anzahl der Seiten bei denen sich Angular um das Routing kümmern soll, relativ gering ist, haben wir uns dazu entschieden ist händisch synchronisiert zu halten. Damit ist gemeint, dass bei den Seiten im Routing auch das ng-view im Content der WordPress-Seite gesetzt ist. Für das Routing muss noch die BaseUrl im HTML Head gesetzt werden und in der Angular Config der HTML5 Modus aktiviert werden.

Tipps und Tricks

In Angular als SPA (Single Page Application) ist es nicht vorgesehen, dass das Routing mit anderen Technologien geteilt wird. Um Angular mitzuteilen, dass es sich beim folgen eines Links nicht um das Routing kümmern soll, gibt es verschiedene Möglichkeiten. Beispielsweise reicht es bei den Links das Attribut target=“_self“ zu setzen, damit Angular weiß, dass es sich nicht um das Routing kümmern muss. Wir haben uns für eine andere Lösung entschieden. Dazu haben wir das Routing um ein „otherwise“ ergänzt. Die nicht gefundenen Routen laufen dort hinein. Dann wird explizit mittels normalen JavaScript ein neuer Browser-Request zu dieser Route ausgelöst. Dies ist für uns die beste Lösung, da wir nur eine kleine Anzahl an Angular Routen benötigten und wir nicht jede möglichen Link in den WordPress suchen müssen um dort Target-Attribut zu ergänzen.

Fallstricke

Beim Verlassen einer Angular Seite und beim Wiedereintritt, muss das komplette JavaScript Model zu Angular erneut aufgebaut werden. Wie beim ersten Aufruf einer Angular SPA. Um dieses Problem zu verringern werden einige Daten über das LocalStorage gecached, anstatt diese erneut beim Server anzufragen. Das dazugehörige JavaScript und Templates werden normalerweise bereits vom Browser gecached und benötigen keiner weiteren Beachtung.

Fazit

Durch die Verschmelzung der beiden Technologien konnten wir das beste der beiden Welten zusammenführen. Alle Schwierigkeiten ließen sich mit relativ geringen Aufwand beheben und der Nachteil des häufigen neu Aufbau des JS Models kann man weiter minimieren und hält sich im Vergleich manchen überladenen Seiten auch noch in Grenzen.