Schneller soll alles werden. Performance ist wichtiger denn je. Nicht nur, weil die Suchmaschine Google es so mag, sondern weil jeder iPhone /Smartphone Nutzer dann dein Freund wird.

Wer braucht solche Plugin Performance Tests

• a) Otto Normaluser, der keinen eignen Server hat und sich nicht auskennt.
• b) Developer, die WP Plugins für ihre Kunden einsetzen. => da kann man Wissen voraussetzen.
• c) Plugin Entwickler, damit sie ihr Plugin im Vergleich sehen => die kennen sich sicher aus (na hoff ich jedenfalls).
• d) Plugin Entwickler, die Performance Tests Plugin anbieten => Verkausstrategie Nr 1 veröffentliche Tests.

Daher sind Plugin Performance Tests nicht grade unwichtig. Nun gibts da einen auf dev4press.com.

Absolut zufällig verkauft Milan ein Performance Test Plugin – GD Press Tools => er fällt damit unter Pkt “d” meiner Aufzählung==> er mag verkaufen.

Das ist legitim. Doch sein Test löst bei mir nur Fragezeichen im Kopf aus.

Fragen an den Plugin Performance Test

Plugin Performance Test – Ausschnitt der Testergebnisse

1. Wieso wird ein Plugin im Frontend bewertet, wenn es nur im Adminbereich wirkt?
2. Woher kommen die “Grade” Bewertungen => welches Mittelmaß nehmen die?
3. Wieso sind Plugin, die absolut unterschiedliche Messwerte haben mit dem gleichen “Grade” bewertet?

Wenn schon ich diese Fragen habe, wie hat sie dann erst jemand, der unter Pkt a meiner Aufzählung fällt=> also Otto Normaluser, der sich nicht auskennt?

Da steht ein Plugin Performance Test, der damit endet, dass Milan alle Plugin Entwickler aufruft, seine Performance Regeln nachzulesen, das ist sehr nett und gut gemeint => ich rufe Milan auf: ändere Deine Testangaben, damit man sich auskennt, akut ist dieser Test einfach ein großes “fail” für mich.

Oder bin ich grippig verschnupft wirklich zu doof diesen Test richtig zu lesen?

Ich freu mich über “Übersetzungen” und Aufklärungen, weil akut steh ich da wie der Ochs vorm neuen Tor….

Das Plugin Custom Field Suite von Matt Gibbs ist wirklich eine “Suite”. Man kann benutzerdefinierte Felder für jeden post_type extra erstellen. Ob für Artikel, für Seiten, Taxonomie oder custom_post_type. Alle können sie ihre eigenen benutzerdefinierten Felder erhalten. Ganz einfach gebündelt und somit leicht administrierbar.

Matt beschreibt sein Plugin so:

Custom Field Suite (CFS) is a plugin for creating, managing, and displaying custom fields.
Matt

welche benutzerdefinierten Felder kann dieses Plugin erstellen und was bieten diese

1. Text (api returns text) => Textefeld
2. Textarea (api returns text with
   ) => Texteingabefeld => Trennt mit einem <br />
3. Wysiwyg Editor (api returns html) => der macht 2 Felder (this is a feature )
4. Date (api returns text) => Datumsmaske
5. True / False (api returns boolean) =>RadioButton, wenn angeklickt, dann mache dies, wenn nicht dann mache das…
6. Select (api returns array of values) => Auswahlfelder => Dropwdown
7. Relationship (api returns array of post objects) => hier werden alle Post Type Artikel aufgeführt, die vorher ausgewählt wurde und dann kann man mit anklicken eines Artikels bestimmen wo diese Felder erscheinen.
8. File Upload (api returns file url) => die URL des Anhanges wird geliefert
9. Loop (repeatable fields!) => damit kann man benutzerdefinierte Felder “wiederholen”. mehrere Uploads, mehrere Namen etc, etc…. quasi custom fields on the fly

Aktivierung und Benutzung

Download auf wordpress.org Custom Field Suite.

Nach der Aktivierung findest Du unter Admincenter/Dashboard==> Einstellungen ==> Custom Field Suite.
Auf der rechten Seite kann man jedwede Einstellung wie einen Artikel “veröffentlichen”.

Dokumentation => wie bau ich das in ein Template ein

