CMS | t3n News News, Infos, Tipps und aktuelle Artikel zu CMS 2014-07-29T09:39:09Z t3n Redaktion http://t3n.de/tag/cms 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 Kickstarter war Webhook ein echter Erfolg. Jetzt ist das CMS 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
Exklusiv: LaterPay für alle! WordPress-Plugin für Paid-Content ab sofort kostenlos verfügbar http://t3n.de/news/laterpay-557417/ 2014-07-21T07:00: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 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.

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
Der große t3n-Guide zum eigenen WordPress-Theme – Teil 2: Das Grundgerüst http://t3n.de/news/grosse-t3n-guide-eigenen-wordpress-theme-das-grundgeruest-555808/ 2014-07-20T14:16: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.

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 offiziellen Testdaten importieren, mit denen später auch die Theme-Tester von WordPress.org das Theme prüfen werden.

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. 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>
<link rel="stylesheet" href="<?php echo get_stylesheet_uri(); ?>" type="text/css">
<link rel="pingback" href="<?php bloginfo( 'pingback_url' ); ?>">
<?php if ( is_singular() && get_option( 'thread_comments' ) ) wp_enqueue_script( 'comment-reply' );
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 der Funktion get_stylesheet_uri() der Pfad zu der style.css und mit bloginfo( 'pingback_url' ) die Pingback-URL ausgegeben. Anschließend wird in Zeile 8 überprüft, ob wir uns gerade auf einer Einzelseite befinden, ob die Einstellung Threaded Comments (also die Möglichkeit auf andere Kommentare zu antworten) aktiv ist und dann entsprechend eine JavaScript-Datei ausgegeben, mit der das Kommentarfeld immer direkt unter den Kommentar geholt wird, auf den gerade geantwortet wird. comment-reply ist dabei der Bezeichner des Skripts – auf die wp_enqueue_script()-Funktion werden wir aber später noch genauer eingehen.

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">
<li class="nav-previous"><?php next_posts_link( __( '<span class="meta-nav">&larr;</span> Older posts', 'bornholm' ) ); ?></li>
<li class="nav-next"><?php previous_posts_link( __( 'Newer posts <span class="meta-nav">&rarr;</span>', 'bornholm' ) ); ?></li>
</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: ?>
<h2 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></h2>
<?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">
<li class="nav-previous"><?php next_posts_link( __( '<span class="meta-nav">&larr;</span> Older posts', 'bornholm' ) ); ?></li>
<li class="nav-next"><?php previous_posts_link( __( 'Newer posts <span class="meta-nav">&rarr;</span>', 'bornholm' ) ); ?></li>
</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
WordPress 4.0: Diese Funktionen bringt die neue Version http://t3n.de/news/wordpress-4-0-funktionen-neue-version-556971/ 2014-07-14T12:08:38Z
Seit dem 10. Juli liegt die erste Beta-Version von WordPress 4.0 für interessierte Nutzer bereit. Wir haben uns die Änderungen angeschaut und zeigen euch die wichtigsten Neuerungen.

Seit dem 10. Juli liegt die erste Beta-Version von 4.0 für interessierte Nutzer bereit. Wir haben uns die Änderungen angeschaut und zeigen euch die wichtigsten Neuerungen.

WordPress liefert in Version 4.0 einige Verbesserungen, die das Leben der Nutzer erheblich vereinfachen können – darunter Änderungen der Medienansicht, bei der Einbindung von Videos, Tweets et cetera und vor allem eine deutliche Verbesserungen Nutzbarkeit des Editors.

WordPress 4.0: Viele hilfreiche neue Features

Doch der Reihe nach: In WordPress ist es seit Version 2.9 möglich, bestimmte Dienste einfach per Angabe der URL einzubinden – häufig genutzt wird beispielsweise die Einbindung von Tweets, die seit Version 3.4 unterstützt wird. In der kommenden Version 4.0 wird in den visuellen Editor eine Vorschau dieser Einbettungen integriert. Wenn ihr also in eine eigene Zeile die URL eines Tweets einfügt, dann bekommt ihr gleich die Vorschau angezeigt. Dasselbe funktioniert auch bei dem Punkt „Von URL einfügen“ unter „Dateien einfügen“.

