CMS | t3n News News, Infos, Tipps und aktuelle Artikel zu CMS 2014-08-19T12:52:14Z t3n Redaktion http://t3n.de/tag/cms Exklusiv: LaterPay für alle! WordPress-Plugin für Paid-Content ab sofort kostenlos verfügbar [Update] http://t3n.de/news/laterpay-557417/ 2014-08-19T12:52:14Z
Das WordPress-Plugin des Münchener Startups LaterPay gilt als deutsche Hoffnung für die Finanzierung journalistischer Inhalte im Netz. Nach einer geschlossenen Testphase ist der Bezahldienst jetzt …

Das WordPress-Plugin des Münchener Startups LaterPay gilt als deutsche Hoffnung für die Finanzierung journalistischer Inhalte im Netz. Nach einer geschlossenen Testphase ist der Bezahldienst jetzt für alle kostenlos nutzbar.

Update vom 19. August 2014: Das LaterPay-Plugin ist ab sofort im offiziellen Plugin-Release-Channel von WordPress.org zum Download erhältlich. Die Installation des Plugins zur Monetarisierung von Content auf Blogs und Webseiten sowie digitalen Gütern wird damit noch einmal erleichtert. Mit der aktuellen Versionsnummer 0.9.7.2 befindet sich das Plugin allerdings noch immer in einer offenen Testphase. Die Macher empfehlen weiterhin, LaterPay vor der kommerziellen Integration in einer separaten Testumgebung zu installieren.

LaterPay: WordPress-Plugin auf Github zum Download

Es ist soweit: Nach mehreren Monaten in der geschlossenen Testphase stellt das Münchner Startup LaterPay ab heute sein WordPress-Plugin zur Monetarisierung von digitalen Inhalten kostenlos zum Testen zur Verfügung. Alle Interessenten – ob Blogger, Journalisten oder Webseitenbetreiber – können sich das LaterPay-Plugin für WordPress über Github kostenlos runterladen und installieren.

Hinter dem Plugin steht die Idee, Leser und Konsumenten nur für jene digitalen Inhalte im Netz zahlen zu lassen, die sie auch tatsächlich gelesen haben. Der Preis für jeden Text wird individuell vom Urheber bestimmt, soll gemäß der Philosophie aber im Bereich einiger Cents bis hin zu wenigen Euro liegen. Die Zahlung wird erst dann veranlasst, wenn Leser Inhalte für insgesamt fünf Euro konsumiert haben. Neben der Möglichkeit, Paid-Content mit nur einem Klick einzusehen und zu bezahlen, können Nutzer die Zahlung für einen Text bei Nichtgefallen auch revidieren. Autoren, Verleger und Urheber wiederum werden mit einem Algorithmus vor Missbrauch dieser Funktion geschützt.

LaterPay-Nutzer wählen zwischen zwei Bezahlmodellen: dem Pay-per-use auf der einen, und dem Freemium-Modell auf der anderen Seite. Beim ersten Modell zahlen Leser beispielsweise für einen kompletten Artikel, beim zweiten Modell können kostenpflichtige und kostenlose Inhalte in Kombination angeboten werden – zum Beispiel kann ein Blogpost kostenlos, eine dazugehörige Infografik oder ein Video aber kostenpflichtig angeboten werden. Über die Preisstruktur bestimmen dabei die Seitenbetreiber.

LaterPay: Das WordPress-Plugin des gleichnamigen Münchener Startups ermöglicht das einfache Bezahlen journalistischer Inhalte im Netz. (Bild: LaterPay)
LaterPay: Das WordPress-Plugin des gleichnamigen Münchener Startups ermöglicht das einfache Bezahlen journalistischer Inhalte im Netz. (Grafik: LaterPay)

Das LaterPay-Plugin mit der aktuellen Versionsnummer 0.9.5.1 beinhaltet schon alle zum Verkauf von Content notwendigen Funktionen. Derzeit arbeite man aber beispielsweise noch an Videotutorials, Integrationsbeispielen und Testumgebungen, um die Nutzbarkeit des Bezahldienstes weiter zu verbessern. Als eine der wichtigsten Neuerungen als Ergebnis der geschlossenen Testphase preist LaterPay eine automatisierte Rechnungsstellung inklusive Umsatzsteuerausweis an. „Wir wissen aus viel Feedback, dass dies eine bei Bloggern, Journalisten und Content-Anbietern immer sehr wichtige Funktion ist“, sagt Daniel Raumer, verantwortlicher Produktmanager bei LaterPay.

Deutsches Startup mit dem Segen von Richard Gutjahr

Das Münchner Startup LaterPay unternimmt den Versuch, eine erste Antwort auf die schon seit Jahren schwelende Debatte um die künftige Finanzierung journalistischer Inhalte im Netz zu liefern. Während einige große deutsche Medien nach dem Vorbild von US-Verlagen eine allumfassende Bezahlschranke (Paywall) um ihre Inhalte errichten, hält der Großteil aus Mangel an entsprechenden Alternativen weiterhin an werbefinanzierten Geschäftsmodellen fest. Beide Lösungsansätze sind bei Lesern und Konsumenten jedoch umstritten.

Julian Assange und Richard Gutjahr, ConventionCamp 2012
Prominente Unterstützung bekommt LaterPay von Journalist und Blogger Richard Gutjahr. (Foto: ConventionCamp 2012)

Mit seinem WordPress-Plugin will LaterPay das ändern und weiß bekanntlich um prominente Unterstützung: Der Journalist und Blogger Richard Gutjahr hat bei dem 2010 von Cosmin-Gabriel Ene und Jonas Maurus gegründeten Unternehmen eine Beraterfunktion inne. Entsprechend wirbt Gutjahr für LaterPay, auf seinem Blog nutzt er das Plugin schon von Beginn an für die Monetarisierung seiner Inhalte. Neben Texten kann Laterpay zum Beispiel auch für die vereinfachte Bezahlung von Video-, Audio- und sogar Gaming-Inhalten im Netz genutzt werden.

So installierst du LaterPay auf deinem Blog

Es wird empfohlen, das LaterPay-Plugin zunächst in einer Testumgebung zu installieren, zu nutzen und erst danach in einer Produktivumgebung zu aktivieren. Losgelöst vom eigenen Blog lässt sich eine solche Testumgebung zum Beispiel über den Cloudhoster Digital Ocean fünf US-Dollar (circa 3, 60 Euro) monatlich einrichten. Neben der automatisierten Installation per Mausklick geschieht die anschließende Konfiguration des Plugins in drei Schritten: Zugangsdaten eingeben, Standardpreis festlegen und aktivieren. Eine Schritt-für-Schritt-Anleitung findet ihr in der nachfolgenden Bildergalerie.

Was Nutzer noch über LaterPay wissen müssen

Wie aber können Blogger, Journalisten und Content-Anbieter das LaterPay-Plugin zu gewerblichen Zwecken nutzen? Schließlich werden in der Testumgebung nur fiktive Zahlungen simuliert. Um reale Umsätze zu ermöglichen, müssen Nutzer ihre gültigen Live-API-Zugangsdaten im Plugin hinterlegen. Diese Daten erhält man, indem man einen sogenannten LaterPay-Händlervertrag ausfüllt und an das Startup zurückschickt.

Der Vertrag ermöglicht den Einsatz von LaterPay auf der Webseite, er verpflichtet jedoch nicht dazu. Fixkosten entstehen übrigens nicht, weder Registrierungs- noch Setup- oder Grundgebühren fallen bei LaterPay an. Nur für verkaufte Artikel führen Nutzer eine Provision in Höhe von 15 Prozent an Laterpay ab. Der Vertrag ist jederzeit monatlich und ohne Angabe von Gründen kündbar.

]]>
Daniel Hüfner
Mächtig und schnell: Das dateibasierte CMS Grav http://t3n.de/news/maechtig-schnell-dateibasierte-cms-grav-562643/ 2014-08-18T12:51:59Z
Wenn ihr ein dateibasiertes und schlankes Content-Management-System für eine Website sucht und des Markdown mächtig seid, solltet ihr euch Grav mal anschauen.

Wenn ihr ein dateibasiertes und schlankes Content-Management-System für eine Website sucht und des Markdown mächtig seid, solltet ihr euch Grav mal anschauen.

Grav: Schnelle Installation und schnelle Ergebnisse

Es dürfte wohl kaum ein Content-Management-System geben, das so schnell istalliert ist, wie Grav. Nachdem ihr Grav heruntergeladen habt, entpackt ihr es einfach in ein Verzeichnis und könnt loslegen. Benötigt wird lediglich PHP 5.4 oder neuer. Wenn ihr jetzt die URL aufruft, in die ihr Grav entpackt habt, sehr ihr schon eine Inhaltsseite, die euch die wichtigsten nächsten Schritte mit dem CMS näher bringt.

Sofort nach dem Entpacken einsatzbereit: Das CMS Grav. (Screenshot: Eigene Grav-Installation)
Sofort nach dem Entpacken einsatzbereit: Das CMS Grav. (Screenshot: Eigene Grav-Installation)

In dem grav-Ordner findet ihr dann einige Verzeichnisse, von denen ganz zu Anfang eigentlich nur user wichtig ist.

Wenn ihr euch die Datei in dem Ordner user/pages/01.home anschaut, werdet ihr feststellen, dass es eine Markdown-Datei ist. Wenn ihr eine neue Seite anlegen möchtet, dann erstellt ihr einfach einen neuen Ordner 02.newpage und darin dann eine default.md-Datei. An den Anfang der Datei kommen dann alle wichtigen Header-Informationen nach dem folgenden Schema:

---
title: New Page
slug: my-new-page
menu: New Page Menu Title
---

Mit title legen wir den Titel des Dokuments fest und das ist die einzige Angabe, die wirklich gesetzt werden sollte. slug überschreibt als optionale Angabe den automatisch erstellten Pfad, der dem Ordnernamen ohne die vorangestellte Zahl entspricht. Mit menu können wir den Titel im Menü verändern, der sonst der Angabe unter title entsprechen würde. Weitere Header-Angaben findet ihr in der Dokumentation.

Wenn ihr nicht wollt, dass die Seite in dem Menü aufgeführt wird, dann lasst ihr einfach die Zahl mit dem Punkt vor dem Ordnernamen weg. Alternativ könnt ihr auch die Angabe visible: false als weitere Header-Angabe in die Markdown-Datei schreiben. Mit der Zahl und dem Punkt im Ordnernamen wird standardmäßig die Reihenfolge der Einträge im Menü festgelegt. Der übrige Inhalt einer Seite wird in Markdown geschrieben.

Die grundlegenderen Konfigurationsdateien sind in der YAML-Syntax geschrieben. Im Ordner user/config/ findet ihr die system.yaml-Datei, in der ihr unter anderem Dinge wie das Datumsformat, die Sortierreihenfolge von Seiten et cetera einstellen könnt. Genauere Informationen findet ihr auch hier wieder in der umfangreichen Dokumentation.

Grav: Mächtige Bildfunktionen

Wenn ihr Bilder oder andere Medien-Dateien in eine Seite einfügen möchtet, dann kopiert ihr einfach das Bild in den Ordner der Seite und bindet es nach dem folgenden Schema ein (dafür müsst ihr im Header den Prozess twig auf true setzen – siehe Header-Dokumentationsseite):

{{ media['grav-cms-installiert.jpg'].html() }}

Daneben gibt es aber noch viel mehr Möglichkeiten, was ihr mit Bildern anstellen könnt. Ihr könnt problemlos das Bild verkleinern, indem ihr beispielsweise folgendes eingebt:

{{ media['grav-cms-installiert.jpg'].resize(200, 200, '75879a').html() }}