Übersicht über das Plugin: uproot.us.
Benutzungshinweise gibts in der Dokumentation. Herrlich übersichtlich, wie ich find.

Und ein Screencast über die Benutzung des Feldes “relationship”. Screencast Relationship.

Support von Matt im wordpress.org Forum

Matt bemüht sich alle Probleme, Fragen wirklich so rasch als möglich zu beantworten, helfen.

Wer Matt aka logikal16 auf Twitter folgen mag, der findet ihn hier: logikal16

weitersagen ausdrücklich erwünscht und wars hilfreich freu ich mich über ein +1

Mit Post Admin Shortcuts kannst Du Artikel/Seiten und Custom Post Types “on the fly” ans linke Dashboard Menü und an die Dashboard Übersicht pinnen. Wann ist das sinnvoll: wenn Du Veröffentlichtes ändern magst und nicht immer danach suchen.

Anwendungen für Post Admin Shortcuts

1.
Ich habe zb vor hier auf der Texto.de alte Artikel – nach denen aber oft gesucht wird- inhaltlich zu erneuern. Prinzipiell einigte ich mich mit mir , dass ich dies nach den vergebenen Tags angehe. Dennoch muss ich die Artikel ständig suchen. Tag aufrufen, Artikel durchforsten, => kaum bin ich dann auf der Artikelübersichtsseite läutet das Telefon und alles ist anders….

Mit dem Plugin Post Admin Shortcuts kann ich mir diese Artikel ganz einfach an die Dashboard Pinwand kleben und ich habe mehr Übersicht. Habe ich mehr Übersicht besteht eher die Chance, dass ich mein Vorhaben auch realisiere.

2.
Für Kunden: Man kann damit die Impressums, Datenschutzerklärungsseite anpinnen, damit sie der Kunde oder man selbst auch nicht vergisst.

Unabhängig davon, dass ich niemand empfehl das Impressum und die Datenschutzerklärung “inhaltlich” für den Kunden auszufüllen=> das ist rechtlich risikoreich.

Was kann Post Admin Shortcuts

Intuitive interface to ‘pin’ posts from the post listing page
Works with posts, pages and any cutom post types
Just as easy to ‘unpin’ posts
pin/unpin changes are made in realtime via AJAX calls so no need to refresh the page

Plugin Autor Bradvin

so siehts am Dashboard dann aus:

Download: Post Admin Shortcuts.

• Herunterladen, entpacken, hochladen, aktivieren => nutzen
• oder via interner Pluginsuche sich holen.

Demo was das Plugin kann und macht: Demo Post Admin Shortcuts.

Wo Du Post Admin Shortcuts nicht einsetzen kannst:

Es kann keine Userberechtigungen. Du kannst nirgends einstellen Autor sieht dies, Editor sieht das und Redakteur sieht jenes… .
Es ist -soweit ich in Erfahrung brachte nicht MultiSite fähig.

Lorelle machte mich über G+ auf dieses kleine feine Plugin aufmerksam.

Ein neues WP-Plugin für den Adminbereich habe ich heut getestet Filter Pages by parent in admin. Es ist so neu, dass es bis jetzt grad mal 14 Downloads hat

Hat man viele statische Seiten und noch mehr Unterseiten geht der Überblick im Adminbereich=>Seiten sehr oft rasch verloren.

Das Plugin bietet eine neue Auswahl bei der Filterung an: “Show only children of:” also “zeige nur die Unterseiten von”..an.

Es heißt: Filter Pages by parent in admin. Geschrieben wurde es von James Irving-Swift und Electric Studio (wobei ich hoff, dass der Mann nicht wirklich so heißt…)

Nutzung des Plugins Filter Pages by parent in admin

• Herunterladen, entpacken, hochladen, aktivieren
• oder via Admin installieren.

Ab dann siehst Du bei Dashboard=>Seiten=> die neue Filtermöglichkeit “Show only children of:”.

Ach ja, gestetet habe ich es mit einem NightlyBuilt von WP 3.3.

Google eröffnete am 15.09.2011 einen neuen Umgang der Suchmaschine mit Pagination/Weiterblättern. Stichworte dazu: rel=prev, rel=next.