Vorschau im visuellen Editor von eingebundenen Quellen. (Screenshot: eigene Installation)
Vorschau im visuellen Editor von eingebundenen Quellen. (Screenshot: eigene Installation)

Für mehr Übersicht und einen schnelleren Überblick in medienlastigen Backends sorgt die Grid-Ansicht, die – jedenfalls in der Beta – standardmäßig aktiv ist. Die „alte“ Listenansicht könnt ihr euch natürlich aber auch zurückholen, wenn ihr wollt.

Für den schnellen Überblick: Die neue Darstellung der Medien in WordPress 4.0. (Screenshot: eigene Installation)
Für den schnellen Überblick: Die neue Darstellung der Medien in WordPress 4.0. (Screenshot: eigene Installation)

Ebenfalls visuell verbessert wurde die Suche nach Plugins. Wenn ihr nach einem Plugin sucht, dann wird euch statt einer Liste jetzt eine übersichtlichere Kachelansicht der Ergebnisse angezeigt – zusätzlich zur Listenansicht wird euch hier auch gleich gezeigt, wann das Plugin zuletzt aktualisiert wurde und ob es bereits erfolgreich mit der WordPress-Version getestet wurde, die ihr nutzt. Wenn ihr euch dann die Details eines Plugins anschauen möchtet, öffnet sich in einem Overlay die Plugin-Seite aus dem WordPress-Plugin-Verzeichnis, wodurch ihr jetzt neben der ansprechenderen Gestaltung auch gleich Zugriff auf die Reviews habt, was in der vorherigen Ansicht nicht möglich war.

So sieht die Ergebnisseite nach einer Plugin-Suche aus. (Screenshot: eigene Installation)
So sieht die Ergebnisseite nach einer Plugin-Suche aus. (Screenshot: eigene Installation)

Die besten Änderungen erfolgen im Editor

„Die besten Änderungen“ ist natürlich rein subjektiv, doch wir denken, dass die Verbesserungen am Editor nicht nur uns sehr gut gefallen. Wie Mark Jaquith, einer der Lead-Developer von WordPress, es in seinem Ticket ganz richtig beschreibt:

„Die Höhe des Bildschirms wird nicht voll genutzt und das Bearbeiten ist eine frustrierende Situation aus einem scrollbaren Container innerhalb eines weiteren scrollbaren Containers mit vielen Ablenkungen.“

Dem kann man nur zustimmen. Hat man aus Versehen mal wieder zu weit „im äußeren Bereich“ gescrollt und die Werkzeugleiste oben nicht mehr sichtbar ist, muss man erst wieder nach oben scrollen, um beispielsweise ein Bild einfügen zu können. Befindet man sich mit dem Cursor im Artikel, muss man eventuell auch hier noch scrollen oder die Maus an den Rand bewegen. Das ändert sich jetzt endlich: Der Editor passt sich in WordPress 4.0 automatisch der Höhe des Inhalts an. Einen Scrollbalken gibt es im Editor damit nicht mehr. Wenn dann gescrollt wird und die obere Werkzeugeiste eigentlich aus dem sichtbaren Bereich verschwinden würde, wird sie einfach am oberen Rand fixiert. Gleiches gilt für die untere Leiste, in der Informationen wie die Wortanzahl und der zuletzt Bearbeitende angezeigt werden.

Meiner Meinung nach die beste Änderung: Die Überarbeitung des Editors. (Screenshot: eigene Installation)
Meiner Meinung nach die beste Änderung: Die Überarbeitung des Editors. (Screenshot: eigene Installation)

Fazit: WordPress 4.0 wird toll – vor allem der Editor!

Es sind zwar keine revolutionären Änderungen dabei, aber die mitgebrachten Verbesserungen sind gut überlegt und sinnvoll. Bis die neue Version voraussichtlich im August final veröffentlicht wird, könnt ihr die Entwickler unterstützen indem ihr die Beta testet und Bugs meldet. Nähere Informationen zu dem Release der WordPress-4.0-Beta findet ihr in dem Blog-Beitrag von WordPress. Dort findet ihr auch die weiteren Änderungen. Es wurde beispielsweise endlich realisiert, dass während der Installation einfach die Sprache ausgewählt werden kann, in der WordPress installiert werden soll.

