str_word_count() beispielsweise scheitert an fast allen Punkten, obendrein noch an Bindestrichen, Zahlen … und UTF-8. Man kann daran vorbeieiern, aber der Aufwand lohnt sich einfach nicht.

Bleiben wir pragmatisch, nehmen schlechtes Deutsch seufzend hin und zählen einfach die Leerzeichen, ja?
Nein. Manche Leute haben immer noch die Angewohnheit, hinter einen Punkt zwei Leerzeichen zu setzen, und im Markup tauchen sie selbstverständlich auch auf.

Also nochmal: Gegeben sei ein String …

$string = '<p class="foo bar"> hello world.  two späceß.<br />
bla</p>'

… aus dem wir erst das Markup entfernen:

$text = strip_tags( $string );

… dann die Leerzeichen am Anfang und am Ende:

$text = trim( $text );

Und jetzt entspräche die Menge der nicht aufeinanderfolgenden Leerzeichen plus eins der Menge dessen, was wir als Wörter akzeptieren. Wir müssen aber nicht addieren, sondern kleben einfach ein Leerzeichen hinten an und lassen einen trivialen regulären Ausdruck durchzählen:

$word_count = preg_match_all( '~\s+~', "$text ", $m );

Ergebnis: 5.

Speed-Dial-Beispiel

Das sieht bei vielen Seiten recht dröge aus; also habe ich mir überlegt, wie man das besser machen kann. Immerhin bietet Opera eine API an. Das Ergebnis ist ein kleines Plugin, das ich ganz kreativ Opera Speed Dial Preview genannt habe. Es liegt natürlich auf GitHub.

Download: Plugin T5 Opera Speed Dial Preview

Das Plugin erfordert keine Konfiguration. Nach dem Aktivieren fängt es Zugriffe ab, die mit dem Request-Header X-Purpose: preview gesendet werden und lenkt sie auf /speedial/ um. Permalinks müssen also aktiviert sein, damit es funktioniert!

Speed-Dial-Plugin Standardansicht

Die Ausgabe wird in der großzügig dokumentierten Datei speed-dial.php erzeugt. Hat das aktuell verwendete Theme eine Datei dieses Namens, so wird diese verwendet, nicht die des Plugins. Damit haben Theme-Autoren freie Hand: Einfach selbst eine Datei speed-dial.php ins Theme werfen, gestalten wie man möchte – fertig. Das dauert nur ein paar Minuten.

Für diese Seite habe ich die Vorschau bloß um das Logo ergänzt:

Speed Dial für toscho.de

Man kann aber eingeloggten Nutzern die letzten Nachrichten eines BuddyPress-Setups präsentieren oder die zu moderierenden Kommentare auflisten … ihr habt freie Hand, denn alle normalen WordPress-Funktionen stehen zur Verfügung wie in jeder anderen Template-Datei auch.

Verbesserungsvorschläge sendet bitte an die passende Adresse auf GitHub, damit ich sie nicht aus den Augen verliere.

Eure eigenen Umsetzungen interessieren mich auch! Schickt sie mir, und ich baue eine Galerie – selbstverständlich mit Dofollow-Link.

GET /thema/suchmaschinen/%23content

Einfach ausgedrückt: Da hat jemand nicht verstanden, was ein # am Anfang eines Linkziels bedeutet.

Momentan reagiere ich noch recht gutmütig darauf mit einer kleinen Regel in der .htaccess:

RedirectMatch Permanent (.*)#.*$ $1

Sieht ein bißchen aus wie Perl-Code, daher ist eine kleine Erklärung angebracht. Die Regel besteht aus drei Teilen:

1. RedirectMatch – die Direktive, die verwendet werden soll.
2. (.*)#.*$ – Erfasse alle URIs, die diesem Muster entsprechen: beliebige Zeichen in beliebiger Menge – .* – plus Raute – # – plus beliebige Zeichen in beliebiger Menge.
3. Lenke diese Anfragen auf die Zeichen um, die der erste eingeklammerte Ausdruck erfaßt hat.

In einem korrekten Request wird der Anker nicht an den Server gesendet, sondern der User-Agent merkt ihn sich einfach. Das zumindest beherrschen auch alle Browser, wenngleich der anschließend plazierte Fokus nicht immer der Norm entspricht. Google Chrome beispielsweise glänzt hier mit besonderer Inkompetenz …