Ich erkläre hier in diesem Artikel das bisherige Problem mit Pagination und Suchergebnissen.
Wie Google es nun für sich gelöst hat.
Wieso dies dennoch derzeit keine Lösung für WP ist -also wieso es sinnvoll ist die rel=next und rel=prev Links aus dem WP Header zu verbannen – und wie es geht .

Pagination /Weiterblättern / Seite 1 von 86 /vorherige Seite/nächste Seite erreicht man in WordPress mit:

• <!- – nextpage- – >
• next_posts_link
• previous_posts_link
• oder diversen Plugins

Und es geht um Linkbeziehungsangaben im html Header: also um die Links die ein link rel=”" im html haben.

Pagination und die Suchmaschine Google bisher

Seit “ewigst” gibt es massive Probleme bei Googles Suchergebnissen, wenn man eine Kategorie oder eine einzelne Seite oder einen Artikel in mehrere Seiten aufgeteilt hat. Google bemängelt die gleiche meta description in den Webmastertools, Google zeigt in den Suchergebnissen zu einem irr hohen Prozentsatz immer nur die 1.Seite an, grad bei Kategorieübersichten und hat man einen einzelnen Artikel aufgeteilt ignorierte dies Google komplett -ja galt lange Zeit sogar als dublicat content, weil der ja anhand des Inhaltes einer “html” Seite gemessen wird und nicht nur vom geschriebenen Artikel abhängt.

am 15.09.2011 verkündet Google rel=prev rel=next

Google erkannte selbst, dass bei einer Kategorie die 2te Seite genauso sinnvoll für den Suchenden sein kann wie die Erste. Vor allem in online Shops etc. Weil sie das Suchverhalten von Google Nutzer bis ins kleinste Detail ständig erforschen.

Nun implementierte Google die korrekten html header Angaben rel=next und rel=prev in das Programm seines Suchbots. Siehe: Google Webmasterzentrale.

Damit Google richtig erkennt ob man bei einer Kategorie auf der 1. oder 56 Seite ist und welche die vorherige oder nächste Seite ist, sollte nun um html Header:

Kategorie Hauptseite:

rel=next => Verweis auf /kategoriehauptseite/page/2/

ist man auf der /kategoriehauptseite/page/2/ sollte im html Header stehen:

rel=prev /kategoriehauptseite/
rel=next /kategoriehauptseite/page/3/

ist man auf der letzten paginierten Seite sollte logischerweise kein rel=next erscheinen.

Kann dies WordPress 3.2.1

Kürzeste Antwort: NEIN => so nicht.

WordPress bietet im html header rel=next und rel=prev, aber sehr eingeschränkt und manchmal “ein bisschen eigenartig”.
Mein Schelm und Schalk meint diesbezüglich: dies passiert, wenn Programmierer mit html Semantik konfrontiert werden.

Nachdem ich ungern etwas behaupte ohne einen Beweis zeig ich nun auf was WP im html Header liefert, wenn man

index_rel_link, adjacent_posts_rel_link und parent_post_rel_link nicht in der functions.php aussperrt.
Manche sperren dies ja aus, weil sie glauben die Angaben rel=next und rel=prev seien ein Sicherheitsrisiko , dabei sind dies absolut korrekte html Angaben.

Ich wiederum sperre diese Angaben aus, weil sie semantisch nicht korrekt und nicht vollständig umgesetzt sind => derzeit.

index_rel_link

zeigt immer:

Magst Du nicht, dass dies automatisch durch wp_head im html Header erscheint, dann füge in die functions.php deines Themes folgendes ein:

remove_action( 'wp_head', 'index_rel_link' ); // index link

adjacent_posts_rel_link

Zeigt einfach die Beziehung eines Artikels rel=next oder rel=prev in zeitlicher Reihenfolge an.

Magst Du nicht, dass dies automatisch durch wp_head im html Header erscheint, dann füge in die functions.php deines Themes folgendes ein:

remove_action( 'wp_head', 'adjacent_posts_rel_link', 10, 0 ); // Display relational links for the posts adjacent to the current post.

start_post_rel_link

Zeigt schlicht und ergreifend rel=prev zum allerersten Artikel Deiner WP Installation, dies ist zu 99% “Hallo Welt”.

Magst Du nicht, dass dies automatisch durch wp_head im html Header erscheint, dann füge in die functions.php deines Themes folgendes ein:

remove_action( 'wp_head', 'start_post_rel_link', 10, 0 ); // start link