Was denkt ihr über die Änderungen, die in WordPress 4.0 auf uns warten?

via www.searchenginejournal.com

]]>
Florian Brinkmann
Der große t3n-Guide zum eigenen WordPress-Theme – Teil 1: Die ersten Schritte http://t3n.de/news/grosse-guide-wordpress-theme-555618/ 2014-07-06T09:47:17Z
In dieser Artikelreihe geht es darum, ein WordPress-Theme zu erstellen – von Grund auf. Im ersten Teil geben wir euch einen Ausblick auf die Reihe und zeigen euch einen Entwurf des Themes.

In dieser Artikelreihe geht es darum, ein WordPress-Theme zu erstellen – von Grund auf. Im ersten Teil geben wir euch einen Ausblick auf die Reihe und zeigen euch einen Entwurf des Themes.

Wir wollen euch mit dieser Artikelreihe eine ausführliche Schritt-für-Schritt-Anleitung bieten, wie ihr ein eigenes WordPress-Theme erstellen könnt. Von Artikel zu Artikel wird das Theme immer weiter wachsen, bis am Ende der Upload in das WordPress-Theme-Directory geplant ist. Dabei soll es euch sozusagen möglich sein, das Theme zum Lernen parallel mitzuerstellen.

In diesem Artikel zeigen wir euch, wie das Theme am Ende ungefähr aussehen soll, was es für Funktionen bekommt und wie das Ganze etwas genauer abläuft.

WordPress-Theme-Guide: Das Design

Da es immer schöner ist, wenn man etwas zu sehen bekommt und damit ihr es euch besser vorstellen könnt, haben wir einen relativ detaillierten grafischen Entwurf vorbereitet (nur von der Ansicht für große Displays – das Theme an sich wird natürlich responsive umgesetzt). Einiges daran ist noch nicht final, wie etwa die Abstände et cetera, aber es sollte einen guten Überblick geben. Und bevor hier noch etwas mehr Text kommt, folgt erst mal ein Bild:

Die Blog-Übersicht. (Fotos: Dennis Brinkmann)
Die Blog-Übersicht. (Fotos: Dennis Brinkmann)

Wie ihr wahrscheinlich schon vermutet, soll es ein Theme werden, das sich an Fotografen oder Foto-Blogger richtet. Das Layout ist insgesamt schlicht, damit die Aufmerksamkeit nicht von den Bildern abgelenkt wird. Um euch mehr Freiheiten zu lassen, wird das Theme einige Besonderheiten und Extras spendiert bekommen.

Besonderheiten des Themes

In der aktuellen Überlegung wird das Theme zwei Seiten-Templates bekommen. Ein soll als kurzer Überblick dienen und sich als alternative Startseite anbieten. Hier werden die letzten Galerien nach Kategorien gruppiert angezeigt. Es werden aber nicht alle dargestellt, sondern nur die ersten drei oder vier – vielleicht überlassen wir die Wahl der Maximalanzahl auch dem Nutzer und integrieren die Wahlmöglichkeit in den Theme-Customizer.

Wenn mehr Galerien vorhanden sind, wird mit einem Link auf die Kategorie-Seite verwiesen. Diese Kategorie-Seiten bekommen vielleicht ebenfalls ein Seiten-Template, damit die Darstellung der Galerien dort ohne Sidebar über die gesamte Breite stattfinden kann.

Das Seiten-Template für die alternative Startseite. Ein großes Bild kann festgelegt werden. (Fotos: Dennis Brinkmann)
Das Seiten-Template für die alternative Startseite. Ein großes Bild kann festgelegt werden. (Fotos: Dennis Brinkmann)

Daneben soll es für dieses Seiten-Template die Möglichkeit geben, die zwei groß dargestellten Widgets (oder nur eins, wenn der Widget-Bereich nur eins enthält) aus dem Footer-Bereich direkt unter dem Header zu platzieren. Dort könnte dann vielleicht neben einer Vorstellung der Firma (des Fotografen/des Bloggers) eine kurze Liste mit den angebotenen Leistungen stehen. Des weiteren soll es die Möglichkeit geben, ein Bildschirm füllendes Bild zu wählen, das den Besucher begrüßt. Als zweites Template ist eine Portfolio-Übersicht geplant, die sämtliche Galerien anzeigt, die es auf der Seite gibt.

