Seit der Version 3.0 wird die Plugintabelle standardmäßig in Seiten aufgeteilt, 20 Einträge pro Seite. In meinen Augen ist die Funktion vollkommen nutzlos, denn sie bedeutet, das ich mich mühsam durch die Seiten klicken muss, anstatt mich einfach mit dem Mausrad durch die Einträge zu scrollen. Es gibt aber eine mehr oder weniger “versteckte” Einstellung, um alle Plugins auf einmal anzuzeigen.
Continue reading WordPress: Paginierung der Plugintabelle ausschalten
Category: WordPress
WordPress Plugin Spam, Teil 2
Im Artikel Interessante neue Art von WordPress-Spam habe ich über eine Webseite berichtet, die Plugins anbietet um unbedarfte Nutzer auf eine Spam-Seite zu locken.
Seitdem war Rahul (der Mann hinter der Spamseite) nicht untätig. Ein deutscher Benutzer berichtete von Problemen mit seiner Webseite, die man ziemlich schnell auf Probleme mit einem Plugin zurückführen konnte. nach kurzer Recherche konnte ein Plugin namens Visitor Stats verantwortlich gemacht werden.
Ein kurzer Blick auf die bekannte Webseite bestätigte meinen Verdacht: Das Plugin wird von “111ways to make money” angeboten. Interessanterweise wird das Plugin von dieser Seite selbst (nicht mehr) angeboten. Na gut, vielleicht hat Rahul einfach vergessen sie hochzuladen. Aber woher hat der Benutzer das Plugin bekommen?
Interessante neue Art von WordPress-Spam
E scheint eine neue Art zu geben, wie Spammer versuchen Benutzer auf Spam-Seiten zu locken: WordPress Plugin Spam
Wie die meisten anderen Autoren überprüfe ich regelmäßig, was andere über meine Plugins sagen. Tatsächlich habe ich einen Google Alert auf die Namen gesetzt. Neulich erhielt ich eine Mail, die mir mitteilte, dass es einen neuen Fork meines pagebar-Plugins namens Advance pagebar gibt. Cool, da hat jemand ein neues Plugin auf Basis meines Codes geschrieben.
Das Plugin heißt komplett “Advance Pagebar – New way to navigate Pages …”. Überraschenderweise funktionierte der Link “http://wordpress.org/extend/plugins/advance-pagebar/” nicht. Was war da los?
E-Mails mit WordPress versenden
Wenn man mit PHP eine E-Mail versenden möchte kann man natürlich auf die interne mail-Funktion zurückgreifen. Diese Funktion ist allerdings sehr grundlegend und häufig fehlen die nötigen Voraussetzungen auf dem System.
Einen Ausweg bieten PHP-Frameworks wie z.B. Zend, CodeIgniter oder Symfony, die eine bequeme API anbieten.
WordPress ist zwar kein allgemeines PHP-Framework wie die oben genannten Beispiele, aber es enthält eine Fülle von Funktionen, die bei der Programmierung von Plugins von Hilfe sein können. So gibt es natürlich auch eine Funktion, die das Versenden von E-Mails ermöglicht.
Dickes P
Wie wird WordPress “richtig” geschrieben? Variationen gibt es viele:
Wordpress, Word Press, WordPress, wordPress, WORDPRESS, WoRdPrEsS
Welche Version ist nun richtig? Die klare Antwort: WordPress, mit einem großen P. Am häufigsten wird es aber wohl einfach WordPress, zum einen aus Unwissenheit zum anderen aber auch einfach als Bequemlichkeit.
Das “Problem” hat es sogar zu einer eigenen Webseite gebracht (www.wpcamelcase.com). Aber warum muss man es dem Nutzer aufbürden, sich Gedanken um die Schreibweise zu machen, dafür gibt es schließlich den Computer. In der Version 3.0 wurde von Matt persönlich folgende Funktion in den WordPress-Core eingefügt:
/**
* Forever eliminate "Wordpress" from the planet (or at least the little bit we can influence).
*
* Violating our coding standards for a good function name.
*
* @since 3.0.0
*/
function capital_P_dangit( $text ) {
return str_replace( 'Wordpress', 'WordPress', $text );
}
Alles in allem doch eine sehr schöne Lösung um das Problem zu lösen… oder doch nicht?
In der wp-hackers-Mailingliste entspann sich auf jeden Fall entspann sich unter dem Titel Putting the P in WordPress eine ausufernde Diskussion über den Sinn und Unsinn dieser Funktion. Ich möchte versuchen, hier die Argumente etwas zu sortieren.
Argument: unnötiges Aufblähen des Programmcodes
Gegenargument: ist ja nur eine klitzekleine Funktion
Argument: der Inhalt eines Artikels sollte nicht vom Programm geändert werden
Gegenargument: der Inhalt wird schon vielen Stellen geändert (emoticons, autop, shortcodes, texturize, special characters, curly quotes, tag balancing, filtered HTML / kses, comment link
nofollows, …)
Argument: Links auf Bilder werden u.U. so geändert, das die Bilder nicht mehr angezeigt werden.
Gegenargument: Wer nutzt denn Großbuchstaben in Dateinamen?
Argument: “WordPress” ist ein Markenzeichen und muss geschützt werden.
Gegenargument: Ist mir doch egal und völlig unwichtig.
Argument: Matt Mullenweg missbraucht seine Stellung als “benevolent dictator”
Gegenargument: Einer muss ja das Sagen haben
Argument: Es gab keine ausreichende Diskussion über das Thema
Gegenargument: Laut Matt gab es eine Diskussion
Die Liste ist sicher subjektiv und es gab sicher noch viel mehr Argumente (es sind immerhin über 110 Nachrichten bisher), aber dies sind diejenigen, die mir am Wichtigsten erscheinen.
Als Lösungen wurden vorgeschlagen:
- komplettes Entfernen der Funktion
- Auslagern in ein (Core-) Plugin
- im Editor als “Schreibfehler” erkennen
- als (Opt-In-) Einstellung anbieten
- als (Opt-Out-) Einstellung anbieten
Es stellt sich natürlich die Frage, wie wichtig eine solche Diskussion ist (und wie wichtig ein Artikel über diese Diskussion!). Überraschend auch die rege Beteiligung, denn normalerweise sind die Threads in dieser Mailingliste nicht so lang. Einfache Antwort: endlich mal was Nicht-Technisches, an dem sich jeder beteiligen kann, auch ohne fundiertes Wissen über den Core-Code.
Jetzt bleibt nur noch abzuwarten, ob sich aus der Diskussion etwas Substantielles ergibt oder ob sie sich irgendwann im Sande verläuft. Popcorn steht auf jeden Fall bereit.
Update (8 July 10): Hier noch einige Links (englischsprachig)
- Lowercase p, dangit! von Justin Tadlock
- The dangit filter von Benjamin Bradley
- Automatically Correcting The WordPress Mistake von Jeff Chandler
- Changeset 14996 – Das ursprüngliche trac ticket
(Links via themelab.com)
WordPress – etwas mehr Platz im Backend
Man hat immer zu wenig Platz auf dem Monitor – egal wir groß er ist. Zumindest im WordPress-Backend kann man einige Pixel in der Breite einsparen, indem man das Navigations-Menü verkleinert.
noteaser – Das unbekannte WordPress-Tag
Die meisten Nutzer werden das <!--more-->-Tag kennen, das es erlaubt, einen Anreißer (engl. “teaser“) zu erzeugen. Dabei wird auf der Hauptseite des Blogs der Text oberhalb des Tags angezeigt und nach dem Anklicken des “More”-Links die einzelne Artikelseite, auf der dann zusätzlich der Text nach dem Tag angezeigt wird.
Es kann aber Situationen geben, in denen man einen gesonderten Anreißer erstellen möchte. So bietet es sich z.B. bei einem reinen Photo-Artikel an, als Anreißer eine Collage zu nehmen. Im eigentlichen Artikel passt diese Collage nicht mehr so richtig. Oder man möchte im Anreißer eine Zusammenfassung des Artikels geben, der aber im Artikel selber nur stören würde.
Um diese Teile des Artikels auf der Artikelseite auszublenden kann man das wenig bekannte <!--noteaser-->-Tag benutzen:
Teaser Text. <!--more--><!--noteaser-->Artikel Text.
Das <!--noteaser-->-Tag muss direkt nach dem <!--more--> folgen, ansonsten wird es nicht beachtet.
Bei der Benutzung des Tags sind allerdings einige Dinge zu beachten:
- Nach dem Anklicken des “more”-Links wird der Artikel bis an den oberen Rand des Browsers geschoben. Dies hat bei einem “normalen” more-Artikel den Sinn, den Text vor dem more aus dem Blickfeld des Lesers zu schieben. Mit noteaser gibt es allerdings keinen solchen Text mehr und es verwirrt den Leser, wenn der Text ganz oben dargestellt wird. Besser wäre es, wenn die Überschrift oben stehen würde.
- Der Text vor den <!--more--><!--noteaser-->-Tags wird im Preview nicht angezeigt. Man muss also in zwei Stufen arbeiten: erst den Text wie üblich erstellen und erst ganz zum Schluss das <!--noteaser-->-Tag einfügen.
- Es werden alle Zeilenumbrüche mit übernommen, so dass man die Tags und den folgenden Text ohne Umbruch hintereinander schreiben sollte, damit auf der Artikelseite keine unschöne Leerzeile über dem Artikeltext dargestellt wird.
Diese Unzulänglichkeiten lassen sich evtl. durch ein neues Plugin verbessern… Mal schauen. Ansonsten ist das Tag eine sehr schöne Möglichkeit sein Blog “anders als die anderen” zu gestalten.
WordPress: Untertitel jetzt auch in einfach
Vor einiger Zeit habe ich beschrieben, wie man die Überschriften seiner Artikel mit Untertiteln versehen kann. Leider war die Methode etwas umständlich und nicht unbedingt inutitiv.
Wenig später schrieb Chris Coyier über Plugins, die er gerne hätte, aber keine Zeit hat, sie selber zu programmieren. Darunter war auch eine ordentliche Integration von Untertiteln in WordPress. 36Flavours hörte den Ruf und programmierte in kürzester Zeit das Plugin “SubHeading“, das die gestellte Aufgabe hervorragend löst.
Die Installation ist zwar einfach, bedarf aber einiger Handarbeit, denn der Funktionsaufruf the_subheading()
muss in alle notwenigen Dateien eingefügt werden, denn es existiert kein Hook, um einen Text direkt nach der Überschrift einzufügen.
Im Editor erscheint hinter dem bisherigen Feld für die Überschrift ein weiteres für den Untertitel:
Das Plugin benötigt noch einige Justierungen in den Feinheiten. So muss man z.B. den Cursor mit der Maus in das Textfeld verschieben, weil es außerhalb der Tabulator-Reihenfolge liegt. Auch bei der Ausgabe gibt es noch einen kleinen Fehler. Ich habe den Autor aber angeschrieben und hoffe, dass diese kleine Probleme bald behoben sind.
Links:
WordPress: Untertitel im Feed
In diesem Artikel, wie man seinen Blog-Artikeln Untertitel hinzufügen kann. Das funktioniert für Artikel, Archive und Suchergebnisse wie beschrieben, allerdings gibt es für Feeds keine Templates.
Man könnte jetzt auf die Idee kommen, die Datei ../wp-includes/feed.php
entsprechend abzuändern. Dies hat aber den Nachteil, dass die Änderungen bei jedem Update überschrieben werden. Hier wird eine Lösung vorgestellt, die das Problem mittels eines Minimal-Plugins löst.
Continue reading WordPress: Untertitel im Feed