ananasblau.com

It’s a common thing that you have a nice javascript-driven link in your rails app to delete an object. Of course you could use a proper button_to but for some reason the boss wants a link. But the usual problem is that with a link_to as rails does it, you will rely completely on Javascript, not nice for old or crappy mobile browsers. The only problem that rails gives you is a missing routes for accessing the destroy action of a controller with a GET request. But, viola, here’s the plugin to solve this: route of destruction. For more see the README.

Oh, and don’t use the plugin.

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.