Wer solche Fehler verfolgen möchte und WordPress benutzt, mag vielleicht mein Plugin T5 404 Tools ausprobieren.

Das Plugin Public Contact Data erzeugt dafür neue Felder im Backend unter Einstellungen/Allgemein. Außerdem gibt es drei weitere Felder für Google Plus, Facebook und Twitter.

Im Screenshot hier werden vier Felder benutzt. Neben E-Mail und Telefon auch Facebook und Google Plus. Im Vordergrund sieht man den Tab mit dem Backend, im Hintergrund den Einsatz in der Website.

Die Liste kann man über den Filter 'pcd_fields' ändern. Ein Beispiel:

add_filter( 'pcd_fields', 'change_pcd_fields', 10, 1 );
function change_pcd_fields( $fields )
{
	// remove an item
	unset ( $fields['facebook'] );

	// add an item
	$fields['github'] = 'GitHub';

	return $fields;
}

Für jedes Feld wird automatisch ein Shortcode erstellt nach dem Muster [public_$fieldname]. Hintergrund dazu auf WordPress Stack Exchange.
[public_email] gibt als die E-Mail-Adresse aus, [public_github] den Wert des per Filter erzeugten GitHub-Feldes.

Für den Gebrauch im Theme existiert auch eine Aktion namens pcd. Deren erster Parameter ist der Feldname, der zweite ein Array mit Optionen:

array (
	'before'  => '',
	'after'   => '',
	'link'    => TRUE,
	'print'   => TRUE,
	'pattern' => FALSE
);

Um einen E-Mail-Link zu bekommen, schreibt man beispielsweise:

do_action( 'pcd', 'email', array ( 'before' => 'Email: ' ) );

Die E-Mail-Adresse wird immer maskiert ausgegeben, also durch die Funktion antispambot() geschickt. Das hilft nicht viel, schadet aber auch nicht.

Wird das Argument pattern benutzt, so wird link ignoriert. Benutze %value% als Platzhalter im Pattern-String.

Der Vorteil beim Einsatz der Aktion: Wird das Plugin abgeschaltet, passiert nichts Schlimmes. Es wird einfach nichts ausgegeben, weil WordPress die Aktion ja nicht mehr kennt und somit ignoriert.

Man kann die wenigen öffentlichen Funktionen der Klasse auch über den Zugriff auf eine eventuell schon existierende Instanz ansprechen. Beispiel:

Public_Contact_Data::instance()->action_handler( $field, $options );

Das Plugin ist natürlich übersetzbar, eine deutsche Übersetzung liegt bei. Deshalb heißt es in der Pluginliste eines ins Deutsche übersetzten WordPress’ auch Öffentliche Kontaktdaten. Momentan wird die Sprachdatei nur im Backend geladen, um die Ladezeit zu schonen.

Download

Den Code findet man auf GitHub, im Bugtracker dort möchte ich auch Fehlermeldungen und Verbesserungsvorschläge sehen.

Ich habe das Plugin unter eine MIT Lizenz gestellt. Die ist kompatibel mit der GPL, gibt dem Benutzer aber etwas mehr Freiraum.

Rettung naht gibt es vielleicht irgendwann: Im CSS Text Level 3 wird die Eigenschaft tab-size vorgeschlagen. Die Diskussion dazu findet man in der CSS-Mailingliste des W3C.

pre
{
    tab-size: 4; /* Nimm vier Leerzeichen! */
}

Das setzt freilich voraus, daß der Browser das Zeichen TAB im Shadow DOM in ein Pseudo-Element packt. Und das können derzeit nur Firefox und Opera. Mit einem Vendorpräfix.

pre
{
    -moz-tab-size: 4;
    -o-tab-size:   4;
    tab-size:      4;
}

Der Test, der auch andere Präfixe prüft, zeigt in Opera und Firefox das erhoffte Ergebnis:

WebKit (hier Chrome) und der IE 9 machen leider dieses:

Fazit: Taugt erstmal nur fürs Userstylesheet. Immerhin. In den nächsten zwei Jahren werden wir unseren Code weiterhin ein bißchen vorbereiten müssen und Tabs in Leerzeichen umwandeln – oder auf die ollen Nischenbrowser pfeifen.

