Wordpress

Was ist Wordpress?

Die kostenlose Software WordPress ist zur Verwaltung von Website-Inhalten konzipiert. Es eignet sich besonders gut, um persönliche Beiträge in einem sogenannten Weblog zu veröffentlichen. Die Schwerpunkte liegen vor allem bei der Benutzerfreundlichkeit, der Ästhetik und dem Einhalten von Webstandards. Dieses System basiert auf MySQL und PHP, ist beliebig erweiterbar und einfach zu installieren.
Der Anwender hat die Möglichkeit Kategorien frei zu erstellen und seine Beiträge einer oder auch mehreren Kategorien zuzuordnen.

Historie von Wordpress

Begonnen hat die Geschichte von WordPress mit Michel Valdrighi, der 2001/2002 ein Weblog-System namens b2/cafelog entwickelte und dieses unter GPL veröffentlichte. Das System basierte auf PHP, Valdrighi stellte die Entwicklung jedoch bald ein. Im Januar 2003 verkündete Matthew Mullenweg, dass er auf der Codebasis von b2/cafelog ein neues Weblog-System schreiben werde. Gemeinsam mit Mike Little begann er seine Ansprüche der Benutzerfreundlichkeit, Flexibilität und Anpassbarkeit mit WordPress in die Tat umzusetzen.

Im Januar 2004 erschien die erste stabil laufende Version des Programms. Auch Michel Valdrighi schloss sich im Laufe der Zeit dem Entwicklerteam von WordPress an. Der Funktionsumfang erweiterte sich mit jeder Version und so ist es seit der Version 1.5 auch möglich, statische Seiten zu verwalten. Diese Tatsache macht aus WordPress mehr als nur ein reines Weblog-System, es hat nun alle Funktionen, die ein Content Management System mitbringt. WordPress gehört zu den am weitesten verbreiteten Weblog-Systemen, es wurde über zehn Millionen mal heruntergeladen.

Funktionen von WordPress

Die Installation von WordPress ist extrem schnell. Vom Download bis zum fertig installierten Blog benötigt es weniger als fünf Minuten.
Ursprünglich für das Verwalten von Weblogs gedacht, unterstützt das System natürlich das Erstellen und Verwalten von Artikeln. Außerhalb der Bloghierarchie können statische Seiten erstellt werden, die geschriebenen Beiträge können zudem versioniert werden. Das mitgelieferte Redaktionssystem umfasst fünf Benutzerrollen (Administrator, Autor, Redakteur, Leser und Mitarbeiter) und ist einfach zu konfigurieren. Ebenfalls zum Lieferumfang gehören eine Volltext-Suche und eine Mediengalerie inklusive Uploader. Diverse Funktionalitäten können mithilfe von Plugins nachgerüstet werden. Mit einem eingebauten Editor können diese Erweiterungen, von denen insgesamt über 5000 frei verfügbar sind, bearbeitet werden.

Durch die sogenannten Theme-Technik ist die Trennung von Programmkern und Design gewährleistet. Dank dieser Trennung können individuelle Designs leicht erstellt werden, ohne dass Programmierkenntnisse notwendig sind. Der Nutzer von WordPress kann sich jedoch auch fertige kostenfreie Themes sowie Wordpress Premium Themes herunterladen und in seinen Weblog importieren.

Installation von WordPress

Für die Installation von WordPress wird Webspace benötigt, der mindestens die PHP Version 7.x, die MySQL Version 5 und das Apache mod_rewrite Modul unterstützt. Das eigentliche Setup ist meistens unkompliziert. Auf der Webseite von WordPress steht eine gut verständliche Installationsanleitung zur Verfügung.

Die beliebtesten Wordpress Plugins

Mit Hilfe von zahlreich vorhandenen Wordpress-Plugins kann man die eigene Wordpress-Installation um nützliche und komfortable Funktionen erweitern, die von Haus aus mit Wordpress nicht möglich sind. Im Laufe der Zeit haben sich einige Plugins mit den verschiedensten Funktionen als besonders praktisch und sinnvoll herausgestellt und gehören mittlerweile zu den beliebtesten und am meisten verbreiteten Erweiterungen für die Weblog-Software.

wordpress.org Plugin-Datenbank: Jede Menge kostenlose Plugins

