access umija thru different domains ....

{DIV(align=>left, width=>25%, float=>right, class="umijabox")}{DIV}

ERFOLG

~~#FF0000:YEEEEEAAAHHHHHAAA FETT!! GEILO GEILO GEILO~~ ICH LIEBE DIESES TIKI !!!! DAMIT KANN MAN EINFACH ALLES MACHEN !!! FETT --> [http://umija.de] (:lol:) JEHH MAN !!! ICH GEH DANN MAL MICH SELBER FEIERN (:cool:) (:arrow:)

Todo

Design für .com
JETZT NUR NOCH DER .COM CATEGORY EIN STYLE ZUORDNEN UND DANN GEHTS LOS :-)
Naja natürlich hier raus noch ein howto erstellen bisch doku, aber dann :-)
Namensraum für .com erstellen worin alle seiten gehostet werden

Umija goes .com! Deshalb brauchen wir ne vernünftige Lösung um einige Seiten von umija.org über umija.com anzuzeigen, jedoch leicht modifiziert!

dis: klml>edma: feeeeeeeetttt, das is ja echt geil, das is ja besser als alles andere, um dich zu preisens wr ich dann getern gleich mal richtig feiern, ins klo kotzemn udn mit 1,5 Promill ins Büro

: what we need

Zwei nicht ganz von einander getrennte Seiten. Beide Seiten sollten in etwa das gleiche Design haben um Identity zu wahren. Aber eben nicht 100% identisch. So brauchen wir sehr alle bzw. andere Menüs auf der .com Seite. Das Layout sollte je nach Lösung angepasst werden um z.B. die vorangestellten Namensraum der Seite nicht Anzuzeigen. Die .com Seiten sind für die Besucher rein Informativ und nicht wiki like, deswegen gibts auch auf der .com nix zum editieren.

: solutions

: statik HTML

Man könnte die Daten einfach als HTML erzeugen und auf dem Server ablegen. Hat den Vorteil dass die Seiten recht schnell angelegt werden können und keinerlei technische Entwicklung bzw. Anpassung notwendig ist. Der Nachteil an der Sache ist der, dass die Seiten eben statisch sind. Jede Änderung bedeutet Datei herunterladen modifizieren und wieder hochladen.

: separate wiki

Um den Nachteil von staren HTML Seiten aufzuheben, kann ein eigenständiges Wiki aufgezogen werden. Dies würde den Betreibern das Ändern der Seiten erleichtern und somit eine Menge Zeit beim Modifizieren ersparren. Jedoch ist es reichlich überdimensioniert für ca. 20 Seiten ein Wiki aufzusetzen, zumal die Seiten auf .com sich nicht so heufig verändern werden.

: separate Database

Ein Wiki jedoch zwei verschieden Datenbanken, könnte den administrative Aufwand von dem separatem wiki mindern. So kann z.B. TikiWiki mehrere Seiten/Domains mit nur einer Software Installation bedienen. Dabei wird je nach URL die Datenbankverbindung angepasst udn die richtigen Daten ausgeliefert. Diese Lösung erleichtert die Administration bei der Installation, jedoch verhällt sich das Wiki anschließend wie zwei unterschiedliche Systeme. Dies bedeutet dass beide weiterhin unterschiedlich konfiguriert werden müssen.

: mix IT baby

Die Usermodule/Module von TikiWiki können einige Parameter überprüfen bevor diese angezeigt werden. In anderen Worten kann das Modul z.B. rausfinden von welcher Seite/URL die Anfrag stammt und dementsprechend etscheiden ob der Inhalt dieses Moduls angezeigt wird oder nicht. z.B: {CODE()} {if ($smarty.server.SERVER_NAME eq 'DOMAIN.TLD')} ICH ERSCHEINE NUR WENN DU MICH ÜBER DOMAIN.TLD AUFRUFST!! {/if}{CODE} Danach muss nur noch der WebServer die Anfragen an die richtige Stelle umleiten ohne dabei den User weiterzu leiten. Aber genau hier liegt der Hund vergrabben.

Notes

Variablen die uns zur Verfügung stehen

{CODE()} _REQUEST["HTTP_HOST"] _REQUEST["SERVER_NAME"] _SERVER["HTTP_HOST"] _SERVER["SERVER_NAME"]