WordPress Plugins bereichern

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.

Kommentare

  
  1. Jared sagt:

    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

    • @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. Ahmet Topal sagt:

    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...

  3. Abend Frank.

    Ich beziehe mich auf diesen Satz:

    Das sparrt eine Datei, geschweige denn einen Ordner und den Zugriff, so dass ein request gespart wird.

    Das sparrt eine Datei

    Richtig.

    einen Ordner

    Stimmt.

    ein request gespart wird

    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.

    • @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.

  4. 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.

  5. 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.

    • 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.

  6. 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.

  7. 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...

  8. meistermochi sagt:

    grundsätzliche frage:

    sind denn alle plugins weg, wenn ich auf eine höhere wordpress-version update?

  9. Tatjana sagt:

    Das Beispiel werde ich gleich jetzt mal austesten. Ich bin mit der neuen Version aber rundum zufrieden!

  10. Fabian von Allmen sagt:

    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.

  11. @Fabian
    Das würde ich nicht machen, es sei du hast deine IE6- & IE7-Nutzer nicht lieb.

  12. Hehe, wenn wir in die Richtung gehen wollen, dann lass es uns richtig professionell angehen und WordPress komplett für IE-Nutzer ausschließen :)

    • 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.

  13. Latz sagt:

    Danke für den "Absprung im Plugin-Bereich". Wollte ich sowieso einbauen und ich muss mir jetzt nicht alles selbst zusammensuchen ;-) .

  14. Latz sagt:

    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.

  15. harald sagt:

    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.

    • @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.

  16. harald sagt:

    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? ;-)

  17. Marion sagt:

    Frank, was du machst, ist ja mal eine super Sache.

  18. ocean90 sagt:

    Die obigen Funktion lüft nur ab WordPress 2.7

    Heißt bestimmt läuft. ;)
    Danke für diesen Artikel. :)

  19. fym sagt:

    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?

    • @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:

      add_menu_page( $page_title, $menu_title, $access_level, $file, $function = '', $icon_url = '' )
      

      Ich hoffe, dass es hilft.

  20. fym sagt:

    @Frank: In der Zwischenzeit hatte ich es dann doch noch gefunden. Kaum fragt man&hellip und so ;) Nichtsdestotrotz danke für die Antwort :)

Trackbacks

  1. [...] Bültge beschreibt in seinem Posting „WordPress Plugins bereichern“ beschrieben, wie man die Bedienungsfreundlichkeit seines Plugins steigern kann, indem man [...]

© 2013, since 2005 bueltge.de [by:ltge.de] · Theme is built by ThemeShift