Neben den Seiten-Templates planen wir noch die Möglichkeit, den Nutzer festlegen zu lassen, ob er quadratische Thumbnails nutzen will oder nicht. Quadratische lassen sich zwar im Design besser händeln, sind aber bei den meisten Fotos nicht optimal, da der Ausschnitt nicht passt. Für Widgets wird es voraussichtlich drei Bereiche geben: einen in der Sidebar und zwei im Footer. Und wo wir gerade bei Widgets sind: Davon wird es auch ein paar geben, unter anderem eins, das die neusten Galerien anzeigt und ein weiteres, in dem ihr Galerien festlegen könnt, die ihr besonders sehenswert findet. In der Einzelansicht einer Galerie wird dann die Sidebar unter den Bildern angeordnet, wo dann auch andere Galerien aus der gerade angeschauten Kategorie angezeigt werden.

Ansicht einer Galerie. Der Nutzer soll die Wahl bekommen, ob er quadratische Thumbnails möchte oder nicht. (Fotos: Dennis Brinkmann)
Ansicht einer Galerie. Der Nutzer soll die Wahl bekommen, ob er quadratische Thumbnails möchte oder nicht. (Fotos: Dennis Brinkmann)

Als kleines Feature wird es dann noch mittels Custom-Fields möglich sein, technische Details zu der jeweiligen Galerie anzugeben, also beispielsweise die verwendete Kamera, das Objektiv, Verschlusszeit et cetera.

Klingt gut – Aber wie soll das genau ablaufen?

Gleich vorweg: Wir haben das Theme selbst erst soweit fertig, wie ihr es hier seht – Code gibt es noch nicht. Es kann also sein, dass spontan noch kleinere Änderungen vorgenommen werden oder vorgenommen werden müssen, was einzelne Funktionen betrifft. Eigentlich sollte das aber alles relativ problemlos zu machen sein.

Wir werden das Theme jetzt also schrittweise entwickeln und das detailliert in der Artikelserie dokumentieren. Am Anfang konzentrieren wir uns nur auf die Inhalte, an das Design setzen wir uns erst danach. Abschließend werden wir das Theme in das Directory hochladen und diesen Prozess im letzten Artikel der Reihe behandeln.

Was würdet ihr euch von dieser Reihe wünschen und gibt es Schritte, die euch ganz besonders wichtig sind?

]]>
Florian Brinkmann
Versionsverwaltung für WordPress: Das kann Revisr http://t3n.de/news/versionsverwaltung-fuer-555328/ 2014-07-03T10:29:30Z
Manchmal kommt man an den Punkt, wo eine ältere Version der WordPress-Installation her muss. Wenn ihr hier nicht entsprechend vorgesorgt habt, kann das schwierig werden. Eine Pluginlösung zur …

Manchmal kommt man an den Punkt, wo eine ältere Version der WordPress-Installation her muss. Wenn ihr hier nicht entsprechend vorgesorgt habt, kann das schwierig werden. Eine Pluginlösung zur Versionsverwaltung stellen wir euch hier vor.

Wenn wieder mal nichts funktioniert: Mit Revisr zur älteren Version

Wenn ihr mit arbeitet und selbst an der Installation bastelt, kennt ihr das sicherlich: Nach einer Änderung funktioniert etwas nicht mehr oder noch schlimmer – ihr merkt es erst später und wisst nicht mehr genau, durch welche Änderung der Fehler entstanden sein könnte. Praktisch wäre es jetzt, wenn ihr ältere Versionen der Installation wiederherstellen könntet. Und das bietet Revisr.

Das Dashboard von Revisr. (Screenshot: Revisr)
Das Dashboard von Revisr. (Screenshot: Revisr)

Mit dem WordPress-Plugin könnt ihr relativ einfach in Verbindung mit einem selbstgehosteten Git-Server eine Versionsverwaltung einrichten. Neben den Daten kann auch die Datenbank gesichert werden. In dem Dashboard findet ihr die letzten Aktivitäten und die Möglichkeit, Änderungen zum Git-Server zu übertragen oder Änderungen wieder rückgängig zu machen. Die Änderungen in den Dateien könnt ihr euch ebenfalls anschauen. Weiter Informationen erhaltet ihr auf der Website von Revisr.

