Das Problem war ein ganz anderes:
In “alten” PHP Dateien kannst du mit >? deinen PHP Code beginnen.
Bei einigen PHP Parsern (also die “neuen”) wird jedoch ein >?php erwartet.

Also immer mit >?php ?> deinen PHP Code deklarieren, dann klappts auch mit dem Parser.
Vielleicht ist das in der php.ini oder sonst wo heutzutage so konfiguriert.
Bringt ja nichts, wenn WordPress deswegen nicht mehr funktioniert

Ähnliche Beiträge

Was war mein erster Eindruck beim Erstellen?

Mir kam das Ganze ziemlich wirr vor. Ein Theme wird aus diversen Dateien zusammengesteckt und greift auf tonnenweise Funktionen von WordPress zurück. Man kann wahnsinnig viel kombinieren und wahnsinnig viel falsch machen.
Aber egal, Jammern hilft nichts und irgendwann muss es halt sein.

Dateien anlegen

Um einen Theme erstellen zu können, muss zuerst ein Verzeichnis für den Theme im /wp-content/themes erstellt werden.
Da gehören alle Code-Schnipsel für den neuen Theme hinein.
Es gibt zum Glück schöne Anleitungen, z.B. auf WordPress.org Codex.
Da kannst du nachlesen welche Dateien warum benötigt werden.
Im Folgenden habe ich einen miradlo-Theme beschrieben. Wenn du also miradlo im Text findest, dann ist das der Pfad des Themes und dessen Name.

Beschreibung zum Theme konfigurieren

In der Datei style.css wird nicht nur das Design deines Themes festgelegt, sondern auch noch die Beschreibung für den Theme hinterlegt. Wenn du im Adminbereich deinen Theme auswählst, wird diese Beschreibung dort angezeigt. Wieso man eine Beschreibung im Stylesheet hinterlegt habe ich zwar nicht kapiert, aber das soll dann wohl so sein… Pass ein bisschen aufs Format auf. Das ist etwas eigenwillig.

Adminseiten für das Theme in der Admin-Theme-Edit Navigation

Um die Administrationsseite des Themes zu erstellen, hat Kubrik in Seine functions.php alle Ansichten eingebaut.
Ich habe mir das mal ein bisschen auseinandergenommen (löschen, löschen, wundern, löschen) und fand ein paar Punkte heraus.
Erstes Ziel war für mich, dass ich auf der Administrationsseite unter Design mein Theme auswählen und weitere Menüpunkte eingeben kann.
Weiterhin wollte ich die sprachabhängigen Texte in de_DE.mo Dateien hinterlegen, damit später eine Übersetzung in andere Sprachen möglich ist.
Also, das Registrieren der neuen Seite funktioniert so:

Mit load_theme_textdomain() wird sichergestellt, dass die eigene Sprachdatei geladen wird.
Mit add_action() wird hier im admin_menu die gewünschten Links eingetragen.
Dabei handelt es sich um eine Callback Funktion, die schlussendlich die miradlo_add_pages() aufruft.
Innerhalb der miradlo_add_pages() Funktion wird mit add_theme_page() der jeweilige Link registriert.
Spannend finde ich noch die Funktion translate(). Damit kannst du einen Text in die aktuell geladene Sprache übersetzen lassen. Wenn du das konsequent durchführst, ist dein neues Administrationstool für den Theme wirklich Multinational
Cool finde ich, dass wenn translate() keine Übersetzung findet, dann verwendet es den Text den du übergibst. Damit kannst du z.B. eine englische Grundsprache deklarieren und die Übersetzungen können dann nach- und nach durchgeführt werden.
Bitte denke daran, der translate() Funktion als zweiten Parameter deine Textdomäne mitgibst. Ansonsten zieht translate() die WordPress Basisübersetzung. Da drin werden wohl ganz selten deine eigenen Übersetzungen passend drin sein
Wenn der Link “Configure custom header” gedrückt wurde, dann wird die miradlo_change_header_page() Funktion aufgerufen.
Innerhalb dieser Funktion kannst du nun deine Administrationsseite aufbauen.

Sprachdateien erstellen

Die Sprachdateien werden als .po Dateien abgelegt.
Wenn du z.B. die deutsche Lokalisierung erstellen willst, dann erstellst du eine de_DE.po Datei.
In der de_DE.po Datei sollte dann für das obige Beispiel folgender Eintrag hinterlegt werden:

Du schreibst im Kommentar (#) rein welche PHP Datei in welcher Zeile den Ursprungstext beinhaltet.
Die Schlüssel / String Eintragung wird über msgid und msgstr eingegeben.
Wenn die Datei erstellt wurde, musst du mit Poedit die Datei öffnen.
Poedit ist ein grafischer Editor für *.po Dateien. Wenn du die Datei editiert hast, kannst du sie speichern. Poedit generiert dann eine *.mo Datei. Und die *.mo Datei wird dann von WordPress verwendet um die Sprache zu laden.

Ausblick

Ich werde jetzt die eigentliche Administrationsoberfläche bauen.
Die einzelnen Seiten werde ich nicht in der functions.php aufbauen. Das bedeutet, dass ich die Callback Funktionen in eigene Dateien auslagere und in functions.php mittels include_once entsprechend einbinde. Dann bleibt die functions.php lesbar und macht das, was sie tun soll. Sie stellt die Funktionen zur verfügung und dispatched auf andere Dateien.
Und dann werde ich dafür sorgen, dass unsere Headers schöne Farben und Grafiken zum Auswählen bekommen
Happy Blogging!

Ähnliche Beiträge

Funktionale Anforderungen an ein Blogsystem

Wenn man ein Blogsystem mal ein bisschen abstrakt anschaut, besteht es aus:

Texteingabe

Eine Texteingabe mit der man seine Überschrift, seine Tags, seine Beschreibung und den eigentlichen Text eingeben kann.

Kategorie / Serienverwaltung

Dann wäre es noch schön wenn man seine Kategorien und eventuell, wenn man Roland heißt , seine Serien pflegen kann. So ein bisschen Ordnung im Blogsystem hat schon was.

Kommentarfunktion / Zitieren

Der jeweilige Blogeintrag muss kommentierbar sein. Sonst ist der Blog ja nichts weiter als eine weitere Seite die nur Texte verteilt und die Community kann nichts dazu beitragen. Wäre mehr als saudoof gelle?

Diverse Präsentationsmöglichkeiten

Wenn dann mal ein Artikel getippt wurde, sollte der auch in einem ansprechenden Design den Lesern zur Verfügung gestellt werden.
Und wir haben heutzutage nicht nur 3270 Emulationen, sondern schöne bunte Webbrowser.
Weiterhin haben wir noch:

• Feedreader
• E-Mail Clients
• Braile Leser
• Mobile Endgeräte (Ichfons, Telefon, Mikrofon… )
• …

Also bietet es sich doch an, für jedes dieser Wunderwerke den nötigen Output zu erzeugen.
Mit XSLT und anderen steinalten Technologien kann man das ja schön erzeugen.
Für die Großgrundbesitzer unter uns könnten wir ja sogar ein ETL Werkzeug einsetzen und richtig viel Geld ausgeben

Trackbacks und Co

Ein Blogsystem soll sich mit anderen Blogssystemen austauschen können. Ansonsten klappt die Vernetzung mit der Welt wohl nicht ganz so gut. Also wäre es doch schick, wenn wir noch die Trackbacks, Pinbacks und was es da so gibt zur Verfügung hätten.

Strukturierte Texteingabe

Nicht jeder ist ein Purist und tippt gerne Plain HTML
Gut, ich hab mich daran gewöhnt und es geht bei mir schneller als wenn ich Klicki-Bunti-Editoren verwende. Aber vielleicht bin ich alter Konsolenjunkie auch nicht die beste Referenz für so was…
Vielleicht muss man ja auch gar keine HTML Eingabe machen. Die Götter des Netzes haben bei den Wikis eine andere Strukturform erfunden. Diese soll für nicht so gewiefte Menschen einfacher zu erlernen sein. Also gibt es auch hier einige Möglichkeiten die man nehmen könnte. Vielleicht könnte man auch schnelle WYSIWYG Eingabewerkzeuge erstellen. Bei Serendipity war ich z.B. von der Geschwindigkeit auf meinem Asus Eee 900 wirklich begeistert…

Das wars dann auch schon. So ein Blog soll meiner Meinung nach zum Kommunizieren anregen. Er soll nicht durch hundert Verwirrknöpfe und Superdefinit-Label-Manager-Ich-Habe-Keine-Ahnung-Wozu Features den Anwender abschrecken. Und wenn dann jemand doch alle Knöpfe und Features haben will, dann kann er oder sie ja Blogsysteme nutzen die dies bieten.

Nichtfunktionale Anforderungen

Es gibt auch eine ganze Menge Anforderungen, die mit der eigentlichen Funktion des Blogs nichts zu tun haben.
Ohne diese Anforderungen funktioniert zwar das System als solches nicht, aber der Nutzen des Blogsystems wird hierüber nicht definiert.

Spamfilter

Leider werden Blogsysteme, vor allem Kommentare, für unsere Freunde von der Spamfraktion gerne und reichlich genutzt. Wir Blogger mögen das gar nicht und sind nicht einmal davon begeistert, dass wir dann mehr Arbeit mit dem Putzen zu tun haben. Und manchmal passiert es dann, dass sogar vernünftige Kommentare (Siehe letze Woche Imbo Sims Kommentar) auch im Spam landen. Das ist einfach nur doof, aber Spamer haben irgendwie ein anderes Weltbild.

Userverwaltung

Ich habe den Verdacht dass der Trend sehr massiv zur Multiuser Instanz geht. Überall sprießen Social Network Plattformen aus dem virtuellen Boden. In Firmen will jede Abteilung einen eigenen Blog und der Verein fühlt sich auch nur wohl, wenn der Vorstand seinen eigenen Blog hat. Also sollte der Blog auf diese Bedürfnisse eingehen.

Erweiterungsmöglichkeiten (Plugins)

Der Featurismus kennt heute keine Grenzen. Für jedes Themengebiet gibt es einen tollen Plugin. Also soll ein Blogsystem sich nicht verschließen sondern eine saubere Schnittstelle für Plugins zur Verfügung stellen.
Bei WordPress gibt es für jedes Thema gleich mehrere Plugins. Bei Serendipity gibt es für jedes Thema exakt einen Plugin.
Beides hat seine Vor- und Hinterteile.
Was mir aber auf alle Fälle sehr wichtig erscheint ist, dass die Plugins nie auf die Coretabellen schreibend zugreifen. Will heißen, wenn ich eine Erweiterung mache, dann soll diese auch in ihrem eigenen Bereich stattfinden. Updates usw. werden ansonsten ein wahrer Horror. Noch geiler ist es, einen Plugin gegen einen anderen auszutauschen und alle Abhängigkeiten, die vom alten Plugin her vorhanden sind, dann noch gerade zu ziehen. Naja, wir basteln ja gerne…

Stabil

Tolle Anforderung! Aber wahr. Ein Blogsystem muss meiner Meinung nach auf einem Stück Holz laufen und darf keine Probleme machen. Es muss einfach funktionieren.

Schnell

Wenn ich z.B. die Eingabe von Serendipity mit WordPress vergleiche, möchte ich sofort von WordPress umsteigen. Ich hasse es zu warten. Klar, meistens schreibe ich meine Artikel mit Quanta im Zug offline und kopiere den Text nur noch ins Blogsystem. Aber das ist ein Würgaround und sicherlich nicht das was eigentlich angedacht war.

Sicher

Jeden zweiten Tag ein Sicherheitsproblem finde ich auch nicht gerade schön. Das System sollte im Idealfall nicht angreifbar sein. Diese Anforderung ist nicht umzusetzen, jedoch sollte es möglich sein eine stabile Software zu erstellen, die dem Stand der Technik entspricht und Scriptkiddies einfach nicht reinlässt.
In diesem Fall sollte man sich den gesamten Stack anschauen.
Angefangen beim Betriebssystem (oder gar den Firewalls) über den Webserver, bis hin zur Datenbank und eingesetzten Programmiersprache.
Wenn man ein bisschen “unsicherer” unterwegs sein will, sollte wenigstens die Architektur des Blogsystems so sauber sein, dass keine unnötigen Fehlerquellen sich darin verstecken können.

Sauber strukturierte Architektur und Coding Styleguides

Damit das System sauber bleibt, muss dafür Sorge getragen werden, dass die Architektur strukturiert und aufgeräumt ist. Ein Framework (muss) eingesetzt werden, mit dem eine saubere Vorgehensweise möglich ist. Wie immer ist Seperation of Concerns und Design Patterns nicht nur toll zum Malen sondern wichtig um die Software stabil zu halten.

Testszenarien

Jede Funktionalität muss regressiv testbar sein. Falls ein Sicherheitsloch gestopft wurde, muss dies getested werden. In einem Jahr kann das gleiche Loch sonst wieder auftreten.

Installierbar

Das Blogsystem muss installierbar sein. Das bedeutet, dass mit einfachen Scripts oder Oberflächen die Installation schnell und einfach vonstatten gehen soll.

Sinnvolle Releaseplanung

Patches, Releases usw. sollen planbar sein. Ein altes Blogsystem sollte auf alle Fälle noch eine Weile (z.B. ein Jahr) supported werden. Ich finde es vollkommen dumm, wenn man jede Woche ein Update, Patch, Flick, Fummel am System durchführen muss. Das ist nicht wirtschaftlich und führt dazu, dass steinalte Systeme mit dicken Löchern im Netz herumstehen.

Sinnvolle Feature Planung

Erweiterungen, neue Features usw. müssen in die neuen Versionen eingebaut werden können. Hier halte ich es für wichtig, dass die Planung klar kommuniziert wird und jedem Anwender klar sein muss wann welches Feature zur Verfügung steht.

Support

Wenns mal nicht klappt sollten Foren, Newsgroups und/oder Bugtracker vorhanden und gepflegt werden.

Dokumentation

So ein Wiki hat was. Wenn man die Dokumentation finden kann, dann können die Fehler der Vergangenheit ruhen und durch Neue ersetzt werden Im Ernst, es ist doch ziemlich dumm ein gutes System zu haben und niemand weiss davon.

Migrationsfähigkeit / Upgradefähig

Gibt es was nervigeres als ein neues Release einzuspielen und dann alle bisher vorhandenen Datensätze nicht mehr verwenden zu können?
Immer diese rethorischen Fragen
Wenn ein neues Update vorhanden ist, soll das ohne manuelle Eingriffe und ohne Datenverlust einspielbar sein. Sowas haben wir in der IT schon seit Jahren eigentlich im Griff. Wieso also nicht auch bei Blogsystemen?
Stellt euch mal vor, nur weil ein neuer Release vorhanden ist, müsst ihr mit eurer Bank nochmal einen neuen Vertrag abschließen. Klingt ziemlich ungeschickt gelle?

Na was sagt ihr dazu?

Ich gebs ja zu, ich hatte mir überlegt eine Blogparade anzustoßen. Aber im Moment bin ich noch zur Hälfte mit der Baustelle daheim beschäftigt und möchte daher nur mal hier ein bisschen rumdiskutieren.
Habe ich noch was wichtiges Vergessen oder bin ich schon wieder übers Ziel hinausgeschossen?
Gibt es Blogsysteme, die diese Anforderungen abdecken?
Sollten wir (die Internetcommunity) ein weiteres Blogsystem erstellen, dass diese Anforderungen abdeckt?
Fragen über Fragen. Ich bin echt gespannt was ihr dazu meint.

Ähnliche Beiträge

Aber hier gibt’s offenbar keine weiteren Probleme mit WordPress und dem Update. Fein, wenigstens etwas.

PS: Wer Fehler findet, bitte nicht behalten, sondern Bescheid geben, danke.

Ähnliche Beiträge

Das sind ja nun drei Wünsche auf einmal gelle?

Ich bin also mal in ein WordPress Theme reingestiegen und wollte gleich wieder raus gehen.
Da drin findet sich ein buntes Gemisch aus HTML-Tags und PHP Code.
Ich war wirklich überrascht wie schlecht man solche Ansichten aufbauen kann.

• Vollkommen unübersichtlich
• Verwendung von PHP 4 Sprachbefehlen (if … :  … endif)
• Aufruf von diversen Helferfunktionen aus den unterschiedlichsten Bereichen
• Wartbarkeit ist für diese Themes eher ein Fremdwort

So, nachdem ich erst einmal lauthals geflucht habe, habe ich mir überlegt was ich damit anfangen will.

Was habe ich zuerst gemacht?

Ich bin hingegangen und habe mir ein paar Helfermethoden erstellt.

• Methode mit der ein dynamischer Text innerhalb eines zu definierenden HTML Tags ausgegeben wird.
  Diese Methode kann mit ein paar Parametern aufgerufen werden und ich kann hiermit ca. 60% vom HTML Code aus dem Theme verbannen.
• Methode mit der komplexe HTML Tags dargestellt werden können.
  Um Listen usw. zu generieren, habe ich noch eine weitere Methode erstellt. Damit spare ich noch mehr HTML Code ein.
• Methode um WordPress Funktionen zu rappen und Funktionen die keinen String zurückgeben dennoch in HTML Tags umzuwandeln.
  Damit konnte ich dann ungefähr 90% aller HTML Tags aus dem Theme entfernen.

Was bringen diese Methoden?

Ich kann hiermit (fast) sämtlichen HTML Code aus dem Theme entfernen.
Das Theme beinhaltet eine Aneinanderreihung der darzustellenden WordPress Funktionen. Wenn diese Funktionen in richtiger Reihenfolge dort eingebunden werden, sind sie sehr einfach zu überschauen und zu verstehen.

Ich habe damit meinem Theme die Lesbarkeit enorm verbessert.

Was mach ich als nächstes?

Wenn ich wieder dazu komme, werde ich alle Theme Dokumente entsprechend umwandeln und dokumentieren.
Danach sieht die Welt mit WordPress gleich viel aufgeräumter aus.
Weiterhin möchte ich die letzten “Geheimnisse” des WordPress Aufbaus verstehen.
Was ich bisher gesehen habe ist, dass die einzelnen Funktionen nach Themengebieten geordnet in den einzelnen Dateien hinterlegt sind.
Die meisten  Funktionen so gebaut, dass sie Strings ausgeben können oder direkt mit echo ihre Ausgaben in den Themes durchführen.
Leider ist das nicht ganz durchgängig. Einige Funktionen können nur Strings zurückliefern oder nur echo durchführen. Hier sehe ich eine ziemliche inkonsistenz des Systems.
Diese Inkonsistenz kapsle ich mit meinen Helfermethoden. Somit kann ich einigermassen gleichmässig mit den Funktionen umgehen.

Was halte ich zur Zeit von WordPress?

Nach anfänglichem Erschrecken habe ich feststellen dürfen, dass WordPress durchaus eine logische Struktur mit sich bringt. Bei vielen Architekturen sammelt sich der “Unsinn” in den Views. Das kommt oft vor, da die Anwender nicht wissen, wo sie ihre Funktionalität einfügen sollen.

Ich denke mal wenn die eigenen Themes sauber aufgeräumt sind, dann wird dieses System auch einfacher zu warten und pflegen sein.
Sobald ich weiter komme, werde ich euch darüber informieren.

Ähnliche Beiträge

Das Verzeichnis /etc/apache2/sites-available

In diesem Verzeichnis findest du nach der Basisinstallation von apache2 die default Datei.

Darin ist der Standard Webserver (/var/www) definiert. Wenn du also deinen localhost im Webbrowser aufrufst, wirst du die Standard Startseite vorfinden.
Kopiere diese Datei und benenne die Kopie z.B. blog.
Editiere die Datei blog und füge folgende Informationen hinzu:

Diese Datei beinhaltet somit die identischen Definitionen, wie bei den Installationen unter Gentoo.

/etc/apache2/sites-enabled Link setzen

Damit der Apache unter Ubuntu die neue Konfiguration findet, musst du in /etc/apache2/sites-enabled noch einen Link auf unsere neue Konfiguration setzen.
Also:

rewrite Mode aktivieren

Mit dem Befehl:

wird das rewrite Modul im Apache freigeschalten.
Dieses Modul wird benötigt damit WordPress seine URLs umbenennen kann.

Hast du auch libapache2-mod-auth-mysql installiert?

Ich hatte ein bisschen Startschwierigkeiten, da dass Paket libapache2-mod-auth-mysql nicht installiert war. Mit diesem Modul wird erreicht, dass wir uns an der MySql Datenbank anbinden können.
Also installiere es mit

Die restlichen Installationsabläufe für BuddyPress kannst du im Artikel Eine BuddyPress Installation durchführen nachlesen.

Ähnliche Beiträge

Stärken

• Die vollständige Integration ermöglicht das Newssystem mit der Community von WordPress zu teilen und zu erweitern.
• Es ist kein Overhead vorhanden, der das Newssystem und WordPress voneinander entkoppelt.
• Die Entwickler lernen Plugins für WordPress zu erstellen und können dieses Wissen für weitere Plugins einsetzen.
• Da es sich beim Newssystem um einen Plugin handelt, sollte die Wartbarkeit und Installierbarkeit kein Problem darstellen. Die entsprechenden Vorgehensweisen sind beschrieben und allgemein bekannt.

Schwächen

• Die Komplexität von WordPress wird auf das Newssystem übertragen.
• Vollständige Abhängigkeit von WordPress und dessen Architektur.
• Bei Updates muss das Plugin entsprechend angepasst werden.
• Die Views für einfache Darstellungen werden relativ komplex
• Die relativ komplexe Eingabemaske von WordPress wird für den Plugin erweitert. Somit wird die Eingabe für News nicht einfach möglich sein.
  Die Anforderung, eine einfache Eingabemaske zu ermöglichen, ist nur schwer zu realisieren.

Chancen

• Das Plugin kann von der WordPress Community ohne Schwierigkeiten mitgenutzt werden.
• Eine große Community steht hinter der Lösung.
• Weitere Plugins können von den Entwicklern erstellt werden.

Risiken

• Die Eigenschaften des Newssystems lassen sich nicht ohne großen Aufwand als Plugin umsetzen.
• Die Komplexität des Plugins wird unterschätzt.
• Durch die speziellen Eigenschaften wird die Performance massiv reduziert.
• Der Einbau in einfache Webseiten kann nur mit hohem Aufwand erfolgen.
• Nicht alle Anforderungen können umgesetzt werden.

Ähnliche Beiträge

Stärken

• Sämtliche Funktionen, wie Benutzerverwaltung und Editier-Eigenschaften, können von WordPress übernommen werden und müssen nicht selbst entwickelt werden.
• Alle Plugins und bestehenden Komponenten von WordPress oder BuddyPress können direkt mitverwendet werden.
• Nur wenige spezielle Funktionen müssen erstellt werden.

Schwächen

• Die Komplexität von WordPress wird übernommen.
• Bei Updates in WordPress müssen die eigenen Komponenten mindestens getestet werden.
• Für die verschiedenen, einfachen Eingabemöglichkeiten, muss die WordPress Funktionalität stark abgeändert werden.
• Das Newssystem ist an WordPress angepasst. Andere Blogsoftware wird nicht berücksichtigt.
  Dieses Problem gilt auch, wenn andere Blogsoftware verwendet wird.
• Man legt sich auf eine Basissoftware fest.
• Die Eigenschaften von WordPress müssen sehr gut bekannt sein und die Entwickler müssen dieses System erlernen.
• Die Installation und Konfiguration wird um die Komponenten des Newssytems ergänzt und stellt sich somit komplexer dar.
• Bei einem Upgrade von WordPress muss die Datenstruktur von WordPress und die Datenstruktur des Newssystems getrennt voneinander betrachtet werden. Das Backup und Recovery wird entsprechend komplizierter.

Chancen

Risiken

• Durch die Komposition können Performanceprobleme auftreten.
• Das Newssystem wird von der WordPress Community nicht akzeptiert, da es nicht nativ in WordPress integriert wurde.
• Die Anpassung der Views, und weiterer Elemente, kann zu unvorhersehbaren Problemen führen. Die Umsetzung ist mit vernünftigem Aufwand nicht möglich.
• Die Einlernzeit in WordPress kann länger sein als die Eigenentwicklung.
• Migrationen auf andere Versionen oder gar auf andere Blogsoftware kann sich als äußerst schwierig herausstellen.

Ähnliche Beiträge

Wenn also die Views kein Problem darstellen, wieso dann nicht einfach den Adminbereich entsprechend anpassen und gut ist?

Das ist eine berechtigte Frage.
Wie immer gibt es pro- und cons dafür.
Wenn ich an meine letzten Kunden denke, dann möchten die so schnell wie möglich so wenig wie möglich eingeben.
Das bedeutet, dass sie keine großen Administrationsoberflächen diesen Menschen unterjubeln kann.
Wenn die plötzlich sich in der Mächtigkeit von WordPress wiederfinden sollen, dann sagen sie zu mir: “Vielen Dank Roland! Kannst du bitte dort zur Türe hinausgehen und diese von außen schließen? Wir wollen mit dir nichts mehr zu tun haben!”
Und das mag ich nicht. Vor allem wenn es draußen regnet und kalt ist…
Geschmäcker sind verschieden. Und wenn diese Menschen eine einfache Oberfläche haben wollen, dann sollen sie diese bekommen.
Wenn sie z.B. zuerst den Text und dann den Titel schreiben wollen, also mein geliebtes Beispiel dass ich immer wieder bringe, dann sollen sie auch das tun können.
Ich möchte die Software so generisch halten, dass ich in der Lage bin die verschiedenen Welten miteinander zu verbinden.
Falls ich dann doch noch auf die Idee komme dieses Newssystem als Plugin zu realisieren ist dass auch ok.
Aber im Moment möchte ich noch ein wenig herumphillosophieren und mir alle Möglichkeiten anschauen.

Ähnliche Beiträge

Was für Erkenntnisse habe ich heute?

Ich habe mittlerweile erkannt, dass ich am Wochenende am Barcamp in Dornbirn locker über die Modularisierung und Benutzung von bestehenden Systemen sprechen kann.
Am Beispiel des Newssystems müssen vermutlich nur

• Ein Endedatum, an dem die News (der Artikel) nicht mehr dargestellt werden darf.
• Eine einfache Eingabe für die News, also keine komplette WordPress Eingabe sondern wirklich nur Titel und Beschreibung sowie Start- und Endedatum.
• Einige Views, mit denen die News Einträge überall ohne das komplette WordPress Verhalten angezeigt werden können. Dies kann über RSS Feeds oder über explizit entwickelte Views erreicht werden.

Wie könnte man WordPress entsprechend einbinden?

Nichts leichter als das!
Wir nehmen eine Factory Klasse, die uns für die unterschiedlichen WordPress Versionen die entsprechenden Adapterklassen anzieht.
Auf diese Weise sind wir vom WordPress entkoppelt und erhöhen nicht die Komplexität bei einem Update.
Das Ganze könnte ungefähr so aussehen:

Ich erstelle einen Adapter, oder eventuell eine Fassade, mit der die Komponenten von WordPress oder BuddyPress an mein eigenes System angepasst werden.
Da sich während eines WordPress Updates die Schnittstellendefinition verändern kann, wird pro WordPress Version ein dafür notwendiger Adapter oder Fassade geschrieben.
Falls sich nichts ändert, kann natürlich der gleiche Adapter verwendet werden.
Über eine Fabrikklasse kann die im Moment aktive Adapterklasse instanziiert und zurückgeliefert werden.
Die Fabrikklasse kann relativ einfach die Version des aktuell verwendeten WordPress auslesen und entsprechend den richtigen Adapter zurückliefern.
Cool oder?

Wie sieht es mit der Komplexität aus?

Auf dem Fucamp in Furtwangen habe ich über Guggat emol Blog, viel Spaß beim Lesen! Über Links zu Artikeln freuen wir uns, jedoch bitte bindet nicht einfach unsere Inhalte in eure Seite ein, danke. Hinweis für Feedleser: Beiträge, die Quellcode enthalten sind auf der Webseite meist besser lesbar, als in einem Feed-Reader.
4e3744397ab2a417f811b29573bcbef4)]]> http://www.baldenhofer.eu/blog/it/factory-und-adapter-pattern-fuer-die-erweiterung-von-wordpress/feed 0 http://www.baldenhofer.eu/blog/it/ist-das-newssystem-einfach-nur-eine-view-auf-eine-blogsoftware http://www.baldenhofer.eu/blog/it/ist-das-newssystem-einfach-nur-eine-view-auf-eine-blogsoftware#comments Tue, 02 Jun 2009 20:12:57 +0000 Roland http://www.baldenhofer.eu/blog/?p=1311 Heute habe ich zu Jozo gesagt, er soll sich einfach mal Gedanken machen was er mit dem Newssystem so alles anfangen will.

