Aktuelle Artikel auf dNaber.de » Webdesign

Wo $wp_scripts drauf steht, ist WP_Scripts drin

David — Wed, 16 May 2012 16:42:35 +0000

Denkste. Hier hat sich für ein paar Tage der Fehlerteufel eingeschlichen. Und er wäre noch immer drin, hätte mich Toscho nicht darauf aufmerksam gemacht. In einem neuen Plugin, dass ich hier gerade teste, soll möglichst flexibel aber sparsam mit externen Javascripts gearbeitet werden. WordPress handhabt das im Kern mit dem globalen Objekt $wp_scripts. Dessen Eigenschaft queue enthält alle registrierten, noch nicht im Template ausgespuckten Scripte. Ein blindes darauf-zugreifen führt dann zwangsläufig zum Crash, wenn das globale Objekt gar nicht gesetzt ist. Genau das ist – logischer weise – im Feed der Fall. Außer man ist angemeldet, dann schlummert in jener Eigenschaft das Script für die Adminbar. Auch im Feed.

Fazit: man sollte auch den eigenen Feed in irgend einem Reader haben und wenn man sich von den API-Funktionen von WordPress löst, lieber einmal öfter die benutzen Globalen prüfen. Und testen, testen, testen.

WordPress: get_terms(), sortiert nach ‘description’

David — Sun, 13 May 2012 16:21:37 +0000

Die Funktion get_terms() nimmt einiges an Parametern in Form eines Arrays entgegen, so auch einen der bestimmt, nach welchem Attribut sortiert werden soll – leider akzeptiert WP keinen Wert um nach der Beschreibung der Begriffe zu sortieren. Zum Glück wird dieser Teil des SQL-Statements auch durch einen Filter geschickt, dieser heißt get_terms_orderby und den kann man dann nutzen. Die Funktionsparameter werden zu einer Datenbankabfrage über die Tabellen wp_terms und wp_term_taxonomy zusammen gefügt. Dabei wird wp_terms der Alias t und wp_term_taxonomy der Alias tt zugewiesen. Die Beschreibung der Begriffe ist in der Tabelle wp_term_taxonomy gespeichert, die Spalte nach der sortiert werden soll benennt man also mit tt.description und platziert diese über den Filter an Ort und Stelle. Das geht so lange gut, bis sich das SQL-Schema der Funktion get_terms mal ändert, dann hat man im schlimmsten Fall einen SQL-Fehler produziert. Um sicher zu gehen, dass wenigstens der Alias der entsprechenden Tabelle stimmt, kann man die Spalte für die Anzahl der mit diesem Begriff verknüpften Posts, genannt count, heranziehen, der sich die Tabelle mit der description teilt. Die Sortierung nach der Anzahl wird von Hause aus nämlich unterstützt. Also:

/**
 * get SQL-clause to 
 * sort by wp_term_taxonomy.description
 * 
 * @param string $orderby
 * @return string
 */
function order_terms_by_desc( $orderby ) {

	return str_replace( '.count', '.description', $orderby );
}

Um dann im Theme (oder wo man sonst möchte) diverse Begriffe nach der Beschreibung sortiert zu bekommen, setzt man den Filter vor dem Funktionsaufruf (und nimmt ihn anschließend wieder raus!):

add_filter( 'get_terms_orderby', 'order_terms_by_desc' );
$terms = get_terms( 
	'eine-taxonomie',
	array(
		# some parameter
		'orderby' => 'count' # important!
	)
);
remove_filter( 'get_terms_orderby', 'order_terms_by_desc' );

Mit PHP Klassen nach dem nth-child-Prinzip vergeben

David — Mon, 07 May 2012 15:37:44 +0000

Es könnte alles so einfach sein wenn da nicht der IE wäre, der bis einschließlich Version 8 nichts von der CSS Pseudoklasse :nth-child weiß. Ich versuche inzwischen, das weitgehend zu ignorieren solange es sich um Schönheitsfehler handelt und nicht um elementare Gestaltungsprobleme. Für den zweiten Fall habe ich mir eine PHP-Klasse geschrieben, die im Template den HTML-Elementen nach der Nth-Child-Syntyx eine Klasse verpasst um diese Elemente mit dem Klassenselektor anzusprechen. Gibt es bestimmt schon in hundert-facher Ausführung, aber ich hatte gerade mal Lust auf ein klein wenig Mathe.

Das ganze funktioniert dann so:

…

Es lässt sich z.B. auch auf WordPress-Posts anwenden, wenn man die Klasse um zwei Methoden ergänzt:

/**
 * applied to the wp filter 'post_class'
 *
 * @param array $classes
 * @param string $class
 * @param int $post_id
 * @return array
 */
public function wp_get_class( $classes, $class, $post_id ) {

	$nth_class = $this->get_class();
	if ( '' !== $nth_class )
		$classes[] = $nth_class;

	return $classes;
}

/**
 * clean up
 */
public function __destruct() {
	remove_filter( 'post_class', array( $this, 'wp_get_class' ), 10, 3 );
}

und im Constructor den Filter setzt:

add_filter( 'post_class', array( $this, 'wp_get_class' ), 10, 3 );

Im Theme wird die Klasse dann vor dem Loop einmal instanziert. Direkt danach räumt man mit unset() auf die Instanzvariable alles sauber auf.

Erkenntnisse Bloggen 2: Firefox’ magische Paddings auf Listenelementen

David — Mon, 19 Mar 2012 11:50:07 +0000

Firefox hat – wie ich seit heute weiß – die nette Angewohnheit, Listenelementen einen mysteriösen Innenabstand zu verpassen, wenn man list-style-position auf inside setzt. Auch dann, wenn der list-style-type auf none gesetzt ist. Warum das so ist, kann ich nicht genau sagen, Fakt ist, dass alle anderen bekannten Browser die – meiner Meinung nach – korrekte Darstellung zeigen. Folgendes Beispiel reproduziert das Verhalten:


	

	
	Floated list elements
	
	
		List-style-possiton
		
			one
			two
			foo
		
	Lorem Ipsum

Was würde man in etwa erwarten?

Statt dessen erscheint einen Innenabstand, interessanter weise auf der rechten Seite der einzelnen Listenelemente:

Danach sucht man gerne mal auch etwas länger. Das float hat dabei übrigens keinen Einfluss auf den mysteriösen Padding, er lässt sich auch nicht mit expliziten Angaben zum Verschwinden überreden. Was hilft ist entweder explizit den list-style-type auf outside zu setzen oder den Listenelementen als Inline-Block Elemente zu formatieren. Zwar ist outside der Standard, sieht aber im Fließtext hässlich aus und wer verlässt sich schon gern auf Standards?

Erkenntnisse bloggen 1: WordPress Post-GUID sind nicht verlässlich

David — Sun, 12 Feb 2012 18:22:50 +0000

Gerade habe ich mit Toscho in einem kurzen Chat über die GUIDs in WordPress gesprochen und festgestellt, dass diese nicht immer so verlässlich sind, wie ich anfangs dachte. Darauf meinte er, dass solche Ensichten eigentlich gleich gebloggt werden müssen. Recht hat er.

Eine GUID ist eigentlich eine global eindeutige ID. Die WordPress GUID, die in der Posts-Tabelle ein eigenes Feld hat ist in aller Regel der Permalink zum Zeitpunkt an dem das Post angelegt wird und ändert sich nicht – theoretisch. Global bezieht sich hier auf den Blog, bzw. auf das Blognetzwerk einer Multisite-Umgebung. Für meine Zwecke reichte das.

Nun fristet die Post-GUID eher ein Nieschendasein (mir ist sie noch nie begegnet, entdeckt habe ich sie eher zufällig) und, so meint Toscho, wenn sie mal zu einer echten GUID mausert, dann war’s dass mit der Konsistenz der Daten, wenn man auf die GUID als Verknüpfung gesetzt hat. In meinem Fall hat dem entsprechend beim Import niemand an die GUID gedacht. In Zukunft werde ich gleich lieber ein Post-Meta mehr nehmen als an der falschen stelle zu sparen. Sogesehen kann ich froh sein, dass der große Chrash ausgeblieben ist und das Problem noch vor dem Release aufgefallen ist.

WordPress: TinyMCE Plugin mit Dialogbox

David — Tue, 24 Jan 2012 09:51:45 +0000

In diesem Beitrag zeige ich eine Möglichkeit, wie man den WordPress-standardeditor TinyMCE um einen Button erweitert der eine beliebig komplexes Dialogfenster öffnet mit dem man mit den gewohnten APIs auf die WordPressumgebung zugreifen kann. Sämtliche Codebeispiele sind als Gist direkt zu sehen.

Das Tutorial beschreibt ein erdachtes WordPress-Plugin mit folgender Verzeichnisstruktur:

my-plugin/
	i18n/
		mce_locale.php
	js/
		editor_plugin.js
	my_plugin.php

TinyMCE

Ein TinyMCE-Plugin ist wie Folgt aufgebaut:

Sämtliche Plugin-Dateien sind in einem eigenen Verzeichnis zusammengefasst. In der editor_plugin.js wird das Plugin initialisiert:

// js/editor_plugin.js
/**
 * an example tinyMCE Plugin
 */
tinymce.create(
	'tinymce.plugins.myPlugin',
	{
		/**
		 * @param tinymce.Editor editor
		 * @param string url
		 */
		init : function( editor, url ) {
			/**
			 * register a new button
			 */
			editor.addButton(
				'my_plugin_button',
				{
					cmd : 'my_plugin_button_cmd',
					title : editor.getLang( 'myPlugin.buttonTitle', 'My Button' ),
					image : url + '/img/example.gif'
				}
			);
			/**
		 	* and a new command
		 	*/
			editor.addCommand(
				'my_plugin_cmd',
				function() {
					/**
					* @link http://www.tinymce.com/wiki.php/API3:method.tinymce.WindowManager.open
					* @param Object Popup settings
					* @param Object Arguments to pass to the Popup
					*/
					editor.windowManager.open(
						{
							file : url + '/dialog.htm',
							width : 320,
							height : 120,
							inline : 1
						},
						{
							plugin_url : url,
							some_custom_arg : 'custom value'
						}
					);
				}
			);
		}
	}
);
// register plugin
tinymce.PluginManager.add( 'myPlugin', tinymce.plugins.myPlugin );

