Open Sourced Brain stellt sein drittes WP-Plugin vor:
getBrowserLanguage ermöglicht es dem Blogbetreibenden, die eingestellte Browsersprache(n) seiner User zu ermitteln. Dies ist vor allem sinnvoll für Blogger, welche wahlweise auf internationaler Ebene agieren wollen, oder auch zwecks eventueller Vermarktungen. Auf diese Weise können z.B. auch auf User-Sprache zugeschnittene Werbeelemente postiert werden, so man denn nicht mit Google AdWords wirbt.
Ebenfalls möglich ist es, wahlweise Sprachdateien zu laden, auf eine anderssprachige Blog-Instanz weiterzuleiten und dergleichen mehr.
Ein anderes, praktisches Plugin ist „is-child„. Damit lassen sich Mutter-Kind Beziehungen abfragen. Beispiel: Ich bin auf einer Subpage und möchte dazu passend eine eigene Sidebar mit weiteren Elementen einblenden. Das ist mit WP Hausmitteln nicht möglich, weil WP eben keine Child-Funktion kennt.
Ich hatte bezüglich der Sprache mal eine Mini-PHP-Funktion geschrieben: PHP: Anhand der Sprache des Besuchers Inhalte anzeigen.
Ich wende das z.B. beim Kontaktformular an (Mathe-Frage, Kommentar bearbeiten, etc.), damit auch Leute, die nicht deutsch können, posten können.
In meinem Multilingual PlugIn verwende ich bereits eine freiverfügbare PHP Klasse, die für die default Sprache im WP sorgt. ml_multilingual.code-in-design.de
Allerdings bin ich beim lesen des Artikels etwas irretiert worden.
Was hat dieses neue getBrowserLanguage PlugIn mit deinem „is-child“ zu tun?
Wo ist der Zusammenhang?
Oder hab ich was nicht verstanden?!
PS: Wo ist denn dein Mathe-AntiSpam-PlugIn abgeblieben?
Nun muss ich mir wieder andere Brainstorming-Aktivitäten suchen.. 😉
[…] Individuelle Kategorie Templates kennen wir schon und wissen, wie man sie im WP realisiert.Hier möchte ich einen (naja recht schlampig umgesetzten ;p ) Weg zeigen, wie man mit einem WordPress auch mehrere Websites in unterschiedlichen Themes realisieren kann.(Verbesserungsvorschläge erwünscht)Vor ein paar Tagen erhielt ich einen Auftrag mit u.a. folgendenAnforderungen:3 Websites3 unterschiedliche Layouts1 Adminbereicheasy BedienungSE-Optimiertwenig statischer Content!Aber auf einer Domain!Es sollte dabei eine bereits vorhandene Domain verwendet werden und die 2 zusätzlichen Micro-Sites sollten entweder als Subdomain oder via Subdirectory aufrufbar sein.Ziel:www.domainname.de -> Hauptseite (Layout #1)www.domainname.de/microsite-one/ -> (Layout #2)www.domainname.de/mircosite-two/ -> (Layout #3) Auf Grund der obigen Anforderungen habe ich als erstes schonmal an den Einsatz von WordPress in aktueller Version gedacht.Da der Kunde bereits eine andere Website von mir – auch mit WordPress – besitzt, ist so eine einfachere Einarbeitung in die Administration sichergestellt.Ausserdem ist damit auch schon zum grössten Teil der Punkt "SE-Optimierung" abgehakt. ;)Für die Umsetzung der 3 unterschiedlichen Layouts in einem WordPress überlegte ich mir, wie ich das umsetzen könnte.Als erstes dachte ich an unterschiedliche Kategorie-Templates, was ja recht simpel zu erstellen ist.Das Problem dabei:pages können keiner Kategorie zugeordnet werdenIndividualisierung von Header-, Metadaten und dem Layout an sich sind sehr umständlich und schwer möglichGeht also so nicht. LösungLogische Trennung des Contents:- 3 Kategorien die die posts unterteilen – die Kategorien erhalten 3 eindeutige Slugs (mainsite, microsite-one, microsite-two)- 3 pages die als "übergeordnete pages" dienen – diese drei pages erhalten den gleichen Slug wie auch die Kategorien (mainsite, microsite-one, microsite-two)Permalink Struktur: – "/%category%/%postname%.html"Nun haben wir eine logische Unterteilung, aber wie bewegen wir WordPress dazu, je nach Slug (Kategorie bzw. Mainpage) das Theme zu wechseln?Als erstes musste ich herausfinden, wie ich das Theme am besten per PlugIn wechseln kann.Das fand ich heraus, indem ich das PlugIn "Theme Switcher" analysierte. (Theme Switcher)Jetzt wusste ich, wie ich das "switchen" realisieren konnte.Wie ermittel ich aber, wann ich welches Theme einsetzen muss?Theoretisch wäre dies machbar, indem ich immer herausfinde, zu welcher Kategorie oder zu welcher Mainpage ein post oder eine page gehört.Das sollte wohl mit dem PlugIn "is_child" möglich sein, worüber ich erst neulich bei Robert gelesen habe. (is_child)Es ermittelt zu jeder/m page/post das Eltern-Element.Somit perfekt für meine Steuerung des Theme Switcher.Oder doch nicht?Leider nein, denn das PlugIn is_child verwendet Funktionen und Variablen, die es zum Zeitpunkt des Theme Switchers noch nicht gibt und liefert somit keine Ergebnisse.Rein cronologisch gesehen, wird das Theme bereits entschieden und eingestellt, bevor es möglich ist zu ermitteln, welche page aufgerufen werden soll und was das Eltern-Element ist (jedenfalls mit WP-Mitteln).Somit leider unbrauchbar.Nach vielem hin und her und einigen Versuchen, musste ich vorerst zu einer etwas unsauberen Variante greifen.Anhand der globalen Server Variable "REQUEST_URI" kann ich sehen, welches Slug in der obersten Hierarchie vorkommt.(Nur mit einer Permalink Struktur wie oben möglich)Enthält der String also z.B. "mircosite-one", kann ich den Theme Switcher anweisen, das entsprechende Theme zu verwenden.Enthält der String "mircosite-two", nimmt er das andere entsprechende Theme und findet er keinen Slug der beiden darin, verwendet er das normale Theme, welches im WordPress eingestellt wurde.Das Ergebnis des Ganzen ist eine einfach zu durchschauende logische Struktur des Contents und ein kleines PlugIn.Das "CiD Multitheme PlugIn" benötigt als Einstellung lediglich die zwei Slugs der microsites und den Namen der jeweiligen Themes.Alles andere sind reine Standardanpassungen am Theme selbst.(Ausblendung von anderen microsites (exclude=x,x,…)(hab ich was vergessen? – poste es als Kommentar)[Tags:Blogs Inside, Multitheme, Plugin, Projekte & HowTos, Theme WordPress] ähnliche Beiträge: […]