Ich bin zum Beispiel noch auf ein paar Gimmicks gekommen. Beispielsweise könnte man an das Newssystem ein paar schöne Ausgabeelemente anbinden:

• Einen Kalender, der anzeigt wann eine News aktuell wird
• Alle News sortiert nach irgendwelchen verrückten Eigenschaften wie z.B. nach Tags.
  Hier müsste man dann aber noch Tags einführen mit denen man dann die News wiederfinden kann. AHA! Schon klingt es sehr nach einer Blogsoftware oder?
• Alle News die ein bestimmtes Schlagwort enthalten.
  Hier würde ich empfehlen, mit einem bestimmten Caching Verhalten zu arbeiten. Sonst wird die News ziemlich langweilig zum Anschauen
• Wenn eine News eines bestimmten Menschen freigegeben wird, könnte man sich informieren lassen. Also könnte man die News seines Platzwartes beim Fußballverein sich per SMS aufs Natel, Handy, Mobile, Cellphone schicken lassen.
• Alle News von allen Redakteuren per SMS oder per RSS oder was weiss ich was verschicken lassen.

Und wenn man das ganze so anschaut, dann sieht es doch schon schwer nach einem WordPress MU oder nach einem BuddyPress aus.

Denn was machen WordPress MU und BuddyPress?

