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!

Nach einer furchtbaren Nacht ohne Kater kurz nach 5 aus dem Bett. 11 Uhr kommen Nick und Micha und wir brausen los.
Da Nick Zoff mit der Dame im Navigationsgerät hat, kommen wir erst gegen 17:30 Uhr im Hotel Meininger an. Von dort gleich weiter zur Brauerei Früh, wo schon 50 andere sitzen. Drinnen ist es laut und voll; statt Bier gibt es Kölsch, eine Art teure Pisse. Ich bestelle eine Bockwurst, von der ich so lange esse, bis der Kotzdrang den Hunger aussticht.

Flucht mit @cbuchler zum Starbucks, einen großen Kaffee fassen, dann ins Hotel. Rückzug nach innen in der Lobby, Mails abrufen, Code schreiben. 12 Uhr ins Bett. Die Inpsydetruppe feiert bis 4. Wir stehen alle 7 Uhr auf, ich bin sogar wach.

Köln

Köln ist 1970 eingefroren. Der Lohn ist ewig gutes Wetter, die Strafe Kölsch. Vermutlich hat Köln selbst dann gutes Wetter, wenn es Scheiße regnet. Weil die Leute es nicht merken. Weil sie Kölsch trinken.

Jeder duzt jeden. Im Hotel, in der Kneipe, bei Starbucks und im Taxi. Ich fühle mich ganz kurz etwas jünger, bis mir aufgeht, daß das Duzen hier einfach nichts mit dem Alter zu tun hat.

Samstag

Frühstück im Hotel. Ich verdicke die Kaffeeparodie mit Milch. Erster Anflug von Heimweh.

Bei gutem Wetter schlendern wir gegen 8 zur Universität. Verkachelte Wände, der Kaffeeautomat spuckt eine Brühe in den Pappbecher, die sicher nicht zum ersten Mal eine Niere sieht. Namensschilder und T-Shirts werden verteilt, Räume gesucht. Frank und Olaf erklären den Ablauf. Die ersten Memmen jammern auf Twitter, weil ihr Drei-Wetter-Taft versagt.

Die Sessions interessieren mich nicht. Das wußte ich vorher, ich bin der Leute wegen hier. Bis zur Mittagspause schwatze ich mich durch die Besucherschar, teste einen pappigen Cappuccino und Apfelschorle.
Der Koffeinist in mir sticht bös und böser zu. Frank und ich rennen ins nächste Café, wo wir eilig jeder zwei Tassen Kaffee einsaugen. Und über DAS BUCH sprechen. Das längst schon fertig sein sollte …

Zurück zur Uni, Frank hält seine Session, die einzige, die mich interessiert, in einem Raum, der mir zu voll ist. Ich seh’ den Code schon früh genug.

Also gehe ich mit dem Schepp in ein anderes Café. Langsam gewinne ich wieder menschenähnliche Züge. Mit Christian kann ich gut plaudern, auch mal eine Pause einlegen, die nicht peinlich wirkt.
Mein leises Bedauern darüber, zu wenig Zeit für Köln zu haben, kontert Christian mit dem Hinweis auf das nächste MMT. Oha! Da habe ich gleich Lust drauf.

In die letzte Session werde ich von den Inpsyde-Leute sehr bestimmt hineingebeten. WordPress-Jeopardy. Die Besucher werden in zwei Gruppen aufgeteilt, die gegeneinander antreten. Ich darf in keine Gruppe. Ich bin der »Joker«, bekomme 1000 Punkte, weil ich einen semantischen Fehler korrigiere, statt die Frage zu beantworten, tue so, als fühlte ich mich nicht verarscht. Spiele mit.

Danach erwische ich endlich noch Sylvia für einen kurzen Plausch, bedanke mich für ihre Hilfe bei einem Artikel, der schon viel zu lange seines letzten Schliffs wartet und dringend hier ans Licht möchte.
Mit David kann ich auch endlich schwatzen. Aus dem wird mal ein guter Nerd.
Wir gehen zum Aachener Weiher, liegen auf der Wiese und sehen den Mädels zu. Ich koste die letzten Sonnenstrahlen aus. Jemand hext mir ein Kölsch in die Hand. Ich laufe umher, Musik in den Beinen. Eine Frau in roter Latzhose mit zwei Beuteln in der Hand führt Selbstgespräche. Wir teilen ein Lächeln.