Die hauseigene Plugin-Datenbank auf wordpress.org bietet eine Fülle von kostenlosen Plugins, die verschiedenste Aufgaben übernehmen können. Zu den beliebtesten Plugins zählt “Contact Form 7”. Die kostenlose Erweiterung bietet die Möglichkeit, auf einfache Art und Weise Kontaktformulare zu erstellen, die dann in Wordpress-Posts oder Wordpress-Seiten eingebunden werden können. Der Nutzer hat bei der Erstellung der Formulare viel Spielraum und sogar Captchas werden unterstützt, um Spam möglichst effektiv entgegenzuwirken.
Ebenfalls enorm beliebt ist das “All in One SEO Pack”, das auch kostenlos von der offiziellen wordpress.org-Seite heruntergeladen und installiert werden kann. Das Plugin übernimmt SEO-Aufgaben und optimiert die Wordpress-Seite für Suchmaschinen, durch die Anpassung von Titel, META-Tags und anderen Werten. Auch für Anfänger ohne SEO-Wissen ist die Erweiterung geeignet, denn schon direkt nach der Installation besitzt das Plugin sinnvolle Grundeinstellungen und funktioniert so “out of the box”. SEO-Experten können eigenes Wissen in die Optimierung einfließen lassen und das “All in One SEO Pack” als Werkzeug nutzen. Neben der kostenloses Basisfunktion gibt es eine Pro-Version ab 39 US-Dollar, die Support und regelmäßige Updates mitbringt.
Noch wesentlich mächtiger und ebenfalls weit verbreitet ist “wpSEO”, das SEO-Plugin des bekannten Wordpress-Entwicklers Sergej Müller, das ab 19,99 Euro zu haben ist. Auch “wpSEO” verfügt bereits direkt nach der Installation und Aktivierung des Plugins über sinnvolle Grundeinstellungen, mit denen der Blog für Suchmaschinen optimiert wird. Auch “wpSEO” ist ein effektives Werkzeug für SEO-Kenner, die eigenhändig verschiedene Einstellungen vornehmen wollen, um sich bestmöglich in den Suchergebnissen von Google, Yahoo und Co. zu positionieren.

“Jetpack by wordpress.com”: Ein kostenloser Alleskönner

Zu den beliebtesten Plugins gehört auch das “Jetpack”-Plugin, das direkt von den Wordpress.com-Machern stammt und den eigenen Blog gleich um mehrere Funktionen erweitern kann. “Jetpack by wordpress.com”, so der volle Name des Plugins, kann kostenlos in der Plugin-Datenbank auf wordpress.com heruntergeladen werden und bietet eine Fülle von neuen Funktionen. Seitenbetreiber bekommen nach der Installation und Aktivierung die Möglichkeit, Besucherstatistiken einzusehen, die direkt in das Dashboard integriert werden. Weiterhin können Kontaktformulare erstellt werden, es gibt einen integrierten URL-Shortener (wp.me), und man kann auf einfache Art und Weise externe Inhalte von YouTube, Digg oder Vimeo in eigene Beiträge einbinden. Das “Jetpack”-Plugin bietet auf Wunsch außerdem eine mobile Ansicht für Besucher, mit dem dem Smartphone unterwegs sind. Zu den weiteren Funktionen gehören E-Mail-Abonnements für die Seitenbesucher, ein Kommentarsystem mit Social Network-Funktionen und eine Share-Funktion, mit der die Nutzer Beiträge direkt in ihren eigenen sozialen Netzwerken teilen können.

Spam effektiv bekämpfen

Spam ist gerade bei Wordpress immer wieder ein großes Problem, aber auch in dem Bereich gibt es wirkungsvolle Plugins. Vorinstalliert ist “Akismet”, das ist allerdings in Deutschland zumindest sehr grenzwertig, was den Datenschutz angeht. Auf der sicheren Seite ist man hingegen mit “Antispam Bee”, das wie “wpSEO” von Sergej Müller stammt. Das kostenlose Plugin verhindert effektiv Spam in den Kommentaren sowie bei Track- und Pingbacks und arbeitet völlig anonym. Im Gegensatz zu “Akismet” ist “Antispam Bee” auch für kommerzielle Wordpress-Projekte kostenlos und arbeitet im Hintergrund selbstständig.

Ab hier sammeln wir ältere Fachartikel von Wolke23 zum Thema Wordpress, weiter unten finden sich Links zu noch aktuellen Artikeln und News:

Deutsche Sprachdateien für City Guide Theme von Woothemes

Veröffentlicht am: 31. Mai 2012

Heute habe ich deutsche Sprachdateien für das schöne Theme City Guide von WooThemes erstellt. Im Netz war nichts brauchbares zu finden, also baute ich es gerade selbst. Bis auf ein oder zwei Sätze, die nicht wirklich relevant sind, ist alles übersetzt. Wer Fehler oder verbesserungswürdige Passagen findet: Bitte in den Kommentaren etwas dazu schreiben.
City Guide Theme von Woothemes

Hier die Infos aus der liesmich.txt

Willkommen zur deutschen Übersetzung des WooThemes City Guide – Version 1.0

Hinweis:
Diese Übersetzungen wurden speziell für das WooTheme City Guide angefertigt. Version: City Guide 1.5.12 Framework 3.7.03.

Files:
de_DE.mo
de_DE.po
liesmich.txt

Anleitung zum Installieren:
Einfach die Dateien nach dem Entpacken hochladen in /wp-content/themes/cityguide/lang. Fertig.
Sollte dein Blog dann noch nicht auf deutsch sichtbar sein, schau in deine wp-config, ob hier die Zeile
define(‚WPLANG‘, ‚de_DE‘);
vorhanden ist. Falls nicht, ergänze diese Zeile vor (!) /* That’s all, stop editing! Happy blogging. */

