Auf Wunsch und zur Frustbewältigung eines einzelnen hier nicht genannten Freunds der Familie und glühenden St. Pauli Verehrers: http://www.schubert-raus.de

Für mich mit dem angenehmen Seiteneffekt, mal Bootstrap und Silex einem Praxistest zu unterziehen und auf ihre RAD Fähigkeiten hin zu überprüfen. Den Test hat das Gespann auf jeden Fall bestanden, einmal Lübeck – Hamburg und zurück mit der Bahn und fertig.

Und wer weiß, vielleicht baue ich dem Herrn Yildirim, seines Zeichen Trainer beim VfB Lübeck, auch gleich eine Seite, da siehts im Moment auch nicht besser aus :-).

Fussball, die zweitschönste Nebensächlichkeit der Welt.

Auch wenn es gestern Abend in dem Vortrag von Pierre Minnieur bei der Symfony Usergroup Hamburg im wesentlichen um das Thema „Bundles are not Plugins“ ging, hab ich dort für mich einen ganz anderen Aspekt mitgenommen, der meiner Meinung nach häufig von Entwicklern vergessen wird, die sich im wesentlichen in einer Frameworkwelt, sei es Symfony, Zend, Flow3 oder was auch immer, bewegen.

Routiniert packt man seine Funktionen in z.B. Symfony Bundles, nutzt die dort vorgegeben Methoden der Vererbung, Strukturierung, etc. und verwendet bestenfalls diese Bundles sogar in mehr als einem Projekt. Bis hier hin eine schöne Welt! Aber was passiert, wenn ich wesentliche Funktionalitäten aus meinem Bundle nun in einem Zend Projekt verwenden will?

Man merkt, eigentlich haben wesentliche Codebestandteile aber so gar nichts in einem Bundle zu suchen, sondern sind für eine gute Wiederverwendung viel besser in einer eigenständigen Library aufgehoben. Nun ist lediglich ein schlanker „Wrapper“, im Falle Symfony ein Bundle, nötig, welches die Funktionalität der Library in den Kontext des Frameworks hebt. Der Code, der sich an ein spezielles Framework bindet, ist deutlich reduziert und die Library wird hoffentlich häufiger wiederverwendet, da diese mit geringem Aufwand auch in anderen Frameworks einfach eingebunden werden kann.

Wesentlicher Grund gegen so ein Vorgehen mag in der Vergangenheit das Fehlen, bzw. die fehlende Akzeptanz von Werkzeugen wie Composer gewesen sein. Mit Composer und Packagist scheint sich in der PHP Welt so langsam eine Entsprechung von Maven und Apache Commons durchzusetzen, so dass zu hoffen bleibt, dass wir bald alle einfach und schnell tolle Libraries in unseren Lieblingsframeworks benutzen können.

Da ich im Moment eine Menge mit WordPress mache und ich dort auf ein Problem gestoßen bin, welches ohne Modifikationen des WordPress Core nicht ganz trivial zu lösen ist, habe ich ein kleine WordPress Plugin geschieben welches sie des Problems annimmt.

Und zwar geht es um die 4 kleinen Media Upload Buttons oberhalb des visuellen Post Editor in WordPress. Diese lassen sich zwar kollektiv über unregistrieren der defaultmäßig registrierten media_buttons Action entfernen, aber eben nicht einzeln. Für die einfache, schnelle, aber auch schmutzige Lösung sei auf die entsprechende media_buttons() Funktion in wp-admin/includes/media.php verwiesen, einfach schwups ein, zwei Zeilen Code rausschmeißen.  Aber eigentlich wollen wir ja eben nicht am Core rumdrehen, um uns damit das Leben beim nächsten WordPress-Update so einfach wie möglich zu machen, richtig?

Allen, die sich eine einfache Updatemöglichkeit und  maximale Konfigurierbarkeit erhalten wollen sei mein Plugin Advanced Media Button Remover ans Herz gelegt.

Einziger Wermutstropfen: Das Plugin blendet die Buttons nur aus, die Funktion bleibt erhalten, so das man sich mit der Javascript Console und rudimentären jQuery Kenntnissen die Köpfchen wieder hinzaubern kann.