Mit 30 Leuten irren wir zum Maracana Rodizio. Hier haben wir 20 Plätze reserviert. Und kein Stuhl mehr frei. Die Gruppe schrumpft leider.
Es gibt Caipirinha und leckere Vorspeisen, dann rennen Kellner um die Tische und schälen Fleisch auf unsere Teller. Alle halbe Stunde schlängeln Tänzerinnen zu ohrenbetäubend lauter Musik an der Theke entlang. Ich fliehe hinaus.

Gegen 22 Uhr zum Hotel zurück, schwatzen, noch einen Tee und Mitternacht ins Bett. Ich schlafe schlecht, ab 5 fechten die vielen scharf gewürzten Fleischstücke in meinem Magen einen Krieg aus.

7:45 Uhr Frühstück allein. Bis 10 fallen alle anderen aus ihren Betten, Gruppenfoto, Abfahrt. Die Tour zurück klappt reibungslos, allein Nicks iPhone nimmt sich eine Wärmepause.
Kurz nach der Heimkehr bringt mein Bruder den Kater zurück, und sobald ich den original brasilianischen Tinnitus überwunden habe, kann ich die Stille genießen.

Ich wollte noch eine Kundin treffen, die dort wohnt, hätte gerne mehr von der Stadt gesehen, vor allem von den Antiquariaten.
Aber ich war schon bis zum Anschlag überreizt. Ich brauche öfter mal Pause, muß die Ideen wegschreiben, die sich unentwegt in mir auftürmen, Ruhe finden. Und ich kann das endlich auch. Manchmal.

Andere haben das WordCamp kritisiert. Manche haben einfach nur geschimpft. Es kommt wohl darauf an, was man erwartet. Ich bin zufrieden.

Alle Fotos hat Alexander Frison (Xtreme Theme) geschossen. Danke! Mehr Bilder gibt es in seinem Artikel zum WordCamp.

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/ 19 http://toscho.de/2011/wordpress-umleitung-upgrade-php-beheben/ http://toscho.de/2011/wordpress-umleitung-upgrade-php-beheben/#comments Thu, 24 Feb 2011 07:30:58 +0000 Thomas Scholz http://toscho.de/?p=1784 Eben habe ich ein Blog auf Version 3.1 aktualisiert. Danach wurde ich immer auf wp-admin/upgrade.php?_wp_http_referer=%2Fwp-admin%2Findex.php umgeleitet, wenn ich auf den Link zum Dashboard – /wp-admin/index.php – geklickt habe.
Ein direkter Aufruf der Adresse /wp-admin/ (ohne index.php) hingegen klappte problemlos.

Eine kurze Suche im Quellcode ergab den Auslöser: In der /wp-admin/admin.php steht eine Abfrage, ob die Datenbank aktualisiert wurde. Steht der Wert db_upgraded in der Optionstabelle nicht auf FALSE, so wird die Umleitung erzeugt, die dann eigentlich den Wert nach dem ersten Aufruf korrekt setzen sollte. Warum das nicht klappt, kann ich noch nicht sagen, aber die Lösung liegt jetzt auf der Hand:

1. Rufe /wp-admin/options.php auf. Diese URL mußt du vermutlich per Hand eingeben.
2. Suche nach dem Eintrag db_upgraded und setze eine 0 (Null) hinein.
3. Drücke auf »Änderungen übernehmen«. Fertig.
]]> http://toscho.de/2011/wordpress-umleitung-upgrade-php-beheben/feed/ 6 http://toscho.de/2011/wordpress-plugin-magische-widgets/ http://toscho.de/2011/wordpress-plugin-magische-widgets/#comments Wed, 05 Jan 2011 14:19:56 +0000 Thomas Scholz http://toscho.de/?p=1768 Download auf wordpress.org

Neulich stand ich vor einem spannenden Problem: Ein Freund wollte eine Zeile JavaScript und einen Link auf ein Stylesheet in den Header seines Themes bringen. Dieses Theme stammt aus dem Verzeichnis auf wordpress.org, und es sollte weiterhin automatisch aktualisiert werden. Ich konnte also nicht direkt hineinschreiben.
Nun hätte ich ein Child-Theme anlegen können, aber das fand ich dann etwas zu umständlich. Obendrein wäre das eine Speziallösung gewesen, und ich bin nun einmal Generalist.
Ich wollte eine Lösung, die ich wiederverwenden kann. Und ihr vielleicht auch.