Damit wird das Bild an der längsten Seite auf 200 Pixel gebracht und der „leere Raum“ der kürzeren Seite, der zum Quadrat fehlt, mit der angegebenen Farbe gefüllt. Dabei wird das Bild nicht einfach per CSS skaliert, sondern wirklich als neues Bild erstellt. Ihr könnt daneben auch noch verschiedene Arten der Skalierung auswählen: Ohne die Ursprungs-Seitenverhältnisse zu berücksichtigen, mit Zuschneiden und so weiter. Außerdem bringt Grav auch noch einige Filter mit, wie etwa einen Helligkeits- und Kontrastfilter.

Fazit: Viele Möglichkeiten in einem schlanken System

Abschließend lässt sich sagen, dass Grav ein ziemlich mächtiges dateibasiertes CMS ist, mit dem viel bewerkstelligt werden kann. In diesem Artikel wurde der Fuktionsumfang nur angerissen, mehr Infos, unter anderem auch zu der Theme-Erstellung, findet ihr in der Dokumentation. Neben dem reinen Grundgerüst gibt es auch schon drei Themes zur Auswahl und einige Plugins.

]]>
Florian Brinkmann
Multi-User-Unterstützung und mehr: Das bringt die neue Version 0.5 der Blog-Software Ghost http://t3n.de/news/mutli-user-unterstuetzung-mehr-562064/ 2014-08-12T12:02:00Z
Ghost ist die Software eines ehemaligen WordPress-Mitarbeiters und soll dem Nutzer in einer schlanken Lösung einfach nur das Bloggen ermöglichen. Gestern wurde Version 0.5 des Systems …

Ghost ist die Software eines ehemaligen WordPress-Mitarbeiters und soll dem Nutzer in einer schlanken Lösung einfach nur das Bloggen ermöglichen. Gestern wurde Version 0.5 des Systems veröffentlicht, und die bringt einige neue Features mit.

Ghost: Multi-User-Unterstützung, offene JSON-API und mehr

Ghost bringt in der neuen Version drei Kern-Veränderungen mit. Zuerst, und für den „einfachen Nutzer“ vermutlich am interessantesten, ist die Unterstützung für mehrere Autoren – dieses Feature haben die Macher auch gleich in ihrem Blogbeitrag zur neuen Ghost-Version genutzt. Das dürfte ein Feature sein, was viele Nutzer oder potenzielle Nutzer von Ghost bislang stark vermisst haben.

Wichtiges neues Feature: Multi-User-Unterstützung bei Ghost. (Screenshot: Ghost)
Wichtiges neues Feature: Multi-User-Unterstützung bei Ghost. (Screenshot: Ghost)

Als zweites Kern-Feature wurde eine öffentliche JSON-API eingeführt, mit der ihr Web-, Desktop-, Android- und iOS-Apps auf Basis eines Ghost-Blogs aufbauen könnt. Jedes Feature von Ghost ist damit für Entwickler von Drittanwendungen zugänglich. In naher Zukunft werden die Entwickler die Authentifizierung per OAuth öffnen.

Als drittes Feature wird das technisch überarbeitete Backend genannt, das komplett neu in Ember.js geschrieben wurde. Neben diesen Schlüssel-Features wurde unter anderem das Standard-Theme überarbeitet und liegt nun in Version 1.0 vor, es gibt OAuth-Support, neue Funktionen für Theme-Entwickler, automatische Gzip-Komprimierung im Produktiv-System und Verbesserungen für die Nutzung auf mobilen Geräten. Alle Änderungen könnt ihr auf Gist finden.

Ghost ab sofort mit einem neuen Update-Zyklus

Bisher hat es Ghost mit Updates ungefähr so gehalten wie andere Open-Source-Systeme und zwei bis drei pro Jahr veröffentlicht. Das ist den Machern von Ghost nicht agil genug, weshalb sie jetzt zu einem Update-Zyklus übergehen, der alle zwei bis vier Wochen ein Update bringt. Große Updates wie das zu Version 0.5 wird es damit nicht mehr geben.

]]>
Florian Brinkmann
Responsive Images in TYPO3: So könnt ihr ab Version 6.2 LTS die Standard-Lösung anpassen und erweitern http://t3n.de/magazin/typo3-6-2-lts-responsive-images-235194/ 2014-08-09T07:59:10Z
Für responsive TYPO3-Layouts müssen Entwickler vor allem die HTML-Quellcodes sauber in die Templates integrieren. Um die dazu gehörenden Responsive Images auszuliefern, bietet die neue …

Für responsive TYPO3-Layouts müssen vor allem die HTML-Quellcodes sauber in die integrieren. Um die dazu gehörenden Responsive Images auszuliefern, bietet die neue TYPO3-Version 6.2 LTS eine integrierte Lösung, die Entwickler allerdings individuell anpassen sollten.

Üblicherweise enthalten responsive Webdesigns dynamisch berechnete Bilder, so genannte Adaptive Images. Alternativ lassen sich auch mehrere Bilder in unterschiedlichen Auflösungen in den HTML-Quellcode einbinden. Man spricht dann von Responsive Images. Um eine solche Lösung in den TYPO3-CMS-Core zu integrieren, hat sich seit den Developer Days 2013 ein Team aus Designern, Frontend-, PHP- und TypoScript-Entwicklern zusammen getan. Ab der Version 6.2 LTS steht deren Lösung nun zur Verfügung und wirkt sich automatisch auf alle per Backend eingebundenen Bilder aus.

HTML-Lösungen

Derzeit aktuelle HTML-Lösungen binden die verschiedenen Bildgrößen im als Ressource ein. Meist kommt dabei zusätzlicher JavaScript-Code zum Einsatz, um das DOM-Objekt der Seite entsprechend des Breakpoints zu modifizieren oder um einen Fallback für ältere Browser zu erstellen. Die drei gängigsten und am weitesten verbreiteten Lösungen sind dabei:

Picture Tag

<picture alt="responsive image"> 
 <source xsrc="large.jpg" media="(min-width:1600px), (min-resolution: 136dpi) and (min-width:800px)">
 <source xsrc="medium.jpg" media="(min-width:800px), (min-resolution: 136dpi) and (min-width:400px)">
 <source xsrc="small.jpg">
 <!-- fallback --> 
 <img xsrc="small.jpg" alt="responsive image">
</picture>

Listing 1

Srcset Attribute

<img alt="responsive image" xsrc="small.jpg" srcset="large.jpg 1600w, large.jpg 800w 1.95x, medium.jpg 800w, medium.jpg 400w 1.95x">

Listing 2

Data Attribute

<img alt="responsive image" xsrc="small.jpg" data-large="large.jpg“ data-large-1.95x="large.jpg“ data-medium="medium.jpg“ data-medium-1.95x="large.jpg“>

Listing 3

TYPO3-Lösungen

In TYPO3 sind in der System-Extension „css_styled_content“ bereits diese drei Lösungen vorbereitet. Ein Integrator muss nur noch eine passende JavaScript-Bibliothek auswählen und implementieren, dann stehen Responsive Images im Frontend zur Verfügung. Welche Responsive-Images-Lösung zum Einsatz kommen soll, lässt sich über die Konstante „styles.content.imgtext.layoutKey“ auswählen. Mögliche Werte sind dabei:

Werte der Konstante styles.content.imgtext.layoutKey
Default Rendering ohne Responsive Images
srcset Rendering als Srcset Attribute
picture Rendering als Picture Tag
data Rendering als Data Attribute

Nachdem die Konstante gesetzt ist, erstellt TYPO3 für jedes eingebundene Bild zwei verschiedene Auflösungen: zwei Bilder mit 600 Pixel Breite, eins für normale Displays und eins für ein Retina-Display. Hier ein Beispiel für srcset:

srcset Image Resource

<img xsrc="fileadmin/_processed_/csm_heimwerker-what-i-really-do_f500fdb67f.jpg" srcset="fileadmin/_processed_/csm_heimwerker-what-i-really-do_f500fdb67f.jpg 600w,fileadmin/ResponsiveImages/heimwerker-what-i-really-do.jpg 600w 2x" alt="">

Listing 4

Konfiguration in TYPO3

Um Responsive Images in TYPO3 zu integrieren, muss der Entwickler die mitgelieferte Konfiguration für die jeweilige Webseite anpassen – das heißt, er benötigt eigene Breakpoints. Dieser Artikel zeigt dies am Beispiel „Data“. Eine mögliche Integration via JavaScript gibt es online. Die offizielle TypoScript-Dokumentation beschreibt die einzelnen möglichen Parameter sehr gut. Bei „css_styled_content“ sind die Werte unter „tt_content.image.20.1“ abgelegt, wo man sie modifizieren kann.

Individuelle Breakpoints definiert der Entwickler als dataKeys unterhalb von „sourceCollection“. Das Beispiel „Data“ benötigt außer den Bildern keine weiteren Informationen im HTML-Code und so ist die Grundkonfiguration kurz: Das Beispiel enthält drei Breakpoints im HTML – small, smallLandscape und big. Dieser Code steht dabei vor jedem weiteren TypoScript-Code und kopiert oder modifiziert gegebenenfalls der Anweisung „css_styled_content“.

Die Beispiel-Konfiguration „Data“

tt_content.image.20.1.sourceCollection >
tt_content.image.20.1.sourceCollection {
 big {
 maxW = 600
 dataKey = big
 }
 small {
 maxW = 200
 dataKey = small
 }
 smallLandscape {
 maxW = 400
 dataKey = smallLandscape
 }
}

Listing 5

Das Ergebnis zeigt drei verschiedene URLs mit unterschiedlich großen Bilddaten. TYPO3 skaliert die Bilder automatisch.

Drei URLs mit unterschiedlich großen Bilddaten

<img xsrc="fileadmin/_processed_/csm_heimwerker-what-i-really-do_f500fdb67f.jpg" data-big="fileadmin/_processed_/csm_heimwerker-what-i-really-do_f500fdb67f.jpg" data-small="fileadmin/_processed_/csm_heimwerker-what-i-really-do_f4aebfef54.jpg" data-smallLandscape="fileadmin/_processed_/csm_heimwerker-what-i-really-do_295ffecc84.jpg" alt="">

Listing 6

Ergänzung oder Anpassung

Damit TYPO3 auch künftige Responsive-Images-Implementierungen umsetzen kann, können diese via TypoScript eingerichtet bzw. modifiziert werden. Die Grundkonfigurationen sind dabei in „tt_content.image.20.1.layout“ abgelegt. Für das Beispiel „srcset“ sieht dies dann folgendermaßen aus:

Die Grundkonfiguration

Layout.srcset {
 element = <img xsrc="###SRC###" srcset="###SOURCECOLLECTION###"###PARAMS######ALTPARAMS######SELFCLOSINGTAGSLASH###>
 source = |*|###SRC### ###SRCSETCANDIDATE###,|*|###SRC### ###SRCSETCANDIDATE###
 }

Listing 7

Im Code sind die verschiedenen Marker für die Attribute im HTML-Code zu erkennen. Um die Konfiguration zu modifizieren, muss der Programmierer einfach den HTML-Code anpassen. Er kann auch eigene Attribute ergänzen, muss sie dann aber sowohl im HTML-Code definieren als auch in den Datakeys. Wer ein eigenes Layout hinzufügt, kann auch weitere, neue HTML-Codes integrieren. Eine Alternativ-Lösung für Figure ist somit ganz einfach:

Eine modifizierte Konfiguration

tt_content.image.20.1.layout.figure {
 element = <figure ###SOURCECOLLECTION### ###PARAMS######ALTPARAMS###><noscript><img xsrc="###SRC###"###PARAMS######ALTPARAMS###></noscript></figure>
 source = data-###DATAKEY###="###SRC###"
 source.noTrimWrap = ; ;;
 source.noTrimWrap.splitChar = ;
}
tt_content.image.20.1.layoutKey = figure

Listing 8