Quälend langsam haben dann einzelne Browser ihre skurrilen Interpretationen der Regeln eingebaut. Da gab es eine Menge zu lernen und zu hacken. Jeder Browser hatte nicht nur Macken, die zu den Macken der anderen inkompatibel waren, sondern auch ein rasch wechselndes Set proprietärer Eigenschaften. Es hat Spaß gemacht, da herumzukurven, im Usenet oder auf Mailinglisten mit anderen Leuten zu tüfteln und zu testen.

Heute ist das weg. Mit den superkaputten Browsern ist auch das Gefühl verschwunden, beim Umgang mit CSS den Kopf zu brauchen. Klar, es gibt immer noch kleine Hacks und vorläufige proprietäre Implementationen. Meistens laufen die nur auf ein weiteres Snippet in der IDE hinaus. Aber früher, als man nicht einmal width schreiben konnte, ohne von mindestens drei Browsern eins in die Fresse zu kriegen, war das irgendwie … spannender.

CSS3 hat uns viele neue Eigenschaften gebracht aber kaum neue Konzepte. Viele Module sind nicht einmal kompatibel zueinander, und das Entwicklungstempo ist – so wirkt es auf mich – deutlich gesunken. Kein Wunder, ich verlöre angesichts dieses Wustes auch die Lust.

Manches nervt sogar. Ich habe die Nase voll von Schättchen und Verläufen, von abgelutscht aussehenden Ecken und Schrift mit Pseudo-Prägeeffekt. Kitsch. Hier wird das alles demnächst verschwinden.

Der Grund für das Fefe-Theme war nicht Fefe. Der Grund waren all die anderen Layouts, die ich in den letzten Jahren verfaßt habe. Bei denen ich zu viel Zeit mit zu leichtem Code verbringen mußte.

Ich bin, wie Aristoteles einst so schön gesagt hat, ein krummes Holz, das mal in die andere Richtung gebogen werden muß. Von mir selbst.

Das Theme verwendet kein Stylesheet, keine Tags oder Kategorien, keine Post-Titel, und mit Bildern kann man auch nicht viel anfangen. Es gibt zwei Widgetflächen – oben und unten – da kann man Text hineinsetzen, wenn man möchte. Einen Shortcode für den Einbau des Suchformulars habe ich auch erstellt: [searchform]. Damit kann man die Maske auf einer beliebigen Seite mitten im Text plazieren.

Vergleich Original und Theme

Die Sprache ist Englisch, es liegt aber eine deutsche Sprachdatei bei, und Andrey Savchenko, den einige sicher als Rarst von WordPress Answers kennen, hat die Übersetzung ins Russische besorgt. Cool.

Das Repository liegt natürlich auf GitHub: https://github.com/toscho/Fefe-Tribute-Theme

Die Version 1.0 herunterladen könnt ihr dort auch.

Verbesserungsvorschläge und Feature-Requests packt bitte in den Issue-Tracker, damit ich den Überblick behalte. Danke!

Gute Themes bieten dafür eine Option an, TwentyTen und auch TwentyEleven leider nicht. Die nachträgliche Entfernung ist umständlich, wenn man kein Child-Theme erstellen möchte.

Deshalb habe ich ein kleines Plugin geschrieben, das sowohl das Bild im Frontend entfernt als auch den Menu-Eintrag im Backend.

Plugin Remove Header Image

Wie üblich – es gibt ein mindestens zwei Haken: Wenn im Theme nicht geprüft wird, ob überhaupt ein Bild vorhanden ist, ehe der Container dafür ausgegeben wird, bekommt man eine leere Fläche. Das ist dann eben ein Schrott-Theme. Davon gibt es leider zu viele.
Und die Seite im Backend ist immer noch erreichbar, wenn man die URL dahin kennt. Bilder kann man aber nicht mehr hochladen.

Als Beispiel für den Einsatz in der Praxis sei das Videoblog Drehlog genannt. Dort blogge ich mit ein paar Freunden ab und zu … tja … Videos.

Irgendwie werde ich das Gefühl nicht los, einen leichteren Weg übersehen zu haben … sei’s drum.

Die erste Antwort darauf sieht ganz pragmatisch aus: Ungeachtet des schlecht gewählten Namens eignet sich Germanix für viele Sprachen: Dänisch, Türkisch, Französisch oder Spanisch zum Beispiel.
Als de_DE.php wäre der Nutzen ohne Not reduziert, denn die benutzt WordPress ja nur, wenn in der wp-config.php eben diese Sprache angegeben wurde.