(Das ist der Standard von TinyMCE, die Datei kann natürlich auch anders heißen). Dafür wird der Methode tinymce.create() neben dem Namen des Plugin-Objekts an zweiter Stelle ein Objekt übergeben, welches u.A. die Methode init definiert. Diese akzeptiert wiederum zwei Parameter: das Objekt des Editorfensters und die URL zum Pluginverzeichnis. Mit dem Editor-Objekt und dessen Methoden kann man sich in die Funktionalität von TinyMCE einklinken und z.B. einen Button registrieren, ein Kommando definieren, dass beim Klick auf den Button zur Ausführung kommt und so fort. Über die Methode editor.getLang() kommt man an die übersetzten Textbausteine heran. Dazu später mehr. Um nun ein Dialog mit mehreren Eingabemöglichkeiten zu öffnen, geht TinyMCE den Weg über eine externe HTML-Datei die es in einem Inline-Frame öffnet. Das ist in sofern von Nachteil, da in diesem Kontext nur schwerlich an die WordPress API heranzukommen ist. Von der umständlichen Handhabung, das Fenster so zu stylen, dass es im WordPress-Look daher kommt mal ganz abgesehen.

WordPress bietet eine andere Option an: Das Markup (in den meisten Fällen ein HTML-Formular) für das Dialogfenster wird einfach über den Hook wp_footer in die Seite eingesetzt und per CSS ausgeblendet.

# somewhere in my_plugin.php
if ( is_admin() ) {
	/**
	 * hook in only, if current user can
	 * see the editor and want to have
	 * a rich text editor
	 */
	if (
	    (    current_user_can( 'edit_posts' )
          || current_user_can( 'edit_pages' ) 
	    )
	    && 'true' == get_user_option( 'rich_editing' )
	) {
		add_action( 'wp_footer', 'my_plugin_dialog' );
	}
}