Ein Hook mitsamt Interface ermöglicht in TYPO3 darüber hinaus auch zusätzliche Erweiterungen oder die Implementierung eines Adaptive Images Servers. Mit ihm ist komplett eigener PHP-Code möglich: \TYPO3\CMS\Frontend\ContentObject\ContentObjectGetSingleHookInterface.

Responsive Bilder für Redakteure

Ein responsiver Web-Auftritt definiert die Bildgrößen durch das Layout und die Breakpoints. Es empfiehlt sich daher, jegliche Funktionen im TYPO3-Backend zu deaktivieren, die eine Veränderung der Bildgröße zulassen – wie etwa Breite und Höhe. Redakteure sollten – gerade bei Web-Auftritten mit einem Breakpoint für Retina-Displays – außerdem immer auch ein hochauflösendes Bild bereitstellen. Damit ein Redakteur seine Arbeit auch in den verschiedenen Breakpoints betrachten kann, wählt er im Modul „Anzeigen“ den entsprechenden Viewport aus. Die jeweiligen Konfigurationen kann man via „PageTS“ hinterlegen und anpassen. Eine solche Anzeige ersetzt natürlich nicht den Test auf einem echten Device bei der Entwicklung. Er ist aber für einen Redakteur eine gute Hilfe.

typo3 responsive images beispiel
Die TYPO3-Beispiel-Installation eines responsiven Layouts via JavaScript.

Backport

Wer noch nicht auf TYPO3 6.2 updaten möchte, kann die Extension „responsiveimagesbackport“ nutzen, um die genannte Funktionalität bereits in TYPO3 4.5 zu verwenden. Nach der Installation muss man nur noch das statische TypoScript hinzufügen, und schon lassen sich die Anpassungen für Responsive Images vornehmen. Auch eine Erweiterung und Ergänzung der Regeln ist mittels TypoScript einfach möglich. Die Preview-Funktionalität können Entwickler über die Extension „responsive_preview“ nachrüsten, die in TYPO3 Forge zur Verfügung steht.

Fazit

Die nächste TYPO3-CMS-Version 6.2 LTS macht die Umsetzung responsiver Images und die Anpassung auf die HTML-Integration einfach. Dabei kann das CMS aber nur dafür sorgen, dass sich die HTML-Codes einfacher erzeugen lassen. JavaScript, CSS und HTML muss jeder Web-Entwickler weiterhin für jeden Anwendungsfall selbst entwickeln.

]]>
Ingo Schmitt
Hosted-CMS für Designer: Ein Blick auf Surreal http://t3n.de/news/hosted-surreal-cms-561604/ 2014-08-08T09:03:17Z
Mit Surreal gibt es ein Hosted-CMS, das sich vor allem an Designer richtet. Das spannendste Feature: Ihr könnt Text- oder Bildbereiche auf euren Seiten definieren und sie anschließend direkt inline …

Mit Surreal gibt es ein Hosted-CMS, das sich vor allem an Designer richtet. Das spannendste Feature: Ihr könnt Text- oder Bildbereiche auf euren Seiten definieren und sie anschließend direkt inline bearbeiten.

Surreal CMS richtet sich vor allem an Designer. (Screenshot: Surreal CMS)
Surreal CMS richtet sich vor allem an Designer. (Screenshot: Surreal CMS)

Surreal: Hosted-CMS bietet praktischen Inline-Editor

Surreal ist ein Hosted-CMS, das sich laut Eigenwerbung vor allem an Designer richtet. Das Alleinstellungsmerkmal des Content-Management-Systems ist der Inline-Editor. Mit ihm lassen sich Texte oder Bilder direkt auf der Seite bearbeiten. Die Vorgehensweise ist dabei denkbar einfach: Nachdem ihr eure Webseiten beispielsweise per FTP auf Surrreal übertragen habt, wählt ihr alle Elemente aus, die ihr zu einem späteren Zeitpunkt auf diese Art bearbeiten wollt.

Anschließend könnt ihr einfach auf den entsprechenden Bereichen klicken und die jeweiligen Inhalte direkt abändern. Dabei erkennt Surreal, ob ihr einen Text, ein Bild oder HTML-Code bearbeiten wollt und stellt euch passende Möglichkeiten zur Bearbeitung zur Verfügung. Im Falle von Textblöcken reicht ein Klick und ihr könnt direkt drauf los schreiben.

Surreal CMS: Ein weiteres Content-Management-System für Designer

Mit Surreal CMS könnt ihr anderen Nutzern auch erlauben, Änderungen an den Inhalten einer Seite vorzunehmen. So soll sich Surreal auch als einfache Lösung für eure Kunden eignen. Die monatlichen Kosten variieren je nach Anzahl der Seiten. Das günstigste Paket kostet zehn US-Dollar monatlich und erlaubt die Erstellung von bis zu fünf Seiten.

Surreal ist bei weitem nicht die einzige Lösung, die sich als das ideale Hosted-CMS für Designer bezeichnet. Beispielsweise versucht auch das über Kickstarter finanzierte CMS Webhook diese Zielgruppe zu erreichen. Letztlich stellt sich aber bei allen Lösungen dieser Art die Frage, ob es nicht lohnenswerter ist, ein umfangreicheres CMS wie WordPress einzusetzen. Hosting-Möglichkeiten dafür gibt es schließlich mehr als genug.

via www.producthunt.com

]]>
Kim Rixecker
Der große t3n-Guide zum eigenen WordPress-Theme – Teil 2: Das Grundgerüst [Update] http://t3n.de/news/grosse-t3n-guide-eigenen-wordpress-theme-das-grundgeruest-555808/ 2014-08-01T13:13:57Z
In dieser Artikelreihe geht es darum, ein WordPress-Theme zu erstellen – von Grund auf. Im zweiten Teil starten wir mit der Entwicklung und stellen die Grundfunktionalitäten des Themes sicher.

In dieser Artikelreihe geht es darum, ein WordPress-Theme zu erstellen – von Grund auf. Im zweiten Teil starten wir mit der Entwicklung und stellen die Grundfunktionalitäten des Themes sicher.

Update vom 1. August 2014: Thomas Scholz hat mir in der „WordPress Deutschland“-Community auf Google+ noch ein paar Verbesserungsvorschläge gegeben, die ich hier noch eingebaut habe. Zum Einen gibt es bei WP Test bessere Testdaten als die von Automattic, die ich von jetzt an verwenden werde. Außerdem habe ich das Einbinden der Pingback-URL in der header.php-Datei noch davon abhängig gemacht, ob sich der Nutzer gerade auf einer Einzelseite befindet und Pingbacks überhaupt erwünscht sind.Des Weiteren ist der Verweis auf die style.css aus dem Header verschwunden – in dieser style.css-Datei stehen nur die Informationen, die WordPress zur Erkennung des Themes braucht. Der CSS-Code wird dann in späteren Teilen in eine andere CSS-Datei geschrieben und diese mit der wp_enqueue_style()-Funktion eingebunden, damit es von Child-Themes oder Plugins leichter abgeschaltet werden kann.

Schlussendlich habe ich die Einbindung der JavaScript-Datei, die für die Platzierung des Kommentarfeldes direkt unter dem zu beantwortenden Kommentar verantwortlich ist, aus dem head-Element entfernt. In einem späteren Teil werden wir das über die functions.php-Datei in den Footer integrieren.

Update vom 7. August 2014: Ich habe die Navigation für paginierte Artikel aus der Datei content.php entfernt – in der Einzelansicht reicht das meiner Meinung nach aus. Außerdem habe ich in allen Übersichtsseiten (content.php, archive.php, index.php, author.php, category.php, search.php, tag.php) die Seitennavigation angepasst, damit auf der ersten beziehungsweise auf der letzten Seite nicht ein leerer Listenpunkt angezeigt wird.

Im ersten Teil unseres Guides für die Erstellung eines WordPress-Themes haben wir euch kurz einen Ausblick auf die Reihe gegeben und euch vorgestellt, wie das WordPress-Theme am Ende ungefähr aussehen soll. Im zweiten Teil werden wir jetzt ganz kurz die lokale Installation von WordPress auf XAMPP anschneiden und anschließend mit der Entwicklung der Funktionen des Themes beginnen. Dabei werden wir uns in diesem Teil nur den Grundfunktionen widmen und Dinge wie Page-Templates, die verschiedenen Post-Formate, Widgets et cetera später behandeln.

WordPress lokal installieren

Da Leser darum gebeten haben, werde ich hier kurz und knapp auf die lokale Installation von WordPress mit XAMPP eingehen. Das ist eigentlich nicht schwer und in ein paar Schritten erledigt:

  1. Ladet euch XAMPP bei apachefriends.org für euer Betriebssystem runter.
  2. Installiert XAMPP – bei Windows müsst ihr darauf achten, dass ihr es direkt im obersten Verzeichnis installiert. Also in C: und nicht in C:/xampp.
  3. Ladet euch die neueste Version von WordPress runter – in Deutsch gibt es die bei de.wordpress.org.
  4. Entpackt WordPress in das htdocs-Verzeichnis von XAMPP.
  5. Startet bei XAMPP den Apache und MySQL – eventuell müsst ihr in den Einstellungen die Ports ändern, damit der Apache startet.
  6. Legt unter http://localhost/phpmyadmin eine neue MySQL-Datenbank an.
  7. Ruft mit einem Browser den Pfad auf, in dem WordPress liegt – wenn der Ordner „wordpress“ heißt also http://localhost/wordpress.
  8. Generiert die wp-config.php über das Webinterface – der Standard-MySQL-Bebnutzer ist root, standardmäßig ist kein Passwort für MySQL bei XAMPP gesetzt – das Feld also einfach leer lassen. Dann noch die Datenbank auswählen – das Tabellenpräfix könnt ihr für den lokalen Einsatz bei wp_ belassen. Im Produktiveinsatz solltet ihr das durch etwas Kryptisches ersetzen!
  9. Anschließend gebt ihr die Daten für euer Blog ein und werdet auf die Anmeldeseite weitergeleitet.

Testdaten importieren und nützliche Plugins installieren

Nachdem wir jetzt eine WordPress-Installation vorliegen haben, können wir uns nun schnell ein paar Beiträge, Seiten und andere Inhalte anlegen, indem wir die Testdaten von WP Test importieren.

Geht dafür im WordPress-Backend auf „Werkzeuge“ und „Import“ und wählt dort den Punkt „WordPress“ in der Tabelle aus. Anschließend werdet ihr aufgefordert, das entsprechende Plugin zu installieren und könnt danach die XML-Datei importieren, die sich in dem zip-Archiv befindet. Jetzt haben wir alles zusammen, um anständig mit der Entwicklung beginnen zu können.

Um das Theme während der Entstehung immer mal wieder auf Fehler zu überprüfen, installieren wir uns jetzt noch das Plugin „Theme Check“. Alle anderen Plugins solltet ihr deaktivieren, wenn es sich nicht um weitere Entwickler-Plugins handelt, damit ihr auf dem Stand seid, den ein Nutzer (oder Tester) hat.

Los geht's – Der erste Code

Bevor wir beginnen, Code zu schreiben, müssen wir uns zuerst einen Theme-Ordner anlegen. Ich nenne das Theme „Bornholm“ und lege deshalb unter wp-content > themes den Ordner bornholm an. Ab sofort werden wir uns nur noch in diesem Ordner bewegen.

Zuerst wollen wir die absolut notwendigen Dateien für ein WordPress-Theme anlegen. Das sind eigentlich nur zwei, nämlich die style.css und die index.php. Kümmern wir uns also zuerst um die style.css-Datei und fügen dort die Informationen über das Theme ein:

/*
Theme Name: Bornholm
Theme URI: http://example-theme-uri.com
Author: Florian Brinkmann
Author URI: http://example-author-uri.com
Description:
Version: 1.0
License: GNU General Public License v2
License URI: http://www.gnu.org/licenses/gpl-2.0.html
Tags:
Text Domain: bornholm
*/

