enge Grenzen für Erweiterungen
Robert beschäftigt sich gerade mit Sicherheit bei Themes und Plugins in Wordpress, ein paar Kommentare hab ich eh schon hinterlassen, aber ich will doch etwas ausführlicher werden.
Themes
Was ist eigentlich die Aufgabe eines Themes? Einfach nur einer Seite einen neuen Anstrich verpassen. Keine neuen Funktionen oder Features, nur die Farbe, Schrift und vielleicht noch ein cooles Badges oben links. Das ist die Minimal-Forderung und meiner Meinung nach auch schon alles was man dem User ermöglichen sollte. Das es möglich ist nur mit einem anderen CSS-File und Bildern eine völlig neu wirkende Seite zu erstellen demonstriert der css Zen Garden sehr eindrucksvoll.
Wordpress erlaubt es solche Themes zu erstellen und zu verwenden, aber es tut nur kaum jemand. Nicht mal meine eigenen Themes die ich letztes Jahr mal erstellt hab waren so gestrickt. Warum? Weil das Standard-Theme von Wordpress mies ist. Persönliche Meinung. Aber: Wer regelmäßig Themes veröffentlicht der sollte sich ruhig das Standard-Theme etwas anpassen und als Basis für alle anderen, eigenen Themes machen. Das hat nebenbei auch den enormen Vorteil dass man php-technisch nur ein einziges Theme zu verwalten halt. Und wer jetzt rufen will “uhh, meine sidebar”, den verweis ich nur auf die widgets.
Plugins
Hier wird’s etwas schwer, denn Plugins erweitern die Funktionalität, sind also Programmcode der auf dem Server ausgeführt wird und nicht im Browser wie das Theme. Programmcode auf dem Server ist immer eine Sache die von Vertrauen abhängt. Ich geb ja mein MacBook auch nur Leuten in die Hand die ich kenne oder von denen ich weiß dass sie wissen was sie tun. Was für den Programmcode also nötig ist wäre beim MacBook die Tasche, dann kommt es zumindest in den meisten Fällen heil an.
Beim Programmcode behilft man sich mit einer Schicht zwischen User (also Plugin) und dem System (hier also Wordpress). Es gibt hier etwas für Themes, zum Beispiel Smarty (welches nur so nebenbei in den frühen Versionen von WordpressMU die Theme-Engine war, erst später konnte man die normalen Themes verwenden), aber wenn es um den Programmcode (und die Interaktion mit Daten) geht dann muss man zu einer sogenannten Domain Specific Language greifen. Man kann eine solche DSL als einen Sandkasten sehen, oder noch besser als eine Fernsteuerung. Ich hab einen Haufen Knöpfe, aber das Gerät an das die Fernbedienung sendet hat die Möglichkeit diese Signale anders zu behandeln als wenn ich vom Sofa aufstehe und die Glotze direkt bediene. Der User hat viele Möglichkeiten aber nicht alle und meistens kann der User auch eine etwas einfachere Sprache verwenden. Beispiel gefällig? Gern.
Nehmen wir mal ein Plugin zur Darstellung ähnlicher Artikel: Es wird der abzuspeichernde Artikel gelesen, seine Inhalte mit anderen Artikeln verglichen und dann diese Relation in der Datenbank gespeichert. In einer DSL hätte ich Lese-Zugriff auf die Artikel und wenn eine Tabelle in der Datenbank nur mir gehört dann darf ich dort reinschreiben ohne das der Mensch am Computer ein OK geben muss. Wenn ich aber in eine fremde Tabelle schreiben will, oder den Artikel ändern will dann kann die DSL dies abfangen und dem Menschen am Computer die Änderungen anzeigen (andernfalls Wordpress Vista Reloaded ;-). Ich hätte in einer DSL gar keinen oder nur eingeschränkten Zugriff auf die ganzen mysql-Funktionen, ich kann den Artikel nur noch über den offiziell genehmigten Weg verändern.
Falls noch jemand Fragen hat, nur her damit.
April 9th, 2008 at 03:15 AM Und wie schreibst du dann die Artikel? Mit insert-Befehlen auf der MySql-Adminoberfläche?
April 9th, 2008 at 08:32 AM Nein, das kann man lassen wie es ist. Die DSL würde nur für die Plugins gelten. Obwohl es sicher reizvoll wäre viele Teile der Wordpress-Admin-Oberfläche über die DSL zu machen, dann würde die DSL auch gleich richtig getestet.
April 12th, 2008 at 01:31 PM html und css waren doch nie Sicherheitslücken, ;) die template tags von den Themes auch nicht, es sind zu 99,9% User, die nichts zahlen wollen, aber ein urgeiles, urindividuelles Design haben wollen, dann zu Themes greifen die verseucht sind - aus lauter Gier ums Geld. mein Mitleid hält sich da in Grenzen ;) Dein Vorschlag ändert nichts daran, außer, dass der Einheitsbrei der Designs zu nehmen wird, hie ein Bildchen austauschen dort auch eines, macht ja noch kein wirkliches Screendesign - Magazin designs zb Fotoblogs etc... die Möglichkeit einzuschränken, wegen einiger weniger, die sich dubiose Designs nahmen, ist Bestrafung der anderen so wie Schäuble....um vor Terroristen zu schützen wird der Bürger zum Terroristen erklärt, das geht nie gut ;)
April 12th, 2008 at 11:14 PM
@Monika: Es ging mir in meinem Artikel auch nicht um gutes/schlechtes Design. Dass man nur mit CSS und anderen Bildern verdammt gute Resulatet erhalten kann zeigt der CSS Zen Garden. Wer dann noch mehr braucht, weil er ein Magazin oder Fotoblog hat, für den soll es auch eine andere Standard-Vorlage geben.