Relevante Links:
http://www.woothemes.com/theme-localizations/
http://www.woothemes.com/tutorials/how-to-translate-a-theme/
http://www.code-styling.de/english/development/wordpress-plugin-codestyling-localization-en

WICHTIG!!!
Es wird keine Garantie oder Haftung übernommen!

Bitte:
Ich freue mich, wenn du als Dankeschön für diese Arbeit auf eine meiner Seiten verlinkst.

Frank Doerr aka Loewenherz, Aschaffenburg, 31.05.12
Website: www.wolke23.de
Download via http://www.meinhosting.de

Download

Hier nun der Link zum Download – ich teste erstmals Pay with a tweet bzw. via Facebook – Deutsche Sprachdateien für City Guide Theme von Woothemes

Trackback-Problem bei Wordpress

Veröffentlicht am: 07. Feb 2011

In den letzten Wochen habe ich bei Wordpress zunehmend das Problem festgestellt, dass Trackbacks nicht ankommen. Okay, strenggenommen sind es Pingbacks, aber aufgrund der in den Kommentaren stets sichtbaren Bezeichnung, dürfte der Begriff Trackback für die meiste vertrauter sein.

Was sind Pingbacks? Eine der ganz großen Stärken von Wordpress: Blog A informiert Blog B darüber, dass aus einem Artikel von Blog A auf einen Artikel von Blog B verlinkt worden ist. Daraufhin verlinkt Blog B den Artikel von Blog A in den Kommentaren zum verlinkten Artikel. Diese Technik ist es, wovon die ganze Blogosphäre profitiert. Vernetzung erfolgt, man erfährt, wenn sich jemand auf einen Artikel bezieht etc.

Dummerweise funktioniert diese Technik nicht mehr richtig.  Im Artikel „Der Pingback-Ärger mit Wordpress“ (jo, genau, das ist ein Pingback) wurde dies bereits für die Version 2.7 festgestellt. Doch bei mir taucht das Problem auch mit Version 3.0.4 immer wieder auf. Nicht unbedingt reproduzierbar, aber soweit ich es verstehe, hängt es eben auch von der Erreichbarkeit der angepingten Blogs ab. Die Lösung aus obigem Artikel könnte immer noch funktionieren:

  • Öffne die Datei /wp-includes/cron.php mit einem Texteditor
  • Suche einfach nach dem Wert 0.01. Bei mir fand er sich in Version 3.0.4 in Zeile 234: „wp_remote_post( $cron_url, array(‚timeout‘ => 0.01, ‚blocking‘ => false, ’sslverify‘ => apply_filters(‚https_local_ssl_verify‘, true)) );“
  • Ersetze die Zahl 0.01 durch die Zahl 1. Dadurch erhält dein Blog mehr Zeit, andere Blogs über den Pingback zu informieren
  • Speicher und lade die veränderte Datei hoch. Fertig.

Die Lösung wirkt auf mich schlüssig, ich teste grade durch. Weitere Tipps sind in den Kommentaren oder Trackbacks willkommen.

Ausgehende Links im Kommentar-Widget von Wordpress entfernen

Veröffentlicht am: 19. April 2010

In Zeiten von Spam kann eines sehr nerven: Wenn die eigene Startseite bzw. alle Unterseiten mit Links zu den Websites der Kommentierenden vollgepflastert sind. Dies geschieht dann, wenn man die Website komplett mit Widgets betreibt.

Denn sobald das Widget „Letzte Kommentare“ zum Einsatz kommt, landet der ausgehende Link auf der Startseite bzw. durch die Sidebar auf allen Unterseiten des Blogs. Und das können zehn (Standard) oder gar fünfzehn (Obergrenze) Links sein, je nachdem, was man als Einstellung gewählt hat.  Die Folge: Es wird massiv Linkjuice vom eigenen Projekt abgezogen, egal ob Kommentare im Blog als nofollow oder dofollow gekennzeichnet sind.

Klar, man kann Kommentatoren (solange sie nicht Bernd Sonnensegel heißen oder sonstwie offensichtlich Links abgreifen wollen) gern mit einem Link belohnen. Aber es muss nicht wirklich auf der Startseite bzw. sidewide sein, die Artikelseite genügt. Dummerweise ist dies eine der Einstellungen (wie beispielsweise bei der Tag Cloud), wo die hart verdrahtete Einstellung von Wordpress unschön ist. Da hilft nur mal wieder ein kleiner, operativer Eingriff.

Also:
Öffne Datei wp-includes/default-widgets.php
Suche den Textteil get_comment_author_link
Ändere zu  get_comment_author
Speichern, hochladen in den Ordner /wp-includes
Fertig