Zuerst kommt der Name des Themes, gefolgt von der URI, unter der nähere Informationen zum Theme zu finden sind, sowie der Namen des Entwicklers und der Website. Um die Beschreibung kümmern wir uns am Ende und lassen sie erstmal, genau wie die Tags, leer. Neben der aktuellen Versionsnummer kommen noch Informationen zur Lizenz hinzu. Die Tags sind dafür da, dass das Theme im WordPress-Theme-Directory nachher auch über die Tag-Suche gefunden werden kann. Text Domain ist die Zeichenkette, die wir für das Vorbereiten auf Übersetzungen brauchen. Mehr werden wir erstmal in der CSS-Datei nicht machen.

Widmen wir uns jetzt der index.php-Datei und legen sie an. Das war's auch schon, jetzt habt ihr schon ein funktionierendes Theme! Naja, funktionierend in dem Sinne, dass WordPress keinen Fehler wirft, wenn wir es im Backend aktivieren. So richtig zufriedenstellend ist es natürlich noch nicht, da im Frontend doch relativ wenig angezeigt wird. Nichts, um genau zu sein.

Das werden wir jetzt ändern und uns sozusagen von oben nach unten durcharbeiten. Wir wollen also zuerst damit anfangen, den Kopfbereich des Themes zu erstellen. Hier geht es sowohl um den sichtbaren, als auch den unsichtbaren Teil des Website-Heads, also auch die Einbindung von Stylesheets et cetera. Dafür gibt es in WordPress die Datei mit der passenden Bezeichnung header.php. Legen wir sie also an und füllen sie mit ein bisschen Inhalt – zuerst geht es um die nicht sichtbaren Informationen innerhalb des head-Elements:

<!DOCTYPE html>
<html <?php language_attributes(); ?>>
<head>
<meta charset="<?php bloginfo( 'charset' ); ?>">
<title><?php wp_title(); ?></title>
<?php if ( is_singular() && pings_open() ):?>
<link rel="pingback" href="<?php bloginfo( 'pingback_url' ); ?>">
<?php endif;
wp_head(); ?>
</head>

Nach dem Doctype wird mit der language_attributes()-Funktion das lang-Attribut in das html-Tag integriert, das die Sprache ausgibt und sich dabei nach der Sprache der WordPress-Installation richtet. In unserem Fall wird also lang="de-DE" ausgegeben. Die bloginfo( 'charset' )-Funktion gibt den Zeichensatz aus – seit Version 3.5 von WordPress ist das standardmäßig UTF-8 und kann auch nicht mehr angepasst werden. Mit wp_title() wird der Titel der aktuellen Seite ausgegeben. Wie wir diese Ausgabe steuern und verändern können, werden wir in einem späteren Teil noch behandeln. Danach wird mit bloginfo( 'pingback_url' ) die Pingback-URL ausgegeben, falls die Funktion aktiviert ist und sich der Nutzer auf einer Einzel-Seite befindet.

Mit wp_head() wird jetzt noch alles ausgegeben, was WordPress irgendwie innerhalb des head-Elements unterbringen muss – das sind beispielsweise Skripte und Stylesheets von Plugins et cetera. Damit sind wir mit dem head-Element auch erst mal fertig. Schauen wir uns jetzt den sichtbaren Bereich an. Rufen wir dafür einmal den Header unseres Theme in Erinnerung:

So soll der Header unseres Themes später in etwa aussehen.
So soll der Header unseres Themes später in etwa aussehen.

Wir benötigen also ganz allgemein einen Logobereich und ein Menü. Das Menü ist keine große Sache – das Logo soll der Nutzer später logischerweise selbst auswählen können, und das wollen wir in den Theme-Customizer integrieren. Wir werden hier also für den Anfang das Logo statisch einsetzen und uns um diese etwas fortgeschrittene Technik erst im nächsten Teil kümmern. Wenn wir also erst mal diese Voraussetzungen nehmen, sieht der weitere Inhalt der header.php-Datei so aus.

<body <?php body_class(); ?>>
<header>
<img src="http://placehold.it/200x100">
<?php wp_nav_menu( array( 'theme_location' => 'header-menu', 'container' => 'nav', 'fallback_cb' => false ) ); ?>
</header>

Hinweis: Bei der Vergabe von Klassen und Ids bin ich erst mal lieber zurückhaltender und setze nur welche ein, wo ich mir bereits ziemlich sicher bin, dass wir sie gebrauchen können – vermutlich kommen später noch welche dazu, wenn es an das geht.

Zuerst integrieren wir in den body-Tag mit der body_class()-Funktion automatisch von WordPress erzeugte Klassen – hier wird beispielsweise home eingefügt, wenn wir uns auf der Startseite befinden. Als Logo nehmen wir wie besprochen erst mal einen Platzhalter. Für das Menü verwenden wir die wp_nav_menu()-Funktion und übergeben erst mal nur die nötigsten Parameter. Wir möchten das Menü darstellen, das mir der theme_locationheader-menu“ registriert wurde. Außerdem soll das Menü von einem nav-Element umschlossen sein und als Fallback, wenn dem Menü keine Seite zugeordnet ist, möchten wir nichts anzeigen. Die header.php-Datei können wir damit erst mal schließen.

Damit das Menü aus der header.php-Datei gefüllt werden kann, müssen wir es registrieren. Das passiert in der functions.php-Datei, die wir uns deshalb als nächstes etwas genauer anschauen und die grundlegenden Dinge festlegen – nicht erschrecken, es sieht schlimmer aus, als es ist:

<?php
add_action( 'after_setup_theme', 'bornholm_setup' );
if ( ! function_exists( 'bornholm_setup' ) ):
/**
* Sets up theme defaults and registers support for various WordPress features.
*
* Note that this function is hooked into the after_setup_theme hook, which runs
* before the init hook. The init hook is too late for some features, such as indicating
* support post thumbnails.
*
* To override bornholm_setup() in a child theme, add your own bornholm_setup to your child theme's
* functions.php file.
*
*/
function bornholm_setup() {
/* Make Bornholm available for translation.
* Translations can be added to the /languages/ directory.
* If you're building a theme based on Bornholm, use a find and replace
* to change 'bornholm' to the name of your theme in all the template files.
*/
load_theme_textdomain( 'bornholm', get_template_directory() . '/languages' );
$locale = get_locale();
$locale_file = get_template_directory() . "/languages/$locale.php";
if ( is_readable( $locale_file ) )
require_once( $locale_file );
add_theme_support( 'automatic-feed-links' );
add_theme_support( 'post-formats', array( 'aside', 'link', 'gallery', 'status', 'quote', 'image', 'video', 'audio', 'chat' ) );
add_theme_support( 'html5', array( 'comment-list', 'comment-form', 'search-form', 'gallery', 'caption' ) );
add_theme_support( 'post-thumbnails' );
}
endif; // bornholm_setup

Hinweis: Eigene Funktionen sollten immer mit der Text-Domain des Themes als Präfix beginnen, wie hier bei bornholm_setup() geschehen. Nicht nur, weil das eine Voraussetzung für den späteren Upload in das WordPress-Theme-Directory ist, sondern auch der besseren Übersichtlichkeit halber.

Dieser Abschnitt kümmert sich um allgemeine Einstellungen des Themes. Die Funktion bornholm_setup() wird an den Hook after_setup_theme angehängt und damit noch während des Seitenaufbaus ausgeführt. In der Funktion wird dann zuerst von Zeile 21 bis 25 die Übersetzungsfähigkeit des sichergestellt und festgelegt, dass sich die Übersetzungen im Ordner languages befinden.

Anschließend werden für das Theme mittels add_theme_support verschiedene Funktionen aktiviert: Mit automatic-feed-links werden RSS-Links in das head-Element eingefügt. In der nächsten Zeile werden sämtliche Post-Formate aktiviert. Für die Kommentare, das Suchformular, Galerien und Bildunterschriften wird anschließend HTML5-Markup aktiviert und die Unterstützung von Post-Thumbnails wird eingeschaltet. Neben diesen Einstellungen gibt es noch einige mehr, die ihr im Codex finden könnt.

Doch kommen wir jetzt zum Menü. Den folgenden kurzen Code-Abschnitt fügt ihr einfach unter den vorherigen Code in die functions.php ein:

function bornholm_menus() {
register_nav_menus(
array(
'header-menu' => __( 'Header Menu', 'bornholm' ),
)
);
}
add_action( 'init', 'bornholm_menus' );

Hier registrieren wir das Menü header-menu (ihr erinnert euch, oben in der wp_nav_manu()-Funktion) und legen als englischen Titel „Header Menu“ fest (zu der komisch aussehenden Syntax im Hinweis-Kasten mehr). Mit add_action geben wir die Funktion anschließend weiter. Wenn ihr jetzt im Backend nachschaut, solltet ihr unter „Design“ den Punkt „Menüs“ vorfinden.

Hinweis: Da am Ende der Upload ins WordPress-Theme-Directory geplant ist, werden sämtliche Strings in englischer Sprache im Theme festgelegt und für die Übersetzung vorbereitet. Dazu bedienen wir uns der gettext()-Funktion, die ihr im oberen Code-Beispiel mit __( 'Header Menu', 'bornholm' ) schon im Einsatz gesehen habt. Der erste Parameter ist dabei immer der String, der übersetzt werden kann, der zweite Parameter ist die Text-Domain des Themes, also in unserem Beispiel bornholm. Wenn der zu übersetzende String wie hier schon in einer anderen PHP-Funktion steht, kommen vor der öffnenden runden Klammer zwei Unterstriche __. Stünde der Text alleine, würde das ganze so aussehen: <?php _e('Header Menu', 'bornholm'); ?>. Der zweite Unterstrich wird durch ein e ersetzt.

Jetzt können wir uns an die Darstellung des Blogs machen und gehen dafür in die noch leere index.php zurück und füllen sie mit Inhalt:

<?php get_header();?>
<main role="main">
<?php if ( have_posts() ) :
/* Start the Loop */
while ( have_posts() ) : the_post();
get_template_part( 'content', get_post_format() );
endwhile;
endif;?>
</main>
<?php if (  $wp_query->max_num_pages > 1 ) : ?>
<ul id="posts-nav">
<?php if(get_next_posts_link()):?>
<li class="nav-previous"><?php next_posts_link( __( '<span class="meta-nav">&larr;</span> Older posts', 'bornholm' ) ); ?></li>
<?php endif;
if(get_previous_posts_link()):?>
<li class="nav-next"><?php previous_posts_link( __( 'Newer posts <span class="meta-nav">&rarr;</span>', 'bornholm' ) ); ?></li>
<?php endif;?>
</ul>
<?php endif;
get_sidebar();
get_footer(); ?>

Auch das sieht auf den ersten Blick schlimmer aus, als es ist. get_header liefert uns die header.php-Datei zurück. Anschließend prüfen wir, ob wir Artikel zum Darstellen haben. Wenn das der Fall ist, gehen wir die Posts mit einer while-Schleife durch. Mit the_post() wird der Index der Artikel durchlaufen, damit WordPress weiß, von welchem Post gerade Informationen gefragt sind. get_template_part( 'content', get_post_format() ); gibt, je nach Post-Format, die entsprechende Datei zurück. Bei einem ganz normalen Artikel ist das die content.php, bei einer Galerie die content-gallery.php und so weiter.

Anschließend prüfen wir nach dem schließenden main-Tag, ob die Anzahl der Seiten größer als 1 ist und geben dann eine Navigation aus, damit der Nutzer auch zu den älteren Beiträgen gelangen kann. Am Ende fügen wir – entsprechend der get_header()-Funktion – mit get_sidebar() die Sidebar ein und mit get_footer() den Footer. Wenn wir jetzt unsere Website aufrufen, sollte schon etwas zu sehen sein. Am auffälligsten ist vermutlich eine lange Liste von Links, die man sich eventuell nicht gleich erklären kann. Wenn wir in den erzeugten Quellcode schauen, wird klar: Das ist die Sidebar – WordPress fügt hier standardmäßig die Datei wp-includes/theme-compat/sidebar.php ein, wenn das Theme keine sidebar.php besitzt.