Zeit für einen kleinen Zaubertrick.

Das Konzept

Im Kopfteil eines jeden Themes, das auf wordpress.org zugelassen wird, finden wir die Funktion wp_head. Diese löst eine gleichnamige Aktion aus. Wenn wir uns in diese Aktion einklinken, können wir tun, was immer uns beliebt. Zum Beispiel Text ausgeben.

Als Plugin wäre das ein Vierzeiler:

<?php
/* Plugin Name: Simple Head Insert */
add_action( 'wp_head', 'simple_head_insert' );
function simple_head_insert() { echo '<!-- Buh! -->'; }

Ganz nett, aber irgendwie … nicht gut genug. Es ist immer noch zu speziell, weil die Ausgabe fest im PHP-Code steht. Wenn die Ausgabe oder die Position geändert werden soll, muß das Plugin umgeschrieben werden. Das ist sehr fehleranfällig.

Jemand anderes möchte vielleicht Code im Backend einfügen. Der muß sich das Plugin im Grunde selbst neu schreiben.

Also habe ich mir gedacht: Dann hänge ich doch einfach an die Aktion widgets_init eine Funktion, die eine Instanz einer Klasse erzeugt, die für die Aktionen wp_head, wp_footer, admin_head und admin_footer eine weitere Funktion registriert, die wiederum den Inhalt einer ebenfalls registrierten Sidebar ausgibt, die man frei mit einem Widget befüllen kann, das ich in eine weiteren Klasse gepackt habe.

Klarsoweit?

Nicht? Dann kannst du dir den Code auf GitHub ansehen und herunterladen. Für die Eingabe des HTML-Codes habe ich eine einfachere Variante des nativen Text-Widgets geschrieben; sie heißt Unfiltered Text Widget.

150 Zeilen mehr als die erste Version, dafür um so mächtiger. Frank wird mich sicher noch ermahnen, daß ich doch eine Sprachdatei einarbeiten sollte. Keine Lust. Insgesamt finde ich den Code immer noch angenehm einfach und enorm flexibel zugleich. Ich bin ausnahmsweise und sicher nur für kurze Zeit mal zufrieden damit.

Einsatz

Jetzt wollen wir uns noch ansehen, wie man das verdammte Ding benutzt.

Zunächst laden wir es herunter, packen es ins Pluginverzeichnis und aktivieren es. Ja, sehr spannend.



Jetzt gehen wir auf »Design/Widgets«, und da haben wir vier neue Sidebars und ein neues Widget namens »Unfiltered Text«.



Wir klappen zur Probe mal die Box für den »Front End Header« auf und ziehen das neue Widget hinein. Das können wir übrigens überall benutzen, auch in anderen Sidebars.

In das Eingabefeld schreiben wir ein Script:

<script>alert('Buh!');</script>



Und dann rufen wir das Frontend unserer Website auf:



Faaaantastisch! Jetzt kann uns nichts mehr bremsen.

• In den Footer des Frontends können wir den Tracking-Code des Analyse-Tools unserer Wahl eingeben – und schon geht das Gezähle los.
• In den Header des Backends können wir schreiben:

  <style>#footer{display:none}</style>

  Und – zack! – ist der Footer weg.

• Wir können den JavaScript-Code des Plugins Icon to Link einbauen.
• Wer so richtig Spaß haben will, schreibt sich dies in beide Header:

  <style>body{display:none}</style>

Für weitere kreative Ideen und die obligatorischen … Verbesserungsvorschläge stehen euch die Kommentare offen.

Anpassen

Für Hacker habe ich zwei Filter eingebaut, die eine Kombination des Plugins mit dem eigenen Theme erlauben:

1. 'magic_widgets_actions' übergibt einen Array mit den Aktionen. Den können wir per Filter in der functions.php frei ändern:

   add_filter( 'magic_widgets_actions', 'change_magic_widget_actions', 10, 1 );
   function change_magic_widget_actions( $arr )
   {
       // Add
       $arr['loop_start'] = 'Post List Start';
       // Remove
       unset( $arr['admin_footer'] );
       // Rename
       $arr['admin_head'] = 'HTML-Kopf Administration';
       return $arr;
   }

   Mehr Aktionen findet ihr im Codex, bei Adam R Brown und auf der-design.com.

   Ich habe mich auf die vier oben genannten Aktionen beschränkt, um die Widgetliste im Backend übersichtlich zu halten. Im Prinzip können wir aber auch 40 oder 400 Aktionen ansprechen.

2. Den Namen Unfiltered Text können wir über den Filter 'magic_widgets_name' ändern (I18n für Arme!).

Fehlt was? Funktioniert alles?

Weitere Artikel dazu hier im Blog

• WordPress-Tutorial: Ein Framebreaker-Plugin schreiben
• WordPress-Tutorial: Eigenes Widget schreiben
• WordPress: Parallele Widgets
• WordPress-Plugin: Backend Style Enhancements
]]> http://toscho.de/2011/wordpress-plugin-magische-widgets/feed/ 17 http://toscho.de/2010/wordpress-plugin-icon-to-link/ http://toscho.de/2010/wordpress-plugin-icon-to-link/#comments Tue, 28 Dec 2010 17:39:07 +0000 Thomas Scholz http://toscho.de/?p=1759 Die Icons über dem Editor in WordPress sparen zwar Platz, verstanden werden sie leider nicht immer. Müde dieser Art Support habe ich kleines Plugin verzapft, das aus den Icons klassische Textlinks macht: Plugin Icon to Link auf GitHub.

So wirkt es:


Und das ist der gegenwärtige alte Code, den man im Archiv herunterladen kann:

<?php
/*
Plugin Name: Icon to Link
Plugin URI: http://toscho.de/2010/wordpress-plugin-icon-to-link/
Description: Changes upload icons in the edit screen into text links.
Version: 0.3
Author: Thomas Scholz
Author URI: http://toscho.de
*/

add_action( 'admin_head', 'itb_change' );
function itb_change()
{   ?>
<script type="text/javascript">jQuery(document).ready(function($){
    $('a#add_image').text( '<?php _e('Image'); ?>' );
    $('a#add_video').text( '<?php _e('Video'); ?>' );
    $('a#add_audio').text( '<?php _e('Audio'); ?>' );
    $('a#add_media').text( '<?php _ex('File', 'column name' ); ?>' );
});</script>
    <?php
}

Auf zwei Details sei hingewiesen: Dazu braucht man kein jQuery. Aber da es ohnehin geladen wird, habe ich es um der Kürze gleich verwendet.
Und der Text File wird seltsamerweise nicht übersetzt, obwohl er genau so in der Sprachdatei steht. Das finde ich noch heraus …
File wird nur ersetzt, wenn man den passenden Kontext angibt, hier column name.

Update 29.12.

Ich habe das Javascript jetzt in eine separate Datei ausgelagert, einen Filter für die Namen eingebaut und sichergestellt, daß der Code nur auf Seiten mit einem Editor und dort erst am Seitenende geladen wird.

PHP-Code

<?php
/*
Plugin Name: Icon to Link
Plugin URI: http://toscho.de/2010/wordpress-plugin-icon-to-link/
Description: Changes upload icons in the edit screen into text links.
Version: 0.4
Author: Thomas Scholz
Author URI: http://toscho.de
*/

add_action( 'admin_init', 'itb_change' );
function itb_change()
{
    // Load the script on editor pages only.
    if ( empty ( $GLOBALS['pagenow'] )
        or ! ( 'post.php' == $GLOBALS['pagenow']
            or 'post-new.php' == $GLOBALS['pagenow'] )
    )
    {
        return;
    }

    $handle  = 'icon-to-links';

    wp_register_script( $handle, plugins_url( 'itl.js', __FILE__ ), 'jquery', '0.4', TRUE );
    wp_enqueue_script( $handle );

    // Localize
    $text = array (
        'image' => __( 'Image' )
    ,   'video' => __( 'Video' )
    ,   'audio' => __( 'Audio' )
    ,   'file'  => _x( 'File', 'column name' )
    );
    // To change the names, add a filter for 'itl_names'.
    $text = apply_filters( 'itl_names', $text );
    wp_localize_script( $handle, 'i2l', $text );

    return;
}