Bei jedem Wordpress-Update, wo diese Datei verändert wird (und Wordpress ändert öfter was in den widgets), muss dies leider wiederholt werden. Ich frage mich, ob es nicht sinnvoll wäre, wenn das Wordpress-Entwicklerteam einen Ordner für die Widgets anlegen und jedem Widget seine eigene Datei geben würde, der Anfang ist durch die Liste zu Beginn der widgets.php ja bereits gemacht. Zumal – siehe oben – auch bei der tagcloud händisch eingegriffen werden muss. Oder die Steuerung im Adminbereich wird endlich komfortabler.

Kommentar von Andreas: Frank’s scharfes Auge, gut beobachtet. Alternativ könnte man das gewünschte Widget aus default-widgets.php rauskopieren und mit den o.g. Änderungen in den wp-plugins Ordner schieben. Jetzt den Namen ändern und schon hat man ein eigenes Widget. Das könnte evtl. irgendwann aufgrund von internen WP Änderungen nicht mehr funktionieren (wobei in dem fall eher unwahrscheinlich) aber zumindest wird es nicht überschrieben..

Elegant Themes: Wordpress URL-Problem bei featured articles

Veröffentlicht am: 18. März 2010

Eine der schönsten Themequellen für Wordpress ist Elegant Themes. Für jährlich knapp 20 Dollar kann man sich eine große Menge hervorragend designter Templates für Wordpress herunterladen. Einige der Features sind beispielsweise die Lieferung der PSD-Dateien zum Anpassen des Templates an eigene Wünsche, eine mächtige Verwaltung der Themeeinstellungen im Backend, Advertisement Ready für verschiedene Bannergrößen und last but not least die Möglichkeit, bestimmte Blogeinträge als featured articles prominent und optisch ansprechend zu platzieren. Geile Sache.

Genau bei diesen featured articles entdeckte ich heute bei einem Blog ein Problem. Ein neuer Artikel wurde in einer neuen Kategorie gepostet. Die URL lautete überraschenderweise http://www.domain.de/featured-articles/neuer-artikel.html. Ooops. An sich sollte die URL aber lauten http://www.domain.de/neue-kategorie/neuer-artikel.html. Was war passiert?

Wordpress vergibt intern IDs für Artikel, Kategorien etc. Werden einem Artikel mehrere Kategorien zugeordnet – und das ist bei einem featured article der Fall – bestimmt die Kategorie die URL, welche zuerst angelegt worden ist, also die niedrigere ID besitzt. In diesem Blog hatte eine Mitarbeiterin die Kategorie featured articles als eine der ersten angelegt, also dominierte sie.

Das Problem daran: Klar ist zum ersten, dass das Keyword in der URL verschwindet, das die Hauptkategorie bringen kann. Wesentlich schlechter ist aber ein anderes Ding: Kein Artikel bleibt ewig ein featured article. Sobald man ihn aber dort herausnimmt, ändert sich seine URL. Backlinks, Trackbacks etc. gehen ins Leere, Rankings verloren, Google muss die neue URL suchen.

Lösungen

Zum einen ist es hilfreich, featured articles möglichst als letzte Kategorie anzulegen, damit er eine möglichst hohe ID erhält. Trägt man später eine neue Kategorie nach, muss man featured articles erst löschen und danach wieder neu anlegen. Dumme Sache. Eventuell könnte es helfen, die IDs direkt in der Datenbank zu verändern, aber ich habe dies noch nicht getestet auf mögliche andere Auswirkungen.

Hat man bereits mehrere Artikel mit der falschen URL im Googleindex, dann hilft im Anschluss an obige Maßnahmen nur ein Eintrag für jeden Artikel in der .htaccess nach folgendem Schema:

Redirect 301 /featured-articles/artikel.html http://www.domain.de/kategorie/artikel.html

Soweit. Weitere Anregungen oder elegantere Lösungen werden gern entgegen genommen :)

Schriftgröße des Wordpress Tag-Cloud Widget ändern

Veröffentlicht am: 23. Feb 2010

Die Schriftgröße des Tag-Cloud Widget in Wordpress ist leider hart verdrahtet – muss aber verändert werden, wenn bei langen Worten plötzlich das Layout gesprengt wird. Für viele User ein Grund, die Sidebar konventionell über das Theme zu verwalten und lieber auf die Widgets zu verzichten. Muss nicht sein, denn man kann eingreifen. An dieser Stelle eine Zusammenfassung meiner Tipps, die ich bislang im Wordpress Forum gepostet habe:

Bei Wordpress 2.7.x :

Datei: includes/widgets.php
Suche wp_tag_cloud();
Findet man z.B. in Zeile 1874 (2.7.1) oder in Zeile 1372 (2.8.6)
ersetzen durch:
wp_tag_cloud(’smallest=8&largest=16′);
(gegebenenfalls letzten Wert kleiner setzen)

Bei Wordpress 2.8.x und 2.9.x :

Datei wp-includes/category-template.php
Suche: function wp_tag_cloud und dann darunter die Zeile mit „largest“ – bei mir aktuell in Zeile 530
dort kann man direkt einstellen: „largest“ (Standard auf 22, ich empfehle z.B. 16).

