WordPress & Webwork » wordpress-anpassung

WordPress: Suchergebnisse hervorheben und more-Tag mit Werbung ersetzen

Vladimir — Fri, 30 Apr 2010 09:17:04 +0000

Ich möchte hier kurz auf zwei Artikel verweisen auf die ich heute aufmerksam geworden bin.

Ich habe vor ein paar Wochen beschrieben, wie man durch die Erweiterung der functions.php die Suchwörter in den Ergebnissen der WordPress-Such hervorheben kann: WordPress: gesuchte Begriffe hervorheben.

Sergej Müller hat da eine etwas leistungsfähigere Variante auf die Beine gestellt: WordPress: Begriffe im Suchergebnis jederzeit hervorheben .

Frank Bültge hat in seinem Weblog einen interessanten Artikel verfasst. In diesem erklärt er wie man den more-Tag – der üblicherweise die Einleitung und den Rest des Artikels trennt – durch z. B. einen Werbeblock ersetzt: more-Tag mit Werbung ersetzen.

Google: Ladegeschwindigkeit wird Rankingfaktor

Vladimir — Sun, 11 Apr 2010 15:17:07 +0000

Google hat die Ladegeschwindigkeit einer Website zu einem von insgesamt 200 Rankingfaktoren befördert. Das heißt in der Zukunft wird die Position einer Website in Google auch von Ihrer Performance bzw. der Ladegeschwindigkeit abhängen. Mehr zu diesen Thema kann man im Weblog von SISTRIX nachlesen.

Das ist gut, Performance-Optimierung ist nun ein SEO-Faktor und war schon seit eh und jeh ein wichtiger Usability-Faktor: wer wartet schon gerne.

Google Webmaster Tools: Performance einer Website

Doch bevor man jetzt alles optimiert was nicht bei drei auf den Bäumen ist sollte man bedenken, dass dieser SEO-Faktor nur einer von 200 ist und das es so sein wird das die anderen Faktoren, wie z. B. die Relevanz des Inhalts, ein größeres Gewicht haben. Daher braucht man nicht zu hoffen, dass man alleine, weil die Website wie Schmitz' Katze abgeht, in die Top-10 der Suchergebnisse reinkommt.

Aber auch aus Usability-Gründen darf man sich nicht zu Tode optimieren. Ergänzt ein Bild oder Grafik den Text-Inhalt, dann sollte man nicht darauf verzichten. Man kann sich aber überlegen ob man für das Bild das richtige Format gewählt hat und ob man es nicht evtl. noch stärker komprimieren kann.

Beim Fundament beginnen

Schaut man sich so einige der 100.000 Tricks zur Optimierung der Ladegeschwindigkeit von WordPress-Websites, dann bekommt man das Gefühl eine Optimierung besteht lediglich darin eines der tollen Cache-Plugins zu installieren und schon ist alles erledigt.

Aber eine Performance-Optimierung fängt schon bei dem Aufbau des (X)HTML- und CSS-Codes an … so wie allen Websites auch, egal ob statisch oder dynamisch und mal davon unabhängig welches CMS im Hintergrund werkelt. Hier ein kleines Beispiel damit man sieht was ich meine. Zuerst die weniger gute Variante, zuerst das (X)HTML:


    
        Überschrift
    
    
        
            Listenpunkt
        
    
    
        Text + Hervorhebung.

und das passende CSS dazu:

.klasse1 h3 {...}
.klasse2 ul {...}
.klasse2_1  {...}
.klasse3 p  {...}
.klasse4    {...}

Und hier das bessere Beispiel. Zuerst HTML:


    Überschrift
    
        Listenpunkt
    
    Text + Hervorhebung.

Und dann das CSS:

#sidebar h3 {...}
#sidebar ul {...}
#sidebar li {...}
#sidebar p  {...}
#sidebar i  {...}