Sie geben für einen Artikel die Möglichkeit vor, einen Titel und einen Text zu schreiben.

Man kann Bilder einpflegen und man kann Tags und Beschreibungen zusammenstecken.
Man kann sich von seinen “Mitbloggern” in seinem Netzwerk zu Gruppen zusammenfassen lassen.
Man kann sich Nachrichten von den Mitbloggern zukommen lassen.

Man kann also eine ganze Menge, die wir mit unserem Newssystem auch machen wollen.

Was können die Systeme bisher so nicht?

Sie können ohne Erweiterung keine eigentlich schnell zu bedienende Newsfunktion bereitstellen.
Man kann nicht die WordPress Seiten ohne weiteres irgendwo einbinden.
Vermutlich gibt es da ein Plugin, also bitte vergebt mir meine Unwissenheit

Auf alle Fälle müsste man die Anzeige von News entsprechend abändern.
Bei einem Blogsystem werden Artikel nach einer bestimmten Zeit in das Archiv verschoben. Man kann normalerweise nicht sagen:

Morgen ist Weihnachten, also zeige diesen Artikel.
Übermorgen ist Weihnachten vorbei, also zeige diesen Artikel nicht mehr.

Daraus folgt, dass man die Blogsoftware entsprechend anpassen müsste.
Oder man schreibt sich doch ein eigenes, für News perfektioniertes, System.