Mit 2.9.x also noch einfacher also als bisher. Wer weiß, vielleicht nähert sich die Lösung bald via Backend bei WP 3.0.
Ansonsten muss bis dahin bei Updates das Procedere möglicherweise wiederholt werden (falls die betroffene Datei im Updatepaket modifiziert wurde), bis WP die Widgetverwaltung für die Tagcloud via Administrationsbereich ausbaut.

WordPress.com Stats ist Schrott

Veröffentlicht am: 08. Juni 2009

Aufgrund meiner Rezension von Peruns Wordpress-Buch habe ich einiges gelernt bzw. mich zu diversen Dingen inspirieren lassen. Eine Sache waren die Plugins, die Perun für Wordpress empfiehlt. Eines der wichtigsten Plugins war für mich in den letzten Jahren Shortstat. Perun empfahl dagegen WordPress.com Stats. Keine leichte Entscheidung…

Shortstat hat ganz klar mehrere Nachteile: Es läuft auf dem eigenen Server und erzeugt als typisches Statistikmodul eine Menge Daten. Bei Blogs mit viel Traffic dauert es eine Weile, bis man die Statistik präsentiert bekommt. Und im Laufe der Jahre stellte ich fest, dass sich grade dieses Plugin gern mal „verschluckte“ und für Probleme sorgte, zumal bei meinem trafficstärksten Blog. Nichts, was sich nicht beheben ließe. Aber man muss ein Auge drauf haben.

Dann empfahl Perun in seinem Buch WordPress.com Stats. Ich bin kein Freund von Plugins, bei denen man sich erst registrieren muss, um sie nutzen zu können. Andererseits stellte ich grade von SpamKarma2 auf Akismet um, das ich bislang nie genutzt hatte und war sehr zufrieden. Direkt eine Empfehlung für das Statistik-Plugin, das ich sofort bei zwei neuen Projekten einsetzte anstelle des bisherigen Shortstat.

Doch die Freude über schöne Statistiken währte nur kurz. WordPress.com Stats spinnt – diese Zeile sprang mir bei der Google-Suche ins Auge, als sich recht bald Probleme einstellten. Wenn ich unter „Dashboard“ im der Admin-Navigation auf die Statistiken wechseln wollte, musste ich mich mit meinem Wordpress-Account einloggen. Username und Passwort stimmten, doch es tauchte wieder der Login auf. Keine Fehlermeldung, keine Statistik, nichts. Und wie sich im deutschen Forum zeigte, hatten einige das Problem. Lösung? Nicht in Sicht.

Mittlerweile sind fast vier Wochen vorbei. Weiterhin keine Chance auf meine Statistiken bei den beiden Blogs mit WordPress.com Stats. Die Projekte mit Shortstat dagegen laufen sauber und auch dieses Plugin wird weiter entwickelt. Insofern habe ich heute den Schlussstrich gezogen: Das Wordpress-Plugin flog raus, Shortstat wurde auch dort eingespielt. Und ich kann perun nur empfehlen, diese Alternative in einer möglichen Neuauflage seines Werkes zumindest zu erwähnen…

Wordpress Theme Blix – Volltext abstellen bei Kategorien, Tags und Archiv

Veröffentlicht am: 09. Feb 2009

Das Wordpress Theme Blix ist sehr beliebt im Netz und wird immer wieder für neue Versionen angepasst, auch wenn die ursprünglichen Erschaffer und der Mensch, der die deutsche Lokalisierung angefertigt hat, sich nicht weiter darum kümmern. Selbst in der Version, die bei Wordpress 2.6.3 problemlos funktioniert, gibt es ein dickes Handicap aus der Sicht der Suchmaschinenoptimierung:

Auf allen Ãœbersichtsseiten – also Kategorie, Archiv und Tags – wird der komplette Volltext eines Artikels angezeigt. Das bedeutet massiven duplicate content für Google. Nun könnte man diese Ãœbersichtsseiten auf noindex setzen, verschenkt damit aber Potential (zuweilen ranken tag-Seiten nämlich brutal gut). Also macht es Sinn, diese weiterhin indexieren zu lassen, aber es so umzustellen, dass nur noch ein Einleitungstext angezeigt wird.

Dies wird folgendermaßen erreicht: Öffne die Datei archive.php. Gehe in Zeile 60. Dort findet sich (Achtung, eckige Klammern durch spitze Klammern ersetzen):

[?php ($post->post_excerpt != "")? the_excerpt() : BX_shift_down_headlines($post->post_content); ?]

Diese Zeile dann bitte ersetzen mit:

[?php the_excerpt() ?]

Bei einem von mir mit Blix betriebenen Wordpress-Blog klappt die Anzeige damit. Sollte jemand dasselbe Problem mit anderen Templates haben, könnte dies ebenfalls die Lösung bringen. Alternativ einfach die Phrase the_content mit the_excerpt ersetzen, wie hier beschrieben.

Wordpress-HowTo: Umwandeln von Seiten in Artikel

Veröffentlicht am: 24. Sept. 2008

