HTML5 Logo

Dass HTML5 ein paar neue input-types definiert, habe ich durch die hcard-input-brainstorming so am Rande auf geschnappt, mir aber nichts weiter dabei gedacht… Durch Zufall bin ich heute aber über folgenden Tweet von Sylvia Egger gestoßen:

Just implemented native #HTML5 form validation on #wp comments form – it' quite simple & should be in #wp default theme

und habe bissle recherchiert… Mit den neuen Input-Types ist es doch tatsächlich möglich Input-Felder über den Browser validieren zu lassen… Ich bin begeistert! 🙂

Trägt man beispielsweise eine Nicht-Email-Adresse in folgendes Feld…

<input type="email" />

bekommt man…

Email Validation im Firefox

Schön wenn man sich noch über solche Kleinigkeiten freuen kann oder 😉

Lange rede kurzer Sinn: Da WordPress alle Formulare an zentraler Stelle definiert, ist es ziemlich einfach sie mit ein paar neuen Input-Types zu versehen. Mit dem folgenden Code wird das Kommentar-Formular mit den Typen "email" und "url" und das Suchformular mit dem Typ "search" (funktioniert nur in den WebKit-Browsern) erweitert:

Code-Update: Eric Eggert hat mich in den Kommentaren darauf hingewiesen, dass man mit <input required /> auch noch die Pflichtfelder validieren kann. Danke!

Code-Update 2: Dank maxe werden jetzt auch die WordPress Settings berücksichtigt (Comment author must fill out name and e-mail) und das "Comment"-Feld ist natürlich auch required

<?php
/*
Plugin Name: html5 input-types
Plugin URI: https://notiz.blog/
Description: Adds the new HTML5 input-types to WordPress' default forms
Version: 0.1
Author: pfefferle
Author URI: https://notiz.blog/
*/

add_filter("comment_form_default_fields", "change_comment_input_types");

function change_comment_input_types($fields) {
  if (get_option("require_name_email", false)) {
    $fields['author'] = preg_replace('/<input/', '<input required', $fields['author']);
    $fields['email'] = preg_replace('/"text"/', '"email" required', $fields['email']);
  } else {
    $fields['email'] = preg_replace('/"text"/', '"email"', $fields['email']);
  }

  $fields['url'] = preg_replace('/"text"/', '"url"', $fields['url']);

  return $fields;
}

add_filter("get_search_form", "change_search_form_input_types");

function change_search_form_input_types($form) {
  return preg_replace('/"text"/', '"search"', $form);
}

add_filter("comment_form_field_comment", "change_comment_field_input_types");

function change_comment_field_input_types($field) {
  return preg_replace('/<textarea/', '<textarea required', $field);
}
?>

Funktioniert als Plugin und in Child-Themes (einfach in die functions.php kopieren).

Danke auch an Marc Görtz der mich über Twitter reichlich mit Links zu dem Thema versorgt hat:

Testen könnt ihr das übrigens hier auf notiz.blog.

OpenWeb-Kolumne (wsm)

Damit das ganze Zeug über das ich so einmal im Quartal im Webstandards-Magazin schreibe nicht pure Science Fiction bleibt, hab ich mich die letzten Wochen mal daran gemacht, ein bisschen Federated Social Web für WordPress zu basteln!

Vor einigen Monaten kam Pepijn de Vos auf mich zu, ob ich ihm nicht bei einem „OStatus for WordPress“ (noch nicht runterladen! funktioniert noch nicht!) helfen wolle. Das damals größte Problem: Wie können wir so viele besehenden Plugins (pubsubhubbub, webfinger, …) wiederverwenden, ohne die Installation zu kompliziert zu gestalten. Da dieses Problem mittlerweile behoben ist und auch das Salmon-Plugin einigermaßen funktioniert, ist es Zeit für einen Test!

Ich würde mich freuen, wenn ihr zwei, drei oder vier Leser da draußen mal diesen Blog bei Status.net oder Identi.ca (oder bei jedem anderen StatusNet-Klon) abonnieren und wie wild auf diesen Artikel antworten könntet. Dazu müsst ihr einfach pfefferle at notizblog dot org folgen:

…und auf diesen Post antworten:

Was bisher funktioniert:

  • Artikel landen in Echtzeit bei StatusNet/Identi.ca (pubsubhubbub)
  • Antworten auf diese Artikel landen als Kommentare bei WordPress (salmon)

Zukünftige Features:

  • Kommentare auf WordPress-Seite sollen auch nach StatusNet/Identi.ca geschrieben werden
  • Bessere Integration in BuddyPress
  • …alles was euch noch so einfällt!?!

Ich würde mich sehr über Feedback, Fragen, Anregungen, Kritik, … freuen. Viel Spaß beim testen!

…sollte alles gut funktionieren, werde ich die Plugins dann nächste Woche veröffentlichen, also TESTEN!

