10 frische, kostenlose WordPress-Themes aus dem offiziellen Verzeichnis

28. März 2012

Kostenlose Themes für wirklich jede Art von Websites sind eine der wesentlichen Stärken von WordPress. Darum liegt der Schwerpunkt der Entwicklung für die Version 3.4 auch auf dem einfachen Wechsel und der leichten Konfiguration des Blogdesigns.

Grund genug, mal wieder einen Blick in das offizielle Theme-Verzeichnis zu werfen und nachzusehen, welche schönen Gratis-Designs die Theme-Autoren für die Community in den ersten paar Monaten des Jahres entworfen haben.

Hier sind zehn meiner Favoriten aus dem heurigen Jahr:

Delicacy

delicacy

Ein kulinarisches WordPress-Theme für die Blogs von “Foodies”.

Autor: alex27

Esquire

esquire

Ein elegantes und ausdrucksstarkes Theme mit vielen optisch unterschiedlich gestalteten Artikel-Formaten.

Autor: Automattic

Hatch

hatch

Hatch ist ein einfaches Theme für Fotoblogs und Portfolios von Designern oder bildenden Künstlern. Optimiert für kleinere Bildschirme von Smartphones und Tablets.

Autor: Griden

Origin

origin

Minimalistisches Theme mit adaptivem Layout.

Autor: Griden

Oxygen

oxygen

Schlichtes Theme für Magazine, die gerne unterwegs auf dem Smartphone gelesen werden.

Autor: Griden

Patchwork

patchwork

Handarbeiten, basteln, nähen und dann darüber bloggen: Die drei verschiedenen Farbstile passen zu vielen kreativen Hobbys.

Autor: sixhours

Rumput Hijau

rumput-hijau

Ein typografischer Leckerbissen, der auch den Suchmaschinen schmeckt.

Autor: satrya

Scrappy

scrappy

Feminin, erfrischend, im Stil der in Europa erst Fuß fassenden Scrapbooks.

Autor: sixhours

Sundance

sundance

Ein Theme für Videos, passend für Inhalte aus YouTube oder Vimeo, aber auch für selbstpubliziertes Filmmaterial.

Autor: Automattic

Vintage Camera

vintage camera

Ein Theme im Sixties-Retrostil mit einer markanten Analogkamera als Signet. Für den traditionsbewussten Schwarzweiss-Fotoblogger.

Autor: sixhours

Kommentare [3]

So wird das deutsche WordPress ab Version 3.4 gravierend schneller

28. Februar 2012

Die deutsche Spracheinstellung kostet WordPress teilweise über 40 Prozent Geschwindigkeit im Vergleich zur englischen Variante. Die Hauptursache ist die aufwendige und speicher-fressende Übersetzungsbibliothek, die WordPress bei jedem Seitenaufruf abarbeiten muss, um die originalen englischen Texte in ihr deutsches Gegenstück zu übersetzen.

Dazu wird der Webserver durch eine träge in PHP geschriebene Nachahmung von Funktionen gequält, die in vielen Fällen bereits als schneller C-Code im Betriebssystem des Webservers vorhanden sind – die sogenannte gettext-Bibliothek.

Langsames WordPress als Resultat von “günstigem” Webspace

Kann das deutsche WordPress auf diese “nativen” C-Funktionen zurückgreifen, reduziert sich der Übersetzungs-Overhead auf schlanke vier Prozent. Gleichzeitig sinkt der Hauptspeicher-Verbrauch des Webservers, sodass als Konsequenz WordPress auch wieder auf billigeren Webhosting-Paketen mit etwas niedrigerem memory_limit laufen könnte. Es gibt ja immer noch günstige Webspace-Angebote, bei dem der Hoster dieses Speicherlimit für PHP auf asketische 32 MB gesetzt hat.

Und beim Webspace-Anbieter liegt auch in Zukunft “der Hund begraben”: Die gettext-Erweiterung für PHP ist ein optionaler Bestandteil, den der Webhoster bereitstellen muss. Nicht auf jedem Webspace ist PHP mit dieser schnellen Extension eingerichtet, und in diesen Fällen wird sich an der Geschwindigkeit wahrscheinlich auch in Zukunft nichts ändern.

Licht → Tunnel

Für Nutzer aller anderen Webspace-Angebote ist Licht am Ende des Tunnels zu erkennen. Beim WordPress-Team ist ein Patch eingetrudelt, der die im Betriebssystem eingebauten schnellen gettext-Funktionen in WordPress integriert, und Andrew Nacin hat vorsichtig signalisiert, dass dieser Patch in die Version 3.4 eingearbeitet werden könnte.

Leider zeigt WordPress nirgendwo im Dashboard an, ob die schnelle oder die langsame Variante der Übersetzungsbibliothek genutzt wird – die Auswahl erfolgt vollständig ohne Eingriffsmöglichkeit für den Anwender, indem die vorhandenen Fähigkeiten (oder eben auch Unfähigkeiten) des Webservers benutzt werden.

Ein Diagnose-Plugin

Ich habe darum das Plugin Native gettext diagnosis geschrieben, das sich als zusätzlicher Eintrag im Menü “Werkzeuge” einnistet und eine Reihe von Tests durchführt.

Screenshot des Plugins “Native gettext diagnosis”

Ist die PHP-Erweiterung “gettext” geladen und das Ergebnis des Tests “WordPress kann das locale setzen” ein “Ja”, kann WordPress zumindest nach dem derzeitigen Stand der Entwicklung in Version 3.4 schneller werden.

Das Plugin funktioniert auch ab WordPress 3.2 und kann daher schon jetzt benutzt werden, um festzustellen, ob der eigene Webspace mit WordPress 3.4 schneller oder langsam arbeiten wird.

