Für Menschen · Seien Sie begeistert und Sie werden begeistern !
Mit der kommenden Version von WordPress 2.7 verändert sich das Menu in die verticale, damit stehen dem Autor aber weitere Möglichkeiten offen, die schon in einigen Beiträgen Erwähnung fanden. In diesem Beitrag möchte ich aber Plugin-Autoren ansprechen und sie bitten, macht eure Plugins bedienerfreundlicher – nur zwei kleine Möglichkeiten möchte ich zeigen; diese zeigen aber, in welchem Detail es liegen kann. Die Möglichkeiten wurden schon mehrfach in der WP-Hacker-Mailing-List besprochen und so gut wie alle sehen es als Mehrwert.
![]()
Im ersten Fall möchte ich zeigen, wie man das Menu um ein Icon erweitern kann. Dies kann zu Mehrwert im Sinne von Übersichtlichkeit führen bzw. ist es auch ein Hingucker für die Nutzer, der Menu-Link ist augenscheinlicher. Ich verwende zum Einbau des kleinen Icon nicht den Verweis auf die Datei, sondern lege das Icon base64-codiert im Code des Plugins ab. Das sparrt eine Datei, geschweige denn einen Ordner und den Zugriff, so dass ein request gespart wird.
Um eine Datei in den Code zu wandeln, habe ich einen kleinen Service eingerichtet, wer sich also nichts selber bauen will, kann diesen gern nutzen – Image2Base64 Generator.
Das Icon wird nur ab Version 2.7 von WordPress integriert, dass prüfe ich mit einer einfachen Abfrage der Version. Weitere Infos habe ich am Code hinterlegt.
/**
* Images/ Icons in base64-encoding
* @use function fb_sayfa_sayac_get_resource_url() for display
*/
if( isset($_GET['resource']) && !empty($_GET['resource'])) {
# base64 encoding
$resources = array(
'ssprc.gif' =>
'R0lGODlhCwALAKIEANTU1Kurq/b29pSUlP///wAAAAAAAAAAAC'.
'H5BAEAAAQALAAAAAALAAsAAAMlSKoRMysGIZ50A1RJ3ybNow3f'.
'VJGoQo4nRJDdpwqjtcDy/dhLAgA7'.
'');
if(array_key_exists($_GET['resource'], $resources)) {
$content = base64_decode($resources[ $_GET['resource'] ]);
$lastMod = filemtime(__FILE__);
$client = ( isset($_SERVER['HTTP_IF_MODIFIED_SINCE']) ? $_SERVER['HTTP_IF_MODIFIED_SINCE'] : false );
// Checking if the client is validating his cache and if it is current.
if (isset($client) && (strtotime($client) == $lastMod)) {
// Client's cache IS current, so we just respond '304 Not Modified'.
header('Last-Modified: '.gmdate('D, d M Y H:i:s', $lastMod).' GMT', true, 304);
exit;
} else {
// Image not cached or cache outdated, we respond '200 OK' and output the image.
header('Last-Modified: '.gmdate('D, d M Y H:i:s', $lastMod).' GMT', true, 200);
header('Content-Length: '.strlen($content));
header('Content-Type: image/' . substr(strrchr($_GET['resource'], '.'), 1) );
echo $content;
exit;
}
}
}
/**
* Display Images/ Icons in base64-encoding
* @return $resourceID
*/
function fb_sayfa_sayac_get_resource_url($resourceID) {
return trailingslashit( get_bloginfo('url') ) . '?resource=' . $resourceID;
}
/**
* add menu in backend
*/
function fb_sayfa_sayac_add_menu() {
global $wp_version;
if ( current_user_can('edit_posts') && function_exists('add_submenu_page') ) {
$menutitle = '';
if ( version_compare( $wp_version, '2.6.999', '>' ) ) {
$menutitle = '<img src="' . wpag_get_resource_url('ssprc.gif') . '" alt="" />' . ' ';
}
$menutitle .= __('Post Read Counter', 'sayfasayacprc');
add_submenu_page('index.php', __('Sayfa Sayac - Post Read Counter', 'sayfasayacprc'), $menutitle, 9, __FILE__, 'fb_sayfa_sayac_statistic');
$plugin = plugin_basename(__FILE__);
add_filter( 'plugin_action_links_' . $plugin, 'fb_sayfa_sayac_plugin_actions' );
}
}
Den img-Tag erweitere ich um ein Leerzeichen, damit es nicht direkt am Menutext klebt. Man könnte das auch über eine CSS-Definition machen, aber das wäre dann in den meisten Fällen wohl ein Inline-Style. Dieser bringt unnötig Code, eine Unsauberkeit und schlechtere Performance in das Backend. Bei den Entwicklern von WordPress habe ich das schon länger angesprochen, eventuell bekommen wir die CSS-Definition noch im Styte zu 2.7.