Erst filtern, dann abonnieren!Die Informationsflut im Internet nimmt immer mehr zu und FeedReader bieten bisher keine wirkliche Möglichkeit diese Informationen sinnvoll zu filtern und da man nicht wirklich (zeitnah) Einfluss auf die Weiterentwicklung von NetNewsWire, Google Reader & Co. hat, bleibt nur noch eins: Erst filtern, dann abonnieren!

NoisePress erlaubt Seitenbesucher, einen RSS/ATOM-Feed mit Hilfe von APML vorzufiltern.

(Zum ausprobieren braucht man ein APML-Profil. Wer keines hat, sollte sich entweder das WordPress Plugin installieren oder heimlich Carstens Profil benutzen 😉 )

Warum mit APML filtern?

Man könnte natürlich auch mit WordPress-Bordmitteln eine Menge Rauschen ausfiltern, und wirklich nur das abonnieren was gerade wichtig ist:

Das Problem: Ändert sich dieses Interesse, müssen alle Feeds mühsam aussortiert (und neue gesammelt) werden. Außerdem besteht die Gefahr, dass einige spannende Themen, die nicht genau die abonnierte Kategorie/den abonnierten Tag besitzen, durch das Raster fallen können.

Das Prinzip von NoisePress: APML ist eine Art semantische Tag-Clound die das Interesse einer Person widerspiegelt. Das Interessens-Profil wird in der Regel automatisch generiert und sollte sich somit auch den diversen Interessensveränderungen anpassen.

Am Beispiel WordPress Plugin: Das Plugin erstellt ein APML-File anhand der Häufigkeit der verwendeten Tags und Kategorien. Schreibt jemand viel über OpenID, kann man davon ausgehen, dass er das Thema für wichtig hält. Ändert sich der Fokus des Blogs, wird OpenID auch im APML-Feed immer irrelevanter.

Hört sich nach Geek-Zeugs an?

Richtig! 🙂 …aber NoisePress ist auch erst einmal nur ein Test ob meine Idee überhaupt funktioniert! Im besten Fall soll der User von all der Technik gar nichts mitbekommen. Ich hoffe dass sich Firefox‘ Account Manager oder XAuth schnell weiter entwickeln und ich eine dieser Techniken für NoisePress missbrauchen könnte.

Ich würde mich übrigens sehr über ein bisschen Feedback freuen!

Ich habe mal ein kleines Plugin geschrieben welches den WordPress-Atom-Feed mit der ActivityStream-Syntax erweitert.

 <entry>
  <id>https://notiz.blog/?p=1775</id>
  <author>
    <name>Matthias Pfefferle</name>
    <uri>https://notiz.blog</uri>
  </author>
  <...>
  <activity:verb>http://activitystrea.ms/schema/1.0/post</activity:verb>
  <activity:object>
    <activity:object-type>http://activitystrea.ms/schema/1.0/blog-entry</activity:object-type>
    <activity:object-type>http://activitystrea.ms/schema/1.0/article</activity:object-type>
    <id>tag:notiz.blog,2009-07-13:/post/1775</id>
    <title type="html"><![CDATA[Matthias Pfefferle posted a new blog-entry]]></title>
    <link rel="alternate" type="text/html" href="https://notiz.blog/2009/07/14/webstandards-kolumne/" />
  </activity:object>
</entry>

Die Syntax ist dazu gedacht, dem Feed-Parser/Feed-Reader zu erklären um was für einen Eintrag es sich handelt. Bei WordPress sind die <entry />s ausschließlich Blogposts/Artikel…

<activity:object-type>http://activitystrea.ms/schema/1.0/blog-entry</activity:object-type>
<activity:object-type>http://activitystrea.ms/schema/1.0/article</activity:object-type>

…die gepostet wurden.

<activity:verb>http://activitystrea.ms/schema/1.0/post</activity:verb>

Und für die Dienste wie NoseRub, die die Aktivität gerne in einen Satz packen, gibt’s das ganze auch noch in Prosa.

<title type="html"><![CDATA[Matthias Pfefferle posted a new blog-entry]]></title>

Das ActivityStream Schema definiert übrigens noch ’ne ganze Reihe an weiteren Objekten und Verben, die auf alle möglichen Aktionen im Netz passen. Falls ihr also noch welche findet, die zu WordPress passen könnten… lasst es mich wissen 😉

Es gibt leider aber auch ein paar Probleme mit der Syntax und diversen Feed-Readern, die das zweite <title /> im <activity-object /> mit interpretieren und dann beide Titel ausgeben… aber da ja auch MySpace und Facebook die ActivityStream-Syntax einsetzen ist dieser Fehler sicherlich bald bei jedem Feed-Reader behoben 😉

Viel Spaß beim ausprobieren!

Joss Winn hatte schon im Mai darüber berichtet, dass WordPress.com jetzt auch XMPP unterstützt:

Just some notes on how to get XMPP notifications from any wordpress.com blog. It’s an experimental service so might not work tomorrow 😉

…und es hat in der Tat am nächsten Tag nicht mehr funktioniert. Durch den ganzen Trubel um WordPress, RSS cloud und dem Echtzeitweb in den letzten Tagen, bin ich auch wieder auf den WordPress XMPP-Service aufmerksam geworden und er scheint mittlerweile relativ stabil zu laufen.