Mein Tipp: “Native gettext diagnosis” installieren, den Menüpunkt “Werkzeuge → Gettext-Diagnose” aufrufen und bei negativem Resultat entweder den eigenen Webhoster kontaktieren oder schlimmstenfalls den Webspace-Anbieter wechseln.

Meine eigenen Tests zeigen, dass zum Beispiel Host Europe, Uberspace und Dreamhost die schnelle gettext-Extension anbieten, während auf Windows basierende Hoster da leider oft passen müssen.

Kommentare [28]

21 nützliche Code-Schnippsel für functions.php

20. Februar 2012

Die Darstellung des Volltexteditors anpassen, Einbruchsversuche mit leicht erratbaren Benutzernamen und Passwörter erschweren, jQuery direkt aus den Google-Netzwerk laden lassen und vieles mehr kann man in WordPress über einige wenige Zeilen in der Datei functions.php des Themes steuern.

Eine wachsende Sammlung solcher nützlicher Schnippsel stellt Merlin Mason zusammen mit einer einfachen Copy & Paste-Funktion auf wpfunction.me zur Verfügung.

wpfunction.me

Gut abgelagerte WordPress-Veteranen werden wahrscheinlich den größten Teil schon kennen oder ein Plugin für den einen oder anderen Zweck aus dem Ärmel schütteln. Aber wer ohne großen Rechercheaufwand das Plugin-Arsenal auf seiner WordPress-Installation ein wenig abmagern möchte, sollte mal einen Blick auf die Sammlung werfen.

Kommentare

5 Wege, um sich in WordPress 3.4 anzumelden

14. Februar 2012

Welcher Webdesigner kennt nicht solche Fälle: Ein Kunde hat eine bestehende, etwas in die Jahre gekommen Website, die im Prinzip noch gut genug ist. Aber schön wär’s doch, wenn der Bereich mit den Neuigkeiten aus dem Unternehmen und den Pressemeldungen etwas einfacher zu verändern wäre und er nicht immer einen Dienstleister beauftragen müsste, um nur ein paar Absätze zu veröffentlichen.

Also installiert man WordPress in einem Unterordner auf dem Webspace, baut ein passendes Theme und zeigt dem Kunden kurz, wie er sich anmelden und einen neuen Beitrag schreiben kann.

Kaum ein paar Monate später möchte der dann schon seine zweite Meldung eingeben und meldet sich ganz verzweifelt: Weg ist er, der Zettel mit den Zugangsdaten, die Adresse zum Anmelden findet er nicht mehr in den Explorer-Favoriten, und probiert hat er auch schon alle möglichen URLs. Ob “WordPress.php”, “login”, “admin”, überall kommt nur eine Seite mit diesem hämischen

Seite nicht gefunden. This is somewhat embarrassing, isn’t it? It seems we can’t find what you’re looking for.

Das ist verständlich. Mit der Zeit gewöhnt man sich als Dienstleister sogar an, schon vorbeugend ein paar solcher Shortcuts direkt in der .htaccess anzulegen und seinen Kunden den Stress zu ersparen.

WordPress 3.4 hilft bei Gedächtnisschwäche

Mit WordPress 3.4 kommt eine kleine Verbesserung für Leute, die den Zugang zum WordPress-Dashboard vergessen haben: Für eine Reihe von “beliebten” Rate-Versuchen leitet WordPress automatisch auf die korrekten URLs für Login und Dashboard um. Voraussetzung dafür ist, dass “schöne” Permalinks verwendet werden.

Hier ist die vollständige Liste von Pfaden, die WordPress 3.4 zur Anmeldung und zum Dashboard führen:

Ich hatte vorgeschlagen, diese Liste noch um /wordpress und /WordPress zu erweitern, aber Andrew Nacin hielt das für doch zu verwirrend und ließ sich (leider) nicht überzeugen.

Kommentare [5]

Sicherheitsanalyse reiht WordPress vor Joomla und TYPO3

7. Februar 2012

Für eine Studie über die Sicherheit von WordPress, TYPO3, Joomla, Drupal und anderen Content-Management-Systemen hat Philipp Krenn die Release Notes und Security Advisories der jeweiligen Projekte analysiert. Die Systeme wurden nach Häufigkeit und Schwere der in den Jahren 2010 und 2011 veröffentlichten Sicherheitslücken gereiht.

Dieses Diagramm zeigt eine Zusammenfassung der Analyse:

CMS-Sicherheit (qualitativ)

Wie man sieht, zeigen sich große Unterschiede zwischen den Systemen:

  • WordPress hatte nur eine schwere Sicherheitslücke in diesen beiden Jahren.
  • Joomla hängt der Ruf eines unsicheren Systems nach. Für dieses schlechte Image liefert die Analyse keine Beweise. Es gab zwar relativ viele, aber nur leichte Sicherheitsprobleme.
  • TYPO3 ist das Schlusslicht unter den beteiligten CMSen und zeigt die meisten, auch schweren Sicherheitslücken.

Natürlich lässt sich die Sicherheit eines CMS nicht objektiv nur über das Auszählen der gemeldeten Fehler messen.

Bei WordPress werden zum Beispiel weder Sicherheitslücken in Themes noch in Plugin offiziell gemeldet, während Drupal Advisories sowohl für den CMS-Kern als auch alle Module veröffentlicht. Drupal und TYPO3 verwenden eine definierte Systematik, um die Schwere der Sicherheitsmängel zu kategorisieren. Für WordPress gilt das nicht.

Die vollständige Studie ist hier zu finden.

Grafik: Phillipp Krenn, CC-BY-SA.

Kommentare [7]