/**
 * Sample filter:

add_filter( 'itl_names', 'change_itl_names', 10, 1 );
function change_itl_names( $names )
{
    $names['image'] = 'Foto';
    return $names;
}

*/

Javascript (itl.js)

jQuery(document).ready(function($){
    $('a#add_image').text( i2l.image );
    $('a#add_video').text( i2l.video );
    $('a#add_audio').text( i2l.audio );
    $('a#add_media').text( i2l.file  );
});

]]> http://toscho.de/2010/wordpress-plugin-icon-to-link/feed/ 10 http://toscho.de/2010/wordpress-plugin-germanix/ http://toscho.de/2010/wordpress-plugin-germanix/#comments Sun, 19 Dec 2010 14:07:28 +0000 Thomas Scholz http://toscho.de/?p=1753

Nicht neu, aber bisher ungebloggt: Das Plugin Germanix wandelt Umlaute und viele andere Nicht-ASCII-Zeichen in einen passenden Ersatz um und erstellt daraus Permalinks und Dateinamen. Es ersetzt das längst nicht mehr gepflegte Plugin o42-clean-umlauts.

Germanix schlägt zu, wenn man eine Datei hochlädt oder einen Artikel anlegt. Bei neuen Schlagwörtern, Kategorien, eigenen Taxonomien und Post-Typen natürlich auch.

Ein Beispiel: Einem Artikel mit dem schönen Titel »12 m³ Scheiße« gibt WordPress ohne weitere Plugins den Slug 12-m³-scheise. Jetzt haben wir ohne Not ein Nicht-ASCII-Zeichen darin, und ein entstelltes ß.

Germanix hingegen produziert 12-m3-scheisse. Das paßt besser.

Das Plugin besteht eigentlich aus zweien: Germanix URL für URLs und Dateinamen und Germanix Translate für Übersetzungen im Backend. Beide Plugins lassen sich separat anschalten. Das Übersetzungsplugin werde ich vermutlich irgendwann fallen lassen – außer der Umwandlung von »Dashboard« nach »Übersicht« brennt darin nichts; manche Einträge sind sogar veraltet.

Fehler und Vorschläge wirf bitte in den Bugtracker. Da finde ich sie wieder.
Oder besser noch: Erstelle einen Fork, baue deine Ideen selber ein und sende einen Push-Request zurück.

Solange das Plugin nur bei GitHub liegt und ich keinen eigenen Updateserver eingerichtet habe, wird es keine automatische Aktualisierung geben, nur Hinweise per Twitter. Sorry!

Ich habe neulich ein anderes Plugin – Remove Redundant Links – testhalber im offiziellen Verzeichnis abgelegt und bin schon jetzt so genervt von SVN, daß ich auf weitere Experimente damit wenig Lust verspüre. Ja, git-svn kenne ich. Das nervt auch.
Schließlich geht es mir bei solchen Projekten auch um den Spaß an der Sache, also nicht um SVN.

Momentan wird der Windows-Livewriter noch nicht unterstützt. Wer das braucht, dem empfehle ich Frank Bültges Alternative. Die erfaßt weniger Zeichen und wird im Sprachverzeichnis abgelegt, wo sie sich nicht so einfach abschalten läßt wie ein Plugin. Dafür wandelt sie auch maskierte Zeichen um – das habe ich bisher weder gebraucht noch geschafft.

Weitere WordPress-Plugins

• Magische Widgets
• Icon to Link
• Backend Style Enhancements
• Canonical Permalink
• Tutorial: Ein Framebreaker-Plugin schreiben
• Basic Settings
• Remove Redundant Links
]]> http://toscho.de/2010/wordpress-plugin-germanix/feed/ 51 http://toscho.de/2010/wordpress-internet-explorer-ohne-css-hacks-ansprechen/ http://toscho.de/2010/wordpress-internet-explorer-ohne-css-hacks-ansprechen/#comments Tue, 28 Sep 2010 07:43:50 +0000 Thomas Scholz http://toscho.de/?p=1731 Den Internet Explorer betrachten die meisten Webentwickler zu Recht als chronische Krankheit. Neben anderen Browsern sieht auch die kommende Version 9 eher bedrückend aus. Ehe wir diesem Browser keine Extrawurst mehr braten müssen, wird noch viel Zeit vergehen.