Klingt ja alles toll, aber …

Ein bisschen unglücklich ist, dass der Git-Server auf dem selben Server installiert sein muss, wie die WordPress-Instanz. Und wenn ihr vergesst, Änderungen immer schön händisch an Git zu melden, bringt euch auch das Plugin nicht viel. Neben diesem Plugin gibt es natürlich noch andere Möglichkeiten, wie ihr eine Versionverwaltung einrichten könnt, beispielsweise via Kommandozeile. Wenn ihr euch aber nicht ausreichend damit auskennt, ist ein Plugin sicher eine gute Alternative.

Ein anderes Plugin, das beispielsweise die Sache mit dem manuellen Pushen von Änderungen automatisch lösen will, ist VersionPress. Daneben sollen hier auch Änderungen einzeln zurückgenommen werden können, anstatt gleich die ganze Installation auf einen früheren Stand bringen zu müssen. Das Plugin befindet sich noch in der Entwicklung und soll im vierten Quartal 2014 in der ersten Version veröffentlicht werden. Es dürfte sich auf jeden Fall lohnen, die weitere Entwicklung zu beobachten.

]]>
Florian Brinkmann
TYPO3 Mask: Die Template-Alternative zu Templavoila http://t3n.de/news/typo3-mask-template-alternative-templavoila-554708/ 2014-07-01T08:15:18Z
Derzeit gibt es wenige Templating-Ansätze im TYPO3 CMS. Einige Erweiterungen sind veraltet und andere bieten einfach zu wenig Funktionalität. Genau das soll TYPO3 Mask ändern.

Derzeit gibt es wenige Templating-Ansätze im CMS. Einige Erweiterungen sind veraltet und andere bieten einfach zu wenig Funktionalität. Genau das soll TYPO3 Mask ändern. Mask ist eine Erweiterung, mit der ihr Seitenvorlagen und Inhaltselemente zentral und innerhalb von TYPO3 CMS verwalten könnt. Alle Masken sind durch eigene Eingabefelder erweiterbar und die Darstellung im Frontend ist mit HTML-Templates flexibel anpassbar.

Die Idee zu Mask ist entstanden, als bekannt wurde, dass nicht mehr weiterentwickelt werden würde. Aufgrund mangelnder Alternativen entschloss sich das Team hinter den TYPO3experten, eine eigene Erweiterung zu programmieren. Dabei blieb die Grundidee von – nämlich einer einfachen Point-and-Klick Template-Engine – erhalten, aber die Schwachstellen sollten ausgemerzt werden.

TYPO3 Mask: Usability im Vordergrund

Auf die Bedienbarkeit und Effizienz beim Verwalten von Masken wurde viel Wert gelegt, denn: ein komfortabler Assistent ermöglicht ein rasches Anlegen von Masken, einfach per Drag-&-Drop. Daraus resultiert: Programmierkenntnisse sind bei der Arbeit mit Mask praktisch nicht nötig.

Redakteure haben den Vorteil, dass sie statt eines Rich-Text-Editors strukturierte Eingabefelder zur Datenerfassung zur Verfügung gestellt bekommen. So können auch verschiedene Redakteure die vorhandenen Inhalte verwalten und erzeugen dabei durch vorgefertigte Designvorlagen ein einheitliches Bild im Frontend.

mask
Der Prototyp von Mask. (Screenshot: t3n)

Fazit zu Mask

Mask wurde mit Extbase programmiert – dem MVC Framework von TYPO3. Es werden alle möglichen TYPO3-Standards verwendet: Fluid für das Frontend, das Backend-Layout für die Spaltenansicht der Seitenvorlagen, TCA für Felddefinitionen, IRRE für sich wiederholende Bereiche und natürlich TypoScript für Konfigurationen.

Im Moment ist Mask noch in der Entwicklung. Ein Prototyp existiert aber schon und ist bereits bei einigen Live-Projekten im Einsatz. Das Kernstück, der Assistent zum Verwalten der Vorlagen, steckt aber noch in den Kinderschuhen. Ihr könnt Mask auf startnext.de unterstützen. Oder ihr überzeugt euch selbst von Mask, indem ihr die Mask-Demo testet.

Vermisst ihr Templavoila?

]]>
Mario Janschitz