Warum habe ich jetzt ein Problem?

Naja, ich möchte am Wochenende auf dem Barcamp in Dornbirn über das Thema Warum muss Software Wegwerfware sein? sprechen.
Wenn ich dort als der Monstermissionar auftreten will und es eigentlich doof finde immer neue Software zu schreiben und auf der anderen Seite ein Newssystem basteln will, dass zu 70% eine Social Network Plattform ist, dann sollte ich schon mal über mein Tun nachdenken.

Ich halte es für mehr als vernünftig, dass ich zuerst mit ein paar Menschen über dieses Thema spreche und dann das Newssystem erstelle.
Im Zweifelsfall ist es immer noch ein Schulungsprojekt um den lieben Jozo durch seine Fachausweis Informatikerlehre durchzudrücken.

Auf der anderen Seite ist es natürlich auch sinnvoll, wenn wir z.B. das BuddyPress so ergänzen, dass unsere News da rauspurzeln. Dann brauchen wir uns wenigstens nicht so arg um die Eingabe der einzelnen Artikel kümmern…

Ähnliche Beiträge

Systemübersicht

Ok, wir haben also diverse Softwarekomponenten die aufeinander aufsetzen.
Im folgenden Deploymentdiagramm kannst du die verschiedenen Komponenten sehen.