Beiträge sehen wir allerdings noch nicht – wie auch, es sind ja noch keine Dateien angelegt, die von der get_template_part( 'content', get_post_format() );-Funktion eingebunden werden könnten. In diesem Teil kümmern wir uns nur um die content.php-Datei, die auch von anderen Post-Formaten verwendet wird, wenn die spezifische Datei nicht vorhanden ist. Schauen wir uns vorher noch an, wie ein normaler Artikel in der Blog-Ansicht aussehen sollte:

So soll ein normaler Artikel mit Beitragsbild in der Blog-Ansicht aussehen. (Foto: Dennis Brinkmann)
So soll ein normaler Artikel mit Beitragsbild in der Blog-Ansicht aussehen. (Foto: Dennis Brinkmann)

Wenn kein Artikelbild festgelegt ist, fällt es einfach weg und die restliche Gestaltung bleibt gleich. Damit brauchen wir einen Header-Bereich, in den dann der Titel und das eventuell vorhandene Artikelbild integriert werden. Neben dem natürlich notwendigen Content-Bereich für den Inhalt beziehungsweise Auszug des Artikels kommen in einen Footer dann die Meta-Informationen zum Post. Und das sieht dann erst mal so aus:

<article id="post-<?php the_ID(); ?>" <?php post_class(); ?>>
<header class="entry-header">
<?php bornholm_the_post_header() ?>
</header><!-- .entry-header -->
<div class="entry-content">
<?php the_content( __( 'Continue reading ', 'bornholm' ). the_title('“', '”', false) );
wp_link_pages( array( 'before' => '<ul class="page-link"><li>' . __( 'Pages:', 'bornholm' ) . '<ul>', 'after' => '</ul></div>', 'link_before' => '<li>', 'link_after' => '</li>', 'nextpagelink'     => __( 'Next page', 'bornholm' ), 'previouspagelink' => __( 'Previous page', 'bornholm' ), ) ); ?>
</div><!-- .entry-content -->
<footer class="entry-meta">
<?php bornholm_footer_meta() ?>
</footer><!-- .entry-meta -->
</article><!-- #post-<?php the_ID(); ?> -->

Wir kleiden den Artikel in ein article-Element und geben ihm mittels the_ID() die id des Artikels mit sowie mit der post_class()-Funktion einige Klassen, die je nach Ansicht und Typ des Artikels variieren können. Hier wird beispielsweise – je nachdem, um was für ein Post-Format es sich handelt – eine Klasse eingefügt, bei einer Galerie wäre das format-gallery. Wenn ihr eine eigene Klasse hinzufügen wollt, könnt ihr das einfach wie folgt tun: post_class('eigene-klasse'). Mehr Informationen findet ihr im Codex.

Den Kopfbereich des Artikels lagern wir in die noch zu erstellende bornholm_the_post_header()-Funktion aus, da er sich bei den verschiedenen Post-Formaten nicht unterscheiden wird – er besteht immer aus einem gegebenenfalls gesetzten Artikelbild und dem Titel. Mit der the_content()-Funktion holen wir uns den Inhalt des Artikels – gegebenenfalls nur bis zu einem eventuell gesetzten more-Tag. Als Parameter übergeben wir den Text, der als Link auf den kompletten Artikel angezeigt wird. Hier übergeben wir – wieder übersetzungsfähig – den String Continue Reading gefolgt von dem Titel des Posts in Anführungszeichen. Der erste Parameter von the_title() ist die Zeichenkette, die vor dem Titel ausgegeben wird und der zweite Parameter die Zeichenkette danach. Der dritte Parameter steuert, ob der Titel gleich ausgegeben wird (true) oder nur zur Verwendung in PHP bereitgestellt wird (false). Da wir die Funktion sowieso per echo ausgeben, wählen wir hier false.

Der optionale zweite Parameter von the_content() ermöglicht es, den Teaser auf der Einzelseite des Artikels zu verstecken. Standard ist hier false. Wenn ihr mehr über the_content() erfahren möchtet, schaut auch hier im Codex vorbei. Neben the_content() gibt es noch die the_excerpt()-Funktion. Damit wird der Auszug des Artikels ausgegeben, den ihr über ein Feld im Backend manuell eintragen könnt. Ist hier nichts eingetragen, werden einfach die ersten 55 Wörter angezeigt. Shortcodes, Bilder et cetera werden hier gefiltert und nicht angezeigt. Die Funktion könntet ihr beispielsweise auf der Suchergebnisseite oder in Archiven anzeigen – wir werden bei diesem Theme aber immer mit der the_content()-Funktion arbeiten. Nähere Details zu the_excerpt() findet ihr hier.

Mit der wp_link_pages()-Funktion geben wir die Seitenzahlen eines paginierten Artikels aus. Die verschiedenen Parameter sollten selbsterklärend sein: Wir geben etwas ganz am Anfang aus, am Ende sowie vor und hinter jedem einzelnen Link. Außerdem noch die Strings, die den Link zur nächsten beziehungsweise vorherigen Seite bilden sollen. Daneben sind noch ein paar anderen Parameter möglich. Theoretisch könnten wir die zwei Funktionen natürlich auch in eine eigene Funktion auslagern und in den anderen Dateien immer wieder aufrufen. Wir belassen es aber erst mal so.

Im Footer hingegen handhaben wir es wieder wie im Header und rufen die Funktion bornholm_footer_meta() auf, die uns die Meta-Informationen ausgeben soll. Als nächstes müssen wir jetzt natürlich diese beiden Funktionen auch erstellen, damit etwas angezeigt werden kann. Das machen wir – ihr habt es euch vielleicht schon gedacht – wieder in der functions.php-Datei. Öffnet also die Datei und schreibt ganz ans Ende folgendes:

function bornholm_the_post_header(){?>
<?php if ( has_post_thumbnail()) : ?>
<a href="<?php the_permalink(); ?>" title="<?php the_title_attribute( array( 'before' => __( 'Permalink to: ', 'bornholm'), 'after' => '' ) ); ?>" rel="bookmark">
<h1 class="entry-title"><?php the_title();?></h1>
<figure class="featured-image">
<?php the_post_thumbnail();?>
</figure>
</a>
<?php else: ?>
<h1 class="entry-title"><a href="<?php the_permalink(); ?>" title="<?php the_title_attribute( array( 'before' => __( 'Permalink to: ', 'bornholm'), 'after' => '' ) ); ?>" rel="bookmark"><?php the_title();?></a></h1>
<?php endif;
}

Wir prüfen zuerst mit der has_post_thumbnail()-Funktion, ob wir ein Featured Image haben. Wenn das der Fall ist, dann verlinken wir den gesamten Header-Bereich mit Bild und Überschrift – HTML5 sei Dank. Als Linkziel übergeben wir mit the_permalink() den Link zu der Einzelansicht des Artikels, das title-Attribut des Links füllen wir mit der „sauberen“ Form des Titels – the_title_attribute() filtert bestimmte Zeichen heraus, andere werden in ihre Entitys konvertiert – beispielsweise Anführungszeichen. Als Parameter übergeben wir eine Zeichenkette, die vor dem Titel angezeigt werden soll – danach soll nichts kommen.

Anschließend geben wir mit the_title() den Titel des Beitrags aus und mit the_post_thumbnail() das Featured Image. Wenn kein Featured Image gewählt wurde, geben wir einfach ganz normal den Titel als Link aus. Kommen wir jetzt noch zur Funktion bornholm_footer_meta().

function bornholm_footer_meta(){?>
<p>
<a href="<?php the_permalink(); ?>" title="<?php the_title_attribute( array( 'before' => __( 'Permalink to: ', 'bornholm'), 'after' => '' ) ); ?>"><?php echo sprintf( __( '%1$s @ %2$s', 'bornholm' ), get_the_date(), get_the_time() )  ?></a>
<span class="sep"> · </span>
<?php $show_sep = false;
/* translators: used between list items, there is a space after the comma */
$categories_list = get_the_category_list( __( ', ', 'bornholm' ) );
if ( $categories_list ):
?>
<span class="cat-links">
<?php _e( 'Posted in ', 'bornholm' ); echo $categories_list;
$show_sep = true; ?>
</span>
<?php endif; // End if categories
/* translators: used between list items, there is a space after the comma */
$tags_list = get_the_tag_list( '', __( ', ', 'bornholm' ) );
if ( $tags_list ):
if ( $show_sep ) : ?>
<span class="sep"> · </span>
<?php endif; // End if $show_sep ?>
<span class="tag-links">
<?php _e( 'Tagged ', 'bornholm' ); echo $tags_list;
$show_sep = true; ?>
</span>
<?php endif; // End if $tags_list
if ( $show_sep ) : ?>
<span class="sep"> · </span>
<?php endif; // End if $show_sep ?>
<span class="author">
<?php _e( 'Author', 'bornholm' );?> <?php the_author(); ?>
</span>
<?php edit_post_link( __( 'Edit', 'bornholm' ), '<span class="edit-link"> ·  ', '</span>' ); ?>
</p>
<?php }

Das sieht jetzt schon ein wenig umfangreicher aus, ist aber auch halb so wild. Zuerst geben wir das Datum aus. An sprintf() übergeben wir als ersten Parameter das Format des gesamten Datums – zuerst kommt das Datum, dann ein @ und anschließend die Zeitangabe. Als weiteren Parameter übergeben wir get_the_date() und get_the_time(), die genau das machen, was sie versprechen.

Danach holen wir uns mit get_the_category_list() die Liste der Kategorien. Wir übergeben als Parameter den Seperator, der mit der Übersetzung auch geändert werden kann. Wenn wir Kategorien zurückbekommen, geben wir diese aus und setzen die Variable $show_sep auf true. Entsprechend verfahren wir im nächsten Schritt mit den Tags. Am Ende geben wir mit der the_author()-Funktion noch den Autor aus und mit edit_post_link() den Bearbeiten-Link ins Backend (wird natürlich nur angezeigt, wenn ihr eingeloggt seid). Als Parameter übergeben wir hier zuerst die Bezeichnung des Links und anschließend den Inhalt davor und danach. Das war's – damit sind wir mit der content.php-Datei und den dazugehörigen Funktionen fertig. Ein bisschen Feinschliff wird es vermutlich noch brauchen, aber grundsätzlich wird alles dargestellt, was wir wollen. Und jetzt sollten im Frontend auch schon Beiträge zu sehen sein.

Wir sind jetzt so weit, dass in der Blog-Übersicht die Artikel angezeigt werden. Aus Ermangelung spezifischer Dateien für die Post-Formate, wie die content-gallery.php-Datei, zieht sich WordPress die Informationen für die Darstellung ausnahmslos aus der content.php-Datei. Das soll uns in diesem Moment auch erst mal an Grundfunktionalität genügen, weshalb wir uns um die weiteren Post-Format-Dateien im nächsten Teil der Reihe kümmern werden.

Wenn wir jetzt in die Einzelansicht eines Artikels wechseln, dann passt das eigentlich größtenteils auch schon. Da wir hier später aber beispielsweise noch eine Autorenbox anzeigen wollen, legen wir jetzt schon mal die single.php-Datei an, die sich um die Darstellung der Einzelansicht kümmert. Das sieht dann so aus:

<?php get_header();?>
<main role="main">
<?php /* Start the Loop */
while ( have_posts() ) : the_post(); ?>
<article id="post-<?php the_ID(); ?>" <?php post_class(); ?>>
<header class="entry-header">
<?php bornholm_the_post_header() ?>
</header><!-- .entry-header -->
<div class="entry-content">
<?php the_content();
wp_link_pages( array( 'before' => '<ul class="page-link"><li>' . __( 'Pages:', 'bornholm' ) . '<ul>', 'after' => '</ul></div>', 'link_before' => '<li>', 'link_after' => '</li>', 'nextpagelink'     => __( 'Next page', 'bornholm' ), 'previouspagelink' => __( 'Previous page', 'bornholm' ), ) ); ?>
</div><!-- .entry-content -->
<footer class="entry-meta">
<?php bornholm_footer_meta() ?>
</footer><!-- .entry-meta -->
</article><!-- #post-<?php the_ID(); ?> -->
<?php comments_template( '', true ); ?>
<?php endwhile; ?>
</main>
<?php get_sidebar();
get_footer(); ?>

Wenn ihr euch das etwas länger anschaut, werdet ihr feststellen, dass das lediglich eine Mischung aus der index.php-Datei und der content.php-Datei ist. Die einzige Besonderheit ist comments_template( '', true ), womit wir die Kommentarfunktion einblenden. Die Navigations-Links unten habe ich rausgenommen – eventuell integrieren wir eine Navigation für Links zum nächsten und vorherigen Post noch in einem späteren Teil. Ebenso in einem späteren Teil kommt der Part, in dem wir verschiedene Dateien für die Einzelansicht verschiedener Post-Formate laden werden – genau so, wie wir verschiedene content-Dateien für die Post-Formate brauchen, bei denen andere Inhalte ausgegeben werden sollen. So soll uns das als Vorbereitung aber erst mal genügen.

Wenn wir uns jetzt eine einzelne Seite anschauen, sehen wir, dass auch dort der Footer mit den Meta-Informationen geladen wird. Das brauchen wir hier nicht – niemand will wissen, wann das Impressum angelegt wurde – weshalb unsere page.php-Datei wie folgt aussieht:

<?php get_header();?>
<main role="main">
<?php /* Start the Loop */
while ( have_posts() ) : the_post(); ?>
<article id="post-<?php the_ID(); ?>" <?php post_class(); ?>>
<header class="entry-header">
<?php bornholm_the_post_header() ?>
</header><!-- .entry-header -->
<div class="entry-content">
<?php the_content();
wp_link_pages( array( 'before' => '<ul class="page-link"><li>' . __( 'Pages:', 'bornholm' ) . '<ul>', 'after' => '</ul></div>', 'link_before' => '<li>', 'link_after' => '</li>', 'nextpagelink'     => __( 'Next page', 'bornholm' ), 'previouspagelink' => __( 'Previous page', 'bornholm' ), ) ); ?>
</div><!-- .entry-content -->
</article><!-- #post-<?php the_ID(); ?> -->
<?php comments_template( '', true ); ?>
<?php endwhile; ?>
</main>
<?php get_sidebar();
get_footer(); ?>

Wie ihr unschwer erkennen könnt, ist hier im Vergleich zur single.php nur der Footer mit den Meta-Informationen rausgeflogen – die Kommentarfunktion integrieren wir erst mal, vielleicht nehmen wir sie später noch raus. Widmen wir uns als nächstes der Archivseite und erstellen dafür die archive.php-Datei. Hier sollen die Beiträge so aufgeführt werden wie in der Blog-Übersicht – der einzige Unterschied ist eine Überschrift, die anzeigt, welches Archiv gerade angeschaut wird. Damit ist diese Datei der index.php sehr ähnlich:

<?php get_header();?>
<main role="main">
<?php if ( have_posts() ) : ?>
<header>
<h1>
<?php if ( is_day() ) :
printf( __( 'Daily Archives: %s', 'bornholm' ), '<span>' . get_the_date() . '</span>' );
elseif ( is_month() ) :
printf( __( 'Monthly Archives: %s', 'bornholm' ), '<span>' . get_the_date( _x( 'F Y', 'monthly archives date format', 'bornholm' ) ) . '</span>' );
elseif ( is_year() ) :
printf( __( 'Yearly Archives: %s', 'bornholm' ), '<span>' . get_the_date( _x( 'Y', 'yearly archives date format', 'bornholm' ) ) . '</span>' );
else :
_e( 'Blog Archives', 'fanoe' );
endif; ?>
</h1>
</header>
<?php /* Start the Loop */
while ( have_posts() ) : the_post();
get_template_part( 'content', get_post_format() );
endwhile;
endif; ?>
</main>
<?php if (  $wp_query->max_num_pages > 1 ) : ?>
<ul id="posts-nav">
<?php if(get_next_posts_link()):?>
<li class="nav-previous"><?php next_posts_link( __( '<span class="meta-nav">&larr;</span> Older posts', 'bornholm' ) ); ?></li>
<?php endif;
if(get_previous_posts_link()):?>
<li class="nav-next"><?php previous_posts_link( __( 'Newer posts <span class="meta-nav">&rarr;</span>', 'bornholm' ) ); ?></li>
<?php endif;?>
</ul>
<?php endif;
get_sidebar();
get_footer(); ?>

Der Unterschied zur index.php-Datei beschränkt sich hier auf die Zeilen 4 bis 16. Hier stellen wir in einem header-Element die Überschrift dar. Per if-Bedingung gehen wir die verschiedenen Zeit-Archive durch: Mit is_day() prüfen wir, ob es sich um ein Tages-Archiv handelt und so weiter. Um die Überschrift auszugeben, arbeiten wir wie vorhin mit der printf-Funktion. Mit get_the_date() übergeben wir das Datum. Beim Tages-Archiv übergeben wir hier keinen Parameter, WordPress holt sich das Datum dann in dem Format, das vom Nutzer im Backend in den Einstellungen festgelegt wurde. Bei den Monats- und Jahres-Archiven übergeben wir als Parameter ein Standard-Format und machen es bereit für die Übersetzung.

Hinweis: Hier lernen wir die dritte Möglichkeit der gettext()-Funktion kennen. Mit _x() können wir als zweiten Parameter vor der Domain des Themes einen Hinweis hinterlegen, der den Übersetzern angezeigt wird.

Wenn ihr jetzt ein Archiv aufruft, solltet ihr je nach Archiv-Art die richtige Zeitangabe in der Headline vorfinden. Kümmern wir uns jetzt um die Kategorie- und Tag-Seiten. Vom Aufbau sind sie fast identisch mit der archive.php-Datei, wir tauschen nur den Inhalt des header-Elements aus. Legen wir also die category.php an, kopieren den Inhalt der archive.php hinein und tauschen den Teil im header-Element aus:

<h1>
<?php printf( __( 'Category Archives: %s', 'bornholm' ), '<span>' . single_cat_title( '', false ) . '</span>' );?>
</h1>
<?php
$term_description = term_description();
if ( ! empty( $term_description ) )
printf( '<div class="taxonomy-description">%s</div>', $term_description );
?>

Als Überschrift geben wir mit der single_cat_title()-Funktion den Namen der Kategorie aus. Anschließend überprüfen wir, ob eine Beschreibung für die Kategorie eingegeben wurde – diese holen wir uns per term_description()-Funktion. Mit der Tag-Seite gehen wir genauso vor: Kopieren wir uns also den Inhalt der category.php-Datei in die neu zu erstellende tag.php und tauschen den PHP-Code in dem h1-Element aus:

<?php printf( __( 'Tag Archives: %s', 'bornholm' ), '<span>' . single_tag_title( '', false ) . '</span>' );?>

Kümmern wir uns als nächstes um die Autoren-Übersicht, also die Seite, die aufgerufen wird, wenn alle Beiträge eines Autors angezeigt werden sollen – die author.php-Datei. Auch sie ist relativ ähnlich zu den anderen Archiv-Seiten, weshalb wir uns zuerst wieder den Inhalt aus der category.php-Datei hineinkopieren. Die Anpassung ist aber ein bisschen umfangreicher, weshalb wir das gesamte main-Element austauschen werden:

<main role="main">
<?php if ( have_posts() ) :
/* Queue the first post, that way we know
* what author we're dealing with (if that is the case).
*
* We reset this later so we can run the loop
* properly with a call to rewind_posts().
*/
the_post();?>
<header class="archive-header">
<h1>
<?php printf( __( 'All posts by %s', 'bornholm' ), get_the_author() );?>
</h1>
<?php if ( get_the_author_meta( 'description' ) ) : ?>
<div class="author-description"><?php the_author_meta( 'description' ); ?></div>
<?php endif; ?>
</header>
<?php
/* Since we called the_post() above, we need to
* rewind the loop back to the beginning that way
* we can run the loop properly, in full.
*/
rewind_posts();
/* Start the Loop */
while ( have_posts() ) : the_post();
get_template_part( 'content', get_post_format() );
endwhile;
endif;
?>
</main>

Die erste Änderung ist der Einsatz von the_post() in Zeile 9. Im Kommentar darüber steht es schon – wir müssen damit prüfen, um welchen Autor es sich überhaupt handelt. Anschließend geben wir ganz normal den Namen des Autors aus. Mit if ( get_the_author_meta( 'description' ) ) prüfen wir, ob eine Beschreibung eingegeben wurde und geben sie mit the_author_meta( 'description' ); aus. Die letzte „Besonderheit“ ist rewind_posts(). Bevor wir jetzt wieder in die Schleife gehen und die Beiträge ausgeben, müssen wir natürlich an den Anfang der Schleife springen, denn the_post() haben wir ja weiter oben schon eingesetzt.

Als letzte „Archiv“-Seite haben wir jetzt noch die Ergebnisseite der Suche auf unserer Liste. Hier müssen wir wieder nur den Code aus der category.php-Datei in die neu erstellte search.php-Datei kopieren und den Inhalt des h1-Elements anpassen:

<?php printf( __( 'Search Results for: %s', 'bornholm' ), get_search_query() );?>

Jetzt fehlen uns in diesem Teil noch die 404.php-, die footer.php- und die sidebar.php-Datei. Was die 404.php-Datei macht, ist klar: Sie wird dargestellt, wenn der Server einen 404-Fehler zurückliefert. Und die sieht bei uns so aus:

<?php get_header();?>
<main role="main">
<article id="post-0" class="post no-results not-found">
<header class="entry-header">
<h1 class="entry-title"><?php _e( 'Nothing Found', 'bornholm' ); ?></h1>
</header><!-- .entry-header -->
<div class="entry-content">
<p><?php _e( 'Apologies, but no results were found for the requested archive. Perhaps searching will help find a related post.', 'bornholm' ); ?></p>
<?php get_search_form(); ?>
</div><!-- .entry-content -->
</article><!-- #post-0 -->
</main>
<?php get_sidebar();
get_footer(); ?>

Wir entschuldigen uns einfach kurz für den Fehler und geben unter der Meldung mit get_search_form() das Suchformular aus, mit dem der Nutzer dann sein Glück versuchen kann. Die footer.php-Datei wird über die Funktion get_footer eingebunden, die wir ja schon mehrfach verwendet haben. Besonders viel Inhalt bekommt sie aktuell noch nicht mit:

<?php wp_footer();?>
</body>
</html>

Mit wp_footer() werden beispielsweise Skripte von Plugins geladen. Zu guter Letzt wollen wir jetzt noch die sidebar.php erstellen, die mit get_sidebar() ausgegeben wird:

<aside id="sidebar" role="sidebar">
<div id="sidebar-content">
<?php if ( is_active_sidebar( 'sidebar-1' ) ):
dynamic_sidebar( 'sidebar-1' );
endif; ?>
</div>
</aside>

Mit is_active_sidebar( 'sidebar-1' ) prüfen wir, ob die Sidebar mit der id sidebar-1 aktiv ist. Wenn das der Fall ist, geben wir sie mit dynamic_sidebar( 'sidebar-1' ) aus. Damit wir die Sidebar jetzt auch im Backend nutzen können, müssen wir sie noch registrieren – ähnlich wie das Menü ganz am Anfang. Dafür schreiben wir folgendes ganz ans Ende der functions.php:

function bornholm_sidebars() {
register_sidebar(array('name' => 'Sidebar',
'id' => 'sidebar-1',
'description' => '',
'before_widget' => '<div class="widget">',
'after_widget' => '</div>',
'before_title' => '<h3>',
'after_title' => '</h3>'));
}
add_action( 'init', 'bornholm_sidebars' );

Im Array übergeben wir als Namen der Sidebar Sidebar, als Id sidebar-1 an – die Id muss mit dem String aus dynamic_sidebar() übereinstimmen! Eine Beschreibung wollen wir erst mal nicht hinzufügen. Wir umschließen das Widget mit einem div-Element, und den Titel packen wir in eine h3-Überschrift.

Was kommt im nächsten Teil?

Das soll es mit diesem Teil dann auch gewesen sein. Wir haben jetzt ein grundlegend funktionierendes WordPress-Theme und ziemlich viel Text in diesem Artikel. Im nächsten Teil werde ich versuchen, den Rest des „Inhaltlichen“ abzuarbeiten, also unter anderem die Dateien für die verschiedenen Post-Formate erläutern, die Kommentarfelder und die Ausgabe der Kommentare anpassen und Widgets erstellen. Ob wir im nächsten Teil schon so weit kommen, dass wir im übernächsten in das Design einsteigen können? Ich weiß es nicht. Erst mal habe ich jetzt zwei Wochen Urlaub, weshalb der nächste Teil vermutlich etwas auf sich warten lassen wird. In der Zeit könnt Ihr das Grundgerüst ja schon mal fertigstellen ... ;)

Habt ihr Fragen zu einzelnen Details, die ich hier nicht ausreichend behandelt habe? Dann schreibt doch einfach einen Kommentar!

Alle Teile unseres Guides im Überblick:

]]>
Florian Brinkmann
Dem Kickstarter-Erfolg auf den Zahn gefühlt: Das kann das neue CMS Webhook http://t3n.de/news/webhook-cms-content-management-system-559791/ 2014-07-29T09:39:09Z
Auf Kickstarter war Webhook ein echter Erfolg. Jetzt ist das CMS verfügbar und wir haben für euch einen Blick darauf geworfen.

Auf war Webhook ein echter Erfolg. Jetzt ist das verfügbar und wir haben für euch einen Blick darauf geworfen.

CMS: Der Kickstarter-Erfolg Webhook ist jetzt verfügbar. (Screenshot: Webhook)
CMS: Der Kickstarter-Erfolg Webhook ist jetzt verfügbar. (Screenshot: Webhook)

Webhook: Das CMS soll sich vor allem an Designer richten

Die Macher von Webhook hatten die Entwicklung des Content-Management-Systems (CMS) über eine Kickstarter-Kampagne finanziert, die wir euch im April 2014 in diesem Artikel vorgestellt hatten. Statt den anvisierten 20.000 kamen über die Crowdfunding-Seite mehr als 40.000 US-Dollar zusammen. Die Zielgruppe des CMS sollten vor allem Designer sein, grundlegende HTML- und CSS-Kenntnisse sollten ausreichen, um schnell eigene Webseiten auf die Beine zu stellen.

Am 23. Juli 2014 endete die Beta-Phase des Projekts und Webhook steht jetzt jedem interessierten Nutzer offen. Das CMS legt alle Daten über Firebase im JSON-Format ab. Die erstellte Website selbst wird als statische Seite generiert. Um ein Projekt mit Webhook zu erstellen, müsst ihr zunächst die entsprechenden Kommandozeilenwerkzeuge installieren, wofür ihr Node.js braucht. Nachdem ihr eure Seite angepasst habt, könnt ihr sie über den entsprechenden Befehl an den Server ausliefern.

Hier dürfte für einige auch das Problem liegen: Webhook kann derzeit nur über den Anbieter gehostet werden. Der Preis pro Seite liegt bei 25 US-Dollar monatlich, wobei Kickstarter-Backer das Hosting zu einem vergünstigten Preis bekommen. Die Installation über die Kommandozeile dürfte keine größere Hürde für versierte Anwender darstellen, zumal es ausführliche Anleitungen für den Installationsprozess unter Windows und OS X gibt. Dennoch stellt sich die Frage, ob die Vorgehensweise für ein CMS ohne Datenbank, das ihr nicht mal selbst hosten könnt, nicht doch etwas einsteigerfeindlich ist.

Webhook: So arbeitet ihr mit dem neuen CMS

Wenn ihr eure erste Website erstellt, habt ihr die Wahl: Entweder ihr startet mit einem der mitgelieferten Themes oder ihr fangt bei Null an. Wählt ihr die zweite Option, müsst ihr euch selbstredend um das Layout per HTML und CSS kümmern. Webhook setzt auf die Templating-Sprache Swig – sämtliche Daten lassen sich damit über einfache Tags ins Frontend ziehen.

Das schöne an Webhook ist, dass ihr über das Webinterface alle benötigten Elemente für eure Seite per Drag & Drop ablegen könnt. Für einen Blog zieht ihr beispielsweise nur das Single-Line-Feld für eure Headline und das WYSIWYG-Text-Feld von der linken Seite auf euren Entwurf. Schon habt ihr alle notwendigen Felder beisammen.

Fazit: Sollte ich Webhook einsetzen?

Die Frage lässt sich nicht pauschal beantworten. Es ist tatsächlich recht einfach, eine Seite mit Webhook zu erstellen. Andererseits fehlt leider nach wie vor die Möglichkeit, das CMS selbst zu hosten. Die Entwickler habe zwar angekündigt, auch die zugrundeliegende Server-Software zu einem späteren Zeitpunkt zu veröffentlichen, wann es aber so weit sein wird, ist derzeit noch nicht bekannt. Wer sich für Webhook interessiert, kann das CMS aber immerhin für zwei Wochen kostenfrei und ohne Einschränkungen testen. Außerdem gibt es eine Live-Demo auf der offiziellen Website des Projekts.

]]>
Kim Rixecker
Modular, modern und elegant: Wir stellen das neue CMS Pagekit vor http://t3n.de/news/pagekit-cms-symfony-558893/ 2014-07-26T06:55:27Z
Pagekit ist ein neues CMS, das auf Symfony Components setzt. Wir stellen es euch in einem Screencast vor.

Pagekit ist ein neues , das auf Symfony Components setzt. Wir stellen es euch in einem Screencast vor.

Pagekit: Das neue Open-Source-CMS aus Deutschland. (Grafik: YOOtheme GmbH)
Pagekit: Das neue Open-Source-CMS aus Deutschland. (Grafik: YOOtheme GmbH)

Pagekit: Das neue CMS von YOOtheme

Pagekit soll ein flexibles und modulares Content-Management-System sein. Das CMS stammt von dem deutschen Unternehmen YOOtheme, die unter anderem für ihr UI-Framework UIKit bekannt sind. Die Open-Source-Software steht unter der freien MIT-Lizenz und ist seit wenigen Tagen in einer Alpha-Version verfügbar.

Über einen integrierten Marktplatz sollen Entwickler kostenfreie und kommerzielle Extensions und Themes direkt anbieten können. Die Installation dieser Komponenten soll für Betreiber des CMS mit nur einen Klick durchführbar sein. Bei der Content-Erstellung hilft ein integrierter Markdown-Editor. Von dort aus lassen sich auch Mediendateien hochladen und managen. Das Backend bietet ein responsives Layout und soll so auch von Smartphones und Tablets leicht zu bedienen sein.

Pagekit: Unter der Haube des neuen CMS

Ihr findet das CMS auf der offiziellen Pagekit-Website und auf GitHub. Zur Installation benötigt ihr Apache 2.2+ oder nginx, MySQL Server 5.1+ und PHP Version 5.4+. Pagekit setzt unter anderem auf bestehende Open-Source-Projekte wie Symfony Components und Doctrine auf. Die Razr-Template-Engine bietet eine einfache Syntax, die von ASP.NET Razor inspiriert wurde. Alternativ dazu kann aber auch PHP zur Erstellung von Templates genutzt werden.

Die integrierte Debug-Toolbar soll Entwicklern bei der Überwachung der Performance und dem Debugging helfen. Die Beta-Version des CMS soll im vierten Quartal 2014 erscheinen. Für die erste Stable-Release peilen die Macher das Ende des Jahres an. Einen kleinen Einblick in die Arbeit mit Pagekit verschafft euch der Screencast unseres Kollegen Johannes Schuba.

]]>
Kim Rixecker
Die WordPress-Story: Wie ein 18-Jähriger die beliebteste Blogsoftware der Welt erfand http://t3n.de/news/wordpress-geschichte-559365/ 2014-07-25T09:24:47Z
Automattic, das Unternehmen hinter WordPress, vereint viele Ideale. In ihrem Artikel blickt Gastautorin Birthe Ziegler hinter den Vorhang und erzählt die Geschichte der weltweit meistverbreiteten …

Automattic, das Unternehmen hinter , vereint viele Ideale. In ihrem Artikel blickt Gastautorin Birthe Ziegler hinter den Vorhang und erzählt die Geschichte der weltweit meistverbreiteten Blogplattform.

Was haben Beyonce.com, Techcrunch.com und seit dem 21. Juli auch NewYorker.com miteinander gemeinsam? Alle drei Websites nutzen WordPress als Content-Management-System – so wie 20 Prozent aller Seiten weltweit. Automattic, das Unternehmen hinter der Marke WordPress, beschäftigt mittlerweile 240 Mitarbeiter und wird mit einer Milliarde US-Dollar bewertet. Wie kam dieser unglaubliche Erfolg zustande? Wir haben die Geschichte für Euch nachgezeichnet.

WordPress-Gründer Matt Mullenweg (Quelle: WordPress.tv)
WordPress-Gründer Matt Mullenweg
(Quelle: WordPress.tv)

Die Geschichte von WordPress nimmt ihren Anfang im Jahr 2002. Als der damals 18-jährige Matt Mullenweg nach der Teilnahme an einem Sommercamp in Washington Fotos von dem Trip mit seinen Freunden in Houston teilen will, richtet er dafür einen Blog auf Basis der zur damaligen Zeit einzigen Open-Source-Software b2 ein. Innerhalb von fünf Monaten besuchen 20.000 Menschen die Seite – nicht wenig für einen privaten Blog dieser Zeit. Mullenweg entdeckt seine Leidenschaft fürs Bloggen. Als die Software b2 im Jahr 2003 vor dem Aus steht, ruft er seine Leser dazu auf, mit ihm eine eigene Open-Source-Software zu entwickeln, die auf b2 aufbaut. In einem Kommentar bekundet Mike Little sein Interesse an der Idee; kurz darauf heben sie gemeinsam WordPress aus der Taufe. Bereits davor führte Little als Web-Entwickler sein eigenes Unternehmen zed1, das er bis heute leitet – mittlerweile ist die Firma auf WordPress-Lösungen spezialisiert.

Automattic bringt WordPress den kommerziellen Erfolg

Im Oktober 2004 wird Mullenweg von der Nachrichtenwebsite CNET eingestellt, um WordPress für deren Blogs weiterzuentwickeln. Schon ein Jahr später verlässt er das Unternehmen wieder, um mit Automattic den kommerziellen Zweig von WordPress aufzubauen, der bis heute existiert. Das Unternehmen bietet auf WordPress.com die Einrichtung und den Betrieb eines Blogs oder einer Website an – inklusive Hosting. Das WordPress-CMS ist dort bereits vorinstalliert, womit das Angebot insbesondere Anfänger ansprechen dürfte. Ein Grundpaket mit drei Gigabyte Speicherplatz ist gratis verfügbar – Zusatzfeatures wie weiterer Webspace, eine eigene Domain und direkter Support kosten Geld.