parent_post_rel_link

Erscheint im html Header bei statischen Seiten.
Und unter d) sieht man, dass die Funktion parent_post_rel_link derzeit nicht die rel Angaben liefert die Google brauchen tät.

a)

Bist Du auf einer Seite, die entweder eine einzelne Seite ist oder eine “Parent” Seite – also eine Seite mit Unterseiten- dann zeigt dies einfach rel=prev oder rel=next (oder beides) für die in zeitlicher Reihenfolge vorher oder nachher geschriebene Seite an.
Nicht auf etwaig vorhandenen Unterseiten. => das sollte es aber tun.

b)

Bist Du auf einer Unterseite ergibt dies:

rel=up zur Hauptseite

rel=prev zur Hauptseite

wenn vorhanden:
rel=next zur nächsten gleichrangigen Unterseite

c)
Bist Du auf einer Unter-Unterseite ergibt dies:

rel=up zur hierarchisch höheren Seite
rel=prev zur hierarchisch höhren Seite

wenn vorhanden:
rel=next zur nächsten gleichrangigen Unter-Unterseite

d)

Bist Du auf /seite/3

kommt nicht rel=prev zur /seite/2
und auch nicht rel=up zur /seite/2

und wenn vorhanden auch kein
rel=prev zur /seite/3

sondern wieder rel=prev zur nächsten gleichrangigen Unterseite /Seite
und wieder rel=up zur nächsthöheren Seite

Magst Du nicht, dass dies automatisch durch wp_head im html Header erscheint, dann füge in die functions.php deines Themes folgendes ein:

remove_action( 'wp_head', 'parent_post_rel_link', 10, 0 ); // prev link

Ich selbst lasse alle Weiterblättern Seiten nicht in den Index von Google. Erstens, weil ich ziemlich viele Artikel pro KategorieSeite anzeigen lasse. Zweitens daher auf der Seite 2 einer Kategorie wirklich ältere Artikel sind. Und Drittens, weil ich der Meinung bin nicht die Quantität an Seiten im Index zählt, sondern die Qualität.
Wie ich das mache erklärte ich in diesem Artikel: Noindex.

Die meistgelesenen Artikel des Tages oder des Monats zu präsentieren. Herzuzeigen wie oft ein Artikel gelesen wird, soll einerseits zum Lesen verführen, andererseits ist es nichts anders als ein “Schw…vergleich”. So ganz urehrlichst.

Klar bin ich ganz stolz, dass ich zwei Artikel habe die seit dem März 2007 weit öfter als 100.000 mal gelesen wurden:

WordPress Theme Vorlage 214 749 und
How to design your own WP theme 161 879.

Das ist für diese kleine NerdSeite ja nicht ganz wenig. Behaupt ich einfach.

Aber die Zeiten ändern sich. So ein PostReadCounter kostet Zeit und daher auch Geschwindigkeit.

Cache Plugins und Post ReadCounter

Es gibt Cache Plugins für WordPress, wo man das für die sichtbare Anzeige der Leserzählerei (datenbankpräfix)_postmeta ausschließen kann. Doch dann wirkt das Cache Plugin nicht so effizient wie es könnte. Zur Nachlese ein Thema aus wordpress.org.

Abhilfe

Als Alternative gibts auch ein AjaxPlugin, dass den PostReadCounter anzeigt.

Und auch hier schreibt der PluginAutor selbst auch, dass dies die Performance verringert.

Erstens habe ich es nicht getestet, und 2tens steht da dabei, dass der Programmierer kaum Zeit hat, also gehe ich davon aus, dass es nicht wirklich Support und Updates gibt.

Solche Plugins verwende ich prinzipiell nur, wenn absolute Not herrscht-irre Not ….

Und anzuzeigen wieviele heute den Artikel hier gelesen habe, ist für mich keine “absolute Not”, es ist meine persönliche Befriedigung.

Doch die kann ich mir auch im Adminbereich meines generellen StatistikCounters holen

Daher wirds ab heute keine “GelesenZählerei” hier mehr sichtbar geben und im “footer” wird der Kasten der meistgelesenen Autoren verschwinden. Ich finde dafür sicher eine gute Lösung, um zum Lesen zu verführen z.B.: eine verdammt gute Performance.