Als erstes möchte ich die Basiskomponenten kurz beleuchten.

MySQL Datenbankserver

Um WordPress, und alle darauf aufbauenden Komponenten, betreiben zu können musst du eine Datenbank zur Verfügung stellen.
Standardmässig wird hier eine MySQL Datenbank vorausgesetzt.

Komponenten auf dem MySQL Datenbankserver

Du musst eine Datenbank auf dem Datenbankserver für WordPress erstellen.
In dieser Anleitung nennen wir unsere Datenbank wordpress.
Diese Datenbank kannst du, wie im Artikel Datenbank anlegen beschrieben, anlegen.

Domain Name Server (DNS) Konfiguration

Wenn du unendlich viele Subdomänen auf dein WordPress MU System loslassen willst, musst du entsprechend deinen DNS Server darüber informieren.
Normalerweise hast du keinen eigenen DNS Server sondern verwendest den von deinem Provider.
Falls du nur eine lokale Testinstallation durchführen willst, dann schau dir mal den Abschnitt hosts an.

Apache Webserver Basisinstallation

Alle weiteren Komponenten finden sich auf dem Apache Webserver wieder.
Der Apache Webserver muss PHP verstehen. Weiterhin muss die httpd.conf und die vhost Konfiguration für WordPress MU durchgeführt werden.