Um den IE im Stylesheet gesondert anzusprechen, brauchen wir weder Hacks im CSS noch eine zusätzliche Datei oder gar (pfui!) eine serverseitige Browserweiche. Wir müssen nur das Element <html> über Conditional Comments anpassen. Diese Idee hatte Paul Irish schon 2008.

Ich habe das neulich in einem WordPress-Theme eingesetzt und mag es so sehr, daß ich künftig all meine Themes damit ausrüsten werde.
Ein wenig umständlich: Die Sprachattribute werden in WordPress mit der Funktion language_attributes() erzeugt – und die hat ein fest eingebautes echo, das man nicht abschalten kann. Ich will nun nicht drei Meter Code in der header.php stehen haben, deshalb habe ich mir zwei kleine Funktionen gebaut. Die Funktion get_language_attributes() ist obendrein etwas schlanker als das Original, und sie gibt das Attribut dir nur aus, wenn der Text von rechts nach links läuft. Andernfalls ist es an dieser Stelle überflüssig.

Doch zum Code, er gehört in die functions.php:

<?php
/**
 * html5 start tag + language attribute + conditional tags for IE Win
 * @link   http://paulirish.com/?p=88
 * @param  bool $print
 * @return void|string
 */
function htmlstart($print = TRUE)
{
    $out  = '<!Doctype html>';
    $lang = get_language_attributes();
    $ies  = array (
        6 => 'lte6 lte7 lte8'
    ,   7 => 'lte7 lte8'
    ,   8 => 'lte8'
    ,   9 => ''
    );

    foreach ( $ies as $n => $class )
    {
        $out .= "<!--[if IE $n]><html $lang class='ie ie$n $class lte9'><![endif]-->";
    }

    $out .= "<!--[if !IE]><!--><html $lang><!--<![endif]-->";

    if ( ! $print )
    {
        return $out;
    }

    print $out;
}

if ( ! function_exists('get_language_attributes') )
{
    /**
     * Returns the language attributes.
     *
     * Unobstrusive copy from the core.
     * Requires WP 3.0+
     *
     * @param string $doctype The type of html document (xhtml|html).
     */
    function get_language_attributes($doctype = 'html') {
        $output = is_rtl() ? 'dir="rtl"' : '';

        if ( $lang = get_bloginfo('language') )
        {
            $output .= ( ( get_option('html_type') != 'text/html'
                || $doctype == 'xhtml' )
                ? ' xml:' : '') . 'lang="' . $lang . '"';
        }

        return apply_filters('language_attributes', $output);
    }
}

Im Theme rufen wir die Funktion dort auf, wo früher die Doctype-Deklaration und das Start-Tag standen.
Die Ausgabe sieht (hier aufgehübscht) etwa so aus:

<!Doctype html>
<!--[if IE 6]>
    <html lang="de-DE" class='ie ie6 lte6 lte7 lte8 lte9'>
<![endif]-->
<!--[if IE 7]>
    <html lang="de-DE" class='ie ie7 lte7 lte8 lte9'>
<![endif]-->
<!--[if IE 8]>
    <html lang="de-DE" class='ie ie8 lte8 lte9'>
<![endif]-->
<!--[if IE 9]>
    <html lang="de-DE" class='ie ie9 lte9'>
<![endif]-->
<!--[if !IE]><!-->
    <html lang="de-DE">
<!--<![endif]-->

Nein, das ist kein sehr schönes Markup mehr. Aber so richtig schlimmes auch nicht. Obendrein validiert es.

Im Stylesheet können wir den Internet Explorer jetzt ganz einfach mit der passenden Klasse ansprechen:

.ie8
{
    top:        10px;
}
.lte7
{
    top:        15px;
}

Das kann ich mir viel besser merken als Kommentarhacks oder Spielereien mit ungültigen Selektoren und Eigenschaften.

Mehrere Internet Explorer auf einem Windows kann man sich mit der Utilo IE Collection einrichten. Zum Testen der Conditional Comments habe ich im Labor eine kleine Seite eingerichtet: CC-Test.

]]> http://toscho.de/2010/wordpress-internet-explorer-ohne-css-hacks-ansprechen/feed/ 14