elektro:elch

Bei der Entwicklung von WordPress-Themes oder -Plugins taucht immer wieder das Problem auf, dass Skripte oder Stylesheets nicht direkt von der Quelle sondern aus einem Cache geladen werden, weil sie irgendwo auf dem Weg vom Server zum Browser zwischengespeichert werden. Es gibt verschiedenee Möglichkeiten dieses zu unterbinden, indem man z.B. den Browsercache in den Optionen ausschaltet oder ein Webentwicklungs-AddOn benutzt. Manchmal funktioniert das allerdings nicht, weil es die verschiedensten Möglichkeiten des Cachings gibt und man vielleicht nicht alle ausgeschaltet hat.

Du hast also einen Benutzer erstellt und ihm ein gutes Passwort gegeben, damit die Sicherheit Deines Blogs nicht gefährdet wird? Leider kannst Du aber nicht sicher sein, dass der Benutzer dieses gute Passwort beibehält, denn er kann es ganz einfach auf seiner Profilesiete ändern.
Dieses Problem kann allerdings mit einem Filter gelöst werden:

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.

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?

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?

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.

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<strong>
 */
function capital_P_dangit( $text ) {
       return str_replace( 'Wordpress', 'WordPress', $text );
}
</strong>

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)