httpd.conf konfigurieren

Im Artikel Installieren von WordPress MU->httpd.conf habe ich die Konfiguration von httpd.conf ein wenig beleuchtet.
Dort bin ich nur auf den Schalter LoadModule rewrite_module modules/mod_rewrite.so eingegangen.
Eventuell musst du, je nach Apache Konfiguration, die Information die ich im Abschnitt 00_default_host.conf konfigurieren beschrieben habe, in die httpd.conf einschreiben.
Das musst du leider selbst entscheiden.

00_default_host.conf Konfigurieren

Hierüber werden deine Blogs später vom Apache an die WordPress MU Funktionalität weitergeleitet.
Im Artikel Installieren von WordPress MU->00_default_host.conf habe ich beschrieben, wie du dedizierte Subdomänen anlegen kannst
Hiermit kannst du sehr genau steuern, welche Blogs bei dir laufen sollen. Falls du also nur bekannte Blogs zulassen willst, kannst du hiermit deine Installation ein wenig absichern.
Normalerweise möchtest du eine unbegrenzte Anzahl von Subdomänen einführen. Deshalb habe ich im Artikel Konfiguration von Apache für viele Subdomains bei WordPress MU die Wildcards beschrieben.

php.ini anpassen

Da WordPress ein kleiner Speicherfresser ist, musst du deine php.ini entsprechend anpassen. Schau dir mal den Artikel php.ini anpassen an.

