Das WordPress-Backend ab Version 3.8 verbessern

Wordpress-LogoMit Einführung der Version 3.8 haben die Entwickler das Admin-Backend des beliebten CMS WordPress grundsätzlich überarbeitet. Während sie von „moderner“ und „stylisher“ reden, stellt man umgehend fest, dass hauptsächlich Platz verschwendet wird. Was der Gelegenheitsnutzer vermutlich nicht für sonderlich maßgeblich hält, führt bei jemandem, der ständig WordPress-Seiten nutzt, zu deutlichen Störungen beim Workflow, weil man insbesondere auf kleinen Bildschirmen mehr scrollen muss. Nicht jeder arbeitet mit Retina-Displays. Wer den alten Look zurück haben möchte, oder zumindest etwas, das dem ähnelt, dem kann geholfen werden.

Schritt eins: In den Benutzeroptionen das Farbschema auf „hell“ stellen, damit sind die für mich störenden Kontraste zwischen Menü und Inhalt schon mal weg.

Schritt zwei: Installation des Plugins „Admin Classic Borders“. Damit kann man nicht nur wie der Name suggeriert dem Adminmenü wieder Trennlinien verpassen, sondern auch relativ einfach Einfluss auf die CSS-Stile nehmen. Die Einstellungen sind weitestgehend selbsterklärend und da diese zudem auch sofort in der Seitenleiste zu sehen sind, kann man experimentieren.

Schritt drei: besonders interessant ist die Option, eigene CSS-Formate fürs Backend vergeben zu können. Das könnte man auch in einem separaten Stylesheet tun, mit Hilfe dieses Plugins ist das allerdings deutlich einfacher zu pflegen. Meine CSS-Definitionen folgen, ich habe sowohl die Menüschriften- und Abstände verringert, als auch die Schriftgrößen der Inhalte des Backends. ich gehe nicht davon aus, dass meine Styles jeden glücklich machen, aber sie stellen eine Basis zum Experimentieren dar.

Ich jedenfalls bin jetzt mit dem WordPress-Backend wieder glücklich. Bis zur nächsten überflüssigen Designänderung durch die Entwickler.

acb
acb2

#adminmenu a.menu-top, #adminmenu .wp-submenu-head {
    font-size: 13px;
    line-height: 13px;
}
#adminmenu li.menu-top {
    min-height: 28px;
}
#adminmenu .wp-has-current-submenu ul > li > a, .folded #adminmenu li.menu-top .wp-submenu > li > a {
    padding: 3px 12px;
}
#adminmenu .wp-submenu a {
  line-heigt:0.9em;
  font-size: 13px;
}
#adminmenu .wp-not-current-submenu li > a, .folded #adminmenu .wp-has-current-submenu li > a {
  padding-top: 2px;
}
ul.categorychecklist li {
    line-height: 16px;
}
textarea, input, select {
    font-size: 13px;
    line-height: 1.2em;
}
.form-table, .form-table td, .form-table th, .form-table td p, .form-wrap label {
    font-size: 13px;
}
.widefat td, .widefat td p, .widefat td ol, .widefat td ul {
    font-size: 12px;
    line-height: 1.2em;
}
h2 .nav-tab {
    padding: 5px 8px;
    font-weight: 600;
    font-size: 14px;
    line-height: 20px;
}
.wrap h2 {
    font-size: 20px;
    line-height: 22px;
}
td.plugin-title strong {
  font-size: 12px !important;
}

Logo WordPress Copyright Automattic

WordPress 3.5: Semmelstatz-Ausgabe bricht nach Referern ab

Wordpress-LogoNachdem ich zwei weniger aufwendig konfigurierte Blogs auf WordPress 3.5 aktualisiert hatte, musste ich feststellen, dass die Ausgabe des Statistik-Plugins „Semmelstatz“ nach der Ausgabe der Referer-Liste abbrach. Da ich an Semmelstatz hänge und kein anderes Statistik-Plugin eine derartige Übersicht liefert (auch wenn manche die Zahlen anzweifeln, aber dazu am Ende mehr), machte ich mich auf die Suche nach dem Fehler. Denn der ursprüngliche Entwickler Andreas „Redunzl“ Müller hatte die Arbeit an dem Plugin lange eingestellt, es war zwar von weiteren Personen übernommen worden, aber auch da hat sich seit 2011 nichts mehr getan. Also selbst Hand anlegen.