function my_plugin_dialog() { 
	?>


Die Funktionalität des Popups stellt das WP-Interne TinyMCE-Plugin »WP-Dialog« zur Verfügung. Der Methode editor.windowManager.open wird anstelle eines Pfads zum Popup einfach die ID des Formulars übergeben. Das ganze an ein Befehl gebunden, der wiederum an einen neuen Button gebunden wird, öffnet das Fenster beim Klick auf selbigen.
// js/editor_plugin.js
/**
 * somewhere in the init-method
 * of the parameter object at
 * tinymce.create()...
 *
 * this requires the mce plugin WPDialog
 */
editor.addCommand(
	'my_plugin_button_cmd',
	function() {
		/**
		 * @param Object Popup settings
		 * @param Object Arguments to pass to the Popup
		 */
		editor.windowManager.open(
			{
				 // this is the ID of the popups parent element
				 id : 'my_plugin_dialog',
				 width : 480,
				 title : editor.getLang( 'myPlugin.popupTitle', 'Default Title' )
				 height : 'auto',
				 wpDialog : true,
			},
			{
				plugin_url : url
			}
    	);
	}
);
WordPress
WordPress kümmert sich dankenswerter Weise um die Integration des Plugins in TinyMCE. Dazu sind die Filter mce_external_plugins für das Plugin-Script und mce_buttons für den Button bereit gestellt. Beide Filter werden auf je ein Array angewendet, dass erweitert zurück gegeben wird. Um etwas Abstand zwischen die Buttons zu bekommen, setzt man als ein Array-Element einen senkrechten Stricht '|'.
# somewhere in my_plugin.php
add_filter( 'mce_external_plugins', 'register_my_tinymce_plugin' );
add_filter( 'mce_buttons', 'register_my_tinymce_button' );

/**
 * register_my_tinymce_plugin
 *
 * @param array $mce_plugins
 * @return array $mce_plugins
 */
function register_my_tinymce_plugin( $mce_plugins ) {
	$mce_plugins[ 'myPlugin' ] = plugins_url() . '/my-plugin/js/editor_plugin.js';

	return $mce_plugins;
}

/**
 * register_my_tinymce_button
 *
 * @param array $buttons
 * @return array $buttons
 */
function register_my_tinymce_button( $buttons ) {
	array_push( $buttons, '|', 'my_plugin_button' );

	return $buttons;
}


Dynamik in den Dialog bekommt man wie gewohnt über ein JavaScript, dass mit der Funktion wp_enqueue_script() geladen wird. Innerhalb dieses Scripts kommt man über das globale JavaScript-Objekt tinyMCEPopup an den Editor bzw. mit edCanvas an die Textarea im HTML-Modus heran. Zu beachten ist, dass tinyMCEPopup zum Zeitpunkt des jQuery-eigenen Events ready nocht nicht verfügbar ist.
i18n
Um innerhalb des TinyMCE Plugins lokalisierbare Strings zu nutzen, bedarf es einer weiteren PHP-Datei, die über den Filter mce_external_languages geladen wird. Genauer gesagt loopt WordPress über mehrere solche Dateien und erweitert dabei einen String, der die entsprechenden Textausteine enthält, die in bekannter Weise übersetzt werden können. Der String selbst ist JavaScript-Code, der die Methode tinymce.addI18n() aufruft. Über den hier definierten Namensraum sind die Textbausteine dann verfügbar.

Das Laden übernimmt wieder WordPress:



Und alle so: px oder em – oder rem?
David — Mon, 02 May 2011 16:08:37 +0000
Es vergeht wohl kein Tag, an dem ich nicht einem zerstörten Weblayout begegne oder seufze, weil die Schrift wieder mal viel zu klein ist um sie vernünftig lesen zu können. Eigentlich habe ich mich zu der Problematik schon ausführlich geäußert und in den anderthalb Jahren hat sich die Lage auch nicht groß verändert, wenn, dann eher ins Negative. Da taucht ein Silberstreif am CSS3-Horizont auf, wie ich gerade durch den Artikel „Font sizing with rem“ erfahre.
Jonathan Snook reduziert das Problem der Einheit px, wie häufig in dieser Diskussion, auf den InternetExplorer. An der Einheit em stört ihn die Ungenauigkeit und die Vererbbarkeit. Ersteres ist leider nich einmal das Hauptproblem und Letztere kann man als Probleme sehen.
Absolut jeder Browser, nicht nur der IE, stellt die Schrift in der Größe dar, in der sie in px bemaßt ist. Ebenfalls in jedem Browser ist die Möglichkeit gegeben, eine Schriftgröße einzustellen, die den persönlichen Gegebenheiten Rechnung trägt – das müssen noch nicht mal körperliche Einschränkungen sein, es reicht z.B. ein 15″-Bildschirm mit einer hohen relativen Auflösung zu nutzen. Zugegeben, diese Möglichkeit wird wahrscheinlich eher selten genutz, aber wer nutzt sie denn? Jemand, der sich nicht jedesmal auf’s Neue den Text zurechtzoomen möchte. Muss er aber, wenn die Schriften mal wieder in px bemaßt sind! Einziger Ausweg ist, die Mindestschriftgröße (die in vielen Browsern ab Werk nicht gesetzt – also null – ist) auf einen erträglichen Wert herauf zu setzen. Die (bedauernswert häufige) Folge: zerschossene Layouts oder Text, der im Nirgendwo verschwindet. „Barrierefreies Webdesign? – Noch nie gehört!“
Die bessere Alternative zu px heißt em. Diese bedarf allerdings im Einsatz etwas mehr der Vorüberlegung. Unachtsam auf ein Element wie ul angewendet, führt eine Verschachtelung zu einer Multiplikation der relativen Schriftgrößenwerte. Für eine konsistente Schriftgößengestaltung würde man also darauf verzichten einzelne Textbausteine wie Absätze oder Listen mit Schriftgrößen zu versehen sondern ganze Inhaltsbereiche wie Navi oder die Sidebar. Wem das zu kompliziert ist, der darf auf CSS3 hoffen, dass mit rem eine Einheit einführt, die sich auf das Wurzelelement bezieht und somit das Verschachtelungs-„problem“ umgeht.
Bleibt noch die Ungenauigkeit die em, bzw. auch rem als Nachteil ausgelegt wird. Jonathan fängt an rumzurechnen: auf Basis der Standardschriftgröße (in den meisten Fällen 16) versucht er, das Verhältniss 10:1 für px:em in der Darstellung zu erreichen und kommt auf einen Umrechnungsfaktor von 62,5%. Wem die Zahl bekannt vorkommt: Diese Idee war schon vor über 5 Jahren schlecht und sie ist es noch heute, denn es läuft auf das selbe Problem hinaus: die Ignorierung der Schriftgröße im Browser. Diese um über ein Drittel zu reduzieren nötigt Betroffene einmal mehr zur Mindestschriftgröße zu greifen. Schade eigentlich.



Navigationsmenüs unter WordPress
David — Tue, 16 Nov 2010 15:46:42 +0000
Mit der Version 3 von WordPress kam ein ziemlich cooles Feature hinzu, welches einem gerade auf nicht-nur-Blog-Seiten sehr gelegen kam: die „Nav-Menus“ oder: die Möglichkeit die Navigation aus dem Backend zu steuern. Endlich muss ich nicht mehr in den Templates rumschreiben, wenn ich die Navigation ändern will. Die dazu passende Template-Funktion heißst wp_nav_menus(), wird im Header- oder Sidebar-Template (oder wo man es halt möchte) untergebracht und nimmt wie gewohnt einige Parameter in Form einens Arrays entgegen um z.B. HTML-Attribute wie Titel, ID und Klassen zu vergeben. Das role-Attribut ist leider nicht vorgesehen. Ich wollte schon nach den passenden Filtern suchen, um dieses Attribut mit einfügen zu können, als ich spaßeshalber folgendes probierte:
wp_nav_menu ( 
	array (
		'menu'       =>; 'main_navigation',
		'container'  =>; '',
		# Seit Version 3.1 geht das hier nicht mehr, Nachtrag beachten!
		'menu_id'    =>; 'navigation" role="navigation',
		'menu_class' =>; ''
	)
);
Zu meinem Erstaunen funktioniert das so einwandfrei. Ich kann mir zwar kaum vorstellen, dass das so gewollt ist und dauerhaft funktionieren wird, aber wenn es so einfach ist, braucht es vorerst keinen zusätzlichen Filter. (Zur Erläuterung: die Funktion zeigt das Menü mit dem Namen „main_navigation“ ohne umschließendes Element und ohne eine Klasse an, allerdings mit dem ID-Wert: navigation" role="navigation woraus der Quelltext



&lt/ul>



 resultiert.) Der Wert wird also ungefiltert übernommen, also aufpassen, was man reinschreibt.
Nachtrag:
Achtung! Spätestens seit Version 3.1 funktioniert das nicht mehr (wahr auch zu erwarten). Hier kann man zu folgender kurzer Funktion greifen, die man in den Filter wp_nav_menu einhängt:

/**
 * fügt ein role-Attribut mit dem Wert 'navigation'
 * dem Ersten öffnenden HTML-Tag von $a
 * hinzu
 */
function mytheme_add_nav_role( $a ) {

    $a = preg_replace(
		'#^\s*<([a-z]+)([^>]*)>#i',
		'<${1}${2} role="navigation">',
		$a
	);

    return $a;
}
add_filter( 'wp_nav_menu', 'mytheme_add_nav_role' );

Seitenauswahl einrücken
Jetzt aber ab ins Backend und das Menü anlegen um zu sehen, wie das funktioniert. In den meisten Fällen wird die Navigation sicher die Stuktur der angelegten Seiten abbilden. Warum die Seiten also nicht in ihrer hirarchischen Anordnung sondern in einer einfachen Liste, ihrem Titel nach sortiert, dargestellt werden, ist mir ein Räzel. Spätestens wenn die Seiten nicht mehr allein durch ihren Titel sondern durch die Beziehung zu anderen Seiten identifizierbar sind, steht man vor einem echten Problem.

Dabei ist der Core-Code nur eine Zeile von der Lösung entfernt. Da in diesen untiefen des WordPress-Codes keine Möglichkeit besteht über die Plugin-API einzugreifen, habe ich die entsprechende Funktion und eine Klasse kurzerhand in einem Plugin geklont. Jetzt existiert eine weitere Metabox in der das Chaos weitgehend gebannt ist.

Das Plugin trägt den schönen Namen „nav-menu-page-tree“ und kann hier herunter geladen werden:
nav-menu-page-tree.zip.
Nachtrag

Mit Version 3.2 werden die existierenden Seiten von WordPress selbst auch hirarchisch geordnet dargestellt, womit das Plugin obsolet geworden ist.
Markup aufräumen
Das durch wp_nav_menus() erzeugte Markup der Navigation im Frontend ist gewohnt tadellos, allerdings reichlich überladen. Jedes Listenelement hat eine ID und mehrere Klassen. Darauf kann ich getrost verzichten. Im Falle der ID geht das ganz unkompliziert mit folgendem Filter:
add_filter( 'nav_menu_item_id', create_function( '$a', ' return ""; ') );
Bevor Worpress das ID-Attribut in den Quelltext einfügt, wird geprüft, ob der Wert überhaupt existiert. Wir haben ihn hier gerade gelöscht. Bei den Klassen funktioniert das seltsamer weise nicht. Nachdem ein Filter die Klassen mit einem leeren String überschrieben hat, müssen vor der Ausgabe des Markups die leeren Attribute entfernt werden:
add_filter( 'nav_menu_css_class', create_function( '$a',' return array();' ) );
add_filter( 'wp_nav_menu', create_function( '$a', 'return str_replace( " class=\"\"","", $a );' ) );
Diese zwei Maßnahmen sparen unter Umständen einen ganze Menge Quelltext. Man kann sich jetzt drüber streiten, ob die Einsparung der Datenmenge die längere Scriptlaufzeit aufhebt, aber als Freund sauberen Quellcodes ist mir das allemal lieber.
Die Funktion wp_nav_menus() schicke ich in den Templates überdies noch durch Thomas’ Funktion remove_self_links() um Links zu entfernen die auf die aktuell angezeigte Seite zeigen. Das klappt hoffentlich auch irgendwann mal von Hause aus.



Kampf dem Spam
David — Mon, 19 Apr 2010 14:07:44 +0000
Was unterscheidet eine Maschine vom Menschen? Scheinbar ist die Antwort schnell gefunden: der Eine kann Gefühle empfinden, der Andere nicht, der Andere ist dumm der Eine… lassen wir das. Leider ist diese Frage, gerade wenn es darum geht Besucher einer Website von einem automatisierten Programm – einem Bot – zu unterscheiden, alles andere als leicht zu beantworten. Das wird einem spätestens dann leidlich bewusst, wenn man z.B. ein Kontaktformular oder Blog mit Kommentarfunktion ins Internet stellt. Früher oder später kommen E-Mails bzw. Kommentare herein, die so gar nicht zum Thema passen, wenn sie denn überhaupt sprachliche Inhalte und nicht nur unzählige Links und Kauderwelsch enthalten. Je populärer dabei das eingesetzte System (z.B. WordPress) desto mehr scheint man im Fokus der Spammer zu liegen. Es muss heutzutage Kinderleicht sein, Bots zu programmieren, die auf ihrem Streifzug durch das Netz sämtliche Formulare mit Links zu Glücksspielseiten und Blauen-Pillen-Händlern zupflastern. Es wäre wohl zu viel verlangt, würden diese Programme ihre Intention in die Browserkennung schreiben. Also müssen andere Möglichkeiten gefunden werden, um dem Spam Herr zu werden.
CAPTCHAS
Wer kann's lesen?
Die wohl zuverlässigste Methode um Spam-Bots zu behindern und echte Besucher auf lange Zeit zu vergraulen nennt sich CAPTCHA. Eine in eine Grafik eingebettete Zeichenfolge soll vom Benutzer erkannt und in ein Feld eingegeben werden. Der Vorteil dieser leider sehr verbreiteten Methode besteht lediglich darin, dass der Seitenbetreiber diesen Schutz sehr schnell in seine Seite integrieren kann. Aus der großen Popularität resultiert aber eben auch eine zunehmende Zahl an Programmen, die diese Bilder auf unterschiedlichen Wegen entschlüsseln oder umgehen können. Unnötig zu erwähnen, dass solche Lösungen nicht nur Barrieren aufbauen, sondern auch nerven. Nur wenig besser (aus Sicht der Zugänglichkeit) sind in Klartext formulierte Logikfragen oder Rechenaufgaben, deren Antwort in ein Feld geschrieben wird. (»Warum muss ich hier eingeben, wieviel Beine ein vierbeiniger Tisch hat?«)
Ich halte prinzipiell von Methoden Abstand, in denen sich der Benutzer als Mensch beweisen muss. Die eingangs gestellte Frage sollte man auch so stellen und nicht anders herum!
(Zentrale) schwarze Listen
Ein anderer Ansatz zur automatischen Erkennung von unerwünschtem Spam ist das Anlegen schwarzer Listen um bestimmte Regelmäßigkeiten in Spamkommentaren zu dokumentieren und jeden Kommentar gegen diese Listen abgleichen. Je größer dabei die betrachtete Menge der Kommentare, desto genauer und umfangreicher werden solche Listen. Zentrale Filterangebote wie Akismet werten alle Kommentare der teilnehmenden Websites aus und erstellen so effektive Filter, von denen alle Teilnehmer profitieren. Doch ist mir bei diesem Gedanken etwas unwohl, da die Formulardaten erstmal eine Reise um die halbe Welt antreten um durch die zentralen Server des Unternehmens zu laufen. Dazu kommt, dass nicht behobene falsch-positive Spamerkennungen einen unbedarften Kommentator gleich auf unzähligen anderen Websites ausschließt.
So effektiv und komfortabel Akismet auch sein mag, hier kommt es vorerst nicht zum Einsatz.
Handarbeit
Vorgefertigte Lösungen wie CAPTCHA-Dienste oder Akismet bedienen auch eines: die Bequemlichkeit dauergestresster Webmaster. Allerdings sind beide Lösungen nervig und/oder datenschutzrechtlich zumindest bedenklich. Dennoch habe ich keine Lust täglich zig Spamkommentare zu löschen. Also habe ich mir mit etwas Handarbeit ein eigenes Plugins gezimmert, in dem ich unterschiedliche Methoden zur Erkennung von Bots anwende. Dabei gehe ich von selbst aufgestellten, oder allgemein bekannten Thesen aus um daraus Filtermethoden abzuleiten.


Bots sind dumm
oder zumindest häufig auf populäre Systeme zugeschnitten. Bei komplexeren Formularen mit mehreren obligatorischen Angaben kann eine Kontrolle der einzelnen Angaben auf Korrektheit schon eine menge Unsinn abfangen. Allerdings sollte man die Filter nicht zu streng auslegen. Eine URL muss nicht zwangsläufig mit ›http://‹ beginnen. Ein Name hingegen endet nur äußerst selten auf ›/index.html‹. Fakultative Felder sollten leer bleiben (Spambots können sich oftmals nur schwer bremsen und füllen gerne alles aus), oder eben den Ansprüchen der Logik genügen: Buchstaben z.B. haben in einer Telefonnummer oder Postleitzahl nichts zu suchen. Wem das zu heikel ist, der sucht nach bestimmten Zeichenketten (›http://‹), man kann sich ja mal vertippen.
Auf vielen WordPress-basierten Seiten ist die Angabe eines Namens und der E-Mailadresse gefordert, wenn man einen Kommentar hinterlassen will. Wahrscheinlich können die Spamprogramme deshalb die Namens-Attribute der Input-Felder lesen. Wir machen es ihnen aber auch einfach: geschätzte 99,9% aller WordPress-Installationen verwenden für die Namens-Attribute ›author‹, ›email‹, ›url‹ und ›comment‹. Ich habe nicht schlecht gestaunt, als das Spamaufkommen hier um gut 90% zurückging, nur weil ich diese Attributwerte durch zufällig generierte Zeichenketten wie ›df4928j‹ ersetzt habe. Die Bots hier verstehen offenbar noch keine Labels.

Bots sind schnell
Auf dieser Seite beträgt die Zeitspanne zwischen Aufruf des Artikels und Eintrag des Kommentars bei automatisiertem Spam im Durchschnitt 2,5 Sekunden. Selbst wenn ein Mensch den gesamten Artikel schon kennt, und einen vorbereiteten Kommentar einfach nur einfügt und absendet, dürfte er bedeutend länger brauchen. Momentan habe ich die Grenze bei 6 Sekunden gesetzt.

Bots lesen keine Stylesheets
Diese Theorie kann man sich zu nutze machen um eine Falle zu platzieren. Ein zufällig platziertes weiteres Formularfeld wird per Stylesheet für alle Parteien aus dem Sichtbereich geschoben bzw. gar nicht mehr angezeigt. Ist das Feld dennoch ausgefüllt, war mit sehr hoher Wahrscheinlichkeit ein Bot am Werk. Wer auf Nummer sicher gehen will, kann hier auch eine Logikfrage platzieren, für den seltenen Fall, dass ein Textbrowser verwendet wird, der kein CSS interpretiert.

Die Kombination dieser Methoden klappt momentan so gut, dass ich auf die Angabe von Name und E-Mail inzwischen verzichten kann und Kommentare auch sofort eingetragen werden können, ohne von mir überprüft zu werden. Schlägt einer der Filter an, wird der Kommentar nicht gänzlich gelöscht, sondern nur als Spam markiert. Notfalls hole ich sie von Hand wieder zurück.
Auf statischen Seiten habe ich auf diesem Weg sehr gute Erfahrungen gemacht. Die Umsetzung als WordPress-Plugin ist noch in der Testphase. Wenn irgendwo Probleme beim Kommentieren auftreten, würde ich mich über eine kurze Problembeschreibung per E-Mail sehr freuen.
Mir ist bewusst, dass auf einer vergleichsweise kleinen Seite wie dieser andere Bedingungen herrschen als auf den großen Blogs und dass der Kampf gegen automatisierten Spam wahrscheinlich bis zum jüngsten Tag andauern wird, da sich auch Spambots weiter entwickeln. Solang ich aber mit etwas Handarbeit auf CAPTCHAS und Akismet verzichten kann, werde ich es auch tun.



WordPress: Aufzählung der Kategorien und Tags im Satz
David — Tue, 02 Mar 2010 20:24:54 +0000
Die Template-Tags the_category() und the_tags() geben die Kateorien und Stichworte eines Artikels wahlweise als eine ungeordnete Liste, oder durch einen Seperator getrennt aus. Für eine lose Aufzählung wäre ein naheliegendes Trennzeichen das Komma; der Funktionsaufruf dazu schaut so aus: the_tags(', ').  Das Ergebnis wäre eine Aufzählung aller Stichworte, die durch ein Komma getrennt sind.
Für diesen Beitrag würde das so aussehen: PHP, WordPress. Kurz und knackig, aber ein ordentlicher Satz lässt sich daraus nicht formulieren, dazu fehlt das „und“ zwischen den beiden (letzten) Stichworten.
Um solche Aufzählungen in einen vernünftigen Satz einbinden zu können habe ich mir folgenden Code-Schnipsel in die functions.php des Themes geschrieben:
/**
 *  Ersetzt das letzte Komma durch ein »und« 
 * 
 * @param string $tags
 * @return string
 */
function mytheme_tag_list( $tags ) {

	# wenn mehr als ein link vorhanden ist
	if ( substr_count( $tags, 'PHP und WordPress behandelt.



Kontaktformulare ohne Zeichensalat
David — Wed, 27 Jan 2010 15:55:45 +0000
Sie sind wohl die am häufigsten anzutreffende Art von Formularen im Web. Man muss kein großer Programmierer sein um selbst ein Kontaktformular zu schreiben, oder man bedient sich der vielen fertigen Skripte, die man im Netz findet. Problematisch wird es, wenn in der E-Mail Umlaute und Sonderzeichen zu kryptischen Zeichen oder fetten Fragezeichen verkommen. Dann liegt ein Verständigungsproblem vor, das aber leicht behoben werden kann.
Um in PHP eine E-Mail zu versenden reicht theoretisch folgendes Codebeispiel aus:
mail(
	'mustermann@mail.de',
	'Urlaubsgrüße',
	'Hallo Max, Urlaub an der Ostsee ist toll!'
);
Der Funktion mail() werden drei Parameter übergeben: Empfänger, Betreff und der eigentliche Nachrichtentext. Nun besteht eine E-Mail nicht nur aus diesen drei Informationen. Genauer genommen, setzt sich eine E-Mail, ähnlich wie ein HTML-Dokument aus zwei Teilen zusammen: einem Kopf (Head) und einem Körper (Body). Im Head(er) werden wichtige Informationen über die E-Mail mit gesendet, unter anderem auch die verwendete Zeichenkodierung. Wenn die Zeichenkodierung nicht angegeben wird, muss der Empfänger „raten“, rät er falsch kommt es zur fehlerhaften Darstellung von Umlauten und Sonderzeichen.
Für die Lösung des Problems sind zwei Schritte nötig:

muss dafür gesorgt sein, dass die Daten des Formulars in einem bestimmten Zeichenkodierung zum Server gesendet werden und
muss diese Zeichenkodierung in der E-Mail angegeben werden.

Die Zeichenkodierung des Formulars
Der Inhalt eines HTML-Formulars wird in der Zeichenkodierung gesendet, in der auch das HTML-Dokument an den Browser gesendet wird. Die zuverlässigste Art, den Browser über die Zeichenkodierung zu informieren ist das entsprechende HTTP-Headerfeld „Content-Type“. Auf dem Apache Webserver geht das recht unkompliziert, in dem man im Wurzelverzeichnis seiner Website die .htaccess-Datei um folgende Zeile ergänzt:
AddDefaultCharset UTF-8
Diese Methode setzt voraus, dass auch alle Text-Dokumente (Skripte, Stylesheets) in dieser Zeichenkodierung vorliegen.
Ob die Zeichenkodierung im HTTP-Header einer Seite gesendet wird, kann man online testen, oder z.B. in Firefox mit verschiedenen Plugins.
Darüber hinaus kann es nicht schaden, die Zeichenkodierung zusätzlich als Meta-Element in den Quelltext des HTML-Dokumentes zu übernehmen:

Eine weitere Möglichkeit bestünde darin, das Formular um das Attribut „accept-charset“ zu erweitern.

	

In der Regel reicht es jedoch aus, die Zeichenkodierung im HTTP-Header zu senden.
E-Mails versenden mit Köpfchen
Der E-Mail Header, den die Funktion mail() generiert umfasst nur die nötigsten Informationen und  kann durch einen weiteren Parameter beeinflusst werden. Dabei werden die einzelnen Feld-Wert-Paare durch einen Zeilenumbruch (\r\n) voneinander getrennt. Die Zeichenkodierung wird im Feld „Content-Type“ angegeben. Mit dem „MIME-Version“ Feld wird gesagt, dass die E-Mail MIME formatiert vorliegt.
$email_header  = "MIME-Version: 1.0 \r\n";
$email_header .= "Content-Type: text/plain;charset=UTF-8 \r\n";

Die Variable $email_header wird als vierter Parameter der Funktion mail() übergeben:
# E-Mail senden
mail( 
	$address,
	$subject,
	$content,
	$email_header
);
Damit hat sich der Zeichensalat erledigt. So lange im E-Mailheader keine Sonderzeichen vorkommen, sind Unicodezeichen im Text der E-Mail ab jetzt kein Problem mehr. Wenn aber z.B. der Name und die E-Mailadresse des Absenders in den Header aufgenommen werden, oder der Betreff im Kontaktformular vom Benutzer eingegeben werden kann, dann muss man davon ausgehen, das nicht nur ASCII-Zeichen in den Header gelangen. Aber nur diese sind dort erlaubt.
In dem Fall müssen die Zeichenketten für den Header kodiert werden. Dazu gibt es zwei Möglichkeiten: Base64 und Quoted-printable. Die kodierten Abschnitte werden von der Zeichenfolge =?utf-8?q? eingeleitet und von ?= beendet. Der einleitende Tag gibt die Ursprüngliche Zeichenkodierung (hier UFT-8) und die Kodierungsmethode (q für Quoted-printalbe und b für Base64) an.
Für die Kodierung bedient man sich der PHP-Funktionen base64_encode() für Base64 bzw. imap_8bit() oder quoted_printable_encode() für die Quoted-printable Methode. Allerdings ist die Funktion imap_8bit() an die IMAP-Extention geknüpft und quoted_printable_encode() gibt es erst seit PHP Version 5.3.
Der Betreff der E-Mail würde wie folgt kodiert werden:
# Zeilenumbrüche haben im Header nix verloren
$subject = str_replace(
	array( "\n", "\r" ),
	'',
	$_POST[ 'subject' ]
);

# Quoted-printable
$subject = '=?utf-8?q?' . imab_8bit( $subject ) . '?=';

# alternativ: Base64
$subject = '=?utf-8?b?' . base64_encode( $subject ) . '?=';

# senden
mail( $address, $subject, $content, $email_header );
Theoretisch sind beide Varianten legitim, in der Praxis scheinen einige Freemailanbieter noch Probleme mit UTF-8 in der ein oder anderen Methode zu haben. Die Web.de Webmail-Oberfläche z.B. zeigte die dekodierten Betreffzeilen in der Übersicht an, in der Einzelansicht allerdings nicht. Thunderbird und auch Outlook (mobile Version) haben hingegen keine Probleme mit der Dekodierung.
Spätestens wenn die Komplexität der zu sendenene E-Mails über ein simples Kontaktformular hinaus geht, empfielt es sich, vorgefertigte Klassen wie phpmailer zu verwenden. Notwendige Kodierungen werden damit intern abgehandelt und die E-Mail automatisch zusammengefügt.



Geordneter Umzug (zu WordPress)
David — Mon, 25 Jan 2010 12:30:29 +0000
Ende letzten Jahres habe ich mich dazu entschlossen, die Website meines Volleyballvereins mit einem Redaktionssystem zu betreiben. Im Zuge der Neuerungen musste auch die URL-Struktur geändert werden, was naturgemäß zu dem Problem führt, dass Aufrufe über Lesezeichen, Links und Suchmaschinen unerwartet im „Seite nicht gefunden“-Nirwana landen. Um unseren Besuchern (und unserer guter Position in den Suchmaschinen) das zu ersparen habe ich den Umzug geordnet durchgeführt und alle alten Links übersetzt und leite die Besucher zur gewünschten Seite weiter.


Die richtige Antwort
Wenn man eine URL Aufruft, zu der keine passende Ressource gefunden wird, landet man für gewöhnlich auf einer weißen „404 – not found“ Seite, die vom Server automatisch generiert wird. Mit etwas Glück ist diese Seite aber im Design der Website und bietet mögliche Alternativen zum nicht gefundenen Inhalt. In beiden Fällen antwortete der Webserver auf die Anfrage mit dem Statuscode „404“ der besagt: „Es wurde nichts gefunden“.
Ändern sich bei einem Umzug die URLs der Seiten, so landet jeder Aufruf der alten Links in der Sackgasse obwohl die Seite noch existiert. Folgerichtig wäre die korrekte Antwort vom Server: „der gesuchte Inhalt ist jetzt unter einer neuen URL verfügbar“. Der richtige Statuscode für diesen Fall ist „301 – Moved Permanently“.
Einige Seiten sind auch komplett verschwunden. Zum Teil weil sie in andere eingebunden wurden (Kontakt und Impressum können durchaus auf einer Seite unterkommen), andere waren einfach veraltet. Anfragen auf gelöschte Seiten beantwortet man ordnungsgemäß mit dem Statuscode „410 – gone“, der soviel bedeutet wie „Diese Seite ist von uns gegangen“. Somit ist auch gleich dafür gesorgt, dass Google & co. bescheid wissen und ihre Indizes aktualisieren können.
Die Umzugskisten auspacken
Während andernorts noch diskutiert wird, ob WordPress als CMS taugt, setze ich es ein. Nicht zuletzt weil Anpassungen wie diese kinderleicht zu integrieren sind. Um alte URLs ihren neuen zuzuordnen und gelöschte Seiten zu kennzeichnen, ergänze ich die functions.php des eingesetzten Designs um folgende Funktion:
/** 
* umleiten alter Permalinks auf die neuen
*/
function translate_permalinks() {

	$_301 = array(
		'/startseite.html' => '/'
		'/kontakt.html' => '/kontakt',
		'/mannschaften.html' => '/mannschaften',
		'/news.html' => '/aktuell',
		'/links.html' => '/weblinks',
		'/impressum.html' => '/kontakt#impressum',
	);
	$_410 = array ( 
		'/alt.html',
		'/javascript/altes_script.js',
		'/css/altes_stylesheet.css',
		'/weg.html'
	);
	if ( array_key_exists( $_SERVER['REQUEST_URI'], $_301 ) ) {
		header(
			'Location: '
				. ( $_SERVER['HTTPS'] 
					? 'https'
					: 'http'
				  )
				. '://' . $_SERVER['SERVER_NAME'] 
                  		. $_301[$_SERVER['REQUEST_URI']],
			true,
			301
		);
		exit();
	}

	if ( in_array( $_SERVER[ 'REQUEST_URI' ], $_410 ) ) {
		header(
			  ( $_SERVER[ 'SERVER_PROTOCOL' ] == 'HTTP/1.1' 
				? 'HTTP/1.1'
				:  'HTTP/1.0'
			  )
			. ' 410 Gone'
		);
		header('Content-type: text/html;charset=utf-8');
		echo 
			'410 - Gone
			Dieses Dokument existiert nicht mehr bei uns.
			Besuch bitte unsere neue Website:
			http://domain.tld';
		exit();
	}
}
In dem Array $_301 ordne ich die neuen Links den alten in der Form zu:

/link/zur/alten-datei.html => /neue_datei.

Alle nicht mehr vorhandenen URLs werden in dem Array $_410 lose aufgelistet. Die Elemente beider Arrays werden mit der Request-URI verglichen und im Falle einer Übereinstimmung erfolgt die Weiterleitung bzw. die Antwort mit dem entsprechenden Statuscode.
Der Funktionsaufruf erfolgt am Anfang der functions.php. Je nach Umfang der Website ist das etwas mehr Handarbeit die sich aber lohnt.
Nachtrag:
In den Kommentaren hat mich Thomas darauf hingewiesen, dass es schneller geht, die Umleitungen in die .htaccess-Datei zu schreiben, da so nicht jedesmal das ganze System geladen wird. Wer also auf die Performance achtet, oder ein anderes System als WordPress nimmt, schreibt die Umleitungen und gelöschten Dokumente besser in die .htaccess.
Für diese Zwecke ist die Redirect-Direktive des Moduls „mod_alias“ geeignet. Alle permanenten Umleitungen werden so notiert:
Redirect permanent /alte_seite.html http://domain.tld/neue_seite
Hier muss man darauf achten, dass die URL zur neuen Seite vollständig angegeben werden muss, da Weiterleitungen nicht zwangsläufig auf eine Domain beschränkt sind.
Für gelöschte Dokumente lautet der Eintrag:

	Redirect permanent /startseite.html http://domain.tld/
	Redirect permanent /kontakt.html http://domain.tld/kontakt
	Redirect permanent /mannschaften.html http://domain.tld/mannschaften
	Redirect permanent /news.html http://domain.tld/aktuell
	Redirect permanent /links.html http://domain.tld/weblinks
	Redirect permanent /impressum.html http://domain.tld/kontakt#impressum

	Redirect gone /alt.html
	Redirect gone /javascript
	Redirect gone /css
	Redirect gone /weg.html

Mit der Redirect Direktive kann man nicht nur einzelne Dokumente sondern auch Verzeichnisse handhaben, wie im Fall der Stylesheets und der Skripte zu sehen ist.
Damit Anfragen auf die entfernten Dokumente nicht mit einer lieblosen Standardantwort abgespeist werden, kann man noch ein Error-Dokument in der .htaccess anlegen:
ErrorDocument 410 /entfernt.html



WordPress: Kommentare nummerieren (v.2.7+)
David — Tue, 01 Sep 2009 13:10:39 +0000
Anmerkung: Klaus hat mich darauf hingewiesen, dass dieser Artikel in der ersten Fassung etwas zu kurz und zu abstrakt geraten ist und dadurch zu unverständlich ist. Aus diesem Grund habe ich diesen Artikel noch einmal überarbeitet um die einzelnen Schritte nachvollziehbarer zu machen.
Worum es geht
Dieses kurze Tutorial soll zeigen, wie man in WordPress die Kommentare fortlaufend nummeriert. Der Semantik wäre schon genüge getan, wenn man jeden einzelnen Kommentar als Punkt einer nummerierten Liste (
) auszeichnet. Manchmal will man aber die Nummern Ziffern mit in die Gestaltung einbeziehen und mit CSS aufhübschen. Wie man die Nummer für jeden Kommentar als Zahl in den Quelltext bekommt, soll hier gezeigt werden.
Die Idee
Der HTML-Code für die Kommentare wird erzeugt, in dem die Datensätze in einer Schleife durchlaufen werden und für jeden Durchlauf der entsprechende Kommentar sein HTML-Kleid bekommt. Für unser Vorhaben reicht es also, vor dem Schleifenaufruf eine Zählvariable zu definieren (ich nenne sie hier mal $comment_counter). Innerhalb der Schleife setzen wir einen Befehl, der den Variablenwert um den Wert 1 erhöht.

Vor der Version 2.7 musste man diese Schleife noch von Hand schreiben und die Zählvariable konnte man bequem mit unterbringen. Das Kommentartemplate (comments.php) sah bis 2.7 schematisch etwa so aus:
/**  
* in der comments.php
*/
# Unsere Zählvariable
$comment_counter = 1;

# der Kommentar-Loop
foreach ( $comments as $comment ) : ?>

	
	
		
		–
		 
		um
		
			
		
	
        
        
	

	
	
	
	

Soweit, so gut.
Umsetzung seit Version 2.7
Seit Version 2.7 muss man die Schleife nicht mehr von Hand starten, sondern hat dafür die Funktion wp_list_comments() zur Verfügung. Diese Funktion organisiert den Schleifendurchlauf automatisch und erzeugt gleichzeitig das HTML, auf welches man geringfügig Einfluss nehmen kann, in dem man der Funktion bestimmte Parameter übergibt. Eine Nummerierung der Kommentare ist leider nicht vorgesehen.
Um das erzeugte HTML komplett selbst zu bestimmen (und somit die Kommentarnummer einzufügen), akzeptiert wp_list_comments() eine sogenannte Callback-Funktion, die man selbst schreiben muss und in der man die HTML-Maske für die einzelnen Kommentare bestimmt. Eine solche Funktion, man könnte sie z.B. mytheme_comment() nennen, schreiben wir in die functions.php. Der Name dieser Funktion kann beliebig gewählt werden, allerdings muss sie dem folgendem Schema genügen, um die Funktionalität zu gewährleisten:
/**
 * functions.php
 */
function mytheme_comment( $comment, $args, $depth ) {

	$GLOBALS['comment'] = $comment; 
	# Ab folgt die Gestaltung des einzelnen Kommentars
	?>
	 id="comment-< ?php comment_ID() ?>">
	
		< ?php comment_author_link();?>
	
	
		Geschrieben am
		
		um 
		
	
        comment_approved ) : ?>
		Dein Kommentar muss erst durch den Administrator freigeschaltet werden
		
	< ?php comment_text() ?>
	< ?php
	/**
	 *   Das schließende-Tag für den einzelnen Kommentar
	 *   setzt die Funktion wp_list_comments() von selbst, der
	 *   darf hier nicht gesetzt werden!
	 */ 
}
Um diese Callback-Funktion aufzurufen, übergeben wir deren Name als Parameter in Form eines Strings an die wp_list_comments():
/**
 * der Aufruf in der comments.php
 */
?>

	


Um auch hier die Kommentare mit ihrer Nummer zu versehen, definieren wir die Zählvariable wieder außerhalb der Schleife, also noch von dem Aufruf der Funktion wp_list_comments():
/**
 * comments.php
 */
?>

	

Da diese Zählvariable außerhalb der Funktion mytheme_comment definiert wird, ist sie innerhalb der Funktion auch noch nicht „sichtbar“. Da wir sie nich einfach als Parameter an die Funktion übergeben können, müssen wir sie innerhalb von mytheme_comment als global definieren um darauf zugreifen zu können. Anschließend kann man sie per echo-Befehl an der gewünschten Stelle ausgeben und setzt deren Wert zum Schluss noch um 1 höher:
/**
 * functions.php
 */
function mytheme_comment( $comment, $args, $depth ) {

	# Zugriff auf die Zählvariable ( startet bei 0 )
	global $comment_counter;
	# Zähler heraufsetzen.
	$comment_counter ++;
	
	$GLOBALS['comment'] = $comment;
	# ...

	echo '' . $comment_counter . '';
}
?>
Ab jetzt hat jeder Kommentar seine eigene Nummer, die man per CSS beliebig gestalten kann.



PHP: String auf die ersten Worte kürzen
David — Tue, 01 Sep 2009 07:08:02 +0000
Eine kleine Funktion, von der ich die ersten Worte eines Strings zurück bekomme, um z.B. in einem Vorschaublock den ersten Absatz eines Artikels anzureißen.
Die Idee, ich habe sie mir bei Thomas Funktion end_on_word() abgeschaut, ist so simpel wie effektiv: Der String wird an den Leerzeichen in ein Array aufgespalten und mit diesem kann man dann arbeiten:
/** 
 * reduziert einen String auf die 
 * ersten Worte
 *
 * @param str $str
 * @param int $count (Default 10)
 * @return str
 */
function getFirstWords( $str, $count = 10 ) {
    
 	$str = trim( $str );

 	# Jedes Wort ein Arrayelement
 	$array = explode( ' ', $str );
  
 	# Array in $count große Teile teilen
 	$array = array_chunk( $array, $count );

 	/**
 	 * Falls der String weniger Worte hatte als $count
 	 * geben wir den String unverändert zurück
 	 */
 	if ( empty( $array[ 1 ] ) ) 
 	 	return $str;

 	/**
 	 * andernfalls entfernen wir eventuelle Kommas am ende
 	 * und fügen ein Auslassungszeichen an
 	 */
  	 return rtrim( implode( ' ', $array[ 0 ] ), ',;' ) . '[…]' ;
}

/** 
 * Anwendung
 */
$str = "Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam.";

# Die ersten 5 Wörter bitte:
echo getFirstWords( $str, 5 );

/**
 * Ausgabe: Lorem ipsum dolor sit amet […]
 */



Schriftgröße in px oder em?
David — Tue, 25 Aug 2009 16:16:03 +0000
Ich spreche heut wieder mal ein Thema an, von dem ich dachte, dass es eigentlich schon vor langer Zeit in diverse x-Dinge-die-man-nicht-macht-Listen aufgenommen wurde. Die Rede ist von Schriftgrößen auf Webseiten und ob diese in der Einheit px angegeben werden sollten.
Die BITV fordert ganz allgemein die Verwendung von relativen statt absoluten Einheiten. Ein Blick in die Spezifikation verrät, dass in CSS die Einheit px als relative Einheit zu verstehen ist. Logisch, denn wenn ich auf einen 15″ Flachbildschirm 1024×768 Bildpunkte aber auch 1400×1050 Bildpunkte unterbekomme, dann muss der Platz pro Bildpunkt von Gerät zu Gerät unterschiedlich sein. Soweit die Theorie die sagt, px als Einheit ist okay für die Angabe der Schriftgröße. In der Praxis offenbaren sich dann doch einige Probleme, die ich hier demonstrieren will.
Als Testobjekt dient dieses HTML Dokument, dessen Quelltext im wesentlichen so aussieht:

	Text mit 2em Schriftgröße
	Text mit 32px Schriftgröße
	Text mit 1em Schriftgröße
	Text mit 16px Schriftgröße
	Text mit .8em Schriftgröße
	Text mit 13px Schriftgröße
Anschauen werde ich die Seite unter WinXP, bei einer Bildschirmauflösung von 1400×1050 mit Firefox 2, Opera 9.6, InternetExplorer 6-8 und Safari 3, sowie unter Vista, 1280×800 mit Firefox 3.5 und IE8 jeweils bei einem im Browser eingestellten Schriftgrößengrad von ›16‹ (also die Standardeinstellung der meisten Browser).

Auf Grund der 100%-Schriftgröße für den Body, die sich auf die im Browser eingestellte Schriftgröße bezieht, sind die jeweiligen Wortgruppen annähernd gleich groß (1em entspricht hier 16px). Mit Ausnahme aller Versionen des InternetExplorers werden bei reiner Schriftvergrößerung alle Texte gleichermaßen vergrößert. Der IE8 und Opera, aber auch Firefox ab Version 3 bieten zusätzlich noch eine komplette Zoomfunktion, die die gesamte Seite proportional vergrößert/verkleinert. 
Soweit so gut. Was passiert aber, wenn ich von der Möglichkeit gebrauch mache, mir die Schriftgröße auf ein für mich optimales Maß im Browser voreinzustellen, z.B. auf 20? Hier zeigt sich das Problem der einheit px: der Text ist festzementiert auf die Größe, die im Stylesheet der Seite steh. Der Schriftgrad in der Browsereinstellung wird schlicht ignoriert. Als Besucher muss ich also erstmal am Mausrad drehen, oder auf die Plus-Taste drücken, um die Schrift zu vergrößern.
Jeder bessere Browser bietet außerdem die Möglichkeit an, eine Mindestschriftgröße festzulegen, die dann nicht mehr ignoriert werden kann. Diese stellt, wenn sie denn überhaupt eingestellt ist, meist die unterste Schmerzgrenze dar, unter der absolut nichts mehr geht, und die für Fließtext eigentlich schon zu klein ist. Spätestens da ist dann Schluss mit den Pixelschriftgrößen. Im schlimmsten Fall verspielt man so die Möglichkeit mit Schriftgrößenunterschieden auf der Seite zu arbeiten, wenn man mit seinen Schriftgrößen unterhalb der Mindestgröße agiert.
Aus diesen Gründen kann ich nur dringend davon abraten, Schriftgrößen in px anzugeben. Ansonsten drängt man den Besucher, zu erst zu Zoomen, um den Text lesen zu können. Dabei ist es unerheblich ob nun reiner Textzoom oder der komplette Seitenzoom eingesetzt wird.
Meine Herangehensweise sieht so aus, dass ich für den Body einen Prozentwert um 100 angebe (von mir aus auch 100.01% für die älteren IEs). Überschriften und große Texte werden dann im Bereich 1.4 bis 2em bemaßt, Fließtest zwischen 1.1 und .85em und Fußnoten .9 bis .8em. Dabei kann man durchaus sehr Genau arbeiten, da die Einheit em bis auf die vierte Nachkommastelle genau angegeben werden kann. Ich richte meine Schriftgröße nur so lang am Design aus, wie es mir die Bemaßung in em erlaubt und bin damit bisher immer gut gefahren, auf Pixelgenauigkeit achte ich auch sonst eher selten. Viel wichtiger sind optimale Zeilenlängen und vor allem ein ausreichender Zeilenabstand. Der Besucher sollte, unabhängig von seinen gewählten Einstellungen, ein lesbares Schriftbild vorfinden. Ihm diese Freiheit zu lassen, muss nicht im Widerspruch zu gutem und detailiertem Design stehen, man muss es nur berücksichtigen.



Sonderzeichen unter Windows (Alt-Codes)
David — Mon, 10 Aug 2009 18:37:01 +0000
Da dieser Artikel über Google so gut gefunden wird, ursprünglich aber nur einige wenige Sonderzeichen für bessere Typographie betrachtete, habe ich ihn erweitert und eine komplette Aufstellung aller Tastenkombinationen unter Windows XP mit ALT+Zahl erstellt
Legt man beim Bloggen, Kommentieren oder (von mir aus auch) Twittern Wert auf den korrekten Einsatz von ganz alltäglichen Sonderzeichen, ist man als Windows-Nutzer ganz schön aufgeschmissen. Wo in Word noch automatisch aus den Zollzeichen " (Shift + 2) Anführungszeichen „ “ werden, hat man in einem Kommentarfeld im Netz nur zwei möglichkeiten: Entweder Copy & Paste oder man kennt die sog. Alt-Codes. 
Okay, wo in einem Forum ein solches Gebilde gerade noch als Zitat durch geht, sieht sowas auf einem Blog ziemlich peinlich aus: “Sein oder nicht sein, das ist hier die Frage”. Also hab ich die wichtigsten Sonderzeichen, die nicht auf der Tastatur sind in einer Tabelle zusammengefasst. Diese liegt jetzt ausgedruckt auf meinem Schreibtisch – immer griffbereit, wenn ich an statt dreimal auf den Punkt zu hacken, korrekter Weise lieber ein Auslassungszeichen verwenden will.
Bleibt zu hoffen, dass man eine Tastatur mit Ziffernblock hat, denn die Tastenkürzel für Windows müssen bei gedrückter ALT-Taste eben dort eingegeben werden. Andernfalls bleibt ja noch die Copy&Paste Methode :)
Nachtrag:
ALT-Code Tabellen
Was jetzt folgt ist alles reine Empirie, denn leider findet man nur wenig Informationen über die Systematik der Ziffernkombinationen mit denen man an Sonderzeichen kommt. Offenbar wird aber häufig danach gesucht, denn dieser Artikel hier ist der meistbesuchte auf meinem Blog. Selbst bei Microsoft habe ich noch keine Infos über die Tastenkombinationen gefunden. Also geht hier Probieren über Studieren!
In Windows XP verstecken sich hinter den ALT-Codes die Positionen der Zeichen von (wenigstens) zwei Zeichensatztabellen. Zum einen die Zeichen der Codepage-850, die noch aus MS-DOS Zeiten stammt. Um also an ein Zeichen zu kommen, tippt man bei gedrückter ALT-Taste dessen Dezimalposition ein. Z.B. hat das Zeichen ¾ die Position F3_HEX bzw. 243₁₀. Also wäre die Tastenkombination ALT+243. Um nicht groß rumzurechnen, gibt es hier eine tabellarische Übersicht.
Zum anderen kann man über die ALT-Tastenkombination auf die Zeichen des Windows-1252 Zeichensatzes, der weitgehend mit ISO-8859-1 (auch (ISO-)Latin-1 genannt) übereinstimmt aber eben nicht identisch ist, zugreifen. Das Prinzip ist das gleiche wie für die Codepage-850, allerdings wird hier der Positionszahl eine Null “0″ vorangestellt. Bsp.: „ƒ“ dessen Position ist 83_HEX bzw. 131₁₀ also wäre die Tastenkombination ALT-0131. Auch hierfür gibt es eine Tabelle, die die ALT-Codes gleich mitliefert. Die ersten 32 Zeichen sind Steuerzeichen, die man wohl eher selten braucht. 
Die möglichen Nummernkombinationen gehen nach 255 bzw. 0255 übrigens weiter, die Zeichen beginnen dann einfach wieder von vorn.



SEO-freundliches, Cookie-unabhängiges Session-Handling in PHP
David — Thu, 30 Jul 2009 14:23:41 +0000
Der Einsatz von Sessions ist nicht immer unproblematisch, vor allem wenn man auch für strikte Cookie-Verweigerer eine Möglichkeit finden muss. Wie man Suchmaschinen aus der Session außen vor lässt und die URIs dennoch einigermaßen sauber hält, stelle ich hier vor.
Bisher konnte ich mich immer erfolgreich um den Einsatz von Sessions für Webseiten drücken oder ich habe mich darauf verlassen, dass der Besucher Cookies akzeptiert und den Rest PHP überlassen. Für Backends oder andere passwortgeschütze Seiten kann ich guten Gewissens den Benutzer bitten, eine Ausnahme zu machen und ein Cookie zu akzeptieren. Mit dieser Verfahrensweise ist spätestens dann Schluss, wenn man Warenkörbe, mehrseitige Formulare oder vergleichbare Erweiterungen der Funktionalität, unabhängig der Cookie-Einstellungen der Besucher, anbieten möchte. Mich persönlich nervt nichts mehr, als wenn mir eine Website vorschreibt aktiviere dies, installiere jenes um die Inhalte möglichst vollständig zu Gesicht zu bekommen.
Um die Session-ID mit dem folgenden Request wieder parat zu haben, hat man grundsätzlich drei Möglichkeiten zur Auswahl:

Die SID

in einem Cookie speichern
per Attribut in der URI übergeben
als verborgendes Feld in einem Formular per POST-Request (da aber eine Website nicht nur aus Formularen besteht, fällt das als Möglichkeit meist aus)

Am elegantesten ist natürlich Variante 1, denn eine Session-ID in der URI kann eine menge Probleme verursachen. Zum ersten führt es zu Sicherheitslücken, denn so ist die Session-ID offen sichtbar und die Session kann im schlimmsten Fall von einem anderen Nutzer übernommen werden.

Zweites Problem: Suchmaschinen und ihre Spider. Wenn Google & Co URIs mit der Session-ID indizieren, dann ist das formal dublicate content (die selbe Seite wäre ja auch ohne, bzw. mit beliebig vielen Session-IDs erreichbar) und wirkt sich unter Umständen negativ auf das Ranking aus – oder ein Nutzer, der diesen Links folgt, findet vieleicht nicht dass, was er eigentlich sucht, wenn der Inhalt individuell an die Session geknüpft ist.

Und zu guter Letzt sieht es einfach ziemlich blöd aus und es zerstört einem die mühsam zusammengebaute URI-Struktur: http://blog.dnaber.de/2009/artikel?PHPSESSID=a3c4efg6ijk0m8o3ue.

Man sollte also diese Möglichkeit der Session-ID-Weitergabe nur dann nutzen, wenn der Benutzer keine Cookies akzeptiert. 
Wie also kann man vorgehen?
Die Grundeinstellungen
Wir wollen, wenn möglich, Cookies verwenden, wir wollen allerdings nicht ausschließlich auf Cookies setzen. Also nutzen wir die Funktion ini_set() um die Laufzeitkonfiguration der Sessionbehandlung in PHP anzupassen:
# Cookieunterstützung aktivieren
ini_set( 'session.use_cookies', 1 );

# Sessionunterstützung ausschließlich mit Cookies deaktivieren
ini_set( 'session.use_only_cookies', 0 );
Je nach Serverkonfiguration kann das auch schon dem Standard entsprechen.
Die Fall-forward-Lösung für Cookie-Freunde
Ein Problem bei Cookies ist, dass man frühestens beim zweiten Request erkennt, ob der Client das Cookie akzeptiert und damit im Request wieder mit gesendet hat. Es bleibt also nichts anderes übrig, als für den ersten Request die Session-ID an die URIs zu hängen. 
if ( empty( $_COOKIE[ session_name() ] ) ) 
	ini_set( 'session.use_trans_sid', 1 );

else     
	ini_set( 'session.use_trans_sid', 0 );

Wir aktivieren also für den ersten Request die automatische Weitergabe der Session-ID über die URIs. Beim Start der Session wird dennoch das Cookie an den Client gesendet und – falls akzeptiert – beim nächsten Request mit gesendet und wir können ohne die transparente SessionID Unterstützung weiter machen.

Das ist nicht gerade schön, aber die einzige Möglichkeit die ich sehe, unabhängig von Cookie-Einstellungen des Client mit Sessions zu arbeiten. Wenn jemand eine elegantere Möglichkeit kennt, nur her damit.
Die Extrawurst für Suchmaschinen
In den Webmaster-Guidelines von Google lesen wir:
If features such as JavaScript, cookies, session IDs, frames, DHTML, or Macromedia Flash keep you from seeing your entire site in a text browser, then spiders may have trouble crawling it.

Okay, dann starten wir die Session gar nicht, wenn wir einen Besucher als Robot identifizieren. Damit sparen wir Ressourcen und gleichzeitig verhindern wir, dass unschöne URIs über diesen Weg im Index auftauchen. Dazu verwende ich folgende Funktion, der ich den User-Agent-String zur Überprüfung übergebe:
/** 
 * Findet einen Crawler anhand des 
 * User-Agent Headers
 *
 * @param str $ua (User-Agent) 
 * @return bool
 */
function isRobot( $ua = '' ) {

	if ( empty( $ua ) ) 
        	return FALSE;

	$robot_list = array(
		'googlebot',
		'Google-Sitemaps',
		'feedfetcher',
		'Slurp',
		'YahooSeeker',
		'msnbot',
		'archive.org',
		'teoma',
		'ia_archiver',
		'baiduspider',
		'WebDataCentreBot',
		'gonzo',
		'DotBot',
		'orgbybot',
		'web-sniffer'
	);
	foreach ( $robot_list as $needle ) {
		if( stripos( $ua, $needle ) )
			return TRUE;
        }

	return FALSE;
}
Die Liste der User-Agents für Robots habe ich hauptsächlich meinen Zugriffsstatistiken entnommen. Sie ist natürlich weit davon entfernt vollständig zu sein, aber damit sollte man die wichtigsten Spider auf dem Markt erfasst haben. (Um die Laufzeiten des Scripts möglichst kurz zu halten, bietet es sich an, die Spiderbezeichnungen nach absteigender Besuchshäufigkeit in das Array aufzunehmen.) 
Und falls doch mal eine unsaubere URI im Netz auftauch?
Es ist natürlich nicht auszuschließen, dass ein Link bzw. die URI eine Session-ID enthält, vieleicht hat ein Besucher einfach die Adresszeile seines Browsers kopiert und verlinkt. Diesen Link werden die Sumas natürlich finden. Um dennoch diese URIs nicht zu indizieren hilft uns der Meta-Tag robots weiter:
# im HTML-head
if ( FALSE !== stripos( $_SERVER[ 'QUERY_STRING' ], session_name() . '=' ) ) {

	echo '';
	# oder kanonische Adresse angeben (siehe Nachtrag)
}
Damit verhindern wir, dass die zusätzliche URI in den Index gelangt. Eine sauberere, aber auch aufwändigere Möglichkeit ist folgende Funktion, die die Session-ID aus der angefragten URI entfernt und die bereinigte URI zurückgibt. An diese können wir dann den Besucher weiterleiten.
/**
 * entfernt die Session-ID aus dem Request-URI
 *
 * @return str
 */
function getCleanURL() {

	if ( FALSE !== strpos( $_SERVER[ 'QUERY_STRING' ], session_name() ) ) {

		# String der Form PHPSESSID=abcde12345 entfernen
		$clean_url = str_replace(
			session_name() . '=' . $_GET[session_name()],
			'',
			$_SERVER['REQUEST_URI']
		);
       
		# & und ? entfernen, falls die am Ende des Strings stehen
		$clean_url = trim( $clean_url, '&?' );

		# sollten wir die Session ID zwischen zwei anderen Get-Parametern, oder 
		# am anfang des Query-Strings herausgelöst haben, müssen wir noch aufräumen:
		$clean_url = str_replace(
			array( '?&', '&&' ), 
			array( '?', '&' ), 
			$clean_url 
		);

		return $clean_url;
	}
	else {
		return $_SERVER['REQUEST_URI'];
	}
}
An diese URI dürfen wir den Besucher nur dann weiterleiten, wenn wir sicher sind, dass er Besucher von einer externen Seite kommt. Andernfalls wäre der ganze Aufwand umsonst gewesen – wir würden unsere eigenen Session-IDs abschneiden. Außerdem brauchen wir die Funktion nicht zu bemühen, wenn gar keine Variablen in der URI mitgegeben wurden, d.h. der Query-String leer ist.
# Ein Referer von der eigene Seite würde so aussehen
# http://meine-seite.tld… 
# also:
$my_referer = ( empty( $_SERVER['HTTPS'] ) ? 'http' : 'https' ) . '://' . $_SERVER[ 'HTTP_HOST' ];

if ( FALSE !== strpos( $_SERVER[ 'QUERY_STRING' ], session_name() )
    && 
    ! empty( $_SERVER[ 'HTTP_REFERER' ] ) 
    &&
    FALSE === strpos( $_SERVER[ 'HTTP_REFERER' ], $my_referer )
) {
	# ab zur Adresse ohne Session-ID
	header( 
		'Location: ' 
			. ( empty( $_SERVER[ 'HTTPS' ] ) ? 'http' : 'https' )
			. '://' . $_SERVER[ 'HTTP_HOST' ] 
			. getCleanURL(), 
		TRUE, 
		301
	);
}
Anmerkung
Die hier gezeigte Lösung ist aus der Not heraus geboren, da man nur wenig über das Wie des Session-Handlings im Internet findet – vor allem, wenn man sich die o.g. Ziele steckt, dass die Session unabhängig von Cookies verwendet werden kann und man das SEO-Problem und die Nutzerfreundlichkeit nicht ganz außer Acht lassen will. 
Konkret werde ich diese Methode für ein Bestellformular auf einer Seite einsetzen, in dem keine sensiblen Daten in der Session gespeichert werden und die Session nicht obligatorisch für die Funktion der Seite ist. Nach einiger Zeit werde ich hier meine Erfahrungen mit dieser Methode veröffentlichen. 
Nachtrag vom 04.08.

Gestern abend laß ich im Blog von Matt Cutts von dem cannonical Link-Element. Damit zeigt man den Suchmaschinen die kanonische Adresse an und vermeidet somit doppelte Seiten. Um diesen Tag sinnvoll einzusetzen, habe ich die Funktion sendToCleanURL() durch die Funktion getCleanURL() ersetzt, weil ich sie so flexiebler einsetzen kann:
if ( FALSE !== stripos( $_SERVER[ 'QUERY_STRING' ], session_name() . '=' ) ) {
     $cannonical_url = 
		  ( $_SERVER['HTTPS'] ? 'http' : 'https')
		. '://'.$_SERVER['HTTP_HOST']
		. getCleanURL();
     echo '';  
}
Sollten wir also eine unsaubere URI im Umlauf haben, so ist damit sichergestellt, dass die Suchmaschinen keine Probleme damit haben.

Weitere Infos: specify your cannonical



Die Shopping-Qual
David — Wed, 01 Jul 2009 12:02:30 +0000
Ich habe noch nie Klamotten im Internet bestellt. Seit heute weiß ich, warum ich ganz gut daran getan habe.

Eigentlich gehe ich gern mal in die Stadt zum Shoppen um mich neu einzukleiden, sogar – man mag es kaum glauben – mit meiner besseren Hälfte (der ich hier mal kurz danken möchte, da sie bis jetzt für jeden Artikel das Lektorat übernommen hat). Eine gute Freundin von ihr hat uns zu ihrer Hochzeit eingeladen. Ein solches Ereignis bedarf natürlich auch angemessener Abendgarderobe seitens der Gäste, also haben wir beide gestern Nachmittag ganz „zwo-nullig“ eine virtuelle Shoppingtour gemacht. D.h. sie hat mir die entsprechenden Links über den Messenger geschickt, und ich durfte meine Meinung kund tun. Lange Rede – kurzer Sinn: ich bin mir jetzt ziemlich Sicher den Grund für die Pleite von Quelle zu kennen. 
Das Martyrium fing an, als der erste Link zu otto.de über ICQ hereinkam. Neben diversen Ordnern (u.a. mit dem Namen des Shop-Systems) die sicherlich keine sind, enthielt die URL auch die 72-stellige Session-ID und das, obwohl ich Cookies akzeptiere. Eine phänomenale Voraussetzung um dem Kunden die Möglichkeit zu bieten, die angebotenen Artikel zu vergleichen und ggf. auch mal zu verlinken bzw. zu den Lesezeichen zu legen. 
Hat man JavaScript in seinem Browser aktiviert, so gelangt man über gigantische Drop-Down-Listen irgendwann zu der gewünschten Artikelübersicht. Ich nutze in solchen Situationen gern die Funktion der mittleren Maustaste um einen Link in einem neuen Tab zu öffnen, um – den vorsintflutlichen Ladezeiten Rechnung tragend – die Übersicht weiter begutachten zu können während die Detailansicht des Artikels lädt, oder ein Artikel „bei Seite zu legen“ um ihn mit anderen zu vergleichen. Das geht allerdings nur, wenn die Seite echte Links hinter die Vorschaubildchen legt anstatt JavaScript-Funktionen. 
Spätestens an diesem Punkt stecke ich als Besucher in einer Zwickmühle: schalte ich JavaScipt ab, wodurch das Layout teilweise zusammenfällt und mir wichtige Funktionen wie die vergrößerte Ansicht oder die Links auf ähnliche Produkte verwehrt bleiben, oder schalte ich es nicht ab, was zu steinzeitlichen Ladezeiten führt und bei mir grundlegende Browserfunktionen blockiert. Ich dachte bisher die Zeiten, in denen man JavaScript zum Selbstschutz deaktiviert wären vorbei. 
Dieses Shopsystem setzen leider noch etliche weitere bekannte deutsche Onlineshops ein u.a. auch Quelle. Ich als normaler Besucher bin da schon nach fünf Minuten satt und gehe lieber in ein Geschäft. Einen Blick in den Quelltext habe ich mir erspart.
Ein Shopsystem von einem solchen Umfang umzusetzen ist ein Haufen Arbeit, weswegen dahinter auch eine Agentur steht, die sich auf diese Produkte spezialisiert hat. Was mich wundert ist, dass in der Entwicklung offenbar kein Gedanke an Benutzerfreundlichkeit geschweige denn an Barrierearmut verschwendet wurde oder aber die falschen Schlüsse gezogen wurden. Bei den Budgets die in solchen Bereichen fließen muss es doch drin sein eine Seite auch, oder gerade für den Nutzer zu optimieren. Vieleicht fehlt aber einfach noch das Bewusstsein, dass das Internet die Nutzer sind und nicht die Shops, die möglichst viel Profit raus holen wollen. Vieleicht habe ich auch gerade eine Marktlücke entdeckt – der barrierefreie Onlineshop? 



Verabschiedung der Accesskeys
David — Wed, 13 May 2009 11:44:41 +0000
Bis jetzt dachte ich, dieses Thema sei spätestens mit HTML 5 vom Tisch. Aber  Qualitätsprüfautomaten für Websites und die WHATWG sind da anderer Ansicht. Da müssen wir noch mal drüber reden.
Das accesskey-Attribut erlaubt dem Webdesigner für fokussierbare Elemente wie Links und Formularelemente eine Taste auf der Tastatur zu definieren, die dieses Element aktiviert bzw. den Fokus auf das Element setzt. Je nach Browser kann der Nutzer mit einer bestimmten Tastenkombination die Elemente direkt anspringen, ohne erst hin-Tab-en zu müssen. Schön und gut, aber hier hören die theoretischen Vorteile aus meiner Sicht auch schon auf und die Probleme fangen an:

Niemand merkt sich die Tastenkürzel für jede Website. Möchte man also den Vorteil der Tastenkürzel nutzen, muss man erstmal die Bedienungsanleitung suchen – jedes mal auf’s Neue. Man müsste sich also auf Standards einigen – was bis heute nur unzureichend geschehen ist.
Wirklich sichere Tasten, die von keinem Programm als Tastenkürzel in der Grundeinstellung verwendet werden, gibt es kaum. Man würde also zwangsläufig mit den vom Nutzer verwendeten Tastenkombinationen kollidieren.
Die Seite schreibt dem Nutzer vor, welche Tastenkürzel er zu verwenden hat.
Kommt es zu dem Fall, dass von der Website definierte Tastenkürzel die Einstellungen des Benutzers überschreiben, dann haben wir nicht nur eine Barriere, dann haben wir eine vollständige Blockade geschaffen. Und einen Besucher auf Dauer vergrault.

Es mögen wohl auch diese Gründe gewesen sein, warum das Accesskey-Attribut bis jetzt aus dem HTML 5 Standard rausflog. Und es sind die Gründe, warum ich mich entschieden habe, die Accesskeys nicht einzusetzen obwohl sie auch heute noch mancherorts empfohlen werden. Beim Qualidator erreicht man die 100% in Accessibility nur, wenn man auch Accesskeys definiert  hat. Na dann.
Die Annahme, mit Accesskeys mehr Zugänglichkeit zu schaffen, scheint also noch weit verbreitet zu sein – ein Grund, das Thema noch einmal kritisch zu beleuchten. Ein Weiterer ist die Wiedereinführung des Acceskey-Attributes durch die WHATWG auf ihrem Blog. Der Unterschied zu HTML 4.01 soll sein, dass in HTML 5 jedes Element das accesskey Attribut bekommen darf, außerdem kann man nun mehrere Werte angeben. Was ist denn da los? Für HTML 6(!) wird vorgeschlagen dem Attribut anstatt einem festen Wert eine Rolle zuzuweisen: accesskey="help". Ein guter Gedanke in die richtige Richtung, der Benutzer sucht sich dann selbst die Tastenkombination aus um zur Hilfe zu gelangen. Das wird bis dahin sicherlich überflüssig sein.
Die Idee hinter den Accesskeys ist prinzipiell nicht verkehrt. Nur ist die Umsetzung unglücklich geraten. Einen ganz anderen Weg sehe ich in HTML 5. Eine bisher recht sinnfreie Div-Suppe weicht damit einem Dokument, welches mit Elementen wie 
, ,  wesentlich mehr Semantik bietet. Es ist dann eine Sache der Implementierung dem Nutzer die Möglichkeit zu bieten, zwischen den einzelnen Bereichen zu navigieren. Eine weitere, zur Zeit schon wesentlich praxistauglichere Möglichkeit bietet WAI-ARIA mit den sog. Landmarks, die einzelnen Bereichen wie Navigation, Hauptinhalt, Header etc. Rollen zuweist. Dazu nur einige Links, da dass schon wieder einen ganzen Artikel füllen würde.

Überblick über WAI-ARIA(en)
7 Gründe Landmarks sofort einzusetzen
Einführung in WAI-ARIA

Accesskeys waren gut gemeint, sind aber in der Praxis eher ungeeignet, bzw. sogar störend und sollten, wie das tabindex-Attribut, nicht eingesetzt werden um die Seite Barrierefrei(er) zu gestalten, da damit im schlimmsten Fall das Gegenteil erreicht wird.



Externe Links auszeichnen und hervorheben
David — Thu, 07 May 2009 15:31:14 +0000
Geht es euch auch so? Wenn ich durch das Web surfe und mir nicht sicher bin ob der Link da nun auf eine interne Seite zeigt, oder zu einer fremden Seite führt, so wandert der Blick meist erstmal Richtung Statuszeile im Browser, um zu sehen, wo es denn hin geht. An dieser Stelle finde ich es immer von Vorteil, wenn der Autor seine externen Links, in Form einer kleinen Pfeilgrafik zum Beispiel, gesondert hervorhebt. 
Bisher habe ich das in diesem Fall naheliegendste getan: den Links eine extra Klasse verpasst und diese dann per CSS entsprechend geschönt. 
Linktext
a.extern {
	background: transparent url(extern.gif) center left no-repeat;
	padding-left: 17px;
}
Nun sieht man seit einiger Zeit, dass vor allem CMS und Blogsysteme von vornherein externe Links gern mal mit dem Attribut rel und den Werten  external (und nicht selten mit nofollow) auszeichnen.  Dass nofollow als präventiver Spamschutz unsinnig ist, hab nicht nur ich schon mal geschrieben. Mir gehts es hier aber um das external. Das taucht zwar erst in der vorläufigen HTML 5 Spezifikation auf, validiert aber auch prima mit den HTML 4.01 und XHTML 1.0 Doctypes. Wenn das Attribut also schon da ist, wozu eine extra Klasse vergeben? CSS bietet dafür den Attributselektor an:
a[rel~=external] {
	background:transparent url(extern.gif) center left no-repeat;
	padding-left:17px;
}
Externer Link
Bis hierher versteht das sogar der IE 7. Die Puristen unter uns verzichten vieleicht gern auf überflüssigen Grafikballast. Warum auch nicht, die Unicodetabelle hält so einiges an Pfeilen bereit. So sieht die Kür im CSS aus:
a[rel~=external]:after {
	/**  
	 * Allen Links folgt ein  geschütztes Leerzeichen U+00A0 
	 * und ein Nord-Ost-Pfeil U+2197
	 */
	content: "0A02197";
}
Hier steigt allerdings auch der IE 7 aus, der mit den Pseudoelementen :before und :after nicht klar kommt. Die Extrawurst könnte in Form einer Hintergrundgrafik gereicht werden.
Sieht man mal von der Tatsache ab, dass sowohl der IE6 als auch Mobile Geräte die Attributselektoren ignorieren, und legt man Wert auf schlankes und semantisches Markup, so kann man die Umsetzung mit Hilfe des rel-Attribut der Variante mit eigener Klasse durchaus vorziehen, da so gleichzeitig ein semantischer Mehrwert geschaffen ist.
Das bleibt natürlich nicht auf externe Links beschränkt. Vorhergehende, oder nachfolgende Seiten eines zusammenhängenden Artikels werden mit rel="prev" bzw. rel="next" ausgezeichnet. Ein Pfeil nach links oder nach rechts verdeutlicht dann die Sache ( ←,→ )
Eine kurze Bemerkung zu dem Target-Attribut sei noch gestattet. Sucht man nach Informationen zu rel und external, findet man hier und da Vergleiche zu target="_blank" oder gar Versuche, das fehlende Target-Attribut in den Srict-Doctypes durch rel="external" und diverse JavaScripts zu ersetzen. PFUI SPINNE! Liebe Webmaster, lasst dem Besucher doch bitte selber die Entscheidung was er wo in welchem Fenster oder Tab öffnet! Danke.
Nachtrag 25.05.09

In den Kommentartexten werden die Links nicht automatisch mit dem Attribut rel="external" versehen. Da ich nur ungern in dem WordPress-Code herumdocktoren möchte, genemige ich mir hier schon eine kleine portion CSS 3: 
Alle Links in den Kommentaren, die mit http:// beginnen, bekommen einen Pfeil hinten angesetzt:
a[href^="http://"]:after {
	content: "0A02197";
}
Die Links, die auf meine Subdomain zeigen, bekommen den wieder überschrieben: 
a[href^="http://blog.dnaber.de"]:after {
	content: "" ! important;
}