In dem man auf unnötige div-Blöcke und unnötige Klassen verzichtet und dann noch dazu die Kurzschreibweise bei CSS (z. B. #000 statt #000000) einsetzt, hat man nicht nur den ersten Schritt bei der Optimierung getan sondern die Dateien auch übersichtlicher und wartbarer gemacht.

Hardcoden vs. Dynamik

Aber auch bei der Erstellung der WordPress-Themes kann man schon von Beginn an optimieren. Setzt man das Theme lediglich bei sich selbst ein – also nicht beim Kunden oder zum freien Download – dann kann man auf einiges in der Dynamik verzichten.

Anstatt einzusetzen kann man den Pfad zu der CSS-Datei auch ausschreiben oder wenn die Website einsprachig ist, dann kann man solche Konstrukte auch direkt übersetzen und im Quelltext manuell notieren. Durch solche einfache Maßnahmen spart man sich zusätzliche Anfragen an den Webserver.

Bilder optimieren

Eine weitere grundlegende Optimierung wird häufig vernachlässigt. Zum einen sind die Dateigrößen der Grafiken im Inhalt häufig zu groß und es wird in vielen Fällen das falsche Format gewählt.

Um für den Webeinsatz gut optimierte Grafiken zu bekommen muss man nicht auf Großgewichte wie Photoshop oder GIMP zurückgreifen, auch so einfache Freeware wie IrfanView bietet, erweitert durch Plugins, einen recht ordentlichen Export für Webgrafiken. Und natürlich bieten auch so einfache Tools einen guten Batchmodus, wo man in einem Rutsch mehrere Grafiken optimieren kann. Zum Thema Bilder optimieren schrieb ich auch bereits ein paar Worte: WordPress-Websites beschleunigen 2: Grafiken Optimieren.

Komprimieren und cachen

Wenn man die oberen Schritte beherzigt hat, dann kann man sich imho Gedanken machen wie man die Dateien auf dem Server komprimieren und cachen (zwischenspeichern) kann. Wie ich schon sagte, gibt es alleine für WordPress eine Reihe an Plugins, die Inhalte komprimieren und zwischenspeichern. Aber bevor man sie einsetzt sollte man wissen, dass es mit denen manchmal Probleme geben kann.

Zudem bin ich der Meinung, dass man sich anschauen soll was der Webserver an Maßnahmen zu bieten hat bevor man WordPress-Plugins installiert. Ich bin der Meinung, dass die Mittel die z. B. Apache (oder auch andere Webserver) zur Verfügung stellt doch etwas Leistungsfähiger und Ressourcen-schonender sind, als das was man über den Umweg über PHP (WP-Plugins) erreichen kann. Falls ich hier Blödsinn erzähle, korrigiert mich bitte.

gzip-Kompimierung und besser cachen mit Apache 2

Folgenden Code habe ich schon in diesem Weblog an mehreren Stellen erwähnt. Unter anderem hier: WordPress-Websites beschleunigen 4: ein Zwischenergebnis.

# mod_deflate (gzip) aktivieren

SetOutputFilter DEFLATE


# ExpiresHeader: verhindert bedingte GET-Anfragen

ExpiresActive on
ExpiresDefault "access plus 35 days"

Den oberen Code einfach in die .htaccess-Datei eintragen, gilt aber nur für Apache 2.0. Und was macht der Code? Der erste Block komprimiert alle Textdateien (HTML, CSS, Javascript etc.) bei der Übertragung.

Andere Formate würde ich hier nicht einfügen, denn z. B. Bilder sollte man mit einem Grafik-Programm komprimieren. Jede Komprimierung kostet Rechenkraft des Servers und daher sollte man sie nur einsetzen, wenn es auch einen wirklichen Vorteil gibt.

Eine gzip-Komprimierung bei einer Bildergalerie-Website ist daher wenig sinnvoll, die Optimierung der wenigen Textinhalte ist im Ergebnis verschwinden gering wie wenn man die ganzen Grafiken mit einer ordentlichen Bildbearbeitung für Web optimiert.

Der zweite Block erweitert die Caching-Funktion des Browsers in dem zusätzliche Anfragen des Browsers an den Server – "wie lange ist die Grafik in meinem Cache noch gültig?" – verhindert werden. Der zweite Code-Block besagt, dass alle Komponenten der Website im Browsercache noch mind. 35 Tage aktuell sind.

Und weiter?

Die Maßnahmen, die ich beschrieben habe sind nur die Spitze des Eisberges. Aber ich denke, dass sie zu einem ein gutes Fundament darstellen und das im Verhältnis zum Einsatz recht gute Ergebnisse liefern. Reichen diese Maßnahmen nicht, dann kann man so Plugins wie WP Super Cache und /oder CSS-JS-Booster von Christian "Schepp" Schaefer ausprobieren.

WordPress 3.0-Entwicklung schreitet voran

Sahanya — Fri, 15 Jan 2010 13:35:30 +0000

Mit Siebenmeilenstiefeln schreitet die Entwicklung von WordPress 3.0 voran und es gibt schon einen Fahrplan. Die interessantesten (angestrebten) Daten für Nutzer sind dabei wohl

1. März 2010: Beginn der public beta
29. März 2010: Veröffentlichung des Release Candidate
13. April 2010: Veröffentlichung der neuen Version: WordPress 3.0

Ich bin mal sehr gespannt. Grundsätzlich halte ich solche engen Zeitpläne immer für sehr gefährlich, da man Erwartungen weckt, die man evtl. nicht halten kann…

Derweil gibt es auch im Entwickler-Blog Neuigkeiten zu dem geplanten neuen Standardtheme. Als eine Art Vorbild soll wohl das Theme Kirby dienen. Beinhalten soll das Theme einen anpassbaren Header (separat für Seiten und Artikel), einen anpassbaren Hintergrund und ein Drop-Down-Menü.

WordPress: einzelne Artikel in der Übersicht kategorierbasiert stylen

Vladimir — Thu, 26 Nov 2009 22:08:17 +0000

Bei meinem vorletzten WordPress-Auftrag ging es unter anderem darum, dass man die Artikel auf der Startseite (und anderen Übersichtsseiten) so ausgibt, dass die Artikel aus unterschiedlichen Kategorien sich auch visuell unterscheiden.

Also rein theoretisch: jeder einzelne Artikel, der durch den Loop ausgeliefert wurde, musste einen kategorieabhängigen Wert für den Klassenattribut bekommen.

Recht schnell bin ich auf die Lösung von Lorelle VanFossen gestoßen, die auch direkt funktioniert hat. Die Plugin-Suche ergab leider nichts konkretes … kann aber auch sein, dass ich einfach die Suchfunktion mit falschen Begriffen gefüttert habe. Im Endeffekt ist das auch Wurscht, weil sich die Code-Lösung bereits im praktischen Einsatz gut bewährt hat.

Folgenden PHP-Code baut man als erstes in die functions.php ein:

function the_category_unlinked($separator = ' ') {
$categories = (array) get_the_category();
$thelist = '';
foreach($categories as $category) {
$thelist .= $separator . $category->category_nicename;
}
echo $thelist;
}

Mit dem oberen Code hat man eine Funktion mit dem Namen erstellt, welche die Kategorienamen der einzelnen Artikel ausliest. Zum Einsatz kommt die Funktion get_the_category(). Den ausgelesenen Namen der Kategorie kann man dann zum Beispiel als einen Wert für den Klassenattribut einsetzen:

Der relevante Code-Abschnitt aus dem oberen Bereich ist:

Dadurch bekommt jeder Artikel auf der Startseite bzw. auf den Übersichtsseiten folgenden Klassenwerte:

Nun kann man hergehen und die CSS-Datei mit entsprechenden Regeln füttern, zum Beispiel:

.wordpress { ... }
.internet { ... }
.blog-rss { ... }
...

Das wär's. Eine sehr einfache Lösung.

WordPress-Websites beschleunigen 4: ein Zwischenergebnis

Vladimir — Sat, 06 Jun 2009 20:12:08 +0000

In drei Artikeln vorher (hier, hier und hier) habe ich einiges beschrieben, wie man WordPress-Website beschleunigen kann. Das allermeiste ist logischerweise auch für andere Website gültig. Hier so ein kleines Vorher-Nachher-Bild.

Hier zuerst die Statistiken vor der Optimierung:

Vor den Optimierungen

Links sind die Angaben, wenn ein Besucher zum ersten Mal kommt (leerer Cashe) und rechts ist das Ergebnis wenn der Besucher wieder kommt. Anschließend habe ich zwei einfache Änderungen in der .htacces-Datei durchgeführt und habe dieses Ergebnis erreicht:

Nach den Optimierungen

Für diese recht ansehnliche Verbesserung sind folgende Code-Zeilen verantwortlich:

# mod_deflate (gzip) aktivieren

SetOutputFilter DEFLATE


# ExpiresHeader: verhindert bedingte GET-Anfragen

ExpiresActive on
ExpiresDefault "access plus 35 days"

Der erste Block aktiviert auf dem Apachen 2 die Komprimierung (gzip) und es werden alle relevanten Dateitypen komprimiert. Sinnvoll ist eigentlich nur die Komprimierung der Textdateien, die Grafiken sind im Web eh schon komprimiert und man würde lediglich den Server um sonst bemühen wenn man versuchen würde auch die Bilder und Grafiken bei der Übertragung zu komprimieren.

Der zweite Block verpasst den Dateien im Cache eine zusätzliche Information. Üblicherweise entsteht bei gecashten Dateien trotzdem eine zusätzliche Kommunikation zwischen dem Browser und dem Server:

Browser:: Hallo Server, ich habe hier ein Bild im Cache. Bin mir nicht sicher ob es noch aktuell ist. Schaue mal bitte nach.
Server:: Lass mal schauen … OK, dass Bild ist noch 12 Tage lang gültig.
Browser:: Fein, dann kann ich das Bild direkt aus dem Cache laden.

Bei so einer "Kommunikation" handelt es sich um eine bedingte GET- bzw. HTTP-Anfrage, in der sich der Browser vergewissert, dass die gecachten Komponenten noch aktuell sind. Mit der Anweisung ExpiresDefault "access plus 35 days" sagen wir dem Browser: "Egal wann der Cache zum Einsatz kommt, aber alle Dateien in deinem Cache sind noch mind. 35 Tage lang gültig, lade Sie daher bitte direkt aus dem Cache".

Ich habe hier vorher lediglich 21 Tage als Wert gehabt. Allerdings hat mir die neue Erweiterung von Google angemerkt, dass die zu kurz sei und das man einen Wert größer 30 Tage nehmen sollte.

Sicherlich, es gibt viel mehr Maßnahmen die man machen kann und dies auch schon im Vorfeld: CSS-Dateien schlank halten, "Entrümpelung" von unnötigem Code in den Themes, Grafiken verkleinern etc. Aber die oberen beiden Maßnahmen sind schnell erledigt, einmal gemacht und entfalten eine starke Wirkung.

Bei anderen Maßnahmen, wie z. B. alle CSS- und JS-Dateien zu jeweils einer verschmelzen um die HTTP-Anfragen zu minimieren, hat man in den Redaktionssystemen wie WordPress nicht immer die volle Kontrolle, speziell dann wenn man gut zwei Dutzend Plugins einsetzt.

WordPress-Websites beschleunigen 2: Grafiken Optimieren

Vladimir — Thu, 14 May 2009 14:08:14 +0000

Ich habe vor gut drei Wochen den ersten Artikel zum Thema "WordPress-Websites beschleunigen" geschrieben. Damals war das Thema gzip und andere Maßnahmen die man in der .htaccess-Datei machen kann.

Doch es gibt sehr wirksame Maßnahmen, die nicht so techniklastig sind: Optimierung von Grafiken. Das man die Grafiken des eigenen Layouts optimieren kann ist hinlänglich bekannt. In der Regel kommt für Grafiken mit fotografischen Elementen .jpg zum Einsatz und sonst .gif oder .png, hier muss man einfach austesten was die beste Kombination aus Dateigröße und Qualität ergibt, vielen ist das hinlänglich bekannt, deswegen gehe ich da jetzt nicht tiefer rein.

.png statt .gif

Aus Erfahrung weiß ich das in den allermeisten Fällen die Entscheidung für .png anstatt .gif darin resultiert, dass man bei gleicher Qualität eine kleinere Dateigröße erreichen kann, speziell bei größeren Dateien. Je nach Größe und Art der Grafik kann das bis zu 20% betragen.

Leider ist es so, dass Photoshop – zumindest bis einschl. CS2 – für die .png-Grafiken den falschen Gamma-Wert übergibt. Daraus resultiert, dass IE und Safari die Grafiken einen Tick dunkler darstellen. Bei einfachen Screenshots im Artikel ist das kein Problem, aber bei Layoutelementen kann das unangenehm auffallen. Der folgende englischsprachige Artikel erklärt was da passiert und stellt auch einige Lösungsmöglichkeiten vor: The PNG Gamma Dilemma.

Matthias Schütz stellt mit TweakPNG eine recht einfache Möglichkeit, die das Problem lösen kann.

CSS-Sprites: ein statt mehrer Hintergrundbildern

Durch den Einsatz von CSS-Sprites (es werden mehrere Hintergrundbilder zu einer Grafik verschmelzt) kann nicht nur an der Dateigröße speichern sondern auch HTTP-Anfragen minimieren, was zusätzlich zur Optimierung der Website beiträgt. Hier ein interessanter Artikel dazu.

Bilder im Inhalt: hohes Optimierungspotential

So, nun aber zum Aspekt worum es mir eigentlich geht und zwar zu den Bildern in den Artikeln selbst. WordPress bietet die Möglichkeit, dass man über die Anwendung selbst, Bilder hochlädt und sie im Inhalt in verschiedenen Größen einbinden kann. Dabei ist mir aufgefallen dass die kleineren Grafiken, die von WordPress automatisch erzeugt werden, sehr häufig aufgebläht werden und zum Teil von der Dateigröße her größer sind, als die die Originale die zum Teil von den Ausmaßen doppelt so groß sind.

Ich kenne mich mit den Tiefen von PHP und seinen verschiedenen Bibliotheken nicht aus, aber ich vermute mal das die PHP-Bibliothek GD-Lib hier die verkleinerten Bildern nicht in der optimalen Dateigröße ausgibt. Wenn ich Blödsinn erzähle, dann korrigiert mich bitte. Auf jeden Fall habe ich, die automatisch generierten Vorschaubilder durch Photoshop geschickt und hier kann man die vergleichen:

Aufgeblähte Grafiken

Auf der rechten Seite sieht man die originalen Grafiken auf dem Server und die dazugehörigen automatisch generierten Vorschaubilder. Links befinden sich ebenfalls die originalen Grafiekn und die Vorschaubilder welche ich kurz durch Photoshop geschickt habe. Das Ergebnis ist eindeutig. Links haben die 11 Dateien zusammen 400kb und rechts 857kb.

Speziell die Vorschaubilder bergen viel Einsparpotential – z. B. die Datei expression-web-2-500×353.png kommt von 122kb auf 43kb runter – und hier lohnt es sich auch mal nachzujustieren. Gut das ist immer auch eine Zeitfrage, aber wenn es viele Bilder sind kann man hier mit den Automatismen (Skripte, Aktionen etc.) der Grafikprogramme schnell vorankommen.

Ob es auch eine vernünftige serverseitige Lösung gibt, würde mich auch interessieren.

WordPress-Websites beschleunigen

Vladimir — Wed, 22 Apr 2009 16:22:00 +0000

Auch wenn mittlerweile immer mehr und mehr Nutzer über Breitbandanschlüsse (DSL, Kabel & Co.) verfügen, so lohnt es sich dennoch ein bisschen an der Größe der Website zu optimieren um die Ladezeit zu verkürzen, aber auch um die Server-Ressourcen zu schonen. Dem erfahrenen Webworker stehen da einige interessante Werkzeuge und Möglichkeiten zur Verfügung.

Das wären z. B. die Verringerung von HTTP-Anfragen durch das Recyclen von Hintergrundbildern oder dem Zusammenfassen von mehreren CSS- oder Javascript-Dateien zu jeweils einer Datei. Eine andere Möglichkeit ist die Daten während des Weges zwischen dem Server und dem Client (Browser) zu komprimieren (zippen).

Bis einschließlich Version 2.3.3 verfügte WordPress über die Möglichkeit die Beiträge mittels gzip zu komprimieren. Seit Version 2.5 ist diese Möglichkeit nicht mehr vorhanden, weil – so weit ich das verstanden habe – der gzip-Einsatz via PHP nicht so effektiv ist und den Server mehr belastet als wenn man dies direkt über den Webserver veranlasst.

Nun gibt es mehrere WordPress-Plugins, die die gzip-Komprimierung aktivieren. Eines davon ist das Plugin von Sergej Müller. Dieses Plugin komprimiert die WordPress-Beiträge. Hier aber zuerst die Daten von www.perun.net ohne jegliche Komprimierung:

perun.net ohne Komprimierung

Die Grafik wurde von YSlow erstellt. Es handelt sich hierbei um eine Erweiterung für Firebug. Auf der Linken Seite sieht man die Angaben, wenn ein neuer Besucher (leerer Browsercache) und rechts wenn z. B. ein Stammbesucher die Website aufruft.

Und hier die generierte Grafik bzw. die Daten, wenn man das Plugin von Sergej aktiviert:

perun.net mit Compress-Plugin von Sergej

Das ist schon einiges an Ersparung, aber es geht noch besser, weil das Plugin von Sergej nur die Beiträge, aber nicht die CSS- und Javascript-Dateien komprimiert. Nach etwas Suche bin ich dann fündig geworden und habe auf brightscape.net folgenden Code-Fragment gefunden:


SetOutputFilter DEFLATE

Wenn man diesen Fragment in der .htaccess-Datei einbaut (vorher bitte das Plugin von Sergej deaktivieren), dann erreiche ich auf perun.net folgende Werte:

perun.net mit Anpassung in der .htaccess

Das schaut noch besser aus als vorher. Mit einfachen Mitteln habe ich die Größe der Startseite von perun.net um etwas mehr als 1/4 verkleinert und das sowohl bei leeren als auch bei vollen Browsercache. Gut, je nach Aufbau der Website kann der Wert variieren, das ist logisch. Aber es lohnt sich auf jeden Fall. Jetzt wird es darum gehen, die anderen Komponenten zu optimieren.

Noch ein Hinweis zum Schluss. Welche Angaben man in der .htaccess machen muss ist von Server zu Server unterschiedlich und es hängt davon ab ob mod_gzip oder mod_deflate zum Einsatz kommt. Ich weiß jetzt nicht ob das auf allen all-inkl-Servern so ist, aber bei mir kommt mod_deflate zum Einsatz. Siehe zu diesem Thema auch den Beitrag auf PHP Performance.de.

Das Dashboard noch persönlicher in WordPress 2.8

Sahanya — Tue, 24 Feb 2009 11:47:39 +0000

Dashboard-Optionen

Seit heute morgen gibt es in der WordPress-Version 2.8-bleeding-edge eine weitere Option bei den Optionen für das Dashboard. Man kann bestimmen in wievielen Spalten die Module angeordent werden sollen, dabei kann man von 1 bis 4 Spalten auswählen.

Wählt man die Spaltenanzahl aus passen sich die Module automatisch in der Größe an. Das "Arrangieren" hat bei mir allerdings noch nicht funktioniert, die Module wollen nicht in die Spalten

Hat es jemand von euch schon hinbekommen? Wahrscheinlich bin ich motorisch unbegabt für solche Fisseligkeiten.

WordPress-Auszug (the_excerpt) anpassen

Vladimir — Fri, 17 Oct 2008 20:16:10 +0000

Neben der üblichen Ausgabe eines Blog-Beitrages durch the_content(); kann man auf den Übersichtsseiten von WordPress den Inhalt auch Auszugsweise ausgeben und zwar durch das Template-Tag the_excerpt();. Leider ist dieser Template-Tag nicht so mächtig, wie der erste oder besser gesagt: ihm wurden keine Parameter auf den Weg gegeben und so kann man ihn im Frontend gar nicht anpassen.

Heute hatte ich die Bitte eines Kollegen bekommen, dass alle Beiträge als Auszüge ausgegeben werden und das anstatt der drei Punkte die richtigen Auslassungszeichen (…) erscheinen sollen. dafür begibt man sich in die Datei formatting.php im Ordner wp-includes und dort zwischen den Zeilen 844-862 findet man den Bereich, der für den Auszug zuständig ist:

function wp_trim_excerpt($text) { // Fakes an excerpt if needed
	if ( '' == $text ) {
		$text = get_the_content('');

		$text = strip_shortcodes( $text );

		$text = apply_filters('the_content', $text);
		$text = str_replace(']]>', ']]>', $text);
		$text = strip_tags($text);
		$excerpt_length = 55;
		$words = explode(' ', $text, $excerpt_length + 1);
		if (count($words) > $excerpt_length) {
			array_pop($words);
			array_push($words, '[...]');
			$text = implode(' ', $words);
		}
	}
	return $text;
}

Speziell die Zeile 853 ($excerpt_length = 55;) und die Zeile 857 (array_push($words, '[...]');) sind recht interessant. Mit der ersten Angabe kann man die Anzahl der Wörter anpassen, die ausgegeben werden, wenn zwar ein Auszug ausgegeben wird, aber keiner vom Autor verfasst wurde. Das System gibt dann hier standardmäßig die ersten 55 Wörter des reinen Textes (engl. plain text) aus.

In der zweiten Angabe kann man das Zeichen setzen welches dem Leser symbolisiert, dass es sich hier einen Auszug handelt. Richtigerweise müssten hier die Auslassungszeichen (… oder …) rein, die oft fälschlicherweise (Unwissenheit oder Gemütlichkeit) durch drei Punkte ersetzt werden.

Aufgeräumtes Dashboard in WordPress 2.7

Sahanya — Mon, 13 Oct 2008 16:09:45 +0000

Seit dem letzten Update von WordPress 2.7-hemorrhage hat das Dashboard bzw. der «Überblick» wieder einen völlig neuen Look bekommen und wurde in seinem Äußeren den anderen Backend-Bereichen deutlich angepasst.

Augeräumtes Dashboard

Es gibt keine kleinen Boxen in zwei Spalten mehr, die die einzelnen Funktionen enthalten, sondern Bereiche, die ein- und ausgeklappt werden können und die sich über die volle Breite erstrecken. Dadurch kann man ein sehr aufgeräumtes Dashboard erzielen. Zusätzlich dazu kann man bei den Seiteneinstellungen auch auswählen, ob man bestimmte Bereiche überhaupt angezeigt bekommen möchte. Dies scheint eine Funktion zu sein, die die Entwickler von WordPress nach und nach auf fast allen Seiten im Backend von WordPress zu integrieren scheinen.

Feeds auf dem Dashboard

Neu ist auch, dass man einzelne Bereiche bearbeiten kann. So kann man z. B. die Anzahl der Beiträge der Feeds in den Bereichen "WordPress Deutschland Blog" und "Weitere WordPress-News" einstellen und auch die URL zu den Feeds selber ändern. Ich frage mich dabei, ob es in der endgültigen Version auch möglich sein wird zusätzliche Feeds auf dem Dashboard einzubinden.

Im Bereich "Eingehende Links" kann man zusätzlich zur Bearbeitung des Feeds eine Checkbox "Artikel-Datum anzeigen?" aktivieren, was im Moment allerdings noch keine Auswirkungen hat. Auch die Bearbeitungsoptionen im Bereich "Quickpress" sind noch nicht aktiviert.

Man darf also weiterhin gespannt bleiben welche Gestalt und vor allen Dingen welche Funktionen das Dashboard in der kommenden Version 2.7 annehmen wird.

Entwürfe speichern in WP 2.7

Sahanya — Thu, 18 Sep 2008 10:19:20 +0000

Mit der neuen WordPress-Version 2.7 wird sich auch der Komfort im Umgang mit Entwürfen ändern. Endlich haben Entwürfe einen richtigen Zeitstempel. Konkret bedeutet dies, dass sie in der Verwaltungsliste nicht mehr am unteren Ende (ohne eine Zeitangabe) auftauchen, sondern an der "richtigen Stelle".

Entwurf mit Zeitstempel

Via Ryan (WP Development Updates)

HTML-Editor von WordPress erweitern

Vladimir — Wed, 03 Sep 2008 14:22:55 +0000

Wenn man sich die Umfrage "Wie verfasst ihr eure Blog-Beiträge?" anschaut wird man feststellen, dass mehr als die Hälfte der Teilnehmer den HTML-Editor bzw. die Code-Ansicht des Redaktionssystems nutzen. Daher ist es sinnvoll sich Gedanken zu machen, wie man diese Ansicht aufbohren kann um die Arbeit komfortabler und effizienter zu gestalten.

Manuelle Anpassung

In WordPress kann man im Ordner wp-includes/js/ die Datei quicktags.js bearbeiten um die Quicktags (Formatierungen und Auszeichnungen) zu erweitern. Wie man die Quicktags manuell erweitert, habe ich vor mehr als drei Jahren beschrieben und die Anleitung ist noch immer aktuell.

WordPress-Plugin

Die zweite Möglichkeit ist etwas komfortabler und kommt als ein WordPress-Plugin daher: AddQuicktags von Frank Bültge. Wie man hier vorgeht habe ich auch bereits geschrieben. Der einzige nachteil bei dem Plugin gegenüber der manuellen Methode ist dass man lediglich neue Quicktags verwalten kann, die schon bestehenden kann man nicht beeinflussen.

Mozilla-Erweiterung

Ein dritte Möglichkeit bieten so Tools wie z.B. die Erweiterung für Firefox und SeaMonkey: BBCode. Dieses Tools bietet eine Reihe an vordefinierten Schnippseln für BBCode (wird häufig in Foren eingesetzt) und für (X)HTML und zwar für so häufig gebrauchte Sachen wie Links erstellen, einen Abschnitt als wichtig auszeichnen, eine Liste einleiten etc.

Darüber hinaus kann man bis zu zehn eigene Code-Schnippsel definieren. Das gute an BBCode ist das man durch die Eingabe eines Platzhalters (_value_) auch einen Textabschnitt markieren und dann auszeichnen kann, zum Beispiel:

`_value_`

Markiert man jetzt einen Abschnitt und ruft diese Formatierung auf, dann wird der entsprechende Abschnitt als Überschrift dritten Grades ausgezeichnet.

Und was verwendest du für ein Werkzeug um die HTML-Ansicht aufzubohren?

Wie hast du das in deinem Weblog gemacht?

Vladimir — Fri, 20 Jun 2008 11:19:21 +0000

Ich habe in den letzten drei bis vier Wochen mindestens sieben Anfragen bekommen, wie ich bestimmte Teile hier im Weblog realisiert habe. Zum Beispiel wie ich die letzten Kommentare aufliste oder wie ich im Footer die Mediadaten ("(Un)wichtige Details") ausgebe etc.

Ich beantworte die WordPress-Anfragen gerne, so fern meine Zeit dafür ausreicht. Aber zu Fragen bezüglich der Techniken und Methoden, die hier in diesem Weblog eingesetzt werden, kann ich nur auf den dritten Teil meiner WordPress-Themes-Reihe verweisen. Dort wird auf 29 Din-A4-Seiten sehr detailliert beschrieben, wie ich hier das Layout und die einzelnen Elemente umgesetzt habe.

Die Linkschleuder

Vladimir — Fri, 13 Jun 2008 00:22:22 +0000

Obama hat den Online-Guerillakampf perfektioniert – In diesem Artikel wird beschrieben wie Obama es geschafft hat, durch das Einsammeln von geringen Spendenbeiträgen über Web, die "Kriegskasse" gut zu füllen.
Die 4-GByte-Problematik – In diesem ausführlichen Beitrag wird die Problematik beschrieben wenn man mehr als 4 GByte Arbeitsspeicher einsetzen will. Ein 64-Bit-Betriebssystem könnte hier helfen, allerdings ist die Unterstützung von solchen Betriebssystemen (Programme, Treiber etc.) noch nicht so ausgereifit, wie sie es sein könnte.
Wir basteln uns einen leisen Rechner – In diesem sehr ausführlichen und hilfreichen Artikel wird beschrieben, wie man sich selbst einen leisen Rechner zusammenbauen kann. Es werden leise Komponenten vorgestellt und es wird hingewiesen worauf man achten soll.
Removing Width/Height from the Image Uploader – In diesem Beitrag wird beschrieben wie man die automatische Angabe zur Breite und Höhe bei dem Bild-Upload in WordPress entfernen kann.
Extrem kleine JavaScript-Galerie – Eine schlanke Javascript-Lösung für Bildergalerien.
ScrollTabView horizontal example – Beispiel eines sog. "tabbed content" (deutsche Übersetzung ist mir nicht geläufig).
An Informative 404 Page – Hier wird beschrieben wie man sich eine 404er-Fehlerseite erstellen kann, die einige Zusatzinformation mitbringt, z. B. woher der Besucher kam.
CSS3.info – Ein Weblog zu Cascading Style Sheets v. 3.
Das schwarze Auge: Drakensang – Das neueste PC-Spiel basierend auf dem deutschen RPG-System verspricht Gutes. Lassen wir uns mal überraschen.

WPlite: Admin-Bereich von WordPress anpassen

Vladimir — Tue, 10 Jun 2008 22:39:55 +0000

Wenn man WordPress als "klassisches" CMS einsetzt – also nur die Pages-Funktion – dann hat man das Problem, dass man den Großteil der Funktionen gar nicht braucht. Wenn man es für sich selbst, Bekannte oder erfahrene Nutzer macht, dann ist das alles kein Problem. Wenn man WordPress allerdings bei Kunden einsetzt, die nicht so erfahren sind, kann es unter Umständen ratsam sein WordPress zu "verschlanken", also die nicht benötigten Menüpunkte zu deaktivieren.

Abhilfe schafft bei so einem Sachverhalt das WordPress-Plugin WPlite. Mit diesem Plugin hast du die Möglichkeit nicht benötigte Bereiche der Admin-Oberfläche zu deaktivieren. Einfach das Plugin herunterladen, entpacken und die Datei wplite.php in den Plugin-Ordner (/wp-content/plugins/) auf dem Server hochladen und aktivieren.

Anschließend gibt es unter "Einstellungen" einen weiteren Unterpunkt mit dem Namen "WPlite":

WPlite einstellen (für die Großansicht das Vorschaubild anklicken)

Bist du der Meinung, dass irgendwelche Menüpunkte im Admin-Bereich überflüssig sind, dann kannst du die entsprechende Checkbox aktivieren. In der oberen Abbildung habe ich alle Bereiche deaktiviert, die in einer "klassischen" Website nicht vorkommen. Man kann auch natürlich weitere Punkte deaktivieren. Wenn man zusätzlich noch das Dashboard deaktiviert, dann fungiert "Seite schreiben" als Startseite des Admin-Bereiches:

Auswirkungen von WPlite (für die Großansicht das Vorschaubild anklicken)

Wie man aus der oberen Abbildung erkennen kann wurden einige Menüpunkte entfernt. Was WPlite hier veranstaltet ist kein Hexenwerk, kann aber die Übersicht erleichtern wenn man WordPress auch bei seinen Kunden einsetzt. Ist in meinen Augen eine wichtige Erweiterung wenn man WordPress als "klassisches" CMS einsetzt.

Optimaler Seitentitel in WordPress 2

Vladimir — Thu, 24 Apr 2008 01:19:30 +0000

Na das wurde ja auch Zeit. Damit ich nicht wieder bei Adam und Eva anfange empfehle ich einfach die Lektüre des ursprünglichen Artikels: Optimaler Seitentitel in WordPress. Dort habe ich erklärt wie ein "guter" Seitentitel ausschaut, warum so ein Seitentitel gut ist und wie man ihn mit Hilfe eines Plugins realisieren könnte.

In der Zwischenzeit verwendete ich folgenden Code anstatt des Plugins "Optimal Title" (siehe auch "WordPress-Themes verstehen 3"):


    <?php bloginfo('name'); ?> - <?php bloginfo('description'); ?>

<?php wp_title(''); ?> » <?php bloginfo('name'); ?>

    <?php bloginfo('name'); ?><?php wp_title(); ?> - <?php bloginfo('description'); ?> | <?php bloginfo(); ?>

Der obere Code war deswegen so lang, weil man vor Version 2.5 das Trennzeichen (Standard: ») nur ausblenden, aber nicht positionieren konnte. Seit der Version 2.5 gibt es eine viel einfachere Möglichkeit.

Zuerst die kurze Fassung:

<?php wp_title('»', true, 'right'); bloginfo('name'); ?>

Die wichtige Stelle habe ich hervorgehoben. Mittlerweile sind hier drei Parameter zulässig. Der erste ist für das Trennzeichen, der zweite Parameter bestimmt ob der Titel ausgegeben wird und mit dem dritten Parameter positioniert man das Trennzeichen.

Und hier dann die ausführlichere Fassung:


    <?php bloginfo('name'); ?> - <?php bloginfo('description'); ?>

    <?php wp_title('»', true, 'right'); bloginfo('name'); ?>

Gefunden bei Mark.

Registration deaktiviert

Vladimir — Mon, 22 Oct 2007 17:16:44 +0000

Da ich seit ein paar Wochen zunehmend seltsame Registrierungen hier im Weblog verzeichne, habe ich temporär diese Funktion deaktiviert, bis ich nicht eine endgültige Lösung gefunden habe. Die bereits registrierten Leser können sich weiterhin einloggen.

Zudem habe ich die ganzen Accounts ala "Hausarzt:-Müller", "Doktor_Schmitz", "Viki-Malone754!" gelöscht. Das ist mir alles irgendwie nicht koscher, zumal die auch sehr exotische E-Mail-Adressen hatten und sonst keine Angaben getätigt haben (z. B. Vorname oder Nickname). Keine Ahnung ob und was die Herrschaften vor haben.

WordPress: nur die Startseite ansprechen

Vladimir — Thu, 28 Jun 2007 16:21:20 +0000

Will man auf einer Website, die mit WordPress betrieben wird, bestimmte Inhalte auf der Startseite unterbringen, dann nutzt man den conditional Tag is_home. Hier ein Beisipiel:

Hast du nicht gesehen!

Der Satz "Hast du nicht gesehen!" kommt nicht in Einzelansicht, nicht auf einer Seite (Page), nicht im Archiv etc. sondern nur auf der Startseite vor. Sehr einfach umzusetzen und sehr nützlich. Allerdings, wenn man den "Weiterblättern"-Links folgt und eigentlich auf der zweiten oder dritten Unterseite ist, dann taucht dieser Satz trotzdem noch auf. Die obere Abfrage spricht halt nicht die Startseite im klassischen Sinn an sondern die Hauptdatei im Template.

Was ist jetzt die Lösung? Ganz einfach:

Hast du nicht gesehen!

Das Ausrufezeichen ist eine Negierung und im Klartext heißt es: Zeige Inhalt xyz auf der Haupt- aber nicht auf den Folgeseiten. Ich hoffe ich habe mich nicht allzu kompliziert ausgedrückt.

WordPress: Autor-Auswahl verschwunden

Vladimir — Wed, 27 Jun 2007 06:00:33 +0000

Ich habe in den letzte Tagen an mehreren Stellen WordPress 2.2.x und WordPress 2.3-alpha installiert bzw. darauf upgedatet.

Mir ist irgendwann aufgefallen, dass die Autor-Auswahl, die sich in der rechten Seite bei "Beitrag schreiben" bzw. "Seite schreiben" befindet, nicht mehr da ist. Da ich mir nicht vorstellen konnte, dass die Entwickler das entfernt haben habe ich mir gedacht, dass so etwas vorkommt in den Blogs wo es nur einen Nutzer (den Admin) gibt. Also habe ich neue Nutzer hinzugefügt und es hat nicht geholfen und aus Zufall habe ich entdeckt, dass wenn man den Admin noch einmal zu Admin erklärt (ich weiß es ergibt eigentlich kein Sinn), dass dann die Autor-Auswahl wieder da ist.

Alte Beitrags-Vorschau herstellen

Vladimir — Tue, 22 May 2007 07:29:56 +0000

Mir ist gerade wieder aufgefallen, nach dem ich ein Testupgrade dieses Weblogs erfolgreich durchgezogen habe, dass die WordPress-Entwickler die Inline-Vorschau in der Version 2.2 entfernt haben.

Die Vorschau war in einem Iframe unterhalb des Beitrages untergebracht und somit hatte man alles auf der gleichen Seite. Jetzt haben Sie diese Vorschau entfernt und oberhalb der Quicktagleiste einen Vorschau-Link untergebracht der eine neue Seite öffnet. Manchmal habe ich das Gefühl, dass die Jungs dort irgendein komisches Zeugs rauchen.

Naja, wie dem auch sei. Wer die alte Vorschau zurück haben will, kann sich an diesen Links orientieren:

Nachtrag: Nun gibt es schon ein Plugin, der die Inline-Vorschau wieder herstellt.

WordPress & Webwork » wordpress-anpassung

WordPress: Suchergebnisse hervorheben und more-Tag mit Werbung ersetzen

Verwandte Beiträge:

Google: Ladegeschwindigkeit wird Rankingfaktor

Beim Fundament beginnen

Überschrift

Überschrift

Hardcoden vs. Dynamik

Bilder optimieren

Komprimieren und cachen

gzip-Kompimierung und besser cachen mit Apache 2

Und weiter?

Verwandte Beiträge:

WordPress 3.0-Entwicklung schreitet voran

Verwandte Beiträge:

WordPress: einzelne Artikel in der Übersicht kategorierbasiert stylen

|

Verwandte Beiträge:

WordPress-Websites beschleunigen 4: ein Zwischenergebnis

Verwandte Beiträge:

WordPress-Websites beschleunigen 2: Grafiken Optimieren

.png statt .gif

CSS-Sprites: ein statt mehrer Hintergrundbildern

Bilder im Inhalt: hohes Optimierungspotential

Verwandte Beiträge:

WordPress-Websites beschleunigen

Verwandte Beiträge:

Das Dashboard noch persönlicher in WordPress 2.8

Verwandte Beiträge:

WordPress-Auszug (the_excerpt) anpassen

Verwandte Beiträge:

Aufgeräumtes Dashboard in WordPress 2.7

Verwandte Beiträge:

Entwürfe speichern in WP 2.7

Verwandte Beiträge:

HTML-Editor von WordPress erweitern

Manuelle Anpassung

WordPress-Plugin

Mozilla-Erweiterung

_value_

Verwandte Beiträge:

Wie hast du das in deinem Weblog gemacht?

Verwandte Beiträge:

Die Linkschleuder

Verwandte Beiträge:

WPlite: Admin-Bereich von WordPress anpassen

Verwandte Beiträge:

Optimaler Seitentitel in WordPress 2

Verwandte Beiträge:

Registration deaktiviert

Verwandte Beiträge:

WordPress: nur die Startseite ansprechen

Verwandte Beiträge:

WordPress: Autor-Auswahl verschwunden

Verwandte Beiträge:

Alte Beitrags-Vorschau herstellen

Verwandte Beiträge:

`_value_`