Da keine Fehlermeldungen geworfen wurden, ein Blick in den generierten Quellcode nichts ergab und auch Firebug in der Konsole keine Fehler meldete, machte ich mich auf die Suche nach möglichen Lösungsansätzen im Web. Und tatsächlich: offenbar sind etliche der mySQL-Abfragen sehr unoptimiert und können dazu führen, dass zuviel Speicher verbraucht wird. Dann wird das PHP-Speicherlimit überschritten. Bei mir liegt das bei 128 MB, bei manch einem Hoster deutlich darunter, deswegen ist das Problem bei anderen auch früher schon aufgetreten, bei mir erst mit der Installation von WordPress 3.5.

Auf der Suche nach einem offensichtlichen Fehler fiel mir auf, dass die Datenbankabfragen tatsächlich … na sagen wir mal … ineffektiv sind, weil viel mehr Daten abgerufen werden, als es nötig wäre. Und das, obwohl in den Einstellungen sogar Limits gesetzt werden können. Nur werden die dann in der eigentlichen mySQL-Query gar nicht verwendet. Ich fand in semmelstatz-statz.php in der Funktion sem_showKeyword():

$limit = $sem_options["statz_keyword_limit"];    
$results = $wpdb->get_results("SELECT referer, time, ip FROM $wpdb->statz 
WHERE referer != 'NULL' ORDER BY time DESC");

Da wird zwar das Limit aus der Konfiguration abgefragt, aber in der mySQL-Query nicht angewendet – und damit wird eine Menge überflüssiger Informationen aus der Statz-Datenbank geholt. Deswegen die Abfrage um ein Limit ergänzt:

$limit = $sem_options["statz_keyword_limit"];
$limit1 = $limit;    
$results = $wpdb->get_results("SELECT referer, time, ip FROM $wpdb->statz 
WHERE referer != 'NULL' ORDER BY time DESC LIMIT 0, $limit");

Daraufhin wurden mir allerdings nicht wie in der Konfig eingestellt zwanzig, sondern nur noch drei Suchbegriffe angezeigt, keine Ahnung, warum. Eine kleine Erhöhung des Limits brachte dann aber den gewünschten Erfolg:

$limit = $sem_options["statz_keyword_limit"];
$limit1 = $limit * 6;    
$results = $wpdb->get_results("SELECT referer, time, ip FROM $wpdb->statz 
WHERE referer != 'NULL' ORDER BY time DESC LIMIT 0, $limit1");

Und schon wurde wieder alles wie gehabt angezeigt:

suchbegriffe

Ein geändertes Plugin-Archiv hängt unten an (selbstverständlich alles ohne Gewähr und ohne Garantie auf Fehlerfreiheit, deswegen vor dem Einspielen: Backup. Bei mir klappts).

Noch eine Anmerkung zu den Zahlen, die Semmelstatz generiert. Ja, im Vergleich mit anderen Statistiklösungen sind die zu hoch. ich hatte aber mal einen Test gestartet, in deren Rahmen ich mehrfach unter verschiedenen IP-Adressen und mit verschiedenen Browsern von unterschiedlichen rEchnern zugegriffen habe. Google Analytics und Piwik haben nicht alle Zugriffe davon gezählt. Semmel schon. Von daher würde ich davon ausgehen, dass die Wahrheit irgendwo dazwischen Liegt, Mulder. Als Tagesüberblick über Besucher, Referer, Suchwörter und beliebte Posts bleibt Semmelstatz ein durchaus hilfreiches Plugin.

Ich gehe davon aus, dass weitere Optimierungen der mySQL-Abfragen möglich sind. Wenn ich Zeit habe, kümmere ich mich mal drum.

Download: Semmelstatz 3.3.2mod

WordPress-Logo Copyright Automattic

WordPress: Artikel im Frontend bearbeiten mit dem Plugin „Front-end Editor“

Ich hatte mich immer wieder darüber geärgert, dass ich erst umständlich den RichText-Editor in WordPress aufrufen muss, um kleinere Änderungen an WordPress-Artikeln vorzunehmen, beispielsweise zur Korrektur von Tipp- oder Flüchtigkeitsfehlern. Nun ahnte ich bereits, dass es Frontend-Editoren gibt, aber gerade habe ich eine Auswahl gesichtet und dann – endlich – einen davon installiert. Ich hätte es schon lange so einfach haben können …

Scribus und Jotschis Plugin trägt den simplen Namen „Front-end Editor„. Der besondere Charme daran ist, dass es den Aloha-Editor verwendet, der es ermöglicht, in fast beliebigen Webseiten Änderungen vorzunehmen.

Nach der installation sieht man im Frontend links neben der Mausposition einen Edit-Button, der immer dann auftaucht, wenn man sich über einem editierbaren Inhalt befindet. Das kann der Titel des Artikels sein, aber selbstverständlich auch der Text, weiterhin kann man auch Änderungen an Tags und Kategorien sowie weiteren Artikelparametern vornehmen.

Durch die Verwendung des Aloha-Editors editiert man im Artikel, der weiterhin in seinem üblichen durch CSS festgelegten Design angezeigt wird, also echtes WYSIWYG – grandios! Durch die Einblendung der Steuerkonsole des Editors hat man die Möglichkeit, Formatierungen vorzunehmen. Nach Fertigstellen der Änderungen klickt man einfach auf OK – oder auf „Abbrechen“ wenn man es sich anders überlegt hat.

Als Fazit muss man sagen, dass das Plugin Front-end Editor ein unverzichtbares Werkzeug für WordPress-Nutzer darstellt, denn damit ist es schnell und einfach möglich „mal eben“ Änderungen in Artikeln vornehmen zu können, ohne erst den vollständigen Richtext-Editor im Backend aufrufen zu müssen. Ich weiß gar nicht mehr, wie ich ohne das Plugin auskommen konnte, denn es erleichtert die Arbeit mit WordPress immens!

Man findet das Plugin auf WordPress.org

Screenshots von PhantaNews.de von mir, das gezeigte Bild von Terry Prat­chett (2007) von Mo­ro­bo­shi, aus Wi­ki­me­dia Com­mons, CC-BY,

Workaround für WPML-Darstellungsfehler im Admin-Backend

Im vorangegangenen Artikel habe ich mich über den nicht zufriedenstellenden Support im Zusammenhang mit dem Lokalisierungs-Plugin WPML geäußert. Inzwischen hat sich der Support dann doch nochmal gemeldet, die angebotene Lösung ist aber nicht wirklich akzeptabel. Vorgeschlagen wurde, dass ich „eine CSS-Datei in wp-admin/css“ anpassen solle. Welche Datei das sein sollte, darüber schwieg man sich aus, dabei ist es nicht so, als wären die bei jeder WP-Installation anders.

Zudem ist es sicherlich nicht sinnvoll, Änderungen an den WordPress-Core-Dateien vorzunehmen. Warum nicht ist einfach zu verstehen: beim nächsten Update werden diese wieder überschrieben.

Nochmal das Problem: Der Sprachwähler wird von Backend-Überschriften überlappt:

Ich habe deswegen einen Workaround umgesetzt und als Plugin programmiert. Auf diese Weise ist gesichert, dass das nächste Update die Änderung nicht überschreibt. Sollte man bei WPML das Problem irgendwann beseitigen und neue Versionen des Lokalisierungs-Plugins zur Verfügung stellen, kann der Nutzer mein Plugin einfach deaktivieren.

Um das simpel zu halten, wurde die Position des Sprachwählers ganz oben im Backend fix auf 500 Pixel von links gesetzt. Damit sollte sichergestellt sein, dass auch längere Seitentitel den Sprachwähler ebenso wenig überlappen wie die Optionsbuttons der jeweiligen Seiten.

Zur Installation das Plugin einfach über die WordPress-Plugin-Administration installieren (oder lokal entpacken und per FTP hochladen) und aktivieren. Sollte ab WP 3.1 funktionieren. Mir ist klar, dass man das elaborierter ausführen könnte, beispielsweise eine Option zur manuellen Angabe des X-Werts liefern, aber das ist wie geschrieben erstmal ein schneller Fix und Workaround. Eigentlich sollten die Damen und Herren von WPML das Problem durch eine aktualisierte Fassung ihres Plugins lösen.

Download: imagcon-wpml-fix.zip (ca. 1kB)

WordPress mehrsprachig mit WPML: Support Fehlanzeige?

Aktuell setze ich eine mehrsprachige Webseite unter WordPress um. Als Standard-Plugin zur Lokalisierung wird allenthalben WMPL benutzt, deswegen wurde das auch für dieses Projekt ausgewählt.

Leider kommt es dabei zu Problemen. Im Backend wird ein Dropdown zum Auswählen der Sprache nicht korrekt angezeigt, es überlappt browserunabhängig mit dem Seitentitel – hier mal zwei Demos:

Normalerweise würde ich das nicht als problematisch ansehen: einfach die zugehörigen CSS-Klassen ändern, ein paar Abstände anpassen und gut ist. Doch leider ist das bei WPML nicht möglich, da aus nicht nachvollziehbaren Gründen CSS-Stile direkt am Element vergeben werden, ich müsste also in die Dateien des Plugins eingreifen, um das zu ändern – und das tue ich selbstverständlich nicht, denn beim nächsten Update würden diese Änderungen wieder überschrieben.

Als zahlender Kunde (immerhin legt man für das Plugin nichtvirtuelle 79 Euro auf den virtuellen Tisch) sollte man Support erhalten, und so wandte ich mich vor über einer Woche an diesen, nur leider lässt der erheblich zu wünschen übrig. Der Supporter möchte Admin-Zugriff auf die WP-Installation (bitte?), weiß aber offensichtlich noch nicht einmal, dass man sich via wp-login.php an WordPress anmelden kann; eine klare Reaktion und Hinweise zur Beseitigung oder eine neue fehlerbereinigte Version fehlen trotz zur Verfügung gestellter Informationen und Adminzugang bis heute.

Nachdem der englische Support offenbar nichts taugt, hatte ich die Idee mich stattdessen mal an den deutschen zu wenden, immerhin liegt die WPML-Seite auch in deutscher Sprache vor. Leider verweist der Support-Link dort auf das englische Forum. Fail.

Für mich als Fazit: nach einem anderen Multilanguage-Plugin suchen und WPML zukünftig nicht mehr verwenden.

WordPress 3.3 – warum einfach, wenn’s auch kompliziert geht

Als Automattics Blogsoftware WordPress noch auf den Versionen eins und zwei herumdümpelte, habe ich auf die harte Tour eins ganz eindeutig gelernt: eine neue Version niemals sofort einspielen, sondern erst einmal warten, was sie diesmal verbockt haben. Ich motze ja nun eigentlich gegen meine eigene Zunft, aber leider sollten die Entwickler hin und wieder darüber nachdenken, womit man täglich als User konfrontiert ist, und dass scheinbar kleinere Änderungen am Bedienkonzept mit „nur einem oder zwei Klicks mehr“, zu einem unbequemeren und nervigeren Workflow führen.

Vollmundig wird für WordPress 3.3 reklamiert, dass man den RichText-Editor nun auch mit dem iPad nutzen kann. Dass allerdings durch die veränderte Funktion des Admin-Menüs im Backend die Nutzung mit einem solchen Gerät zum Masochismus gerät, möchte man lieber verschweigen.

Die Submenüpunkte des Adminmenüs sind nicht mehr ausklappbar, die sind nun über ein sogenanntes „Flyout“ realisiert. Sobald man mit dem Mauszeiger darüber fährt, klappen sie aus. Und was ist, wenn ich keinen Mauszeiger habe? Als Lösung wurde vorgeschlagen, man möge auf den jeweiligen Link klicken, dann könne man die Menüpunkte ja sehen. Dass dafür die Seite neu geladen werden muss, interessiert bei Automattic offenbar niemanden. Dass man versuchen kann, „ganz kurz“ zu tippen, um auf dem iPad das Flyout doch zu sehen, wurde als Tipp erst später nachgereicht, hilft aber auch nicht wirklich weiter, weil auch das eben ein völlig überflüssiger Klick mehr ist.

Die Adminbar, die man auch im Frontend sehen kann, wurde deutlich verkleinert. Das macht insbesondere unter kleinen Bildschirmauflösungen zwar Sinn, aber auch hier wurde etwas weggelassen, nämlich der direkte Link zum Dashboard, den man nun nur noch über ein Flyout-Menü erreicht. Das ist sogar auf herkömmlichen, nicht mobilen Browsern lästig.

Fragwürdig auch die Änderung im Dateihandling. Als großer Fortschritt wird seitens Automattic zum einen gepriesen, dass es keine unterschiedlichen Knöpfe zum Hochladen verschiedener Dateitypen mehr gibt, sondern nur noch einen (dem ist auch so, ob das jetzt besser ist als vorher muss bezweifelt werden). Weiterhin freut man sich dort über Drag & Drop zum Upload von Dateien. Leider ist das Drag&Drop-Feld so groß, dass man nun auf alle Fälle scrollen muss, wo man bislang effektiv und ohne Scrollen arbeiten konnte.

Im Moment kann ich von einem Update auf das ergonomisch verschlimmbesserte WordPress nur dringend abraten und anregen erst einmal lokal zu testen, ob man mit den „Verbesserungen“ leben kann.

Dass die Rückmeldungen insbesondere zum Menü offenbar nicht allzu positiv sind, sieht man allein daran, dass einer der Entwickler (Aaron Campbell) zwar vehement verteidigt, was da gemacht wurde, aber gleichzeitig vorsichtshalber mal ein Plugin bereit stellt, um die Ausklapp-Funktionalität des Adminmenüs wieder herzustellen.

WordPress muss meiner Ansicht nach somit dringend für Nachbesserungen nochmal zurück in die Werkstatt. Ob es irgendwelche Probleme mit Plugins gibt (wovon ich ausgehe) ist dabei sogar noch unberücksichtigt.

Nachtrag: von der behaupteten Unterstützung des iPads beim Verfassen von Content merke ich übrigens nichts – keine Spur vom RichText-Editor…

Artikel waren nicht einsehbar

Wer zwischen Sonntagabend und heute diese Seite besucht hat, der durfte leider feststellen, dass man zwar auf der Startseite alle Artikel sehen konnte, die Artikeleinzelansicht jedoch nur eine leere Seite mit Hintergrundgrafik präsentierte. Leider ist mir das gerade erst aufgefallen.

Der Übeltäter war das Plugin „Fix Facebook Like“, das normalerweise Probleme mit der Einbindung des Like-Buttons beseitigen sollte (Optimierung von weitergeleitetem Bild und verwendetem Text), stattdessen aber einen Fehler warf, da es eine nicht vorhandene WordPress-Funktion aufrief. Zwar gab es heute ein Update für das Plugin, das beseitigt das Problem aber nicht.

Plugin deaktiviert, jetzt klappt wieder alles. Ich bitte den Fehler zu entschuldigen.

Das Thematic Framework

Wenn neue Themes für WordPress erstellen möchte, stößt man früher oder später auf Frameworks, die einem die Arbeit erleichtern sollen, indem sie ein Gerüst vorgeben, in dessen Rahmen man dann agiert – und das man zudem auf möglichst einfache Art und Weise erweitern kann.

Bereits für das bei diesem Blog vorliegende Template hatte ich Thematic benutzt, allerdings war das nur eine vergleichsweise „kleine“ Umsetzung. Für eins meiner anderen Blogs sollte nun endlich mal ein Theme her, das (unter anderem) vier Voraussetzungen erfüllen sollte:

  1. vollständig selbst erstellt statt nur angepasst
  2. Anzeige der Beiträge eines Custom Post Types über ein eigenes Menü
  3. Widgetpositionen nach meinem Gusto
  4. flexible Sidebar mit einer und zwei Spalten

Weiterlesen

WordPress: „Forgot The Category“ für Custom Post Types

Ich erweitere gerade ein relativ umfangreiches Blog um einen Custom Post Type, um neben News auch Artikel darstellen und beide Beitragsvarianten unabhängig voneinander layouten zu können. Zudem wollte ich für die Artikel nicht die Standardkategorien nutzen, sondern neue Taxonomien.

Die Einrichtung des entsprechenden Custom Post Type war mit dem Plugin „Custom Post Type UI“ ein Kinderspiel (die Erstellung des Themes unter Einbindung der CPTs ist es nicht, aber dazu ein andermal).

Beim Test stieß ich dann allerdings auf ein unerwartetes Problem: ich habe das Plugin „Forgot The Category“ installiert, das mich darauf hinweist, eine Kategorie anzugeben, was ich schonmal vergessen hatte und das ist ärgerlich, wenn man es nicht merkt. Mit den bereits vorhandenen Beiträgen klappt das ohne Probleme, nur bei der selbst eingerichteten Taxonomie für den CPT zickte das Plugin und bemängelte nicht gewählte Kategorien.

Ein schneller Blick ins Plugin und via Firebug in den Quellcode der Kategorie-Box im WP-Backend zeigte mir schnell, wo das Problem lag, aber auch wie die Lösung auszusehen hatte:

Der Quelltext des Plugins (Auszug):

class DC_ForgotTheCategory {
  function AddToEditPage() {
    
  }
}

add_action("edit_form_advanced", array("DC_ForgotTheCategory", "AddToEditPage"));

In Zeile fünf entdeckt man den jQuery-Selektor

ul#categorychecklist

das Element mit der ID #categorychecklist gibt es allerdings in der Liste der Custom Taxonomy nicht. Der Quelltext zeigte mir aber dass dasselbe UL-Element auch eine Klasse namens

.categorychecklist

besaß und die war auch in der Liste der selbsterstellen Taxonomie vorhanden. Der Rest war einfach, Zeile fünf musste nur in

if ( jQuery("ul.categorychecklist input:checkbox:checked").length < 1 ) {

geändert werden (Raute gegen Punkt austauschen), und schon wurden korrekt mit einem Haken versehene Taxonomie-Begriffe nicht mehr bemängelt.

Quicktipp: WordPress 3.1 – Adminbar deaktivieren

Persönlich halte ich die neue Adminbar, die WordPress seit der Version 3.1 bietet, ja für ein sehr nützliches neues Feature, andere scheinen aber nicht so glücklich damit zu sein.

Man kann sie aber relativ einfach deaktivieren – entweder in der functions.php:

if (!is_admin() && !current_user_can('add_users')){
	wp_deregister_script( 'admin-bar' );
	wp_deregister_style( 'admin-bar' );
	remove_action('wp_footer','wp_admin_bar_render',1000);
}

Oder in der header.php, hier gehört der Code vor <?php wp_head() ?>

if (!current_user_can('add_users')){
        wp_deregister_script( 'admin-bar' );
        wp_deregister_style( 'admin-bar' );
        remove_action('wp_footer','wp_admin_bar_render',1000);
}

Eigentlich wäre es sinnvoll, wenn das via Option im Backend geschehen könnte, ich würde mal vermuten wollen, dass das aufgrund der geübten Kritik an diesem neuen Feature bald implementiert werden wird