Die zweite – und mir wichtigere – Antwort fällt vielleicht eher unter Meinung, deshalb möchte ich vorausschicken, wie meine Sicht gefärbt ist: Ich schreibe pro Woche mindestens ein Plugin, oft zwei, manchmal drei. Pro Monat schreibe ich zwei bis drei Themes. Ich weiß also ein wenig, was wo am besten funktioniert. Oder ich bin eingefahren, wie immer man das sehen möchte.

Was ich nicht bin: perfekt. Ich mache Fehler, schreibe Bugs in meinen Code, die ich dann wieder repariere. Bei einem komplexen System, dessen Bestandteile (Core, Themes und Plugins) separat aktualisiert oder ersetzt werden, kann sich so ein Bug recht gut verstecken. Manchmal entsteht so ein Fehler auch durch fremden Code, der nicht sauber geschrieben wurde, oder durch das Aufeinandertreffen zweier an sich ganz harmloser Codes.

Beispiel: Ein Beitrag wird plötzlich ganz anders ausgegeben, als er geschrieben wurde. Oder der Permalink dafür leitet auf die Fehlerseite.
In solchen Fällen gehe ich wissenschaftlich vor: Ich ändere immer nur eine Variable, Schritt für Schritt, bis ich alle notwendigen Faktoren ermittelt habe. Dann weiß ich, wo ich suchen und flicken muß.

Programmieren ist zu 80% Debuggen, also muß das einfach sein.

Das heißt: Ich muß Code schnell und möglichst granular abschalten können. Als de_DE.php müßte ich zum Debuggen die Datei umbenennen, denn allein das Ändern der Sprache in der wp-config.php erfaßt zu viele weitere Faktoren. Das ist mir zu umständlich, obendrein vergesse ich es vielleicht.

Und für die Nutzer meines Plugins ist es noch umständlicher. Wer hat schon immer das FTP-Programm oder eine SSH-Shell geöffnet, wenn er an WordPress sitzt?

Als klassisches Plugin kann ich Germanix jederzeit einfach und isoliert abschalten.

Gleiches gilt auch für viele Hacks, die für die functions.php empfohlen werden. Wenn der eingebaute Code im Stylesheet oder in einer Template-Datei nicht berücksichtigt werden muß, dann gehört er in ein Plugin.
Dabei entsteht keine zusätzliche Last, nur die Liste der aktiven Plugins wird um einen Eintrag erweitert. Und wenn diese paar Zeichen dein System schon in Not bringen, dann ist das System kaputt.

Wenn dir jemand sagt, er habe Plugin-Funktionalität ohne ein Plugin, dann glaub es nicht. Nicht der Ort des Codes entscheidet darüber, ob er ein Plugin ist, sondern das, was er tut. Auch ich habe diesen Fehler schon begangen. Sorry.
Mein Dofollow-Code ist jetzt ein Plugin, der Code zur Kontrolle des Umbruchs im Titel auch.

Warum ist also Germanix ein Plugin? Weil es ein Plugin ist. Der Code benutzt die Plugin-API, er kann vom Theme komplett ignoriert werden, und er muß abschaltbar sein.

Weitere Lektüre

• WordPress-Plugin: Germanix
• WordPress als CMS: Hilfreiche Plugins
• WordPress-Tutorial: Ein Framebreaker-Plugin schreiben

Leider sieht sie dämlich aus: Hellgrau auf Mittelgrau, zeitgemäß verhunzt mit Schatten und abgerundeten Ecken. Kinkerlitzchen, CSS3 vom Schlimmsten.

Ich habe diesen Quatsch mal aufgeräumt, die Farben auf die des Betriebssystems umgestellt und ein Plugin daraus gemacht:

Admin Bar In System Colors

Das kann hoffentlich jede und jeder gut lesen.

Forks, Fragen oder Fer Verbesserungsvorschläge?

Umfangreiche Browsertests habe ich noch nicht gemacht – keine Zeit! – und vielleicht sollte ich das Standardstylesheet komplett ersetzen, statt es zu überschreiben. Auch über die feste Höhe samt Pixelschriftgröße werde ich sicher nochmal nachdenken. Und die kleine Grafik für aufklappbare Menus kann man kaum noch erkennen …

Weiterlesen

• WordPress-Plugin: Backend Style Enhancements
• WordPress: Grundeinstellungen per Plugin setzen
• WordPress: Administrator mit PHP herausfinden
]]> http://toscho.de/2011/wordpress-adminbar-in-systemfarben/feed/ 20