Beim Updateprozess von Wordpress 2.3.3 auf 2.6.2 zeigte sich bei einem Blog folgendes: Ich hatte dies vor weit über einem Jahr als proof-of-concept für die Nutzung von Wordpress als Content Management System angelegt. Das heißt: Fast alle Inhalte bestanden aus Seiten (Pages), während Artikel (Posts) kaum zum Einsatz kamen. Nun zeigte sich, dass dies einige Nachteile mit sich brachte:

Beim Umstieg vom bisherigen Tagging-Widget auf das bei Wordpress integrierte Widget wurden nur noch die Tags der drei oder vier Artikel angezeigt. Die Tags der Seiten waren allerdings wesentlich wichtiger. Auch sonst gab es zahlreiche Dinge, die mich störten. Auch wenn Wordpress sich immer mehr von einem reinen Blog-System in Richtung Content Management System entwickelt, gibt es hier doch noch einige offene Baustellen. Und ich mochte nicht mehr auf einige Plugins angewiesen sein, um dieses Manko auszubügeln.

Damit war klar: Die derzeit optimale Lösung würde darin bestehen, alle Seiten in Artikel umzuwandeln. Eine Neuanlage war indiskutabel: Zu viel Arbeit, alle Kommentare etc. würden verloren gehen. In Wordpress selbst fand ich keine Lösung dazu – ähnlich wie bei Joomla 1.0.x, wo static pages einfach nicht in Content umgewandelt werden können, der zu Categories oder Sections gehören konnte. Ein Umstand, der mit Version 1.5 glücklicherweise behoben wurde. Wordpress bietet diese Flexibilität scheinbar noch nicht.

Ein Blick in die Datenbankstruktur zeigte mir, dass Wordpress hier aber mittlerweile schon den Weg bereitet hat. Der einzige Unterschied zwischen den beiden Posting-Varianten besteht in der Definition des post_type. Früher waren die Unterschiede wohl gravierender, wie sich in einem mittlerweile nicht mehr ganz passenden Kommentar-Tipp im Netz fand.

Also schrieb ich kurz ein MySQL-Snippet, dass ich in PHPMyAdmin eingab:

UPDATE ‚wp_posts‘
SET ‚post_type‘ = REPLACE(‚post_type‘, ‚page‘,’post‘)
WHERE ‚post_type‘ LIKE ‚%page%‘

Das war’s dann schon. Nun musste ich nur noch hingehen und bei den wenigen Seiten, die Seiten bleiben sollte, dies wieder ändern.

Allerdings waren die neuen Artikel nun der Standard-Kategorie zugeordnet. Also im Adminbereich noch neue Kategorien angelegt und die Seiten von Hand dort einsortiert. Dabei zeigte sich, dass durch die Arbeit in der Datenbank bereits Google angepingt worden war und die ersten Artikel bereits mit der Standard-Kategorie-URl im Index hatte. Unglaublich und nicht ganz gewünscht. Also die sitemap.xml aktualisiert, damit Google die neuen URLs zügig kennen lernt.

Kurz und gut: Arbeit von knapp einer Stunde und alles läuft jetzt wie gewünscht.

Updates von Wordpress 2.3.3 auf 2.6.2

Veröffentlicht am: 24. Sept. 2008

Viele meiner Wordpress-Installationen waren bei Version 2.3.3 stehen geblieben. Dies war die letzte Version der 2.3er-Reihe. Ob hier Sicherheitslücken bestanden? Unklar. Bei Wordpress wechseln die Releases der Zweige derzeit schneller als man gucken kann. Ob also eine Lücke in 2.6.x nur den 2.6er-Zweig betrifft oder auch früherer, bleibt unklar.

Klar zeigte sich jedenfalls, dass die 2.6er-Reihe eine tolle Weiterentwicklung ist. Die gesamte Ãœberarbeitung des Adminbereichs mit verschiedenen neuen Features wie der Anzeige von Plugin-Updates, des neuen Bild-Uploades usw. ist einfach ansprechend.

Insofern stand die letzten Wochen eine Update-Welle an. Knapp 30 Blogs (eigene und Kundenblogs) mussten von 2.3.3 auf 2.6.1 bzw. das im Laufe der Arbeiten erschienene 2.6.2 aktualisiert werden. Vorneweg: Es gab keine wirklichen Probleme.

Das Verfahren war immer identisch:

  1. Backup der Datenbank mit MySQLDumper
  2. Backup des Webspaces
  3. Löschung aller Ordner und Dateien mit Ausnahme von /wp-content/ sowie .htaccess und wp-config.php
  4. Upload der Dateien im Root-Ordner, /wp-includes, /wp-admin und des neuen /wp-content/languages
  5. Aktualisierung der Datenbank

Alles Schritte, die sich nebenbei ganz gut erledigen ließen. Der jeweilige Blog war dadurch für allerhöchtens fünf Minuten (eher weniger) nicht erreichbar.