Es sollte eigentlich mit jedem Jabber-Client funktionieren der PubSub (XEP-0060) unterstützt:

  1. Zuerst einen neuen Jabber/XMPP-Account hinzufügen:
    • Jabber ID
      name@im.wordpress.com
      Der name ist der WordPress.com Benutzer-Name gefolgt von “@im.wordpress.com”.
    • Password
      Das WordPress.com Passwort.
    • Jabber Server/Host
      im.wordpress.com
    • Port
      5222 (Standard-Port)
  2. Dann den WordPress-Bot als Kontakt hinzufügen: „bot@im.wordpress.com
  3. Für alle weiteren Anweisungen einfach dem WordPress-Bot eine Nachricht mit „help“ schicken.
  4. Fertsch 🙂

XMPP on WordPress.com

Nachdem man mit dem Befehl „sub <wordpress-url>“ einen Blog abonniert hat bekommt man alle neuen Posts auf den Jabber-Client und wenn es der eigene Blog ist, kann man sogar über z.B. Adium neue Blog-Posts verfassen.

Großartig!

…wer braucht da noch PubSubHubBub und RSS cloud 🙂

Weiterführende Links:

Will Norris hat vorgestern ausführlich über die neuen Features seines WordPress-Plugins berichtet. Das wohl interessanteste Feature von wp-openid 3.0 ist der neue OpenID-Provider:

The next major release of wp-openid includes a built-in OpenID provider and delegation engine. This will certainly be the most exciting feature of this release for most people, so let me explain a bit how it works. Each authorized user on the WordPress blog will have an OpenID at the author posts URL (ie. http://example.com/author/admin). Authorization to use the OpenID provider is controlled based on user roles and is managed in the main OpenID settings page.

Das Plugin kann in zwei verschiedenen Modi betrieben werden. Multi-user erstellt aus jeder Autor-URL (z.B. http://example.com/author/admin/) eine OpenID während blog-owner für Private-Blogs mit nur einem Autor gedacht ist und die Home-URL zur OpenID (z.B. http://example.com) macht:

In multi-user, the default configuration, the server supports a feature in OpenID 2.0 called OpenID Provider driven identifier selection. What this means is that ANY user on that blog can enter the home URL as their OpenID, and the OpenID provider itself will make sure that the correct identifier is returned to the relying party. The final identifier will still be something like http://example.com/author/admin/, but the user only needs to enter example.com at a relying party. If you’ve used ever used Yahoo’s OpenID provider, then you’ve probably seen how this works.

Zwei weitere spannende Features sind die Hooks, als Schnittstelle für z.B. andere Plugins…

I haven’t sat down to document them all yet, but I’m adding in more hooks for other plugins to add functionality. Want to pull profile data from FOAF instead of sreg? No problem, now you have a hook you can implement. This makes everything in the plugin much more lightweight and “loosely joined” which is always good. All of the existing non-core OpenID functionality (like SREG) is currently using these hooks.

…und die Unterstützung des OpenID-Firefox-Plugins (welches übrigens auch mit der Version 2.x funktioniert) über das DiSo XRDS-Simple Plugin.

Ich habe das Plugin bisher nur einmal ausprobiert, da es noch einige kleine Fehler hat und die Admin-Oberfläche des OpenID-Providers noch gänzlich fehlt. Trotz dieser kleinen Fehler merkt man, dass sich Will Norris für diese Version sehr viel Zeit (die er sicherlich auch hatte) genommen hat und ich bin sehr gespannt auf die fertige Version.

Wer sich nochmal ausführlich mit den Features beschäftigen will, sollte unbedingt Will Norris‘ Artikel darüber lesen:

NoseRub hat ein WordPress-Plugin:

If you have an account on a social network site powered by NoseRub, i.e. identoo.com
this plugin provides a couple of widgets to show your lifestream your hCard, your contacts
and, on newer installations of NoseRub, your services.

You can also choose to use your weblog as an OpenID-URL, powered by your NoseRub account.

…außerdem wurde noch ne ganze Menge XFN verwendet 🙂

Mal schau’n was Dominik Schwind auf dem nächsten NoseRub-DevCamp so zaubert.

Die beste Methode sich mit einer Sache zu beschäftigen ist, einen sinnvollen Anwendungsfall zu schaffen… Bei dem „näher beschäftigen“ mit Ubiquity ist ein WordPress-Plugin rausgekommen 🙂

Das WordPress-Plugin erstellt eine Ubiquity-Suche für das eigene Weblog (Quellcode) mit dem Command „search-<Blog-Titel>“

ubiquity-wordpress-command.jpg

Das kann teilweise (wie im Falle meines Blogs: search-notizblog-a-private-weblog-written-by-matthias-pfefferle) ziemlich lang werden, was aber nicht weiter schlimm ist da auch schon der Anfang des Commands (z.B. search-notizblog) reicht…

Viel Spaß beim ausprobieren 🙂