Ich wurde per E-mail gefragt, ob man bei WordPress einfach so die URL eines Artikels ändern kann und ob es dann eine korrekte Weiterleitung auf die neue URL gäbe. Grund:die Person hatte einen Tippfehler im Titel und somit auch in der URL und wollte dies korrigieren.

Sie war sich aber unsicher, ob sie dann einen Eintrag in die htaccess machen muss, damit korrekt auf die neue URL umgeleitet wird.

Kürzeste Antwort: ändern. URL Slug wird seit der WordPress Version 2.1 automatisch korrekt per Redirect Permanent weitergeleitet. D.h. einen einzigen WordPress Permalink kann man getrost einfach so ändern.

Artikelhistorie

Erstveröffentlichung: 25. Juli 2010 21:14

WordPress liefert die Möglichkeit die Error 404 Seiten selbst zu gestalten. Dies ist ein Service an Deine Leser und Leserinnen, wenn mal eine Seite, ein Artikel nicht gefunden wird. Dies alles nutzt aber nichts, wenn Du kaum Möglichkeit hast diese Error 404 abzustellen. Klar man kann dies auch via den Webmastertools von Google finden, doch ich mag manchmal hauseigne Lösungen lieber, weil ich da schneller reagieren kann.

Ein wirklich uraltes Script hilft mir dabei, dass ich ganz am Ende des 404.php templates eingebaut habe.

<?php
$ip = getenv ("REMOTE_ADDR");
$requri = getenv ("REQUEST_URI");
$servname = getenv ("SERVER_NAME");
$combine = $ip . " tried to load " ;
$url = $servname . $requri ;
$httpref = getenv ("HTTP_REFERER");
$httpagent = getenv ("HTTP_USER_AGENT");
$today = date("D M j Y g:i:s a T");
$message2 = "On $today, $combine:\n
http://www.$url\n
User Agent = $httpagent \n
$httpref ";
$to = "DeineEmailAdress";
$subject = "404 Error Report";
$from = "From:AbsenderEmailAdresse\r\n";
mail($to, $subject, $message2, $from);
?>

Wie arbeitet dieses Error 404 E-mail

DeineEmailAdress => hier einfach Deine E-mail Adresse eintragen.
AbsenderEmailAdresse => hier die Absende E-mail Adresse eingeben. Zu 99% ist es klug diese mit wordpress-klammeraffe-domainadresse anzugeben. So verschickt WordPress ja auch seine Datenbankbackups via E-mail.

Vorteil des kleinen Error 404 E-mail

Ich sehe wer diesen Error 404 verursachte. Ob es Bots waren, oder Leser und Leserinnen.

Update im Oktober 2011:

Den Code von Jendrischek nahm ich endgültig raus, weil es denn doch einige gab, wo ernicht funktionierte.

Quasi als Trostpflaster biet ich jedoch wunderbare Beispiele schön gestalteter Error 404 Seiten bei t3n.de an.

WordPress bietet jede Menge an Spielereien mit dem Menü an.

Ob Du ein- oder mehrere individuelle Menüs auf Deiner Seite haben magst ist ja alles keine Hexerei mehr, wenn es das Theme in der functions.php drin hat.

Ob Du bei dem Menü einen Artikel oder eine Kategorie angezeigt haben magst, ob da Unterkategorien dann erscheinen oder ganz was anders unter einem Menüpunkt ist einfach ein “Klick” und ein bisschen “drag & drop”.

Damit Du dann aber auch so einen netten kleinen Pfeil bei dem Menüpunkt hast, der Unterpunkte anzeigt gibts jede Menge an JQuery Lösungen. Ich nutz dafür gern die “Optionen” bei den Menüs.

wo sind diese Optionen der WP Menüs

Klickst Du auf Admincenter==> Design==> Menü
und guggst Du oben Rechts hin, siehst Du “Optionen“.

Einfach mal anklicken und guggen was da alles geboten wird. Sogar Custom Post Types oder Taxonomien stehen da.

Für die kleinen Pfeilchen wäre eine zusätzliche CSS Klasse nett, ich nenn die immer “parent”.

weiterführende INFOs

Wie Du Deine Menüs verwalten kannst und mehr findest Du hier “Menüs anlegen … “.

Wie so ein Menü auch angepasst werden kann findest Du hier: Menü anpassen ….