Darüber hinaus gibt es den Premium-Service VIP für umfangreiche Unternehmenslösungen. Mit Akismet entstand 2005 das erste WordPress-Plugin, welches vor Spam in Blog-Kommentaren schützen soll. Das Geschäftsmodell ist heute unter dem Namen Freemium bekannt: Nutzer persönlicher Blogs können die Standard-Variante des Tools für eine unbegrenzte Anzahl nicht-kommerzieller Seiten kostenlos bzw. auf Spendenbasis nutzen; die Business-Variante beinhaltet eine kommerzielle Seite und kostet fünf Dollar pro Monat und Unternehmen, wer die Software für eine unbegrenzte Anzahl kommerzieller Seiten benötigt, muss 50 Dollar monatlich für den Dienst bezahlen.

Gründe für den rasanten Erfolg von WordPress

Byrne Reese, der Gründer von Movable Type, einer anderen zu der Zeit populären Blogging-Software, stellte sich die Frage, wieso WordPress erfolgreicher wurde als seine eigene Lösung. Dazu berücksichtigt er die Diskussion in seiner Community und fasste drei Gründe für die Entwicklung zusammen: Zunächst stellte Movable Type 2004 auf ein intransparentes Lizensierungsmodell um, das viele User verärgert hat und wovon WordPress, das alle Services kostenlos anbot, profitierte. Zum zweiten hätten viele Nutzer begrüßt, dass WordPress komplett Open-Source war – im Gegensatz zu Movable Type. Und schließlich erklärte Reese, WordPress hätte mit PHP als Programmiersprache mehr Leute gewinnen können als Movable Type, das auf Perl basierte. Zum Erfolg von WordPress verhalfen seiner Meinung nach außerdem die einfache Installation sowie die starke Community, die WordPress seit Beginn unterstützte.

Heute wird die die große Popularität von WordPress in der einfachen Nutzbarkeit, der zahlreichen Plugins und der umfangreichen Auswahl an Themes begründet.

Wie wird Umsatz generiert?

Für das Jahr 2012 rechnete Mullenweg mit Einnahmen von 45 Millionen US-Dollar für Automattic. Jüngere Zahlen sind nicht bekannt. Im Interview mit dem amerikanischen Wirtschaftsmagazin Forbes aus diesem Juni gab Mullenweg an, dass lediglich jeweils zehn Prozent der Einnahmen durch WordAds und VIP-Programme entstehen. WordAds ist das Advertising-Programm von WordPress, das Blogs bei der Monetarisierung helfen soll. Die übrigen 80 Prozent der Einnahmen werden durch Registrierungen mit eigenen Domain-Namen und Extra-Features generiert.

Über 20 Prozent der weltweiten Webseiten basieren auf WordPress

Über 20 Prozent der zehn Millionen relevantesten Websites weltweit basieren nach Angaben von W3Techs auf WordPress. Zwei Jahre zuvor waren es 15 Prozent. Zu den VIP-Kunden von WordPress gehören unter anderem CNN, TechCrunch, NBC Sports, PandoDaily und seit dem 21. Juli auch der New Yorker. Das Magazin erhoffe sich mit dem Umstieg auf WordPress eine einfachere Bedienbarkeit für die mobile Nutzung. Unternehmen wie Zalando, Ritter Sport, Vodafone und Tchibo gestalten ihre Blogs mit der Software – auf dem Zalando-Blog findet man sogar den Hinweis „Proudly powered by WordPress“. Auch Musikstars bloggen mit WordPress. Zu den bekanntesten Vertretern gehören Justin Bieber, Beyoncé, Justin Timberlake, LL Cool J und Snoop Dogg.

Heute beschäftigt Automattic nach eigenen Angaben 240 Mitarbeiter in vielen Büros weltweit – das größte Office mit 15 Angestellten ist in San Francisco. Ein Drittel seiner Zeit verbringe Mullenweg damit, neue Mitarbeiter zu akquirieren, wobei er das geplante „aggressive“ Mitarbeiterwachstum nicht in Zahlen oder Prozent angibt – er wolle so viele gute Leute einstellen, wie er finden kann.

Eine Milliarde Dollar wert

Im Mai dieses Jahres hat eine Investorengruppe um Insight Venture Partners den Wert von Automattic auf eine Milliarde US-Dollar angegeben und 160 Millionen Dollar in das Unternehmen investiert. Ein Jahr zuvor verkündete Mullenweg noch auf seinem Blog, das Unternehmen brauche keine finanzielle Unterstützung. Seit dieser Aussage hat sich einiges getan: Automattic kaufte 2013 fünf Startups auf, deren Preise nicht bekannt sind. Außerdem tauschten Mullenweg und CEO Toni Schneider die Positionen – seit Januar 2014 ist Mullenweg Chef und Schneider für die Produktentwicklung verantwortlich.

Ursprünglich publiziert bei Online Marketing Rockstars.

]]>
Online Marketing Rockstars
8 SEO-Tipps für WordPress http://t3n.de/news/seo-tipps-wordpress-558560/ 2014-07-21T13:57:43Z
WordPress ist ein zurecht sehr beliebtes CMS. Wir geben euch Tipps zur Suchmaschinenoptimierung eures WordPress-Blogs.

ist ein zurecht sehr beliebtes . Wir geben euch zur eures WordPress-Blogs.

WordPress: Fast 75 Millionen Websites nutzen das CMS

Am Erfolg von WordPress sollten kein Zweifel bestehen. Mehr als 74,6 Millionen Websites nutzen das Content-Mangament-System (CMS). Zu dem Erfolg dürfte auch der Umstand beigetragen haben, dass WordPress auch aus SEO-Perspektive keine schlechte Wahl ist. Die Oberfläche ist leicht verständlich und bietet euch alle notwendigen Funktionen. Ohne ein bisschen Arbeit nutzen euch aber auch die vielen Features des CMS nur wenig. Im Folgenden geben wir euch daher acht SEO-Tipps für WordPress-Nutzer.

8 SEO-Tipps für WordPress-Nutzer

1. Bearbeitet eure Permalink-Struktur

Über die Permalink-Struktur legt ihr fest, wie die Adressen eurer einzelnen Posts in der Adressleiste des Browsers dargestellt werden. Die URLs sollten so klar wie möglich sein. Das hilft nicht nur dem Nutzer, sondern auch den Suchmaschinen beim Erfassen eurer Seiten. Laut Joost de Valk, dem Macher des populären SEO-Plugins Yoast, sieht die beste Permalink-Struktur entweder so /%category%/%postname%/ oder einfach so /%postname%/ aus. Die entsprechenden Einstellungen könnt ihr in den Permalink-Einstellungen in WordPress vornehmen.

worpress permalink
Permalink: Struktur und eigentliche URL solltet ihr in WordPress anpassen. (Screenshot: t3n)

2. Permalink selbst anpassen

Im eigentlichen Permalink sollten idealerweise alle wichtigen Keywords enthalten sein. Außerdem, so eine Aussage des Google-Webspam-Gurus Matt Cutts, sollte sie idealerweise zwischen drei und fünf Wörter enthalten. Zusätzliche Begriffe wird Google weniger starke Bedeutung beimessen, auch wenn die Begriffe wohl nicht gänzlich ignoriert werden. Eure Headline, aus der WordPress den Permalink generiert, dürfte im Regelfall nicht nur länger sein, sondern auch zusätzliche Wörter enthalten, die nicht wirklich wichtig sind. Hier empfiehlt es sich vor Einstellung des Artikels, den Permalink händisch anzupassen.

3. Nutzt SEO-Plugins

WordPress SEO by Yoast
WordPress: Es gibt mehrere sehr empfehlenswerte SEO-Plugins für das CMS. (Screenshot: t3n)

Es gibt viele gute kostenpflichtige und kostenlose SEO-Plugins für WordPress. Egal ob All-in-one-Pakete oder spezialisierte Plugins, ein Blick lohnt sich auf jeden Fall. Zum Einstieg in dieses Thema empfehlen wir euch die Lektüre des Artikels „Die besten SEO-Plugins für WordPress“ von unserem Kollegen Lars Budde.

4. Überlegt euch gut, welches Theme ihr verwendet

Im Juni 2013 hat Google angekündigt, Seiten die keine oder nur mangelhafte Mobile-Seiten anbieten schlechter zu ranken als bisher. Das betrifft zwar nur die Suchergebnisse von Smartphone- oder Tablet-Nutzern, aber auch auf diesen Traffic solltet ihr nicht mutwillig verzichten. Idealerweise nutzt ihr daher gleich ein Theme im Responsive Design, das auf jeder gängigen Bildschirmgröße gut aussieht und funktioniert. Eine kleine Übersicht solcher Themes findet ihr in unserem Artikel „40 kostenlose WordPress-Themes für Responsive Design“.

Außerdem solltet ihr darauf achten, dass euer Theme sich auch mit allen notwendigen Plugins gut versteht und es nicht zu Problemen damit kommt. Auch sollte das Theme sich an verschiedene andere Konventionen halten. Der Seitentitel sollte beispielsweise den h1-Tag nutzen und das Theme sollte generell semantisch einwandfrei sein. Das könnt ihr bei bedarf mit dem W3C-Validator testen.

5. Robots.txt: Indiziert nur die Seiten, die Nutzer tatsächlich über Google finden sollen

Natürlich wollt ihr, dass eure tollen Artikel auch gefunden werden. Das gilt aber nicht für alle anderen Seiten. Wenn ihr beispielsweise eine Seite habt, die Nutzern für das gerade abgeschlossene Abonnement eures Newsletters dankt, besteht kein Grund dafür, dass diese Seite auch über Google auffindbar ist. Das selbe gilt für Admin-Seiten oder andere Pages die nur für den internen Gebrauch bestimmt sind. Diese Seiten könnt ihr ausschließen, indem ihr die folgenden Zeilen in eurer Robot.txt-Datei unterbringt:

User-agent: *

Disallow: /[relative Page url]

6. Nutzt Alt- und Title-Tags für eure Bilder

WordPress Mediathek. (Screenshot: t3n)
WordPress Mediathek. (Screenshot: t3n)

Google und seine Konkurrenten sind mittlerweile recht gut um textbasierte Inhalte zu erfassen und auszuwerten. Mit Bildern tun sie sich aber nach wie vor etwas schwer. Daher ist es hilfreich, passende Beschreibungen für die Bilder zu hinterlegen. Dazu solltet ihr die Alt- und Title-Tags nutzen. In WordPress geht das ganz einfach über die Mediathek.

7. Verzichtet nicht auf interne Verlinkungen

Über interne Verlinkungen kommen Nutzer nicht nur einfacher von einem interessanten Beitrag zum nächsten, auch für Suchmaschinen wird es einfacher, eure Seite zu analysieren. Natürlich sollten die Links auch jeweils relevant sein und nicht auf völlig themenfremde Inhalte verweisen.

8. Verfasst richtig gute Inhalte

Okay, der letzte Tipp ist logischerweise nicht ganz so einfach zu befolgen wie die vorherigen, trotzdem solltet ihr ihn nicht vergessen. Googles Suchalgorithmen werden immer besser darin, tatsächlich relevante und hilfreiche Inhalte für einen Suchbegriff aufzuspüren. Wenn ihr oben mitspielen wollt, kommt ihr an gutem Content nicht vorbei.

Als erste Hilfestellung dazu, solltet ihr einen Blick auf die Artikel „Das DATIF-Prinzip: So produzierst du extrem guten Content“ und „Content-Marketing: 5 Ideen für günstige und effiziente Inhalte“ werfen.

Habt ihr noch weitere Tipps, die ihr einem Einsteiger auf jeden Fall mit auf den Weg geben würdet? Wenn ja, erzählt uns in den Kommentaren davon.

via www.searchenginejournal.com

]]>
Kim Rixecker