Aufwändiger war da schon die Aktualisierung der Plugins, auf die WP jetzt so nett hinweist. Bei den meisten Blogs kommen allerdings die selben Plugins zum Einsatz, da ich hier eigene Standards gesetzt habe, so dass auch dieser Schritt zur Routine wurde.

Die paar auftauchenden Probleme waren folgende:

  • Bei einer Installation funktionierte das Template nicht ganz korrekt und konnte ergänzt werden.
  • Bei zwei Installationen bei demselben Provider tauchten – einmal sobald wpSEO aktiviert wurde folgende Fehlermeldung auf:
    Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 80757 bytes) in …/wp-admin/includes/plugin.php on line 4Eine ähnliche Meldung gab es beim zweiten Problemblog beim Updateprozess der 2.6.2. Hier findet sich dazu eine Lösung: http://faq.wordpress-deutschland.org/exhausted-php-memory/:
    „Es gibt allerdings Webhoster, bei denen das memory_limit unnötig/ungewöhnlich niedrig gesetzt ist. Du solltest dich also ruhig mit Verweis auf die bei dir auftretende Fehlermeldung, an deinen Webhoster wenden und fragen, ob es möglich wäre, den Wert des memory limits in der php.ini zu erhöhen.“
    Da ich bei jenem Provider Zugriff auf Confixx habe, konnte ich in der httpd Spezial den Wert  php memory_limit bis 64MB setzen – und alles funktionierte.

Das war alles. Ansonsten war es eine gute Gelegenheit, überall nach dem Rechten zu sehen, alles auf den neusten Stand zu bringen und nicht mehr benötigte Plugins aufzuräumen, indem beispielsweise Tags in WP importiert wurden und dort nun kein Plugin mehr verwendet wird. Insgesamt hat sich der Updateprozess vollkommen gelohnt.

Wenn keine Kommentare in Wordpress möglich sind

Veröffentlicht am: 01. März 2008

Manchmal macht es Sinn, in eigenen Blogs einen Kommentar zu schreiben. Vor allem dann, wenn seit einiger Zeit kein Kommentar mehr von Surfern kam. Denn vielleicht lag es nicht daran, dass sich keiner für dieses Blog interessiert – bei einem etablierten Blog ohne nofollow kaum möglich *g* -, sondern daran, dass etwas nicht in Ordnung ist. So erlebte ich es durch Zufall grade bei einem meiner Blogs.

Beim Versuch einen Kommentar zu schreiben, tauchte folgendes auf:

Structural failure: no comment ID sent to comment hook
Aborting Spam Karma

Woran konnte das liegen. Und warum redete SpamKarma mit mir plötzlich englisch? Also mal die deutsche Sprachdatei wieder korrekt installiert, die bei Aufräumarbeiten wohl gelöscht worden war.

Struktureller Fehler: Es wurde keine Kommentar-ID an den Kommentar-Hook gesendet. Spam Karma abbrechen

Super, das war doch direkt schon ein Fortschritt. SpamKarma als Ãœbertäter? Ich deaktivierte das Plugin. Ergebnis: Keine Fehlermeldung mehr. Aber Kommentare wurden dennoch nicht eingetragen, ohne dass der Fehlversuch irgendeine Ausgabe brachte. Es wurde einfach die kommentierte Seite ohne den Kommentareintrag geladen. Das Problem lag also woanders. SK2 also wieder aktiviert.

Lag es an dem vor kurzem durchgeführten Update auf die 2.3.x-Reihe oder dem uralten Template? Standard-Template drauf, alle Dateien von Wordpress 2.3.3 nochmals hochgeladen. Weiterhin der Fehler.

Der nächste Schritt führte in die Datenbank. Alle Tabellen mit Ãœberhang wurden optimiert. Fehler blieb bestehen. phpMyAdmin einmal freundlich gebeten, alle Tabellen zu analysieren. Und schau da:

Found key at page 55296 that points to record outs… dbname.sk2_blacklist analyze error Corrupt

Und noch verschiedene Fehler mehr. Hier das Ergebnis der Reparatur:

dbname.sk2_blacklist repair warning Number of rows changed from 6427 to 6428
dbname.sk2_blacklist repair status OK
dbname.wp_comments repair warning Number of rows changed from 17668 to 17669
dbname.wp_comments repair status OK
dbname.wp_sk2_logs repair warning Number of rows changed from 11014 to 11016
dbname.wp_sk2_logs repair status OK
dbname.wp_sk2_spams repair warning Number of rows changed from 17097 to 17098
dbname.wp_sk2_spams repair status OK
dbname.wp_ss_stats repair warning Number of rows changed from 14026 to 14027
dbname.wp_ss_stats repair status OK

Danach funktionierte alles wieder. Also: Sollte SpamKarma mal nicht jeden Tag den Spambericht nach Hause funken (so nervig es auch ist, jeden Tag von Dutzenden Blogs darüber informiert zu werden, dass kein Spam eingetroffen ist), dann zügig in die Datenbank. Denn ein Blog ohne Kommentare ist wie … ;-)

… ein solches Posting ohne Selbstversuch.

