WBCE CMS – Way Better Content Editing.
Du bist nicht angemeldet.
Hallo,
meine Frage ist, ob je aktiver Subdomain eine eigenständige WBCE-Installation erforderlich oder empfohlen ist.
Hintergrund ist die Redundanz von Programmcode und ein erhöhter Warungsaufwand, Jedenfalls soloange Core- und Modulupdates händisch ausgeführt werden müssen.
Bei Wordpress habe ich mal von der Möglichkeit gelesen, von einer zentralen Installation aus, auch den Content mehrerer Subdomains zu verwalten. Wie ist das bei WBCE?
Danke und Gruß
Offline
Das ist durchaus möglich.
Ich habe eine Instanz von WBCE auf 2 Domains laufen, jeweils eine andere Sprache die eine eigene Domain hat.
Das lässt sich über die config.php (im RootVZ) steuern.
Wenn das selbe Template verwendet werden soll müsste es im Template noch abgefangen werden und das Menü müsste entsprechend dafür vorbereitet werden.
Auch die Seitenbaum Struktur (PageTree) im Backend sollte im Voraus geplant werden. So könntest Du z.B. für die Subdomain eine bestimmte Seite vom Typ "Seiten Link" anlegen und dadrunter die Seiten der Unterdomain anlegen (eine Ebene Tiefer).
Über show_menu2 im Frontend dann diese Seite als Startseite angeben.
Es geht.
Christian
“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale
Offline
Naja, so ganz einfach ist das aber nicht und eigentlich auch nicht vorgesehen.
Also ich wüsste jetzt nicht, wie das praktikabel umzusetzen wäre.
Mit Bordmitteln geht das definitiv nicht. Das fängt schon damit an, dass die meisten Module den Pfad zu Bildern etc. absolut in die DB schreiben.
Wir Benötigen: Cents, Euros... jetzt spenden!
Offline
Ich hatte das vor vielen Monden mal für einen Kunden realisiert:
2 Domains für unterschiedliche Produktbereiche mit dem Wunsch sie über ein Backend zu verwalten.
Im Prinzip machbar aber ein elendiges Gefummel bei der Einrichtung.
Möchte ich heute wirklich nicht mehr machen müssen.
Letztendlich ist auch der Kunde dann wieder davon abgekommen, da er mit steigender Anzahl der Seiten teilweise im PageTree die Übersicht verloren hat, obwohl der an sich ganz vernünftig angelegt war:
-- Domain 1
-- -- Seiten zu Domain 1 gehörig
-- Domain 2
-- -- Seiten zu Domain 2 gehörig
Also analog zu dem Vorgehen bei einer mehrsprachigen Seite.
... nein in Europa verwenden wir beim Programmieren nicht € statt $ ...
Offline
macht ihr das über htaccess?
oder wie erkennt das System die unterschiedlichen Domains?
Ginge das ev über ein Tool analog zu shortUrl?
Ich frage mich deshalb, weil ja das Menü letztlich die Hauptdomain auswirft...
Interessant wäre das Thema sicherlich, mit Unterverzeichnissen geht es ja auch.
Beitrag geändert von berny (13.06.2023 08:58:27)
Offline
Im Prinzip machbar aber ein elendiges Gefummel bei der Einrichtung.
Möchte ich heute wirklich nicht mehr machen müssen.
Ja, das bestätigt meine Ahnung und die anderen Aussagen hier - nämlich, dass das kein 'reguläres' Bordmittel des CMS und eben fummelig ist. Und mein Interesse ist vor allem, weniger statt mehr Einrichtungs- und Wartungsaufwand zu haben.
Ich bleibe also bei der klassischen Parallelinstallation meherer Instanzen. Der erfreulich geringe Speicherhunger ist ja einer der vielen Pluspunkte von WBCE und kommt dieser Variante entgegen.
Danke für alle Antworten!
Offline
florian
Ja, es stimmt schon: das System ist nicht wirklich darauf ausgelegt. Aber lass uns festhalten, dass es machbar ist. In meinem Falle war das sogar eher die einzige Lösung, da auf beiden Domains die gleiche Software im Hintergrund läuft die Kundendaten in einer Datenbank zusammenhält.
Etwaige hard-codierten URLs (die es in meinem Falle nicht gab) könnte man auch über Outputfilter abfangen und je nach Domain korrigieren.
Ich kann aber auch sehen, dass es nicht die einfachste Lösung ist und es durchaus sinnvoller sein kann, es mit zwei Instanzen umzusetzen. Vor allem dann, wenn Inhalte beider Seiten völlig unterschiedlich sind.
Christian
“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale
Offline
Ich könnte mir noch vorstellen, dass man mit Softlinks auf die Verzeichnisse "modules" und "framework" arbeiten könnte, das kann aber bei manchen Modulen schief gehen, wenn die z.B. versuchen, mit ihrem eigenen Verzeichnis zu arbeiten. Und man könnte sich auch noch was basteln, dass nach dem Update einer Instanz die anderen automatisch aktualisiert werden. Ist aber alles Bastelei und nicht out-of-the-box. Den Core wird man vermutlich sogar relativ einfach auf Multisite umstellen können, haarig wird's bei den Modulen. Das ist sehr viel Testaufwand.
Ich habe eine Amazon-Wishlist.
Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal
Offline
Momentan erschließt sich mir die Problematik mit Modulen nicht. Meinst Du spezielle Module oder grundsätzlich alle Module?
In welche Schwierigkeiten könnte man da reinlaufen?
(Ich strebe keine generelle Multi-Domain Fähigkeit an, frage nur aus Interesse. Ich scheine etwas zu übersehen.)
Gruß,
Christian
“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale
Offline
Naja, zum Beispiel speichert das Droplets-Modul Exporte (Zips) in einem Unterverzeichnis des Modulverzeichnisses. Die meisten Module verwenden irgendwo sowas wie dirname(__FILE__) oder direkt __DIR__. Bei Softlinks ist das Ergebnis nicht unbedingt das, was man erwartet. Dafür müßte man noch realpath benutzen, damit habe ich aber auch schon negative Erfahrungen gemacht. Und dann kommt noch dazu, dass Softlinks unter Windows was anderes sind als unter Linux.
Ob das ein Problem ist, hängt davon ab, was das Modul dann damit anfängt. Ich kann Dir nichts Konkretes sagen, aber mein Bauchgefühl sagt, dass es ganz sicher irgendwo knallen wird.
Denken wir auch an MEDIA_DIRECTORY. Das müßte für jede Site ein anderes sein. Genau wie das pages-Verzeichnis. Eigentlich alles, wo absolute Pfade drin stehen. Das immerhin könnte man aber vom Core aus steuern, so lange die Module dann mit den Konstanten arbeiten und nicht mit relativen Pfaden.
Ich habe eine Amazon-Wishlist.
Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal
Offline
Achja, und dann haben wir auch noch CSS- und JS-Dateien in den Modulen, die nicht über die Site-URL aufrufbar wären, sondern über die URL der einen Core-Installation. In BC2 - das multisitefähig gewesen wäre - haben wir solche Themen alle schon gehabt. Dort wurden z.B. die fehlenden CSS und JS aus den Modulen beim ersten Aufruf in das jeweilige Site-Verzeichnis kopiert, so dass sie dann über die Site-URL aufrufbar waren. Das war notwendig, um die Engine (oder den Core) auch außerhalb von htdocs betreiben zu können. Da hängt aber auch noch einiges dran - erkennen von Änderungen, Löschen von nicht mehr benötigten Dateien, etc.
Alles in allem ist noch die einfachste Lösung, über eine Seitenstruktur zu arbeiten, wie oben schon beschrieben. Das kann halt nur schnell unübersichtlich werden und hat immer noch den Makel, dass z.B. Assets - also Bilder aus media etwa - ggfs. mit einer "falschen" Adresse ausgeliefert werden. Manchmal stehen halt vollständige URLs im Content, da ist der Output Filter nur dann eine Option, wenn die Links dann auch wirklich mit der jeweiligen Domain funktionieren.
Ich habe eine Amazon-Wishlist.
Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal
Offline
Ich sollte wohl noch dazu sagen, dass ich hier von einer echten Trennung zwischen Core und Site spreche. Also der Core liegt irgendwo auf dem Server und irgendwo anders liegen Site-Verzeichnisse mit ihren eigenen media- und pages-Verzeichnissen. Eventuell auch eigenen tmp-Verzeichnissen.
Von Rechteproblemen (User darf nur Site A bearbeiten und nicht Site B) fang ich lieber gar nicht an. 
Ich habe eine Amazon-Wishlist.
Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal
Offline
Hallo Bianka,
danke für den Input.
Hab zwar alles gelesen aber nicht alles "processed". Bin grad etwas überladen, war ein heißer Tag hier. Aber ich komme drauf zurück.
Schönen Abend.
Christian
“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale
Offline
Die meisten Module verwenden irgendwo sowas wie dirname(__FILE__) oder direkt __DIR__. Bei Softlinks ist das Ergebnis nicht unbedingt das, was man erwartet. Dafür müßte man noch realpath benutzen, damit habe ich aber auch schon negative Erfahrungen gemacht. Und dann kommt noch dazu, dass Softlinks unter Windows was anderes sind als unter Linux.
Hm... ja, aber die Pfade beziehen sich auf den Server und nicht auf die URL ans sich.
Denken wir auch an MEDIA_DIRECTORY. Das müßte für jede Site ein anderes sein. Genau wie das pages-Verzeichnis. Eigentlich alles, wo absolute Pfade drin stehen. Das immerhin könnte man aber vom Core aus steuern, so lange die Module dann mit den Konstanten arbeiten und nicht mit relativen Pfaden.
Ich habe das bei mir so gesteuert, dass die config.php abfängt von welcher Domain das Script aufgerufen wird und dann entsprechend wird die WB_URL gesetzt.
if(strpos($_SERVER["HTTP_HOST"], 'domain1') !== FALSE){
define('WB_URL', 'https://www.domain1.de');
}
if(strpos($_SERVER["HTTP_HOST"], 'domain2') !== FALSE){
define('WB_URL', 'https://www.domain2.com');
}Aus dieser WB_URL werden dann die anderen URLs wie ADMIN_URL etc. gebastelt.
Aber jetzt sehe ich, wo die Problematik ist bzw. WO das System wirklich "zu kurz" kommt.
Man kann damit nicht wirklich 2 völlig voneinander getrennte Websites betreiben die unterschiedliche Admins, Editoren, Medienverzeichnisse etc.
hat.
Wie in meinem Falle handelt es sich mehr oder weniger um "die selbe" Seite, den gleichen Verantwortlichen die ins BE dürfen, die selben Dateien und Module ansteuern und verwenden können etc. nur dass sie eben auf 2 Domains je Sprache zugänglich ist.
Mehr als das würde ich mit WBCE nicht machen sondern stattdessen 2 unterschiedliche Instanzen aufsetzen.
Gruß,
Christian
“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale
Offline