BuddyPress Komponenten installieren

Ich habe hier angedeutet, dass sich BuddyPress aus WordPress MU und BuddyPress Plugins / Themes zusammensetzt.
Wie unter Download der WordPress MU Sourcen beschrieben, kannst du dir die aktuelleste Version von WordPress MU herunterladen.
Weiterhin musst du dir die aktuellen BuddyPress Sourcen herunterladen.
In diesen beiden Archiven finden sich alle Komponenten von WordPress, WordPress MU und BuddyPress wieder.

Konfiguration der Sourcen

Die heruntergeladenen Sourcen müssen wir nun auspacken und die Plugins und Themes versorgen.
Wir werden hierfür alle Sourcen in einem Verzeichnis wordpress_mu vorbereiten. Von dort aus kannst du die Sourcen später in deinen Webspace Document Root hineinschieben.
Damit wir diesen Vorgang mehrmals durchführen können, habe ich folgende Verzeichnisstruktur angelegt:

Script generateBuddyPress.sh erstellen

Das ist nicht zwingend nötig. Da ich aber sicher stellen wollte, dass ich BuddyPress auf mehreren Servern einsetzen kann, habe ich dieses Script zusammengeschraubt.
Dieses Script nimmt die Sourcen, packt sie aus und schiebt die BuddyPress Dateien an den richtigen Ort.
So sieht es aus:

Was macht das Script genau?

Zuerst räumt es eventuell vorhandene Verzeichnisse und Dateien auf. Das mach ich, damit ich dieses Script mehrmals laufen lassen kann.
Danach hole ich mir aus dem /source Verzeichnis die aktuellen Quelldateien.
Diese packe ich in die Verzeichnisse wordpress_mu und buddypress aus.
Zum Abschluss schiebe ich die BuddyPress Dateien noch an den richtigen Ort innerhalb der WordPress MU Installation.
Du solltest dir das Readme.txt im buddypress Ordner mal anschauen. Es erklärt genau was ich da gemacht habe.

Installation der Sourcen

Die nun vorliegenden Sourcen installierst du im Document Root deines Webauftritts.
Damit du die Konfiguration abschliessen kannst, musst du noch wie unter Rechte für die Installation vergeben die Rechte korrekt vergeben.
Dann kannst du deine Konfiguration mit der Weboberfläche durchführen.
Nehme dazu einen Webbrowser, gib die Basisadresse deines Blogsystems an und fülle Datenbankverbindung, E-Mail usw. aus.
Ich habs schon ziemlich oft erwähnt: Nimm bitte nur vollqualifizierte Namen, da du ansonsten dich nicht mit dem IE oder dem Firefox einloggen kannst.
Schau dir dazu den Artikel WordPress MU Firefox oder IE klappt nicht
Wenn alles geklappt hat, wird dir das Passwort bekannt gegeben, mit dem du dich das erste Mal einloggen kannst. Speichere es irgendwo und nehme deine Zugriffsrechte wieder weg, damit kein böser Wicht dir deine Konfiguration verhauen kann.
Wenn du dich das erste Mal einloggst, gehe bitte gleich zu Users->Edit User und gebe deinem Administrator ein passendes Passwort.

Konfigurieren der Theme und der Plugins

Zuerst werden unsere Plugins aktiviert. Das machst du im Menüpunkt Site Admin->Options. Dort findest du ganz unten eine Checkbox die auf den Namen Plugin hört. Diese bitte auswählen.

Plugins aktivieren

Gehe zu Plugins und aktiviere BuddyPress Plugins.

Theme aktivieren

Die Standard-BuddyPress Theme kannst du unter Site Admin->Themes auswählen und aktivieren.
Danach kannst du dem jeweiligen Blog mit Appearance->Themes das BuddyPress Theme zuteilen.
Und schwubs! Du hast einen BuddyPress WordPress MU Blog mit Social Network Funktionalität.
Viel Spaß damit!

Ähnliche Beiträge

Die Installation und Konfiguration hat soweit prima funktioniert. Doch dann kam das böse Erwachen.

Ich wollte mich mit dem Firefox als admin anmelden und habe auch dass generierte Passwort richtig eingegeben. Doch danach wurde ich nicht zum Dashbord, sondern zur Loginmaske zurückgeführt. Ich konnte mich nur mit einem Konqueror oder Opera einloggen.

Woher kommt das Problem?

WordPress MU kann nur mit vollqualifizierten Domänennamen zurechtkommen. Also nicht http://example sondern mit http://example.de
Beim lokalen Rechner verwende ich normalerweise keine vollqualifizierten Adressen.

Lösung

Verwende den vollen Domänennamen. Ich habe zum Beispiel bei meinem lokalen Rechner, der auf den Namen karle hört, den Domänennamen karle.wollmatinger erfunden.
(wollmatinger ist einfach die Straße in der ich wohne…)

Jetzt kriegt WordPress MU einen vollqualifizierten Namen und routet richtig weiter.

Dann klappts auch mit dem Firefox und IE .

Ähnliche Beiträge