Wordpress als CMS – suchmaschinen-freundliche Sitemap

Veröffentlicht am: 23. Jan. 2007

Eines der hilfreichen Dinge bei der Erstellung eines suchmaschinen-freundlichen Webprojektes ist die Existenz einer Sitemap. Mit dem Google Sitemaps Generator und dem darauf aufbauenden Plugin Sitemapview existierenden bereits tolle Möglichkeiten. Letzteres wurde erst gestern aufgrund einer Anregung von mir optimiert. Doch ließe sich das Ganze nicht noch optimaler gestalten?

Was mir vorschwebte, war eine direkte Möglichkeit, die Sitemap automatisch zu erzeugen und zwar mit suchmaschinen-freundlichen Titeln direkt aus der Datenbank. Die Lösung ist wirklich einfach, valides XHTML und wurde mit Wordpress 2.1 erfolgreich getestet.

Umsetzung

Es wird ein Template erstellt – im Zweifelsfall einfach als Kopie der index.php -, das für die Sitemap verwendet werden soll. Ganz oben steht dann beispielweise (eckige Klammern müssen durch spitze Klammern ersetzt werden, also < durch [ – sorry, ging gerade nicht anders):

[?php
/*
Template Name: Sitemap

*/

?]

An der Stelle, an der die Ausgabe der Sitemap erscheinen soll, wird nun folgendes eingefügt:

[ul]
[?php wp_list_pages(’sort_column=menu_order&title_li=&child_of=0′ ); ?]
[/ul]

Nun wird eine neue Seite (Page) erzeugt. Diese darf Sitemap heissen, es ist allerdings zu beachten, unter „Page Slug“ als optimierten Titel nicht „Sitemap“ einzutragen. Eine gute Lösung wäre beispielsweise die Kombination des wichtigsten Keywords der Seite mit Bindestrich und „sitemap“, wie etwa „soziale-sitemap“. Dieser Page wird dann das Template „Sitemap“ zugewiesen. Fertig.

Viel Spaß damit. Bitte Tutorial nicht kopieren, sondern hierhin verlinken. Ich danke meinem Bruder Buckaroo für seine Unterstützung beim Austüfteln dieser Lösung.

Wordpress als CMS – automatische Child-Pages-List

Veröffentlicht am: 23. Jan. 2007

Wordpress ist zwar ein klassisches Blog-System, doch kamen findige Menschen bereits vor Jahren auf die Idee, es auch als CMS einzusetzen. Mit der vor wenigen Stunden erschienenen Version 2.1 und der Möglichkeit, feste Startseiten zu definieren, fördern die Programmierer exakt diese Entwicklung.

Basierend auf den hervorragenden Tutorials des Buchautors Perun erstellte ich ein persönliches Proof-of-Concept. Hier zeigte sich allerdings ein Problem: Auch wenn der Ansatz Peruns, sämtliche Inhalte über Pages zu realisieren, schlüssig ist, und die Möglichkeit, für jede Page ein eigenes Template zu erstellen, wundervolle Möglichkeiten bietet, so hat die von ihm gewählte Methode bei größeren Projekten einen Nachteil.

Denn Perun erzeugt in seinen Beispielen für jede Hauptelement ein eigenes Template. Für ein Projekt mit wenigen Hauptkategorien mag dies noch angehen. Was aber, wenn ein Projekt wie das Meine allein 16 Hauptkategorien enthält? Also 18 Pagetemplates, wenn man Impressum und Sitemap dazurechnet?  Wenn das Layout hier im Grunde gleich sein soll, erscheint mir dies überflüssig und schlecht in der Pflege.

Das einzige wirklich relevante Unterschied liegt nämlich im Aufruf der jeweiligen Subnavigation, der Anzeige der gelisteten untergeordneten Pages. Und hier bietet es sich an, dies alles PHP zu überlassen.

Umsetzung

Es wird ein Template erstellt, das für alle Pages verwendet werden soll. Ganz oben steht dann beispielweise (eckige Klammern müssen durch spitze Klammern ersetzt werden, also < durch [ – sorry, ging gerade nicht anders):

[?php
/*
Template Name: Allpages
*/
?]

An der Stelle, an der die jeweilige Subnavigation erscheinen soll, wird nun folgendes eingefügt:

[ul]
[?php
for ($i=1;$i<30;$i++)
{
if(is_page($i))
{
$dings = „sort_column=menu_order&title_li=&child_of=“.$i;
wp_list_pages($dings);
}
}
?]
[/ul]

Dabei ist die Zahl 30 willkürlich gewählt, wer mehr Hauptpages verwendet (bzw. wenn diese bereits in einem höheren ID-Bereich liegen), kann diesen Wert auch höher setzen.

Nun wird in der Verwaltung jeder Page das Template „Allpages“ zugewiesen. Fertig.

Viel Spaß damit. Bitte Tutorial nicht kopieren, sondern hierhin verlinken. Ich danke meinem Bruder Buckaroo für seine Unterstützung beim Austüfteln dieser Lösung.