den obigen Code genauer angeschaut hat, der wird schon den Zugriff auf den Filter plugin_action_links bemerkt haben. Diese nutze ich um auf der Plugin-Seite einen Absprung einzuhängen. Dieser erleichtert den Absprung in die Einstellungen oder den Datenbereich, wie hier im Beispiel. Ich denke, dass man damit dem Nutzer die Benutzung vereinfacht - kein Suchen, wo befindet sich nun der Bereich. Der Screenshot zeigt es schon, dass ich bei meinen Plugins immer den Settings-Link links der beiden Standard-Links Deaktivieren und Bearbeiten, wenn die Rechte der Datei das zulassen, integriere.
/**
* Adds an action link to the plugins page
*/
function fb_sayfa_sayac_plugin_actions($links) {
$settings_link = '<a href="sayfa_sayac_de.php">' . __('Settings') . '</a>';
array_unshift( $links, $settings_link );
return $links;
}
Die obigen Funktion läuft nur ab WordPress 2.7 und wurde von Latz näher vorgestellt! Möchte man abwärts kompatibel sein, dann geht es etwas umständlicher.
/**
* Adds an action link to the plugins page
*/
function fb_sayfa_sayac_plugin_actions($links, $file){
static $this_plugin;
if( !$this_plugin ) $this_plugin = plugin_basename(__FILE__);
if( $file == $this_plugin ){
$settings_link = '<a href="index.php?page=sayfa_sayac/sayfa_sayac_de.php">' . __('Settings') . '</a>';
$links = array_merge( array($settings_link), $links); // before other links
}
return $links;
}
Nutzt man diese etwas unübersichtliche Form, dann muss der Filter anders eingebunden werden, in meinem Beispiel in der Funktion fb_sayfa_sayac_add_menu() ist zu tauschen
$plugin = plugin_basename(__FILE__);
add_filter( 'plugin_action_links_' . $plugin, 'fb_sayfa_sayac_plugin_actions' );
in
add_filter( 'plugin_action_links', 'fb_sayfa_sayac_plugin_actions', 10, 2 );
Über den Hook admin_menu aktivere ich die beiden anderen Hooks. Im Vorfeld frage ich aber ab, ob man sich auch im Admin befindet, so dass nur dann der Code Beachtung findet.
/* Register WordPress hooks */
if ( is_admin() ) {
add_action('admin_menu', 'fb_sayfa_sayac_add_menu');
}
Ich denke, dass die diese beiden Möglichkeiten einen Mehrwert darstellen und schon eine ganze Reihe von Plugins haben diese Funktion, andere werden in naher Zukunft ein Update bekommen. Vielen Nutzer bestätigen mir das und mögen vor allem den schnellen Absprung im Plugin-Bereich. Ideen, Lob und Kritiken – wie immer steht die Kommentarfunktion offen und freut sich über Meinungen.
händischer Spam:
Beachte die Kommentarregeln, jede Form von versuchtem Spam wird gelöscht. Warum und wieso steht in einem meiner Beiträge.
Bezug auf Textstellen:
Du kannst direkt bezug auf Textstellen im Beitrag nehmen. Dazu muss lediglich der Bereich im Artikel markiert werden; daraufhin erscheint ein Button, der den markierten Text in das Kommentarfeld übernimmt und als Zitat auszeichnet. Die Funktion ist nur bei aktivem JavaScript nutzbar.
xHTML:
Du kannst folgende Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <pre> <em> <strong> <strike> <ul> <ul> <li>
Achte darauf, wenn du Code im Kommentar hinterlegen willst, dann muss der Code maskiert sein. Dann wird er nicht interpretiert. Der Code muss mit Hilfe von HTML-Entities dargestellt werden, d.h. dass man z.B. < als < und > als > einfügt.
E-Mail-Benachrichtigung bei neuen Kommentaren ?
Wenn der Haken in der Checkbox gesetzt ist, dann wirst du über neue Kommentare vie E-Mail informiert. Der Versand erfolgt nur, wenn du die URL in der Bestätigungs-E-Mail genutzt hast oder schon Abonnent hier im Blog bist.
Kommentar erscheint nicht:
Alle Kommentare werden manuell geprüft, freigegeben und nach Möglichkeit beantwortet. Bitte um etwas Geduld und Nachsicht.
Identifikationsbilder (Avatare):
Auf Gravatar.com kann man sich mit seiner E-Mail-Adresse registrieren und ein Bild hochladen, dann erscheint dieses Gravatar hier und in vielen weiteren Blogs.
Spamschutz:
Das Kommentarformular ist mit einem Spamschutz ausgerüstet. Solltest du diesen Artikel ohne JavaScript besuchen und kommentieren wollen, so muss du die Frage beantworten und das jeweilige Wort in das Textfeld eingeben.
bueltge.de [by:ltge.de] wird von Frank Bültge geführt, administriert und gestaltet. Alle Inhalte sind persönlich von mir ausgewählt und erstellt, nach bestem Gewissen und Können, was die Möglichkeit von Fehlern nicht ausschließt.
Das Weblog wird angetrieben von WordPress und aktuell gibt es 971 Beiträge, 19448 Kommentare in 14 Kategorien und 459 Tags.
Das Blog wird liebevoll mit xHTML & CSS in Handarbeit gestaltet. Erstellt mit ♥ zum Befüllen und Erhalten.
Design und Code ist unter Copyright
© 2001 - 2012 bueltge.de [by:ltge.de]
2. November 2008 um 12:22
Du sprichst da etwas an, worüber ich mir schon bissle Gedanken gemacht habe.
Dein Plugin Feedstats hast du ja im Dashboard angesiedelt, aber leider gibt es Plugins wie "wp-poll", "cforms" usw die unbedingt sofort im Hauptmenü zu sehen sein müssen - kann man das nachträglich ändern?
Oder vielleicht von den WP Entwicklern einschränken lassen?
lg
Jared
2. November 2008 um 13:41
Mit dem bas64 gefällt mir schon. Ich habe zwar nur kleine Plugins gemacht.. Arbeite aber gerade an einem Etwas besseren Plugin. Ich werde dann Settings und ein base64 Bild machen
Ich finde es super, dass du einen Pic->Base64 generator gemacht hast. Kann ich bald gerauchen
Gleichmal als Favort speichern...
2. November 2008 um 14:12
@Jared: man kann es eigentlich nur ändern, in dem man in den Code des Plugins eingreift. Man kann es auch ändern, in dem man die Variable $menu verändert, ist aber ziemlich verbogen. Dem Plugin-Autor bleibt überlassen, wo er es einhängt und wie optional er/sie das macht. Daher ist auch dieser Artikel entstanden - es gibt sehr viele gute Entwickler, aber sie machen sich wenig Gedanken über Usability und machen das Plugin in der Regel explizit für einen Fall. Wenn man nur wenige Einstellungen hat, dann will ich sogar dazu übergehen, dass man keine eigene Seite mehr für Einstellungen hat, sondern dass man am Plugin auf der Plugin-Seite per JS die Felder bekommt. Oft braucht man ja die Felder nie wieder und wozu das Menu unnötig ausweiten. Aber dazu ein andermal mehr.
2. November 2008 um 18:36
Abend Frank.
Ich beziehe mich auf diesen Satz:
Richtig.
Stimmt.
Das sehe ich anders. Der durch den IMG-Tag erzeugte Request ist immer da: In den meisten Fällen fragt der Browser beim Server nach dem File. Ob der Server die angeforderte Datei zurückgibt und mit 200 antwortet oder lediglich per Not Modified kommuniziert ist nebensächlich. Die in PHP implementierte Base64-Lösung für grafische Elemente ist wirklich nur dafür da, um nur mit einer einzigen PHP-Datei mehrere Elemente verwalten und ausliefern zu können.
Ohne einen Server-Request kommt die elegante Lösung mit CSS, wo ebenfalls kodierte Quellen der Grafiken als SRC hinterlegt sind. Aber auch die neuste Version des verbreitesten Browser kann diese Methode nicht interpretieren.
2. November 2008 um 19:47
@Sergej: da muss ich leider widersprechen, Steve Souders verweist in seinen Analysen zu besserer Performance auf das data:URL-Schema, welches hier zum Einsatz kommt. Er weist darauf hin, dass man damit Bilder aufrufen kann, ohne einen http-Request zu nutzen. Die CSS-Lösung ist ebenfalls dem gleich zu setzen.
2. November 2008 um 20:18
Aber ich meine, die Abfrage für den zurück gesendeten Header ist ja nicht umsonst da: Würden keine Anfragen seitens Browser kommen, wozu dann die Abfrage, wenn sowieso kein Request aus dem Client? Und noch eine Tatsache: Woher soll der Browser denn wissen, was er an der Stelle der Grafik anzeigen soll, ohne eine Anfrage an den Server bzw. den PHP-Script zu stellen - der Source im IMG-Tag verweist den Client auf den Server und das ist für ihn (den Browser) auch das Ausschlaggebende?
Die CSS-Lösung bedarf keinen Request, da base64 direkt im Code eingebaut ist.
Aber wenn Steve Souders das irgendwie anhand der Beispiele belegen kann, dann bin ich natürlich still.
2. November 2008 um 20:36
Hier mal ein Link zum Schema: data:URL Auf der Website von Steve Souders habe ich nichts gefunden, er publiziert das ja immer via Yahoo. In seinem Buch ist es etwas ausführlicher.
2. November 2008 um 22:10
Die Seite kenne ich
Ich könnte dir eine russische Seite empfehlen, die sich intensiv mit dem Thema auseinandersetzt.
Aber dein Beispiel oben werde ich mal morgen austesten
Schönen Abend noch, Frank.
2. November 2008 um 22:41
Im Grunde leuchtet es mir schon ein, denn es ist ja wie bei CSS, es ist schon da und muss nur geladen werden (vereinfacht und kurz).
* Mein Russisch ist nicht so toll, auch wenn ich es auf einigen Reisen und auch nochmal im Abi versucht habe.
3. November 2008 um 11:52
Frank, also ich habe jetzt deinen Code nachgebaut (damit es auch außerhalb von WP funktioniert) und es genauso wie ich sagte: Der Browser stellt mindestens einen Request zum Server, um die Grafik abzuholen (Firebug ist mein Zeuge). Je nach dem, ob der Browser mit dem Cache was anfangen kann und wie effizient die Cache-Vorgaben des Severs genutzt werden, kann es unter Umständen auch bei jeder Darstellung der Grafik zu einem Request kommen.
Das kann der Browser auch nicht anders, denn im IMG SRC steht ein Pfad der Quelle, dem der Client folgen muss, es sei denn, er holt die Datei aus dem internen Cache raus, was bei PHP-Dateien nicht zwingend ist (ist ja in deinem Beispiel eine, der Name der GIF-Datei ist lediglich ein Parameter).
Summa summarum: Die vorgestellte Lösung spart keine Requests, kann jedoch mehrere Grafiken im Plugin unterbringen.
3. November 2008 um 12:54
Vielen Dank! Kannst du denn ansonsten einen Merhwert für Plugin sehen bzw. wirst du Settings o.ä. in deine Plugins einbauen?
3. November 2008 um 13:00
Frank, du hattest mir den Code für Settings ja schon mal geschickt, diesen hatte ich in all meine Plugins (wpSEO, wpSALE usw.) eingebunden. Die Icons werden sicherlich auch kommen...
3. November 2008 um 13:08
ah, vergessen
Wunderbar, denn ich finde den Mehrwert sehr hoch.
3. November 2008 um 21:56
grundsätzliche frage:
sind denn alle plugins weg, wenn ich auf eine höhere wordpress-version update?
3. November 2008 um 22:12
@meistermochi: nein, sie bleiben erhalten
5. November 2008 um 08:24
Das Beispiel werde ich gleich jetzt mal austesten. Ich bin mit der neuen Version aber rundum zufrieden!
5. November 2008 um 10:12
Die Idee mit Abspeichern von Bilddaten als kodierte Strings finde ich eine schöne Lösung. Das mit dem Request kann ich so auch bestätigen. Der springende Punkt ist hier einfach wie das ganze Aufgebaut ist. Wenn Du einen weiteren Request verhindern möchtest, dann muss Du die Daten kodiert Inplace einbauen:
<img src="data:image/gif;base64,R0lGODlhCwALAKIEANTU1Kurq/b29pSUlP///wAAAAAAAAAAACH5BAEAAAQALAAAAAALAAsAAAMlSKoRMysGIZ50A1RJ3ybNow3fVJGoQo4nRJDdpwqjtcDy/dhLAgA7" alt="Red dot" />
Damit hast Du deinen Mehrwert in Bezug auf einen Request weniger absolut erreicht.
5. November 2008 um 10:27
@Fabian
Das würde ich nicht machen, es sei du hast deine IE6- & IE7-Nutzer nicht lieb.
5. November 2008 um 12:55
Jap, das ist sicher bekannt, aber eventuell leiden die IE-User dann noch mehr
5. November 2008 um 12:59
Hehe, wenn wir in die Richtung gehen wollen, dann lass es uns richtig professionell angehen und WordPress komplett für IE-Nutzer ausschließen
5. November 2008 um 15:08
Danke für den "Absprung im Plugin-Bereich". Wollte ich sowieso einbauen und ich muss mir jetzt nicht alles selbst zusammensuchen
.
5. November 2008 um 19:27
Nein, ich bin eher für das Gegenteil - aber meine Sicht ist so, dass es in IE und dem Rest der Browser nicht gleich sein muss. Die Nutzbarkeit leidet ja nicht, wenn das Icon entfällt. Aber dazu nutze ich zu viel WP in prof. Umfeld und da führt kein Weg am IE vorbei.
6. November 2008 um 12:40
6. November 2008 um 12:45
Absprung im Plugin-Bereich: Mit Version 2.7 gibt es auch eine einfachere Version, um den Link zu generieren: <a href="Absprung im Plugin-Bereich: Mit Version 2.7 gibt es auch eine einfachere Version, um den Link zu generieren:
Absprung im Plugin-Bereich v2.7.
6. November 2008 um 12:58
@Latz: habe ich bei dir gelesen, und schon getestet und implementiert, Artikel geupdatet - Danke!
6. November 2008 um 16:12
eine sehr nützliche funktion wäre ein button, mit dem man direkt den cache leeren kann, ohne ins backend gehen zu müssen. (in verbindung mit dem plugin wp-cache) ist echt doof, wenn man ständig den cache leeren muss und immer so einen aufwendigen weg gehen muss.
6. November 2008 um 16:34
@harald: das ist in meiner Version schon drin, leider konnte ich den Code noch nicht so bereinigen, dass ich es frei geben kann. Ich habe einen Link im Footer, der also daher von überall Zugriff hat und einen im Favoritenmenu der kommmenden WP 2.7, alles optional.
7. November 2008 um 13:35
jaaaaaaaaaa, so einen will ich auch haben. ich veränder ständig etwas an der wordpress-site und es nervt, wenn der cache da immer dazwischen kommt. wie komm ich an den code?
7. November 2008 um 16:26
@harald: ich bin am bauen
7. November 2008 um 17:27
Frank, was du machst, ist ja mal eine super Sache.
11. November 2008 um 15:22
Heißt bestimmt läuft.
Danke für diesen Artikel.
11. November 2008 um 20:50
@ocean90: danke, gefixt
20. November 2008 um 13:02
Wie schaut das aber bei Plugins aus, die gerade ein Top-Level Menü ( Untermenüs) haben? Mit der obigen Funktion bleibt das generische Icon im Toplevel erhalten (bei Verwendung von add_menu_page()) und nur das erste Untermenü (im Prinzip also der gleiche Link, den auch das Top-Level Menü-Icon hat) wird mit dem Icon versehen. Was übersehe ich?
21. November 2008 um 10:45
@fym: ja, du übersiehst einen Parameter, mal ein einfaches Beispiel:
add_menu_page( __('TEST'), __('test'), 9, __FILE__, 'test', '/test.jpg' );Der letzte paramter kann den Pfad zum Icon enthalten. Dieser kann natürlich auch via Base64URL gemacht werden. Dies nur auf die schnelle. Wenn ich Zeit finde, dann schreibe ich eventuell noch einen Artikel. Nun mal alle Parameter:
Ich hoffe, dass es hilft.
21. November 2008 um 15:12
@Frank: In der Zwischenzeit hatte ich es dann doch noch gefunden. Kaum fragt man&hellip und so
Nichtsdestotrotz danke für die Antwort