 Jetzt muss ich mich wieder ohne Intro rein moderieren, das ist blöd. Herzlich willkommen im Presswerk, heute live auf dem WordCamp in Soltau vor Publikum, und zwar erstaunlich viel Publikum. Hallo Publikum, ihr dürft Geräusche machen, es ist ein Podcast. Einer hört euch um Himmels Willen. Ich sitze hier mit Felix Arns und wir sprechen über ein Thema, das das Potenzial hat sehr technisch zu werden. Ja, fürchtig. Vielleicht auch nicht. Vielleicht auch nicht. Wir versuchen das irgendwie auf einem akzeptablen Niveau zu halten. Es geht um eine Funktion, die sich, wie ich gestern belehrt wurde, Multi-Network nennt. Bevor wir darauf kommen, Felix, sag vielleicht noch kurz in zwei Sätzen ein bisschen was zu dir, weil ich habe zwankendimitär aufgenommen, aber das liebe ich zuerst für öffentlich. Okay. Ja, ich bin, ja ich bin Plug-in Entwickler, Core Committer und ich, ja bei Wordpress arbeite ich hauptsächlich an der Multisite Funktionalität und bin ursprünglich dazu gekommen, weil ich mit einem Kunden gearbeitet habe, der tatsächlich Multi-Network benutzt hat. Und obwohl ich im Moment nicht mehr viel damit am Hut habe, so direkt, bin ich immer noch deswegen geschädigt davon und bin immer noch sehr stark so daran, da auch am Core so ein bisschen was zu verbessern, auch wenn kommen wir gleich noch mehr zu, dass oft ein, meistens ein Edgecase ist, dass man es nicht so braucht. Bevor wir zum eigentlichen Multi-Network kommen, sollten wir vielleicht auch noch erklären, was es mit dieser Multisite Funktion überhaupt auf sich hat. Ja, genau. Eine Multisite ist eine erstmal in Wordpress komplett versteckte Funktion, die einem ermöglicht, mehrere Websites, mehrere im Prinzip separate Websites über eine Wordpress Installation laufen zu lassen. Das hat dann zum Beispiel so Vorteile wie, dass man nur einmal den Wordpress Update-Button klicken muss oder alle Plug-ins nur einmal updaten muss für alle diese Websites und sie gehen alle auf einmal kaputt. Genau. Diese Nachteil, sobald man das macht, hat man auch mit anderen Dingen zu kämpfen, teilweise die dann etwas komplizierter werden, natürlich auch irgendwann die Skalierbarkeit etc., aber an sich für größere Setups verschiedene Art, da gibt es eben ganz verschiedene Use-Cases, wofür man das einsetzen kann, können wir vielleicht auch gleich noch was genauer darauf eingehen. Ja, hat auf jeden Fall dann da schon seine Vorteile und eine große Sache, die auch noch sehr wichtig dabei ist, ist, dass alle Benutzer von einer Multisite für die gesamte Multisite gelten. Das heißt, wenn man irgendwie mehrere Websites hat, wo man dann aber dafür sorgen will, dass alle Nutzer mit den gleichen Nutzerdaten sich überall in diesen Websites anmelden können, dann hat das auch dann da schon diesen Vorteil. In welchem Fall gehe ich dann auf diese nächste Ebene mit der Multinetwork-Installation? Sind die Nutzer da auch komplett geschert über alle Installationen oder? Erst mal, ja, also generell vom Datenbankschema, es gibt für eine ganze Multisite nur eine Datenbank-Tabelle für die Nutzer, das ändert sich nie, also während es bei einer einzelnen WordPress-Seite ist es ja so, dass für die Website eine Nutzer-Tabelle gibt, genau wie es für die ganzen anderen Kramen, Posts etc. einzelne Datenbank-Tabellen gibt. Bei einer Multisite ist es dann so, dass für jede weitere Website diese Tabellen, also bzw. neu erstellt werden, für jede einzelne Website kommen dann noch mal diese ganzen Tabellen noch mal dazu, weil die User-Tabelle und dementsprechend auch die User-Meter-Tabelle sind dann die einzigen Ausnahmen, die bleiben für immer einmalig in dem ganzen System und dadurch hat man eben dann schon auf dieser Datenbank-Ebene das erzeugt, dass User global sind. Das ist generell erst mal, ja. Multinetwork lässt sich erst mal am besten so erklären, dass Multisite, ein anderes Wort für Multisite ist Network. Es ist einfach nur ein Netzwerk von mehreren Websites und Multinetwork ist dementsprechend mehrere Netzwerke von solchen Websites, aber auch die laufen dann immer noch auf einem Set-Up. Da würde man sich dann wahrscheinlich erst einmal fragen, warum, also warum braucht man Multinetwork und nicht einfach mehrere einzelne Multisites und da, ja oder eben warum braucht man Multinetwork und nicht einfach eine riesige Multisite, wo dann alles zusammen in einem Pool ist. Multinetwork ist eben dann wieder noch eine weitere Abstufung, wo man dann im Prinzip eine Art hat, die Websites zu kategorisieren, aber nicht nur das, das bietet eben zum Beispiel, wenn man Multisite mal ausprobiert hat, da gibt es zum Beispiel Features wie, dass man Plug-ins für das gesamte Netzwerk aktivieren kann oder generell für das gesamte Netzwerk bestimmte Einstellungen machen kann. Wenn man da dann aber merkt, dass man mehrere Gruppen von Websites hat, die in Sachen Plug-ins oder generell der Grundfunktionalität doch dann komplett anders an unterschiedlich funktionieren sollen und man merkt, das ist jetzt auch nicht für eine einzige Seite, sondern da sind vielleicht Gruppen von 20 Websites und dann 20 andere Websites, die funktionieren komplett unterschiedlich, da sollte man dann schon darüber nachdenken, da könnte man dann einen Multinetwork benutzen, wo man dann eben die Konfiguration für diese beiden Netzwerke separat von nimmt und dann hat man 20 Seiten im einen Netzwerk und 20 anderen Seiten Sites im anderen Netzwerk. Das heißt, ich kann mir das Multinetwork im Prinzip mehr Struktur in eine Multisite reinbringen. Genau, genau. Ist das der Einzeljuscase? Ja, also im Prinzip, ich würde sagen, der Hauptjuscase ist eben, dass man da die Funktionalität noch besser voneinander trennen kann, wenn die wirklich unterschiedlich ist, weil man eben komplett unterschiedliche Verhalten definieren kann, man kann auch zum Beispiel, wenn man so etwas einführt wie Standardverhalten, wenn man eine neue Website erstellt, funktioniert so und so, dann will man vielleicht für das eine Netzwerk das so haben und für das, man kann zum Beispiel also Dinge einprogrammieren, wie das automatisch bestimmte Einstellungen so gemacht werden und solche Dinge, die funktionieren, kann man eben wirklich dann pro Netzwerk einstellen und intern für sich selbst ist es natürlich auch eine Möglichkeit der Kategorisierung, man kann dann eben Websites per Netzwerk suchen, also man kann dann sagen, ich will nur alle Websites mal hier gelistet haben, die aus dem Netzwerk sind, das alleine würde ich jetzt nicht, also wenn man das haben will, da würde ich jetzt nicht Multinetwork für machen, das kann man auch sicherlich anders regeln, aber ja, ich würde sagen, der Hauptpunkt ist tatsächlich die Trennbarkeit wenn wirklich unterschiedliche Arten von Funktionen, Grundfunktionen benötigt werden. Wie sieht das ganz im Moment technisch aus? Es ist ein Teil, der funktioniert, es ist im Core, aber ohne Plugging komme ich an die Stelle noch nicht, ist das richtig? Also im Core ist die Prakti, also ist fast erstmal nur die Datenbankstruktur, die Datenbankstruktur ist erlaubt theoretisch Multinetwork und das liegt daran, dass es gibt eine Datenbanktabelle in der die Netzwerke beziehungsweise das eine Netzwerk bei einer Multisite gespeichert werden und ja diese Datenbanktabelle heißt Sight, das klingt jetzt erstmal nicht so sinnvoll, aber das hat mit Legacy Namensgebung zu tun, die wir nie mehr ändern können und ja, also generell ich möchte einmal kurz zur Multisite diese Verwirrung auflösen, es gibt eben früher hat man bei Multisite, was man heute Websites nennt, oder Sites hat man früher als Blogs bezeichnet und das was man heute als Network oder Netzwerk bezeichnet hat man damals als Sight bezeichnet und gerade Letzteres verwirft dann sehr viel Verwirrung auf, wenn man dann Sight sieht, da muss man heute erstmal überlegen, meint das Netzwerk, also meint das Netzwerk, weil es alter Code ist oder meint das Sight, weil es neuer Code ist, dann muss man immer auf den Kontext gucken und gerade das, wir wollen da irgendwie mal zumindest, wir wollen versuchen da zumindest im, ich sag mal, in den öffentlich sichtbaren APIs und so loszukommen, die Datenbanktabellen werden wir wahrscheinlich nie ändern können, aber die soll man ja eh nicht direkt drauf zugreifen etc., aber ist im Moment auf jeden Fall noch problematisch da und verwirrend. Was kann da schon schiefgehen? Noch mal zurück genau zu der Datenbanktabelle, die da ist halt, wenn man eine Multisite erstellt wird, einfach das Netzwerk, da steht dann drin zum Beispiel die Domänen von dem Netzwerk und der Fahrt von dem Netzwerk und da das eine Datenbanktabelle ist, hat man eben schon grundsätzlich den Gedanken klar, da kann man noch mehrere Einträge drin speichern und das ist eigentlich schon der Grundgedanke, warum sich irgendjemand gedacht hat. Dann können wir jetzt auch da Multinetwork machen wahrscheinlich. Und Core selbst hat aber eigentlich, also im Core selbst ist das nirgendwo offengelegt, es gibt keine, es gibt auch tatsächlich keine, fast keine API Funktionen, um dann zum Beispiel einfach als Programmierer sagen zu können, jetzt ein Netzwerk erstellen oder so, das geht nicht, also das müsste man, da müsste man einfach direkt was in die Datenbankmanuelle einfügen und natürlich dann auch keine Oberfläche erst rechnen, also es gibt aber ein Plug-in, was dann oder mehrere Plug-ins vielleicht sogar, aber es gibt einen, ich sag mal Canonical standardmäßig empfohlenes Plug-in dafür, das heißt WP Multinetwork, das wurde ursprünglich, ich weiß nicht ob es ursprünglich ist, aber auf jeden Fall Haupt-Maintainer ist jetzt mittlerweile John James Jokowi, der auch so ein Buddy-Press so parteilig ist, ja und das Plug-in fügt eben API Funktionen in den Core, also ja nicht in den Core, aber fügt API Funktionen hinzu, mit denen man dann Netzwerke im Prinzip verwalten kann und gibt dann auch eine Oberfläche, dass man einfach einen Menüpunkt hat, Netzwerk, da kann man ein neues Netzwerk erstellen, Netzwerk bearbeiten, Netzwerk löschen genauso wie das halt eigentlich auch mit Sites in der Multisite funktioniert. Ist es denkbar, dass diese Funktion in den Core wandert irgendwann oder wird das auf aufsehbare Zeit zu planen? Es gibt, also es ist sogar geplant, also was in den Core, also was wir im Core machen passieren soll, ist, dass der Support für Multinetwork verbessert werden soll, es gibt nämlich eben auch viele Punkte, wo jemand, der da irgendetwas entwickelt hat, sich nicht mehr, ja nicht, dass sich überhaupt nicht im Klaren war, dass es Multinetwork gibt, das ist halt auch eben, wirklich eben versteckt und unbekannt und ja genau, deswegen gibt es viele Stellen im Core, die nicht Multisite, die nicht richtig Multinetwork kompatibel sind, die dann zum Beispiel, wenn man, wenn man allein so eine typische Sache ist, wenn man nicht weiß, dass es Multinetwork gibt und will alle Web, alle Sites im aktuellen Kontext haben, dann macht man eine Datenbackabfrage, gibt mir alle Sites, aber eigentlich braucht man eine Datenbackerfrage, gibt mir alle Sites, die in diesem aktuellen Network sind und das ist eine Sache, die dann oft schon ein Fehler aufwirft oder ein bisschen inkonsistent wird, genau. Okay, wir haben eine Frage aus dem Publikum, Thorsten Fromm ist vorweigekommen und hat sich das Headset aufgesetzt, genau. Es wurde ja gerade gesagt, dass es einen Plug-in gibt, was API-Funktionalität uns so weiter integriert, wie sieht es in Sachen WPCLi aus, gibt es da irgendwas entweder offiziell oder Third-Party irgendwie für das Verwalten eines Multinetworks? Es gibt, also das Plug-in, WPCLi Multinetwork hat eigene WPCLi Funktionen, also wenn man das Plug-in installiert, dann kriegt man auch ein paar CLI-Kommandos, um genau diese Funktionalität zu nutzen. Was ich eben auch noch anfangen genauer gesagt haben wollte, ist, dass eben jetzt geplant ist, API-Funktionen auch in den Core reinzubringen. Eine UI wird es im Core wahrscheinlich niemals geben, das soll weiterhin immer, das soll für immer Plug-in-Bereich Territorium bleiben, aber wir wollen eine konsistente Basis-API zumindest in den Core bringen, die die rudimentären Funktionen abdeckt und ja unopinionated ist, so dass dann Leute weiterhin die verrückten Sachen damit machen können, die sie auch wollen, aber eben die Basis soll einheitlich werden und so, dass dann irgendwann in der Zukunft dieses WPCLi Multinetwork Plug-in nur noch für die UI zuständig ist. Und zu dem Zeitpunkt wird dann wahrscheinlich sobald das in den Core kommt, wird auch wahrscheinlich WPCLi dann offiziell solche Funktionen einfügen, die sich an den Core lehnen. Es ist nämlich im Moment halt so, dass Plug-in fügt CLI-Commandos hinzu, aber die sind dann natürlich schon, also die sind dann alle Präfix, also man muss immer schreiben WP, WP-Multiminus-Network und dann erst was man macht, weil das also ist halt alles erstmal unter dem Plug-in gescoped sozusagen. Ja, aber ich denke, da passiert halt auch gerade einiges, dass das im Core verbessert wird. Bevor das Ganze in den Core wandert, sollte ich so mutig sein, Multinetwork schon einzusetzen, oder ist das im Moment so... Ihr solltet Multinetwork einsetzen, wenn ihr ein Newscase habt und euch ein bisschen quälen wollt? Das klingt auch großartig. Nein, also es gibt eben wirklich manche Newscases, wo die sich perfekt dafür eignen. Ich möchte mal so ein paar Sachen nennen, die so typisch sind, zum Beispiel Universitäten. Universitäten sind ein ganz typisches Beispiel, wenn ein ganzes komplette Universität mit WordPress läuft, da es gibt eben viele schon einige solcher Fälle, das sind große, ich sag überhaupt, Nutzer von Multinetworks, die haben dann zum Beispiel für jede Fakultät ein Netzwerk und dann hat jeder, weil jeder Fakultät jetzt schon alleine sichseits hat, aber die wollen vielleicht komplett auch unterschiedliche Leute haben, die die Netzwerke verwalten, das ist eben natürlich auch noch dann wieder ein Vorteil von Multinetwork, dass man dann für die gesamten Netzwerke unterschiedliche Leute festlegen kann. Ja, so was zum Beispiel, das ist typischer Usecase. WordPress.com ist auch ein Multinetwork mit einem sehr speziellen Usecase. Es gibt zwei Netzwerke auf WordPress.com, das eine ist, die sind die Seiten, die Leute bei WordPress.com direkt erstellen und das andere sind Monitors von all unseren euren Jetpack-Sites. Also ja, also die kann man natürlich nicht öffentlich aufrufen, aber WordPress.com speichert ja irgendwo, muss ja auch irgendwo diese ganzen Sachen speichern, die per API von Jetpack rübergebracht werden oder abgeholt werden und das funktioniert alles in einem separaten Jetpack-Network. Das klingt ja großartig. Gut, dass für meine Jetpack-Seiten da, da braucht man keinen Netzwerk für. Was passiert aktuell, wenn ich das Multinetwork-Pluggin deaktiviere? Ist das dann einfach tot? Wenn man das deaktiviert, dann funktioniert, solange man jetzt irgendwas custom entwickelt, was dann noch die Funktion aufbaut, geht es natürlich kaputt, aber wenn man generell das deaktiviert, dann bleibt erstmal die Grundfunktionalität, dass diese Netzwerke existieren und dass man weiterhin aufrufen kann, bleibt komplett bestehen. Man kann da nicht mehr die Netzwerke nahmen oder Domains bearbeiten oder neue Netzwerke hinzufügen oder irgendwas löschen. Generell bleibt es aber erst mal bestehen, weil WordPress eben schon so gemacht ist, dass man kann weiterhin über die Netzwerke URL das Netzwerk aufrufen. Das ist aber auch ein wichtiger Punkt, weil WordPress an sich keinen Multinetwork direkt in der Oberfläche anbietet. Gibt es in WordPress keine Verbindung von einem Netzwerk zum anderen? Man müsste einfach die URL von dem anderen Netzwerk oben eingeben, um dahin zu kommen. Aber das würde weiterhin bestehen. Es würde aber überhaupt nicht mehr so aussehen, als wäre es in einer Installation. Da kommt immer Coke Zero rein. Das kann nur Robert sein. Und er ist zu spät. Es gibt dann keine Verbindung mehr zwischen den einzelnen Netzwerken. Also intern? Intern, ich meine, so rein von der GUI. Genau, genau. Das ist aber auch noch ein... Generell ist es ein interessanter Sache, dass das Multinetwork Plug-in fügt, die Oberfläche hinzu, um Netzwerke zu bearbeiten. Da kommen wir aber dann zum nächsten, zu der nächsten Sache, die... Also es ist so, wenn man Multinetwork einsetzt, da muss man eigentlich schon immer Handanlegen, generell noch, um das an seine Bedürfnisse anzupassen. Es ist nämlich so, dass das Plug-in erst mal diesen Menüpunkt, um neue Netzwerke zuzufügen und zu bearbeiten, etc., fügt das einfach in den Netzwerkadminbereich ein. Aber man will vielleicht nicht, dass jeder Netzwerkadministrator einfach weitere Netzwerke erstellen kann. Woher dann auch der Netzwerkadministrator wird? Warum denn nicht? Das ist aber erstmal so. Und da muss man dann gucken, weil es ist ja auch so, dass der Netzwerkadministrator in WordPress, der hat automatisch Berechtigung alles zu tun. Deswegen hat er auch diese Berechtigung das zu tun. Und da müsste man... Man kann dann entweder erstmal simpel vorgehen und irgendwo in den Code... Also an der Stelle bei den Berechtigungen sich in den Code reinhucken und sagen, nur diese eine User-ID, darf das jetzt noch zum Beispiel, könnte man sagen, oder das irgendwie in einer globalen Variable festlegen, oder einen Konstanten festlegen oder so was, welche User-IDs, welche User-IDs neue Netzwerke erstellen dürfen. WordPress bringt schon eigene Berechtigungen mit. Nur standardmäßig hat die halt jeder Netzwerkadmin. Man kann noch weitergehen und dann über so was nachdenken, wie Global-Admin. Das klingt superfenzi. Ja, ich will das. Also ich habe... Ich habe einen Vortrag bei der Loop-Kunft darüber gehalten, über Multinetwork-Organisationen und was man da eigentlich bedenken muss, weil eben diese Multinetwork-Plugin erstmal die Basis mitbringt, aber für den wahrscheinlich für fast keinen Newscaster direkt fertig ist, weil man dann eben noch so ein bisschen vor allen Dingen die Berechtigungen anpassen muss. Wenn man aber... Wenn man jetzt aber an sich schon drüber nachdenkt, wenn man an Multinetwork denkt, und das Vergleich mit Multisite, da hat man die ganzen Websites und dann gibt es die eine Ebene da drüber, ein Network, wo man dann die ganzen Websites verwaltet. Hast du dann mehrere Netzwerke? Brauchst du eigentlich auch eine Ebene darüber, die wir dann typischerweise einfach als global bezeichnen? Und es wird hoffentlich niemals multi-global geben? Das wäre meine nächste Frage gewesen. Galaxy-Network. Genau, genau. Ich mag das. Bevor wir zu den wirklich wirklich abgedrehten Fragen kommen, und ich glaube, das sind ein paar... ein paar möglich, wir fallen mehrere ein, haben wir irgendwas zu den Kernfunktionen des Multinetsworks noch nicht gesagt? Und wie ja meine ich dich? Ja, ich überlege, ich kann das grad, grad, denke ich, okay, nicht. Ein wunderschöner Use-Case, wenn ich mir einfallen würde, wäre es möglich, in dem Multinetwork einfach ein Netzwerk zu kopieren, eins zu eins, um dann da irgendwie den Content kaputt spielen zu können? An sich, also, also jetzt nicht mit Boardmitteln, das kann man recht einfach einprogrammieren, genau, aber ja, Netzwerke müssten eben nur, WordPress erwartet zumindest, die Datenmachstruktur gibt es nicht vor, sondern es erwartet, dass alle Netzwerke und alle Websites immer eins unterschiedliche Domains haben. Du könntest theoretisch schon, denke ich, ein Netzwerk kopieren und dann zum Beispiel Staging dort davor schreiben oder sowas, also wäre vielleicht ein interessanter Überlegung, aber andererseits ist es natürlich nicht wirklich eine Staging-Umgebung, weil du im gleichen Set-Up bist. Zum Content-Staging kann ich es mir vorstellen, dass du sagst, okay, dann schiebt irgendetwas in das andere Netzwerk rüber. Du hast Domains eben schon angeschnitten. Domain-Mapping im Multinetwerk klingt irgendwie harig. Ich muss jetzt erst einmal kurz fragen, Domain-Mapping Ich möchte richtige Top-Level, also Stärkung-Level-Domains. Okay, ja. Dazu brauchst du, das kannst du eigentlich mit Multisite machen? Mit Boardmitteln? Ja. Das funktioniert, eigentlich funktioniert es dann, mit Multinetwerk, der ändert sich eigentlich nichts daran, meiner Meinung nach. Du musst halt generell schauen, je komplizierter du da vorgehen willst, was du mit den Domains um Pfaden machen willst, da muss man halt darauf achten, dass WordPress halt so ein Standardscript, was entdeckt, durch die aktuelle URL und den Pfad, welche Sitegrad die aktuelle ist und welche Networkgrad das aktuelle Netzwerk ist. Und wenn man da dann arg konfuse Sachen machen will, wie zum Beispiel wie zum Beispiel Pfade 3-Emen tief verschachteln und davon dann auch irgendwie erkennen, ob dann das oder daran erkennen, welche Website, wo man gerade sich befindet, da muss man eben dann dieses Skript anpassen, was dann entdeckt, wie die, wo man gerade ist. Aber an sich kann man ja auch mittlerweile mit Boardmitteln einfach in WordPress die Domain zu einer ganz normalen Domain machen und von da aus dann aus gehen. Was immer noch zu irgendeinmaßen extrem schrecklich UI-mäßig ist, denn du musst immer erst deine Seite mit einer Subdomain oder SubDirectory erstellen, so wie WordPress halt für die Multisite konfiguriert ist und dann kannst du aber bearbeiten und da kann man dann eingehen, was man will. Und dann kann man auch direkt eine Domain eingeben. Das ist irgendwie einfach nur so ein Oberflächen. Ja, genau. Aber wir arbeiten gerade erstmal an saubereren APIs und dann auch eine REST-API Support von den ganzen Multisite-Funktionen und auch, es wird auch tatsächlich sehr wahrscheinlich ein Networks Endpoint geben. Also da soll es dann schon soweit sein. Aber dann kann man natürlichen UI-Probleme angehen, die da noch von denen noch einige bestehen. Kann ich in einem Multinetwork Subfolder und Subdomain Geschichten mischen? Pro Netz, also pro Netzwerk dann? Ich glaube nicht, das ist nämlich per Konstante festgelegt. Und ich glaube, es gibt doch keinen Filter, um die Konstante zu überschreiben. An sich ist es aber, wie gesagt, eigentlich egal. Das ändert an den meisten Fällen, ändert das nur, was für dieses Skript was erkennt, wo du gerade bist. Dadurch aber das mit einem Drop-in, also das Data Sunrise-PAP, die könnt ihr in den WP-Contentor tun. Und das, was da dann, da könnt ihr dann im Prinzip die ganze Funktionalität überschreiben, die multisite-standardmäßig macht, um zu erkennen, wo man sich gerade befindet. Und da könnte man dann auch, wie gesagt, dann theoretisch schon, man kann auch einfach komplett ignorieren, ob das jetzt Sub-Domain oder Sub-Directory ist, immer irgendwelche Domains verwenden, solange das eigene Skript das berücksichtigt. Keine spezielle Multinetwerkfrage, warum heißt dieses Ding Sunrise-PAP? Fragt mich nicht. Schade, ich dachte, das geht nicht. Ja, okay, da meldet sich der Robert. Wenn du etwas sagen möchtest, was du so vorkommen und dir das Headset aufsetzen, das will ich wirklich. Jetzt kommt Robert in den Tisch, der wahrscheinlich gleich mit Gewalt vom Mikrofon entfernt werden muss. Ich glaube, das geht nicht über deinen Hut. Doch, das kriegt man schon so hin. Das Mikro zeigt auf dein Auge. Ja, weil man hört mich ja wahrscheinlich trotzdem. Jetzt zeigt es auch nicht mehr auf dein Auge. Besser. Ich kann die Sunrise-PAP nicht technisch erklären, warum die so ist. Aber wenn man sich den Zustand überlegt, wo sie ist und wo sie reingreift, nämlich beim anderen des Systems. So habe ich mir das quasi eben erklärt, dass die ja quasi zum Sunrise der ganzen Instanz quasi da ist und deswegen eben im frühestenmöglichen Zeitpunkt schon Änderungen machen kann. Das klingt verdächtig plausibel, genau? Vielleicht sollte man den Shutdown-Hug dann in Sunset oder so umbenennen. Hat das Mikro tatsächlich von alleine wieder hergegeben? Entschuldigung. Gibt es irgendwie einen Plan, wann wir die ganzen APIs sehen werden? Benutzen können? Also erst mal, es hat immer alles... Nein, nein, ich wollte eigentlich sagen, alles ist erstmal, bei allem Ding ist erstmal, Sites sind wichtiger als Networks, weil es Multinetwork eben und EdgeCase ist, noch größer EdgeCase als Multisites selbst schon ein bisschen ist. Wir arbeiten erstmal an den APIs für die Sites und da denke ich, da sind wir gegen Herbst oder spätestens Ende des Jahres mit fertig und dann sobald die APIs, die internen Sites APIs fertig sind, ist der Rest API Endpoint eigentlich ein No-Brainer und da wird dann auch direkt folgen und danach ist auch im Prinzip das mit den Netzwerken No-Brainer, weil wir uns dann bei den Sites nicht haben und das kann man fast replizieren für die Netzwerke nur sogar simpler, weil da nicht so viel mit einher geht dann. Also ich denke, Sites spätestens Ende des Jahres und Netzwerke vielleicht dann Anfang nächstes Jahr und danach geht es hoffentlich mal daran, Multisite von Grund auf benutzerfreundlicher zu gestalten und ja. Da ist ein bisschen Verbesserungspotenzial auf jeden Fall. Die Qualität in Multinetwerk Plugins oder Themes bei Themes ist es relativ einfach, aber Plugins nur für einzelne Netzwerke und zur Verfügung zu stellen, dass Network 1 nur Plugin X aktivieren kann und nicht Y auch nicht mit Boardmitteln. Bei Themes ist es ja so, dass man, wie meinst, Netzwerk per Netzwerk. Grundsätzlich ist es erstmal so, dass der Plugin und die Themes, die Ordner die sind immer noch komplett für das ganze Setup. Bei generell ist es ja bei Themes so, dass man die auch bei einer normalen Multisite schon pro Website aktivieren kann und das heißt ja in jedem Fall nicht freischalten genau, noch nicht mal direkt aktivieren, sondern nur freischalten. Plugins sind ja immer, Plugins hingegen sind immer sichtbar. Also man kann nicht sagen, dass das bei einer bestimmten Website nicht angezeigt werden soll oder so. Da kann man sich aber reinhucken, da habe ich schon mal einen Plugin zugeschrieben, dass das dann macht. Also das dann sagt, wo man dann bestimmte Plugins ausschließen kann, die dann nur für den Netzwerkadministrator überhaupt angezeigt werden. Wenn man komplett unterschiedliche Plugins oder auch komplett unterschiedliche Themes pro Netzwerk haben will, dann ist das aber auch nicht allzu schwer. Dafür müsste man einen Must-Use Plugin zum Beispiel schreiben, was früh genug lädt, um dann dynamisch pro Netzwerk zum Beispiel den Ordner für, wo wir dann Plugins draus geladen werden und Themes draus geladen werden, anzupassen. Also da werden ja konstant zugesetzt und wenn man eben früh genug, ich weiß gar nicht genau, woher das müsste eigentlich mit einem Must-Use Plugin funktionieren, falls nicht, vielleicht muss man sogar in die Sunrise einfach sich das reinhacken. Die relativ früh lädt, wie wir gerade haben. Genau, genau. Ja und da kann man dann, da könnte man dann zum Beispiel sagen, bin ich in dem Netzwerk, dann lasst es nicht, dann ladt alles aus dem Ordner Netzwerk ID1 Plugins oder sowas und so könnte, also sowas in der Richtung macht auch definitiv WordPress.com, aber sogar pro sites, weil die erlauben jetzt ja in den teuren Verträgen ist irgendwie, dass man auch Plugins installieren kann und das soll natürlich dann nicht jeder im ganzen WordPress.com System haben. Das wäre ziemlich lustig. Genau und da wird definitiv genauso was angewandt um dann pro website eigene Ordner zu haben, wird natürlich dann auch ein Riesen-Setup, aber ja so ist das dann. Per Netzwerk ist es dann auch etwas glümpflicher, weil man ja wahrscheinlich nicht 100.000 Netzwerke hat. Bleibt zu hoffen. Gibt es an der Stelle, es klingt nicht so, als wird es irgendwo ein Problem mit der Performance geben, aber ich frage der Vollständigkeit, aber trotzdem mal müsste ich da irgendwas beachten, dass ich ein Multinetwerk ein nutzen möchte. Performance Probleme gibt es ja ich sag mal immer, wenn es zu viel wird. Wenn die Performance schlecht ist, gibt es Performance Probleme. Genau. Wenn du eine Multicite hast mit 10.000 Websites hast, dann hast du natürlich wahrscheinlich ein Performance Problem als wenn du ein Multinetwerk mit 20 Websites hast. Also an sich, da hört sich da eigentlich nicht zu viel. Von Multinetwerk auf Multicite, da ist kein zu großer Unterschied. Wichtig ist natürlich, es ist natürlich wichtig, dass man, wenn man das Plug-in einsetzt, da werden ja auch die Datenbackabfragen entsprechend gecached und so was. Ein großes Problem, was halt existiert ist, vor allen Dingen beziehungsweise die Nutzer, weil User sind eben global, das heißt diese Tabelle kann auch mal wirklich riesig werden. Also noch riesiger als andere riesige Tabellen. Und ja, Userabfragen haben im Moment in WordPress kein Caching. Das ist nicht so toll. Es ist aber so. Daran gibt es auch Tickets, woran da gearbeitet wird. Aber ich kann auch gar nicht genau die Historie, warum genau diese eine Teil keine gecached Datenbankabfragen hat. Aber bei da muss man, ich denke da haben auch größere Netzwerke ihre Layer da rumgeschrieben, weil das einfach sonst überhaupt nicht funktioniert. Aber wahrscheinlich dort kommen auch Magierlaufen. Haben wir aus dem Publikum Fragen, ich weiß es ist gruselig hier vorzukommen und dieses Headset aufzusetzen, aber vielleicht brennt euch ja etwas so unter den Nägeln, dass sich der Weg nochmal lohnt. Begeisterung, Thorsten, Robert, nein. Möchtest du uns noch etwas ergänzen? Ja, ich kann auch etwas, ich kann auch etwas eingefallen, was auch sehr zentral ist, was erst mal nicht so toll an einem Multinetwerk ist. Also auch eine Funktion, die einfach standardmäßig nicht da ist. Es ist nämlich so, dass, wie gesagt, User sind global und man kann eben die Nutzer, es ist halt möglich bei, zum Beispiel, es ist möglich, sich die User nur für eine bestimmte Zeit anzeigen zu lassen, was aber schon auch eine sehr komplizierte Datenbankabfrage ist, weil die Websites, denen ein Nutzer zugehörig ist, nur dadurch dem Nutzer zugeordnet werden können, dass der Berechtigung auf dieser Website es hat. Die sind in einem serialisierten Area gespeichert und man muss dann zum Beispiel würde man alle User von Website eins haben wollen, dann müsste man halt eine Meta Query mit Like Query machen, um dann das zu kriegen und wenn man dann das auf riesige Tabellen macht, dann kann das auch schon mal schnell problematisch werden. Aber generell gibt es da die Möglichkeit, Nutzer zu einer site zu zuordnen. Bei Netzwerken gibt es das nicht. Das heißt, wenn man erstmal, wenn man Multinetwerk erstmal aktiviert, dann werden in jedem Netzwerk alle Nutzer angezeigt, nur die Nutzer des aktuellen Netzwerks. Das macht aber auch im aktuellen Kontext teilweise sogar Sinn, weil es ja keinen globalen Atmen gibt und man braucht ja eigentlich auch die Möglichkeit, irgendwo alle Nutzer zu sehen. Alle überhaupt. Aber standardmäßig würde man natürlich erstmal warten, in einem Netzwerk werden nur die Nutzer von diesem Netzwerk angezeigt. Das ist aber im Moment unmöglich durch eine Query zu vollbringen. Man müsste dann eben, das ist auch etwas, was mir persönlich eben sehr herzlich, das im Core zu fixen. Das ist aber auch was, da müsste man dann so etwas machen, wie, dass man sobald ein Nutzer zu einer Website im Netzwerk hinzugefügt wird, dass er automatisch auch zum Beispiel dann zu dem Netzwerk hinzugefügt wird, dass das auch irgendwo dann gespeichert ist, damit man es eben abfragen kann. Ja, aber das ist eben auch noch ein großes, oder eine unerwartete Sache, weil man, dass die Nutzer, ah, dass alle Nutzer in jedem Netzwerk angezeigt werden. Gibt es andere Probleme mit Multinetworks, von denen ich wissen sollte, bevor ich so ein Ding aufsetze? Es ist generell was für Freakler. Ja? Das kann ich, also ich, ja, da kann ich jetzt fällt mir sonst auch gar nichts mehr konkret ein. Aber Robert wieder zum Mikrofon, mal gucken, was er sagen möchte. Nein, es ist nicht für Freakler. Der Ansatzpunkt von Multinetworks ist ja in der Basis, also nur weil ich dir jetzt gerade so vehement widerspreche, es ist ja seit Version 3 mit dem Merge ist ja die Multisite Funktionalität im Chord drin. Mit dem Zeitpunkt kam ja auch die Multinetwork Funktionalität, weil es schon immer geht. Und weil ich auch schon im Meetup gehört habe bei uns, oh mein Gott, Multisite und Performance und so, das ist halt, stabil. Es ist quasi stabiler als jetzt, wird es nicht, weil es halt auch WordPress.com benutzt wird. Man muss halt überlegen, was will man damit erreichen, was will man als Zusatzfunktion machen und wenn man es quasi braucht, um Leute, um halt Firmen zu trennen, also Firmen, global quasi aufeinander zu trennen, aufeinander zu trennen und wirklich über Multinetworks das abzubilden, die Funktion von WordPress mit den Users gebe ich dir recht, dass der Netzwerkadmin, den du ja sowieso nicht eingrenzen kannst, weil es auch noch nicht die Netzwerkadmin-Rollen gibt, die auch noch irgendwann kommen, hat der Netzwerkadmin natürlich, weil ja, weil ja Gott ist, kann ja alles sehen und das ist halt nichts, was jetzt, also das ist zwar, klingt zwar schlimm, dass man das nicht will, aber der ist ja Netzwerkadmin und es gibt keine technologische Möglichkeit aktuell, Netzwerkadmin zu beschränken und deswegen kann er alles sehen und das auch richtig so. Ja, du kannst den Netzwerkadmin, du kannst den Netzwerkadmin bestimmte Berechtigungen entziehen mit Hilfe von Do not allow. Genau, du kannst einem User Netzwerkadmin-Rechte im Netz 1 geben und im Netz 2 ist ein ganz normaler User. Genau. Das geht, da könnt ihr also im Netz 1 quasi könnt ihr alles sehen, weil die Netzwerkadmin-Rollen noch nicht da sind und es keine Query gibt, um die User quasi zu trennen. Ja, du könntest, aber du kannst einem Netzwerkadmin auch spezielle Berechtigungen trotzdem entziehen, in dem du bei deinem, den du an den Capabilities an diesen Berechtigungen da feilst und sagst, wenn du eine Berechtigung im Endeffekt in Do not allow auflöst, dann da kann doch nicht mal der Netzwerkadmin mehr das machen. Schalten Sie auf am nächsten Mal wieder ein, wenn Robert und Felix den Rest des Raums verlieren. Ja, so ein Mikro ist gefährlich in unserem Raum. Ja, häng das mal wieder hin. Danke, Robert. Ja, also klar, es hat auf jeden Fall sein Newcase, sonst wird es ja auch nicht eingesetzt werden, aber man sollte eben mit Vorsicht es einsetzen, weil man da eben, man muss eigentlich immer Selbsthand anlegen, um dann seine Belöffnisse anzupassen. Kann ich denn bestehen, ist bestehende Multisat-Installation einfach wie auf Multinetwork heben oder schreit die dann rum? Eigentlich ja, also ich schreit nicht rum. Okay, dann probiere ich das mal. Das Multinetwork-Plugin erlaubt übrigens auch eine Funktion Move-Site, um dann eine Website von einem deswegen ins andere zu bewegen. Ich habe noch nie auf den Button geklickt, aber es gibt's das. Sehr gespannt. Wenn du was hinzufügen möchtest, darfst du gerne, ach, fünf Minuten einschuldigen, man hört dich nicht mit den Komforten auf. Ich denke, wir sind auch soweit am Ende. Ja. Vielen Dank für dieses kleine Experiment. Ja, gerne. Danke für die Einladung hier. Es ist sehr ungewohnt, weil zumindest die Aufnahme, die auf Wordpress TV landet, nicht geschnitten werden kann. Vielleicht nehme ich aus meiner Robert nachher noch raus, aber das schauen wir gleich. Also ich kann nur noch sagen, wer mehr noch sich damit beschäftigen will, guckt euch erstmal auf jeden Fall das Multinetwork-Plugin an. Ich habe halt wie gesagt, ich habe einen Vortrag, der im Bereich Multinetwork-Management im Bezug auf, wie man dann über das globale weiter noch nachdenken kann. Da habe ich einen Vortrag, der Luke kommt drüber untergehalten, der ist dann auch auf YouTube unter der Luke kommt zu finden. Ja, der wird sagen, da ist eigentlich auch noch ein großer Überblick, der dann gesichtgenauer mit diesen kompliziteren Themen beschäftigt. Sehr schön. Die Links dazu und so den anderen Sachen, die wir eventuell haben, gibt's in den shownotsoffpresswerk.net und das TV-Könne. Sehr schön. Felix, magst du zum Schluss noch sagen, wo wir dich im Internet finden, wo man dich verfolgen kann? Ja, ja. Ich bin eigentlich überall, so Twitter, Github, so was Unwichtiges wie Instagram. Da heiße ich überall Felix Arns, einfach zusammengeschrieben, wie mein Name ist, ARNTZ. Und sonst, aber WordPress.org ist mein Nutzername Flix aus 90. Ja, denn das hatte ich schon bevor ich alles andere hatte. Und da habe ich noch nicht mein eigener Namen benutzt. Wer tut das auch? Das Presswerk gibt's auf Twitter als Presswerkunterstrich Cast. Im Internet als Presswerk.net. Wir sind auf iTunes, da kann man uns abonnieren und Sterne verteilen. Außerdem sind wir bestimmt auch wieder auf dem nächsten deutschen Wordcamp in ihrer Nähe und machen das hier vielleicht noch wieder, das war ganz lustig, auch wenn so viele Menschen auf einen gucken, während man dieses duselige Headset aufhat. Vielen Dank euch fürs Zuhören und bis zum nächsten Mal. Danke, ciao.