(A Waste of) Words

  • WordPress-Entwicklerteam: “Wir kriegen Desktop-Blogging nicht sicher hin!”

    WordPress 2.6 erhält nicht nur zusätzliche Features. Nein, es werden auch Features wieder abgebaut, die bisher enthalten waren.

    Eines davon ist der XML-RPC-Server, der für den Anschluss eines WordPress-Blogs an Desktop-Clients wie ecto, Blog Desk, Zoundry Raven, MarsEdit oder Windows Live Writer und das Posting von del.icio.us-Links oder Flickr-Fotos zuständig war.

    Über diesen Zugangspunkt kann der Inhalt eines Blogs sehr weitreichend verändert werden, und das auch noch auf eine gut automatisierbare Weise.

    script kiddies hatten in der Vergangenheit viel Spaß damit: Sobald wieder eine Sicherheitslücke im XML-RPC-Server aufgetaucht war, bombardierten die pöhsen Cracker jede nur ansatzweise nach WordPress riechende Website und versuchten, den Administrator-Account zu knacken oder Links in den Footer des Themes einzuschmuggeln.

    In WordPress 2.6 gibt’s das nicht mehr – aber nicht, weil Automattic den XML-RPC-Server endlich wasserdicht programmiert hat. Naiver Ansatz…

    Nein, Automattic legt die Verantwortung für die Sicherheit dieser Administrationsschnittstelle in die Hände jedes einzelnen Blogbetreibers. Und das geht so:

    Ab WP 2.6 wird die Funktion zwar noch mitgeliefert, aber nur optional auf ausdrücklichen Wunsch des Administrators auch aktiviert.

    Das lässt nur eine Interpretation zu:

    • Du als Blogadministrator erhältst eine Funktion, die als sich in der Vergangenheit mehrfach als Sicherheitsrisiko erwiesen hat.
    • Diese Funktion ist auch in WordPress 2.6 nicht wasserdicht, deswegen wird sie in inaktivem Zustand ausgeliefert.
    • Wenn du diese Funktion brauchst, aktiviere sie bitte ganz auf eigenes Risiko.
    • Ob du dieses Risiko auch beurteilen kannst, steht in den Sternen.
    • Jedweder Exploit dieser Funktion wird jedenfalls wesentlich weniger Blogs betreffen als in den Vorversionen. Automattic steht daher unter geringerem öffentlichen Druck und der Drang zu Fehlerkorrekturen wird damit wesentlich sinken.

    Daniel Jalkut, Entwickler des bei Mac-Jüngern beliebten Desktop-Blogclients MarsEdit, meint in den Kommentaren zum Ticket:

    What a bummer. Terrible news for desktop clients. I hope the security enhancing tradeoff is very high because this will be a support burden on developers who are supporting users of desktop clients.

    It’s also worth noting that this will add friction to the process of using a remote client with WordPress, and therefore make other systems such as Blogger potentially more attractive to such users.

    Ich denke noch über andere Erklärungsversuche für diesen Schritt nach, aber mir fehlt entweder die Fantasie oder das technische Verständnis:

    • Die Deaktivierung des XML-RPC-Servers bringt keine Performancevorteile.
    • Desktop-Blogger sind keine Nischengruppe.
    • Daily Links aus del.icio.us und Posts aus flickr sind auch in Zeiten von Sidebar-Widgets durchaus verbreitet.

    Ich halte daher den Schluss für zulässig, dass Automattic vor der Herausforderung, den XML-RPC-Server gegen bösartige Angriffe abzudichten, kapituliert hat.

    #

  • WordPress “CrazyHorse”: Automattic experimentiert am User Interface

    Ella, Getz, Dexter, Strayhorn, Brecker: Alle bisherigen Versionen von WordPress hatten Jazz-Größen als Paten.

    Ein wenig aus der Reihe tanzt da der Spitzname eines experimentellen WordPress-Entwicklungszweigs, in dem Automattic ein alternatives Theme für das Backend entwickelt: „Crazy Horse“.

    Einige Screenshots vom aktuellen Stand aus dem Subversion-Repository zeigen, wohin die Reise geht: Die Menüs wandern nach links, ein „New Post“-Link ist in der Kopfzeile permanent sichtbar.

    Kommt dir das bekannt vor? Kein Wunder – einige Anleihen aus dem sind unverkennbar.

    Jeffro weiß von Plänen Matt Mullenwegs, eine PDF-Datei mit Wireframes und Analysen in den kommenden paar Wochen in ein lauffähiges Blogsystem umzusetzen.

    Benutzt wird dieses Backend-Theme künftig bei den Usability-Tests, die als Teil der Verbesserungsmaßnahmen am kommerziellen Automattic-Service WordPress.com in einigen US-Städten durchgeführt werden. Abhängig vom Ausgang dieser Tests fließen ausgewählte Veränderungen dann zurück in den Hauptentwicklungszweig und damit in das allgemein nutzbare WordPress, wie es jeder kennt.

    #

  • Neu in WordPress 2.6: Verschlüsselter Zugang zum Adminbereich

    Nach einigen Wochen, während der in der Entwicklung von kein signifikantes neues Feature auszumachen war, enthüllte ein gründlicher Blick auf die letzten change sets im WordPress-Trac nun doch wieder Berichtenswertes:

    Der Administrationsbereich von WordPress 2.6 kann unabhängig vom Zugang zur öffentlichen Seite wahlweise über SSL, also verschlüsselt, erfolgen. Damit erreicht die Übertragung der Zugangsdaten wie Benutzername und Passwort ein Sicherheitsniveau, dass auch den Ansprüchen von kritischen Unternehmensumgebungen genügt. Ein simples Abhören der Logindaten auf dem Weg zwischen Browser und Webserver ist nach heutigem Stand der Technik ausgeschlossen.

    Der Blogadministrator hat die Wahl, den Zugang entweder auf beiden Wegen zu ermöglichen, also sowohl http: als auch https: als Protokoll zu erlauben, oder strikt ausschließlich verschlüsselten Zugriff vorzuschreiben. Eine zusätzliche Zeile in der wp-config.php erzwingt die SSL-Anmeldung:

    define ('FORCE_SSL_LOGIN', true);
    

    Testen konnte ich dieses neue Feature leider noch nicht, denn vorher muss von der WordPress-Entwicklermannschaft noch ein Bug in der Auswertung der vom Server an WordPress übergebenen Parameter behoben werden.

    #

  • Google schwingt die große Keule gegen gehackte Blogs

    Technorati hat damit den Anfang gemacht, und Google zieht jetzt nach: Gehackte Blogs mit unsichtbaren Links auf allerlei geldträchtige Websites werden aus dem Google-Index geputzt.

    Und zwar restlos.

    Ryan Stewart berichtet hier, wie sein PR9-Blog von einem Tag auf den anderen aus den Google-Trefferlisten verschwunden ist.

    Matt Cutts, der Google-Spambuster, erklärt in seiner Reaktion die Gründe dafür:

    I know that it’s disappointing if you don’t show up in Google, but there’s another way to look at it. It looks like your blog was hacked to show “buy pharmacy”-type links, but what if the hackers had hosted malware on your site? Then every user to your site might have gotten infected just by visiting your site. That danger to Google users is one of the reasons that we temporarily remove hacked sites from Google.

    Für mich ist das eine interessante Haltung: Google unterscheidet nicht zwischen Websites, die wirklich Schadsoftware verbreiten, und solchen, die nur ein paar spammige Links auf Love Candies enthalten, aber dem Besucher wahrscheinlich keinerlei Schaden zufügen.

    In einer idealen Welt, in der sich jeder Blogadministrator um die Sicherheit seines Blogs kümmern wollte und auch technisch dazu in der Lage wäre, ist das auf jeden Fall eine Überreaktion.

    Die ist allerdings der wirklichen Welt angepasst: Die meisten Blogs werden nicht aktualisiert, wenn ein Sicherheitsleck in WordPress auftaucht. Sei’s aus Nachlässigkeit, einem gar nicht vorhandenen Verantwortlichen bei fremdinstallierten Blogs, wegen mangelnder Information oder Überlastung durch die Update-Häufigkeit…

    Und damit bleibt Google als dem “verantwortungsvollen” Türsteher zum Web eigentlich nur ein Mittel, den Blogbetreiber wach zu rütteln: Die Tilgung aus dem Google-Index.

    Wie man an Ryan Stewart sieht, ist die Haltung erfolgreich. Die kleine Bloggerin ohne direkten Draht zu Matt Cutts, der schwuppdiwupp das “hacked site”-Markerl wieder löscht, muss halt selbst die Augen offen halten.

    Ich wiederhole dazu mal den kleinen : Ein paar Google-Alerts für den eigenen Blog und spammige Begriffe helfen dabei recht ordentlich.

    Außerdem sollte man auf den Kanälen lauschen, auf denen Google sendet: Benachrichtigungen über eine Entfernung aus dem Index sendet Google an die E-Mail-Addressen info, contact, support und webmaster der betroffenen Domain und als Nachricht in der Webmaster-Konsole.

    #

  • WordPress 2.6 wird 661 Prozent besser!

    Ah, welch‘ eine Schlagzeile! Solche Steigerungen kannte man sonst nur noch von den Bilanzzahlen der Banken vor dem heurigen Bankendomino…

    Ich habe eine der jüngeren Entwicklerversionen von WordPress 2.6 (Revision 7938) getestet, und es ist wahr: WordPress 2.6 ist um Längen schneller als WordPress 2.5.

    Allerdings nicht überall: Gemessen habe ich diese Steigerung beim Aufbau der „Artikel schreiben“-Seite. In anderen Bereichen und leider vor allem auch auf der „Vorderseite“ des Blogs ist in Sachen Geschwindigkeit alles beim Alten.

    Google Gears LocalServer für WordPress 2.6

    Woher kommt diese Steigerung? Ist ein Wunder passiert?

    Natürlich nicht: Wie von Matt Mullenweg vor nicht ganz zwei Wochen , setzt WordPress nun tatsächlich Google Gears ein, um häufig gebrauchte Teile des Backends wie Scripts, Grafiken und Stylesheets auf dem PC des Benutzers zu speichern. Damit entfällt ein großer Teil der Kommunikation mit dem Webserver – das schlägt sich der Ladegeschwindigkeit der WP-Administrationsseiten nieder.

    Jeder Benutzer kann unabhängig von allen anderen einstellen, ob Google Gears verwendet wird. In der Entwicklerversion von WordPress 2.6 wird die Bloggerin bei der Anmeldung mit dieser Gewissensfrage konfrontiert:

    Derzeit ist diese einmal getroffene Einstellung noch endgültig1, aber bis zur im August 2008 wird das wohl über ein Hakerl im Benutzerprofil an- und abschaltbar werden.

    Nach einem kurzen Umweg über die Downloadseite für Google Gears und einem Browserneustart geht’s dann so richtig los.

    Der Import von 185 Scripts, Bildern und Stylesheets dauert je nach Webserver-Geschwindigkeit irgendwas zwischen zehn Sekunden und über eine Minute.

    Damit ist der Google Gears LocalServer bereit für die Beschleunigung des Blogs. Der Importvorgang muss für jedes Blog wiederholt werden.

    Wann gibt’s sichtbare Beschleunigungseffekte?

    Es ist jetzt höchste Zeit für ein paar Benchmarks… Ich habe die Ladezeit der „Artikel schreiben“-Seite in zwei WordPress-Installationen mit aktivierten und deaktivierten Google Gears verglichen:

    • Die erste Installation hat ideale Bedingungen: Mein lokales Testsystem hat praktisch keine Netzwerklatenz, die gesamte Ladezeit wird nur von der Ausführung des Programms und Datenbankzugriffen verursacht.
    • Als zweites Testobjekt dient ein WordPress-Blog auf einem Server, der in Los Angeles steht und zusätzlich zu dieser weiten Distanz auch noch ein paar andere Klötze am Bein hat.

    Die Ergebnisse im Detail:

    Server Ladezeit ohne Google Gears Ladezeit mit Google Gears Verbesserung
    Lokal 2,5 s 1,7 s 32 %
    Los Angeles 11,9 s 1,8 s 661 %

    Das entspricht also den Erwartungen: Je schlechter der Webserver erreichbar ist, desto mehr profitiert das WordPress-Backend von den lokalen Kopien. Im günstigsten Fall sind unabhängig vom Serverstandort Ladezeiten im Bereich einer lokal betriebenen Installation erreichbar.

    Im Echtbetrieb sind die Ergebnisse nicht ganz so beeindruckend wie im Benchmark, weil der konventionelle Browsercache vieles ohnehin zwischenpuffert und damit für den LocalServer weniger zu tun übrig bleibt.

    1 Die Nachfrage wird über einen Eintrag in der usermeta-Tabelle mit dem meta_key 'gearsinfobox' gesteuert.

    #

  • WordPress beschleunigt demnächst mit Google Gears

    Matt Mullenweg denkt in seinem Beitrag Infrastructure as Competitive Advantage über den Anteil der Infrastruktur am Erfolg einer Webanwendung nach.

    Anlass ist Googles Eintritt in die „Grid-Computing für die Massen“-Arena mit „Google Apps“, das – bei ähnlicher Zielgruppe – mehr Funktionsumfang als die schon länger bei Amazon mietbaren Web-Infrastrukturen EC2 und S3 bietet.

    Beide zusammen geben ein deutliches Signal, dass die Einstiegshürden für innovative Webanwendungen sinken. Datenbanken, Speicher und Webserver betrachtet man wie die Wasserleitungen und die Espressomaschine im Büro: Selbstverständlich vorhandene (angemietete) technische Komponenten, die man im besten Fall gar nicht beachten muss.

    Matt meint, dass junge Webanwendungen in der Vergangenheit Anwender eher wegen Unattraktivität als wegen zu langsamer Server verloren haben:

    If you solve the what-people-want problem, they’ll use you no matter how bad your interface is, how slow your site is, just give them somewhere worth waiting for.

    Ich bezweifle das ein wenig: YouTube würde ohne flottes Videostreaming vermutlich keine zwei Wochen überlebt haben, und auf WordPress.com wär’s auch noch gähnend leer, wenn der Klick auf „Veröffentlichen“ mit einer minutenlangen Nachdenkpause einherginge.

    Wie auch immer… Mit den Angeboten von Google oder Amazon Web Services beginnt jedenfalls eine Aera, in der Webanwendungen ohne viel Aufwand auf der selben Infrastruktur laufen wie die „Großen“.

    Wenn alles so einfach ist: Warum ist WordPress trotzdem langsam?

    Eine schöne neue Welt – leider ist die Wirklichkeit für WordPress-Anwender noch nicht so weit: WP ist weder in der auf eigenem Webspace laufenden Version noch bei WordPress.com eine wirkliche Rakete.

    Zwischen der Anmeldung bei der Administrationsoberfläche und dem Eintippen des ersten Buchstaben für einen neuen Beitrag vergehen auch schon mal 30 Sekunden.

    Warum?

    Matt ortet den Flaschenhals richtigerweise in der Programmierung. Die Bremse steckt auch laut Experimenten von Yahoo in den HTML-Dateien, den Scripts, bei den Bildern:

    Yahoo has fantastic resources on this.

    Yahoo hat eine ganze Reihe von Empfehlungen veröffentlicht, die im Kern aussagen: Versuche nicht, möglichst viele Anfragen an den Server so schnell wie möglich zu erledigen – reduziere zuerst die Zahl der Anfragen. Also: Packe mehrere Scripts in eine Datei, mehre Icons in ein Bild, mehrere Stylesheets in eine CSS-Datei.

    Wendet WordPress die Yahoo-Empfehlungen an?

    Ich habe mit dem Netzwerkmonitor von Firebug mitgeschnitten, wie sich die „Artikel schreiben“-Seite aufbaut. Welche Dateien gegen Ende das Ladevorgangs von Server geholt werden, sieht man auf diesem Screenshot:

    Eines wird sofort deutlich: Die WordPress-Administrationsoberfläche ist ein Schwergewicht. 300 KB Datentransfer und 49 Einzelanfragen an den Webserver sind nötig, um die Seite aufzubauen.

    Der überwiegende Traffic wird durch viele kleine Anfragen verursacht – im Screenshot habe ich zur Illustration die vier Anfragen hervorgehoben, mit denen die Symbolbilder für die Mediathek-Buttons geladen werden.

    Bereits die Zusammenfassung dieser vier kleinen Bildchen zu einem Sprite würde die Zahl der Requests um rund zehn Prozent senken. Liegt der Webserver etwa in den USA, kostet jeder zusätzliche Request über den Atlantik rund 0,1 bis 0,2 Sekunden.

    Damit wären hier alleine ein halbe Sekunde zu holen – gar nicht so übel für eine Seite, die du vermutlich am häufigsten brauchst, oder? Davon gibt’s noch mehr, wenn man das Netzwerkmonitoring ein wenig genauer analysiert.

    Wann wird WordPress schneller?

    In den Plänen für ist derzeit noch keine Rede davon, ob Optimierungen in diese Richtung kommen werden.

    Viel wahrscheinlicher gehen Matts Gedanken in eine andere Richtung: WordPress soll den Google Gears LocalServer benutzen.

    Google Gears LocalServer ist ein kleiner Webserver, der häufig benötigte Komponenten einer Webanwendung wie eben der WordPress-Administration direkt vom PC des Benutzers an den Browser liefert.

    Als zusätzlicher Bonus wird Offline-Blogging ohne speziellen Desktop-Blogclient möglich: Der LocalServer speichert bearbeitete Posts solange offline, bis wieder Internetverbindung besteht und überträgt sie dann auf den „echten“ Webserver.

    Eins ist sicher: Das eröffnet vollkommen neue Möglichkeiten – auch für eine Reihe neuer Bugs…

    #

  • Shrimps, Widgets und andere Nebensächlichkeiten

    Heute mal was aus der Kategorie “Nutzloses Wissen”: Alex “Tellyworth” Shiels mag keine Shrimps.

    Soll man über solche halbwichtigen Erkenntnisse bloggen?

    Eher nicht – aber so als kleine Randbemerkung in der Sidebar eines Weblogs könnte man ab und zu clevere Gedankensplitter, aufgeschnappte Zitate oder ein halbfertiges Bonmot unterbringen…

    Hier kommt Alex’ neues Widget Asides ins Spiel.

    Asides entfernt entsprechend getaggte Blog-Beiträge aus der normalen Darstellung in der Hauptspalte und zeigt sie in einem an. Bei langen Beiträgen wird eine automattisch gewählte Kurzfassung dargestellt.

    Manche Themes bieten schon eine ähnliche Funktion, aber wenn der Theme-Programmierer dafür keine Vorbereitungen getroffen hat, war bisher wenig zu machen.

    “Asides” ist in jedem widget-fähigen Theme und damit wesentlich universeller einsetzbar – sehr praktisch!

    #

  • Warum WordPress 2.5.1 so eilig veröffentlicht wurde...

    Nicht mal einen Monat nach folgt WP 2.5.1 – das ist selbst für WordPress-Verhältnisse ein atemberaubend schneller Releasezyklus.

    Der Grund für das hastige Update war ein Sicherheitsleck, das Angreifern ein potentielles Einfallstor auf den gesamten Webserver geöffnet hätte. Steven J. Murdochs Advisory in Kurzfassung: Angreifer können über ein wenig Trickserei mit dem Cookie, das WordPress bei der Anmeldung erstellt, den Zugriff als Administrator erreichen.

    Voraussetzung: Die WordPress-Site erlaubt die Registrierung als WordPress-User. Wer also ein unmittelbares Update auf 2.5.1 nicht durchführen kann, sollte zumindest die Einstellung “Jeder kann sich registrieren” in der Zwischenzeit ausschalten:

    Waage

    Der im Advisory beschriebene Angriffsvektor geht davon aus, dass der Administrator des Blogs den Benutzernamen “admin” verwendet.

    Himmel! Wer immer noch einen Benutzer mit dem Namen “admin” in seinem Blog führt, ist eigentlich selber schuld… Viele Exploits laufen ins Leere, wenn unübliche Verhältnisse vorgefunden werden.

    Also: Wenns noch nicht geschehen ist, lege jetzt einen neuen Administrator-User mit einem fantasievollen Namen an, melde dich ab und mit dem neuen Namen wieder an und lösche dann den Benutzer “admin”. Keine Angst, WordPress fragt dich nach dem neuen Eigentümer aller alten Beiträge.

    Und wenn du schon dabei bist, ändere gleich auch noch den Datenbank-Präfix abweichend zum Standardwert wp_. Dafür gibt’s ein Plugin und eine ausführliche Anleitung.

    Ein vorher angefertigtes aktuelles Backup der Datenbank ist nervenschonend.

    Und noch was Wichtiges kam gerade auf dem anderen Kanal: hatte neulich Austern und Cobb Salad.

    #

  • Schnellstart zur Widget-Programmierung für WordPress

    Widgets sind kleine Module, die der Sidebar eines Blogs neue Funktionen beibringen. Schon mit WordPress wird ein Hand voll Widgets mitgeliefert, die man beispielsweise für die Anzeige der jüngsten Kommentare oder die Textsuche im Blog einsetzen kann.

    Daneben gibt’s eine raue Menge von Widgets aus der Werkstatt unabhängiger Programmierer. Diese Widgets sind nachträglich installierbare Plugins, die einigen Vorgaben für die Einbettung in WordPress folgen.

    Ich werde das Vorgehen bei der Widgetprogrammierung an Hand der Entwicklung eines Widgets, das den Body Mass Index errechnen kann, Schritt für Schritt aufdröseln und mit Beispielcode erläutern (Warum gerade was zum BMI? Nun, aus Faulheit – der Codeschnippsel war schon hier im Einsatz und musste nur als Widget verpackt werden).

    So wird das fertige Widget aussehen – versuch’s mal!

    Das Programmiermodell von WordPress-Widgets

    Namensraum

    Widgets teilen den Namensraum für Variable, Optionen, Funktionen, DOM-Elemente und anderes mit dem Rest von WordPress.

    Um Kollisionen mit WordPress oder auch Widgets anderer Autoren zu vermeiden, ist es daher am klügsten, ein neues Widget eindeutig zu benennen und diesen Namen als Präfix für alle globalen Objekte zu verwenden.

    Integration in das Basissystem

    Das Plugin muss zumindest den Code für Darstellung des Widgets im öffentlich sichtbaren Bereich der Website enthalten. Viele Widgets enthalten zusätzlich noch einen Konfigurationsdialog, der im Backend genutzt wird – den so genannten Controller.

    Das Plugin registriert seine eigenen Funktionen für die öffentliche Darstellung und für den Controller beim Laden über die beiden WordPress-Funktionen wp_register_sidebar_widget() und wp_register_widget_control(), und WordPress sorgt anschließend dafür, dass das Widget bei Bedarf die Kontrolle erhält.

    Ein Widget-Rohgerüst

    Das rohe Skelett eines Widgets sieht demnach so aus:

    1. Einleitender Kommentar, den WordPress auf der Plugin-Seite im Backend anzeigt
    2. Initialisierungsfunktion als Eventhandler für den Event widget_init
    3. Funktion für die Verarbeitung der Benutzereingaben und die Ausgabe auf der öffentlichen Seite der Website (view)
    4. Funktion für die Konfiguration des Widgets (controller)
    <?php
    /*
    Plugin Name: Body Mass Index (BMI)
    Plugin URI: http://bikinifigur.at/goodies/wp-bmi-rechner
    Description: Allows the user to calculate the BMI from body weight and height.
    Author: Robert Wetzlmayr
    Version: 1.0
    Author URI: http://wetzlmayr.at/
    License: GPL 2.0, @see http://www.gnu.org/licenses/gpl-2.0.html
    */
    
    function wet_bmicalc_init() {
    
    	// check for the required WP functions, die silently for pre-2.2 WP.
    	if ( !function_exists('wp_register_sidebar_widget') )
    		return;
    
    	// front end view
    	function wet_bmicalc($args) {
    		extract($args);
    		// the widget's form, themeable through $args
    		echo $before_widget . $before_title . $title . $after_title;
    		echo '<div style="margin-top:5px;">';
    		echo '</div>';
    		echo $after_widget;
    	}
    
    	// back end controller
    	function wet_bmicalc_control() {
    	}
    
    	// let WP know of this plugin's widget view entry
    	wp_register_sidebar_widget('wet_bmicalc', 'Body Mass Index', 
            'wet_bmicalc', 
    	     array(
            	'classname' => 'wet_bmicalc', 
            	'description' =>'Allows the user to calculate the Body Mass Index'.
            	        	' (BMI) from body weight and height.'
    	    )
            );
    
    	// let WP know of this widget's controller entry
    	wp_register_widget_control('wet_bmicalc', 'Body Mass Index', 
            'wet_bmicalc_control', 
    	    array(
            	'width' => 300
    	    )
            );
    }
    add_action('widgets_init', 'wet_bmicalc_init');
    ?>
    

    Download

    Das Widget-Gesicht gestalten

    Im nächsten Schritt wird der view für das Frontend mit Leben gefüllt: Zwei Eingabefelder für Körpergröße und Gewicht, ein Ausgabeelement für den daraus errechneten BMI und die eigentliche Rechenfunktion in Form eines Scripts reichen für dieses einfache Widget.

    wet_bmicalc sieht dann so aus:

    <?php
    /* ... */	
    function wet_bmicalc($args) {
    	extract($args);
    	echo <<<JS
    <script type="text/javascript">
    function wet_bmicalc()
    {
    	var theform = document.getElementById('wet_bmicalc_form');
    	var bmi = document.getElementById('wet_bmicalc_bmi');
    	var pane = document.getElementById('wet_bmicalc_pane');
    	var h = theform.wet_bmicalc_height.value;
    	var result_value;
    	// ...calculation of result_value done here...
    	bmi.innerHTML = result_value;
    	pane.style.display = "block";
    }
    </script>
    JS;
    	// the widget's form, themeable through $args
    	echo $before_widget . $before_title . $title . $after_title;
    	echo '<div style="margin-top:5px;">';
            echo '<noscript><p>This Widget requires Javascript</p></noscript>';
    		echo <<<FORM
    <form id='wet_bmicalc_form' method='post'>
    	<label for='wet_bmicalc_height'>Grösse</label><br />
    	<input id='wet_bmicalc_height' type='text' name='wet_bmicalc_height' value='' />
    	<label for='wet_bmicalc_weight'>Gewicht</label><br />
    	<input id='wet_bmicalc_weight' type='text' name='wet_bmicalc_weight' value='' />
    
    	<p id='wet_bmicalc_pane' style='display:none'>
    	BMI: <strong id='wet_bmicalc_bmi'></strong>.
    	</p>
    	<input type='submit' value='Los!' onclick='wet_bmicalc(); return false;' />
    </form>	
    FORM;
    	echo '</div>';
    	echo $after_widget;
    }
    /* ... */
    ?>
    

    Download

    Die richtige Einstellung zu WordPress-Widgets

    Widgets sollen flexibel sein, damit sie möglichst universell eingesetzt werden können. Das BMI-Widget hat zwei triviale Optionen: die Buttonbeschriftung und den Titel.

    Die Einstellung von Optionen für ein Widget passiert im Backend über ein Formular, das WordPress bei der Administration öffnet, und das im Widget-Controller codiert ist.

    // back end options dialogue
    function wet_bmicalc_control() {
        $options = get_option('wet_bmicalc');
    	if ( !is_array($options) )
    		$options = array('title'=>'Body Mass Index', 'buttontext'=>'Calculate');
    	if ( $_POST['wet_bmicalc-submit'] ) {
    		$options['title'] = strip_tags(stripslashes($_POST['wet_bmicalc-title']));
    		$options['buttontext'] = strip_tags(stripslashes($_POST['wet_bmicalc-buttontext']));
    		update_option('wet_bmicalc', $options);
    	}
    	$title = htmlspecialchars($options['title'], ENT_QUOTES);
    	$buttontext = htmlspecialchars($options['buttontext'], ENT_QUOTES);
    
    	echo '<p style="text-align:right;">'.
    	'<label for="wet_bmicalc-title">Title:'.
    	' <input style="width: 200px;" id="wet_bmicalc-title"
    		name="wet_bmicalc-title" type="text" value="'.
    		$title.'" /></label></p>';
    	echo '<p style="text-align:right;">'.
    	'<label for="wet_bmicalc-buttontext">Button Text:'.
    	' <input style="width: 200px;" id="wet_bmicalc-buttontext"
    		name="wet_bmicalc-buttontext" type="text" value="'
    		.$buttontext.'" /></label></p>';
    	echo '<input type="hidden" id="wet_bmicalc-submit"
    		name="wet_bmicalc-submit" value="1" />';
    }
    

    Download

    Diese Optionen werden später in wet_bmicalc() wieder geladen und im Markup verwendet, ich spare mir den entsprechenden Codeausschnitt hier und verweise auf den Download des vollständigen Plugins.

    Widgets mit Fremdsprachenkenntnissen

    Alle Textausgaben sind tief im Code begraben – nicht gerade ideal für ein international einsetzbares Widget. Besser ist, ebenso wie WordPress selbst Sprachdateien zum Widget zu erstellen, in alle Zielsprachen zu übersetzen und die passenden Texte abhängig von der Spracheinstellung des Website zu laden.

    Zur Lokalisierung von WordPress mit poEdit habe ich ja schon ein wenig geschrieben, das auch bei Widgets anwendbar ist. Linuxer haben alle nötigen Werkzeuge an Bord und können sofort loslegen, bei Windows hilft gettext for Win32.

    Einfach zum Mitnehmen

    Das fertige Widget kannst du hier herunterladen.

    #

  • Sicherheitslücke in WordPress 2.5

    Nein, es ist nicht schon wieder 1. April. Dieses Mal ist es echt: In WordPress 2.5 wurde eine Sicherheitslücke entdeckt. Über diese Sicherheitslücke ist es Angreifern möglich, sich als beliebiger Benutzer an einer WordPress-Site anzumelden.

    Aber: Keine Panik! Damit der Angriff gelingt, müssen einige Umstände zusammenspielen…

    Ist dein Blog angreifbar?

    Erstens: Betroffen sind nur Websites, die mit WordPress 2.5 betrieben werden.

    Zweitens: Trifft einer der nachstehenden Gründe zu, kann die Schwachstelle auftreten:

    1. Die Website ist von einer älteren Version auf 2.5 aktualisiert worden.
    2. Die Website ist mit WordPress 2.5 vollkommen neu eingerichtet und dabei nur über das Browser-Frontend konfiguriert worden. Die Datei wp-config.php wurde nicht über FTP auf den Webspace übertragen.
    3. Ein frisches WordPress 2.5 wurde über einen “One-Click-Installer” des Webhosters eingerichtet.

    In allen diesen Konstellationen besteht die Möglichkeit, dass WordPress einen site-spezifischen Schlüssel nicht einrichtet und damit Sicherheitsmaßnahmen, die eben in WP 2.5 eingeführt wurden, nicht greifen.

    Drittens: Der Angreifer braucht Zugriff auf ein gültiges Login-Cookie. Ein gültiges Cookie erhält man zu Beispiel durch die Anmeldung auf der Website als Abonnent.

    Vorsichtsmaßnahmen sind einfach

    In die Datei wp-config.php findest du eine solche Zeile:

    define('SECRET_KEY', 'put your unique phrase here');
      // Trage hier einen eindeutigen Ausdruck ein.
    

    Fehlt diese Zeile, oder wurde der vorgegebene Satz 'put your unique phrase here' nicht ersetzt, besteht das Sicherheitsrisiko.

    Abhilfe ist einfach: Ersetze oder ergänze diese Konfigurationszeile. Kopiere dazu einfach die gesamte nachstehende Zeile und füge sie in wp-config.php ein:

    Nachtrag: Es geistern diverse Anweisungen herum, die empfehlen, auch in der Datei wp-settings.php Veränderungen vorzunehmen, weil dort ebenfalls der Satz 'put your unique phrase here' auftaucht.

    Das ist kontraproduktiv und nicht richtig. Lasse wp-settings.php unverändert.

    WordPress erkennt an der Übereinstimmung zwischen dem Key in wp-config.php und jenem in wp-settings.php, dass die zusätzlichen Sicherheitsfunktionen nicht verwendet werden sollen, weil offensichtlich kein selbstdefinierter Key in wp-config.php eingetragen wurde.

    #