CMS | t3n News News, Infos, Tipps und aktuelle Artikel zu CMS 2016-02-07T15:13:58Z t3n Redaktion http://t3n.de/tag/cms Formular-Plugins für WordPress: 6 Lösungen im Kurztest http://t3n.de/news/formular-plugins-wordpress-676119/ 2016-02-07T15:13:58Z
Formulare finden sich auf ziemlich vielen Seiten, und sei es nur in der Funktion des Kontaktformulars. In diesem Artikel stellen wir euch WordPress-Plugins vor, die euch die Erstellung von Formularen …

Formulare finden sich auf ziemlich vielen Seiten, und sei es nur in der Funktion des Kontaktformulars. In diesem Artikel stellen wir euch WordPress-Plugins vor, die euch die Erstellung von Formularen erleichtern.

Contact Form 7

Sehr beliebt, aber nicht die bedienfreundlichste Lösung: Das WordPress-Formular-Plugin „Contact Form 7“. (Screenshot: WordPress.org)
Sehr beliebt, aber nicht die bedienfreundlichste Lösung: Das WordPress-Formular-Plugin „Contact Form 7“. (Screenshot: WordPress.org)

Das vermutlich bekannteste und am häufigsten genannte Formular-Plugin für dürfte Contact Form 7 mit seinen über eine Millionen aktiven Installationen sein. Ihr könnt verschiedene Formulare erstellen und alle gängigen Formularfeld-Typen verwenden. Als CAPTCHA kommt standardmäßig reCaptcha von Google zum Einsatz, es können aber auch andere Lösungen wie etwa ein Quiz genutzt werden.

Neben dem Formular kann die E-Mail angepasst werden, die verschickt wird, sowie die Meldungen, die bei erfolgreichem Senden oder bei Fehlern im Frontend angezeigt werden. Das bietet allerdings keinen Drag-&-Drop-Editor, teilweise ist eine Anpassung direkt im Text-Editor notwendig, beispielsweise um das label-Tag nachzurüsten, das nicht automatisch korrekt genutzt wird.

Fast Secure Contact Form

Ansicht der Formular-Erstellung im Fast-Secure-Contact-Form-Plugin. (Screenshot: eigene Installation)
Ansicht der Formular-Erstellung im Fast-Secure-Contact-Form-Plugin. (Screenshot: eigene Installation)

Das Plugin Fast Secure Contact Form bietet ähnliche Funktionen wie Contact Form 7. Die Einstellungsmöglichkeiten sind aber um einiges umfangreicher, damit allerdings auch etwas unübersichtlicher. Die Beschriftung der Felder wird hier automatisch korrekt als Label für das Formularelement ausgezeichnet, bei Contact Form 7 ist dafür eine etwas größere Anstrengung notwendig. Für jedes Formular können einige Style-Angaben direkt angepasst werden. Auch dieses Plugin kann das Formular durch ein CAPTCHA vor Spam schützen und unterstützt eine Vielzahl verschiedener Formularfeld-Typen.

Die Handhabung der Formularerstellung basiert nicht auf einem großen Text-Feld, sondern auf einzelnen Einträgen, wobei jeder ein Feld darstellt. Diese Einträge können einfach per Drag & Drop umsortiert werden. Nette Option: Über URL-Parameter kann ein Formular im Frontend mit bestimmten Werten vorausgefüllt werden.

Ninja Forms

Formulare für WordPress umsetzen mit dem Ninja-Forms-Plugin. (Screenshot: eigene Installation)
Formulare für WordPress umsetzen mit dem Ninja-Forms-Plugin. (Screenshot: eigene Installation)

Vom User-Interface ist Ninja Forms einfacher und bedienungsfreundlicher als die beiden schon vorgestellten Lösungen. Die Erstellung der Formulare geschieht in einem übersichtlichen Interface, wie oben im Screenshot zu sehen. Ihr könnt Felder einfach per Drag & Drop umsortieren, und über den kleinen Pfeil rechts bei jedem Feld gibt es weitere Einstellungen wie die Möglichkeit, ein Feld zum Pflichtfeld zu machen oder eine Zeichenbeschränkung anzugeben.

Neben der Möglichkeit, eine Mail mit dem Formularinhalt an verschiedene E-Mail-Adressen zu schicken – gegebenenfalls auch unterschiedliche Felder an unterschiedliche Adressen – können die Daten auch im Backend eingesehen werden. Neben der kostenlosen Version gibt es noch kostenpflichtige Pläne, die unter anderem Erweiterungen enthalten. So können damit beispielsweise Bedingungen oder mehrseitige Formulare umgesetzt werden. Auch Formulare für das Schreiben von Beiträgen, Seiten oder Custom-Post-Types aus dem Frontend ist mit einer Erweiterung möglich.

Caldera Forms

Caldera Forms ermöglicht auch die Anordnung von Elementen in mehreren Spalten. (Screenshot: WordPress.org)
Caldera Forms ermöglicht auch die Anordnung von Elementen in mehreren Spalten. (Screenshot: WordPress.org)

Das Caldera-Forms-Plugin bietet die Möglichkeit, Formularelemente in mehrere Spalten aufzuteilen. Darüber hinaus unterstützt es mehrseitige Formulare und Bedingungen. Wie bei den meisten vorgestellten Plugins kommt auch Caldera Forms mit einem Drag-&-Drop-Interface daher, bei dem für jedes Element neben dem Namen weitere Einstellungen vorgenommen werden können – wie etwa besagte Bedingungen, ein Platzhalter, eigene CSS-Klassen und mehr.

Zusätzlich zu der umfangreichen kostenlosen Version gibt es einige kostenpflichtige Erweiterungen wie beispielsweise PayPal-Integration und Slack-Benachrichtigungen, wenn ein Formular ausgefüllt wurde.

Formidable Forms

Die Bearbeitungsansicht von Formidable Forms. (Screenshot: WordPress.org)
Die Bearbeitungsansicht von Formidable Forms. (Screenshot: WordPress.org)

Formidable Forms unterstützt in der kostenfreien Variante die wichtigsten Formularfelder, die in einer Drag-&-Drop-Ansicht eingefügt und angepasst werden können. Mehrseitige Formulare sowie Felder, die nur in bestimmten Situationen angezeigt werden, sind nur in der Pro-Version verfügbar – genauso wie alternative Formular-Aktionen wie das Erstellen von Beiträgen.

Nach Erstellung eines Formulars kann bei Bedarf der HTML-Code individuell angepasst werden und die Einträge sind über das Backend einsehbar. Für das Plugin gibt es einige Add-Ons, zum Beispiel für die Integration von PayPal oder MailChimp.

Gravity Forms

Sehr umfangreich ist Gravity Forms. (Screenshot: gravityforms.com)
Sehr umfangreich ist Gravity Forms. (Screenshot: gravityforms.com)

Bei Gravity Forms handelt es sich um ein reines Premium-Plugin, dessen Preis bei 39 US-Dollar für ein Jahr mit Updates und Support für eine Installation anfängt. Das Plugin liefert einen Drag-&-Drop-Editor für das Zusammensetzen des Formulars, für jedes eingefügte Feld werden erweiterte Einstellungsmöglichkeiten bereitgestellt. Formulare können bei Bedarf für einen bestimmten Zeitraum sichtbar gemacht werden, zudem kann ein Formular für das Anlegen von Beiträgen erstellt werden.

Ein Formular kann außerdem auf mehrere Seiten aufgeteilt werden, und neben Bedingungen für einzelne Felder können auch Bedingungen für ganze Formular-Seiten eingestellt werden. Auch Bestell-Formulare sind möglich, im Developer-Plan gibt es außerdem eine passende Integration von PayPal. Alle Einträge werden in der WordPress-Datenbank gespeichert. In den teureren Paketen gibt es noch Add-Ons wie etwa eine MailChimp-Integration, im Developer-Plan eine Dropbox-Integration und mehr.

Welche Lösungen nutzt ihr, um Formulare in WordPress umzusetzen?

]]>
Florian Brinkmann
Flexibilität bis zum Abwinken: Das CMS „ProcessWire“ im t3n-Test http://t3n.de/news/processwire-cms-675223/ 2016-02-06T09:29:25Z
ProcessWire ist ein CMS mit Fokus auf Flexibilität. Statt ein großes Feld für alle Inhalte bereitzustellen, arbeitet es mit mehreren Feldern für kleinere Abschnitte. Wir stellen euch das CMS kurz vor.

ProcessWire ist ein mit Fokus auf Flexibilität. Statt ein großes Feld für alle Inhalte bereitzustellen, arbeitet es mit mehreren Feldern für kleinere Abschnitte. Wir stellen euch das CMS kurz vor.

Wie schon im Teaser angerissen, geht ProcessWire bei der Verwaltung von Inhalten einen etwas anderen Weg als beispielsweise WordPress. Statt ein großes Feld für den kompletten Inhalt einer Seite zu benutzen, arbeitet ProcessWire mit mehreren Feldern, die die Flexibilität deutlich erhöhen. Aber beginnen wir am Anfang.

ProcessWire-Installation

Auswahl der Websiteprofils für die ProcessWire-Installation. (Screenshot: eigene Installation)
Auswahl der Websiteprofils für die ProcessWire-Installation. (Screenshot: eigene Installation)

Zur Installation könnt ihr euch das CMS ProcessWire von der offiziellen Download-Seite runterladen. Es gibt drei Download-Pakete – ich habe für diesen Artikel die 3.0.5-Version gewählt. Nachdem ihr das ZIP-Archiv auf eurem Server entpackt habt, müsst ihr einfach den Pfad zu den Dateien aufrufen, um die Installation zu starten.

Direkt nach dem Welcome-Screen könnt ihr ein Website-Profil auswählen, das installiert werden soll – das ist besonders praktisch, wenn ihr noch nicht mit ProcessWire gearbeitet habt und nicht von Null starten wollt. Wir wählen das Profil „Default (Beginner Edition)“ aus und gehen weiter zum nächsten Schritt. Hier wird geprüft, ob die Server-Umgebung alle erforderlichen Voraussetzungen erfüllt. Im Anschluss müssen die Zugangsdaten für die MySQL-Datenbank sowie Zeitzone und Zugriffsrechte für Dateien angegeben werden – Standardrechte sind hier 755 für Ordner und 644 für Dateien. Zudem sollten die Host-Namen angegeben werden, unter denen die Installation laufen wird.

Die Ansicht des ProcessWire-Backends nach dem ersten Login mit den Beispiel-Seiten. (Screenshot: eigene Installation)
Die Ansicht des ProcessWire-Backends nach dem ersten Login mit den Beispiel-Seiten. (Screenshot: eigene Installation)

Im Anschluss wird die Datenbankverbindung überprüft und der Nutzer kann die URL, unter der das Admin-Login-Formular erscheinen soll, sowie das Farbschema für das Admin-Panel angeben. Außerdem muss ein Admin-Account angelegt werden, und optional kann die Installation von unnötigen Dingen befreit werden – wie dem Installer und ungenutzten Website-Profilen.

Danach ist die Installation abgeschlossen und das Backend kann aufgerufen werden, das normalerweise über die URL /processwire zugänglich ist. Der erste Blick ins Backend sieht aus, wie in dem Screenshot oben.

Die Inhaltsverwaltung von ProcessWire verstehen

Ansicht des Templates „basic-page“ mit den zugehörenden Feldern. (Screenshot: eigene Installation)
Ansicht des Templates „basic-page“ mit den zugehörenden Feldern. (Screenshot: eigene Installation)

Wie schon erwähnt, arbeitet ProcessWire nicht mit einem einzigen großen Inhaltsfeld, sondern mit kleineren Unterteilungen. Jeder Inhaltsseite muss zuerst ein Template zugewiesen werden – alle Inhalte werden in einem Seitenbaum organisiert. Für diese Templates wiederum können Felder festgelegt werden, die der Nutzer dann für eine Seite mit diesem Template ausfüllen kann. So gibt es beispielsweise das Template basic-page mit den Feldern title, headline, summary, body und sidebar – wenn im Backend über den Menüpunkt „Setup“ › „Templates“ ein Template gewählt wird, können auch neue Felder hinzugefügt werden, die schon angelegt sind. Außerdem kann hier eingesehen werden, welche Seiten das Template benutzen. Diese Ansicht ist im Screenshot oben zu sehen. Ein Template muss aber nicht unbedingt Felder haben – für ein Blog-Template könnten beispielsweise alle Informationen aus den Unterseiten geholt werden, die dann die einzelnen Blogbeiträge darstellen würden.

Die „About“-Seite im ProcessWire-Backend. (Screenshot: eigene Installation)
Die „About“-Seite im ProcessWire-Backend. (Screenshot: eigene Installation)

Wenn wir jetzt in unserer Installation mit der Beispiel-Site im Backend die Inhaltsseite „About“ wählen, können wir die Felder des Templates sehen und verändern, wie im Screenshot oben abgebildet ist.

Um ein neues Feld anzulegen oder alle Felder zu sehen, die schon angelegt wurden, gehen wir über den Menüpunkt „Fields“ unter „Setup“ – die Ansicht seht ihr unten im Screenshot. Hier sehen wir ganz links den Namen der Felder, daneben die Beschriftung, die im Seiten-Editor angezeigt wird, den Typ des Felds und die Anzahl der Templates, die das Feld nutzen. Wie geschrieben, kann hier auch ein neues Feld angelegt werden, beispielsweise eine Checkbox, ein Datumsfeld oder ein Upload-Dialog. Beim Anlegen des Felds können jeweils noch Einschränkungen gemacht werden, wie etwa die maximale Anzahl von Dateien, die hochgeladen werden können.

Alle Felder der ProcessWire-Installation. (Screenshot: eigene Installation)
Alle Felder der ProcessWire-Installation. (Screenshot: eigene Installation)

Inhalte auf der Website anzeigen

Jetzt haben wir grob umrissen, wie die Inhalte im Backend angelegt und organisiert werden, es fehlt uns noch die Möglichkeit, Inhalte auf der Website anzuzeigen. Dafür ist eine PHP-Datei zuständig, die immer mit einem Template gekoppelt ist. Die Dateien befinden sich im Ordner site/templates der Installation. Beim Anlegen eines neuen Templates im Backend versucht ProcessWire automatisch, eine passende PHP-Datei zu finden und sucht dabei nach einer Datei gleichen Namens. Für das Template basic-page gibt es daher im templates-Ordner die Datei basic-page.php. Es ist am einfachsten, wenn ihr vor dem Anlegen eines neuen Templates zuerst eine entsprechende Template-Datei anlegt, damit ProcessWire die Zuordnung automatisch vornehmen kann.

Die About-Seite im Frontend. (Screenshot: eigene Installation)
Die About-Seite im Frontend. (Screenshot: eigene Installation)

Wie die Ausgabe gehandhabt wird, werden wir uns beispielhaft mit dem basic-page-Template angucken, dem beispielsweise die About-Seite zugewiesen ist. Wie die Seite im Frontend aussieht, seht ihr im Screenshot oben. Der Inhalt der Datei basic-page.php sieht – gekürzt um ein paar Kommentare – folgendermaßen aus:

<?php
include('./_head.php'); // include header markup ?>
<div id='content'><?php 
    // output 'headline' if available, otherwise 'title'
    echo "<h1>" . $page->get('headline|title') . "</h1>";
    // output bodycopy
    echo $page->body; 
    // render navigation to child pages
    renderNav($page->children); 	
?></div><!-- end content -->
<div id='sidebar'> 1) {
        // output sidebar navigation
        // see _init.php for the renderNavTree function
        renderNavTree($section);
    }
    // output sidebar text if the page has it
    echo $page->sidebar; 
?></div><!-- end sidebar -->
<?php include('./_foot.php'); // include footer markup ?>

Zuerst wird der Kopfbereich des Templates eingebunden, in dem die Navigation und andere Infos bereitgestellt werden, die auf jeder Seite eingebunden werden sollen. In der fünften Zeile seht ihr dann den ersten Inhaltsbereich, der ausgegeben wird: Die Headline beziehungsweise der Title, wenn keine Headline hinterlegt ist. Dafür wird die get()-Methode des $page-Objekts genutzt und mehrere Namen von Feldern übergeben, getrennt von einem senkrechten Strich. Das erste Feld, das nicht leer ist, wird ausgegeben.

Um den Inhalt des Felds body auszugeben, muss lediglich echo $page->body ausgeführt werden. Nach demselben Prinzip kann auf alle Felder zugegriffen werden, die im Backend angelegt sind und die eine Seite nutzt. Einige Feldtypen sind etwas komplexer, wie beispielsweise Felder zum Hochladen von Bildern. Nähere Infos zu den verfügbaren Methoden für einzelne Feldtypen gibt es auf der entsprechenden Doku-Seite.

Mit renderNav($page->children); wird eine Verlinkung auf die Child-Seiten der aktuellen Seite ausgegeben, inklusive Ausgabe des Summary-Felds. Soweit ich gesehen habe, ist diese Funktion nicht offiziell dokumentiert, ein Blick in den Quellcode schafft aber schnell Klarheit.

In der Sidebar soll ein Baum des aktuellen Seiten-Zweigs abgebildet werden, wenn die erste Ebene des Zweigs – in unserem Fall die Seite „About“ – mehr als eine Unterseite hat. Dafür wird über $page->rootParent zuerst die oberste Seite des Zweiges ermittelt und dann geprüft, ob hasChildren eine Zahl größer 1 ergibt. Ist das der Fall, wird renderNavTree aufgerufen. Wie im Code zu sehen, kann neben den Seiten auch noch eine maximale Tiefe des Baumes angegeben werden, sowie ein oder mehrere Feldnamen, die mit ausgegeben werden sollen – beispielsweise eine kurze Beschreibung jeder Seite.

Die _head.php-Datei werden wir uns nicht komplett anschauen, sondern nur ein paar Dinge herauspicken.

$homepage = $pages->get('/');
$children = $homepage->children();
// make 'home' the first item in the navigation
$children->prepend($homepage); 
// render an <li> for each top navigation item
foreach($children as $child) {
    if($child->id == $page->rootParent->id) {
        // this $child page is currently being viewed (or one of it's children/descendents)
        // so we highlight it as the current page in the navigation
        echo "<li class='current'><a href='$child->url'>$child->title</a></li>";
    } else {
        echo "<li><a href='$child->url'>$child->title</a></li>";
    }
}

In diesem Code-Block wird die Hauptnavigation ausgegeben. Zuerst wird mit $pages->get('/'); die Startseite gespeichert und anschließend alle Kindelemente mit $homepage->children(); ermittelt. Um auch die Startseite in der Navigation einzufügen, wird diese Seite mittels $children->prepend($homepage); an den Anfang des Arrays eingefügt. Danach wird in einer Schleife die Navigation ausgegeben.

Um für angemeldete Nutzer mit den notwendigen Rechten einen Link zur Bearbeitungsansicht der aktuellen Seite anzuzeigen, genügt folgender Code:

if($page->editable()) {
    echo "<li class='edit'><a href='$page->editUrl'>Edit</a></li>";
}

In der _foot.php, die wir hier ebenfalls nicht komplett ausbreiten werden, findet sich noch folgender interessanter Schnipsel:

if($user->isLoggedin()) {
    // if user is logged in, show a logout link
    echo "<a href='{$config->urls->admin}login/logout/'>Logout ($user->name)</a>";
} else {
    // if user not logged in, show a login link
    echo "<a href='{$config->urls->admin}'>Admin Login</a>";
}

Über $user->isLoggedin() kann getestet werden, ob der aktuelle Nutzer eingeloggt ist.

Fazit

ProcessWire ist ein tolles CMS, das vor allem durch seine große Flexibilität besticht – darüber hinaus ist es leichtgewichtiger als die „großen“ Systeme. Durch intelligenten Einsatz der Felder können viele Informationen von Seiten anderswo wiederverwendet werden, ohne sie erneut anlegen zu müssen.

Eine tolle Funktion für jemanden, der hauptsächlich das Bild-Management von WordPress gewohnt ist: Bilder können direkt vor der Ausgabe in der Template-Datei auf die richtige Größe zugeschnitten oder skaliert werden – es werden keine Bildgrößen beim Upload angelegt.

Dazu kommt, dass der Einstieg nicht wirklich schwierig ist, wenn die grundlegende Art der Felder und Templates verstanden wurde. Ein näherer Blick lohnt sich auf jeden Fall!

]]>
Florian Brinkmann
Erschreckender Anstieg gehackter WordPress-Seiten: Hunderte Blogs sollen Ransomware ausliefern http://t3n.de/news/wordpress-sicherheit-ransomware-677129/ 2016-02-05T11:34:19Z
Gleich mehrere Sicherheitsfirmen haben diese Woche berichtet, dass es einen starken Anstieg an gehackten WordPress-Websites gibt. Die betroffenen Seiten sollen versuchen die Rechner von Besuchern mit …

Gleich mehrere Sicherheitsfirmen haben diese Woche berichtet, dass es einen starken Anstieg an gehackten WordPress-Websites gibt. Die betroffenen Seiten sollen versuchen die Rechner von Besuchern mit Ransomware zu infizieren.

WordPress-Seiten liefern Ransomware aus

Am 1. Februar 2016 berichtet die Sicherheitsfirma Sucuri von einem massiven Anstieg an gehackten WordPress-Seiten. Seitdem bestätigten zwei weitere Unternehmen aus dem Sicherheitsbereich die Angaben von Sucuri. Laut Malwarebytes sollen Hunderte Websites betroffen sein. Bei den angegriffenen Seiten wird schädlicher Javascript-Code in die bestehende Codebasis integriert. Dieser Code schickt Besucher weiter auf andere Seiten, auf denen ihre Rechner dann mit Ransomware infiziert werden könnten.

Betroffen sind Nutzer die eine nicht aktuelle Version von Adobes Flash-Player, Adobes Reader, Microsofts Silverlight oder des Internet Explorers einsetzen. Um nicht sofort aufzufliegen, zielt die Weiterleitung nur auf Besucher, die zum ersten Mal die betroffene WordPress-Seite aufrufen. Immerhin soll Googles Safe-Browsing-Mechanismus Nutzer vor dem Besuch einiger der betroffenen Weiterleitungen warnen. Ein Blog-Beitrag von Heimdal Security zeigt allerdings, dass sich die Ziel-Domains seit Beginn der Kampagne geändert haben. Es bleibt daher anzunehmen, dass die kriminellen Urheber der Ransomware-Kampagne die Weiterleitungen immer wieder aktualisieren.

WordPress: So sieht der verschlüsselte Schadcode aus. (Screenshot: Sucuri)
WordPress: So sieht der verschlüsselte Schadcode aus. (Screenshot: Sucuri)

Anstieg an WordPress-Hacks: Ursache derzeit noch unbekannt

Derzeit ist unklar, wie sich die Hintermänner der Kampagne so vielen WordPress-Blogs bemächtigen konnten. Es ist möglich, dass die betroffenen Seiten einfach nicht sonderlich gut auf ihre Sicherheit geachtet haben. Möglich wäre aber auch der Einsatz einer bislang unbekannten Sicherheitslücke in WordPress oder einem der eingesetzten Plugins.

Die Malware infiziert nach Angaben des Sicherheitsexperten Denis Sinegubko alle JavaScript-Dateien auf einem Server. Werden mehrere Websites über einen Hosting-Account betrieben, könnten leicht alle Seiten infiziert werden. Auch müssten im Schadensfall alle Seiten von dem Schadcode bereinigt werden, da sie sonst die anderen Websites immer wieder infizieren könnten.

In diesem Zusammenhang sollten Seitenbetreiber auch unbedingt einen Blick auf unseren Artikel „WordPress, Joomla!, Drupal und Co.: Die wichtigsten Updates für die wichtigsten CMS (Januar)“ werfen.

via arstechnica.com

]]>
Kim Rixecker
WordPress, Joomla!, Drupal und Co.: Die wichtigsten Updates für die wichtigsten CMS (Januar) http://t3n.de/news/cms-updates-januar-2016-675883/ 2016-02-02T13:41:05Z
Bei den großen CMS und einem Blog-System gibt es regelmäßig Updates, die neue Funktionen liefern oder Sicherheitslücken schließen. Die wichtigsten Updates aus dem Januar stellen wir euch hier …

Bei den großen CMS und einem Blog-System gibt es regelmäßig Updates, die neue Funktionen liefern oder Sicherheitslücken schließen. Die wichtigsten Updates aus dem Januar stellen wir euch hier kurz vor.

WordPress

Am 5. Januar wurde ein Release-Kandidat für WordPress 4.4.1 veröffentlicht. Die neue Version behebt unter anderem ein Problem mit älteren OpenSSL-Versionen sowie eins mit falschen Weiterleitungen, wenn Teile eines Slugs wiederverwendet werden. Außerdem wurde das Emoji-Polyfill aktualisiert und unterstützt nun Unicode 8.0. Am Tag darauf wurde die finale 4.4.1-Version des CMS veröffentlicht, die die genannten Änderungen an alle Nutzer verteilt. Neben den genannten Neuerungen wurde in eine XSS-Lücke behoben. Alle Neuerungen und Änderungen können in der entsprechenden Core-Trac-Query angeschaut werden.

Einen Release-Kandidat für 4.4.2 haben die WordPress-Macher am 1. Februar vorgestellt, der unter anderem ein Paginierungs-Problem auf der Startseite nach dem 4.4.1-Update behebt. Darüber hinaus wurden Probleme bei den Kommentaren behoben, die beispielsweise eine falsche Pagination sowie falsche Sortierung betreffen.

4.4.1

  • Aktualisierung des Emoji-Supports
  • Fixed: XSS-Sicherheitslücke
  • Fixed: Falsche Weiterleitung bei wiederverwendeter Post-URL

4.4.2 RC

  • Fixed: Paginierungsproblem auf der Startseite
  • Fixed: verschiedene Probleme im Kommentarbereich

Drupal

Für den 8er-Zeig des Drupal-CMS wurde eine neue Version veröffentlicht. (Screenshot: drupal.org)
Für den 8er-Zeig des Drupal-CMS wurde eine neue Version veröffentlicht. (Screenshot: drupal.org)

Für das Drupal-CMS wurde am 6. Januar Version 8.0.2 veröffentlicht. Bei dem Release handelt es sich um einen Wartungsrelease, der unter anderem einen Fehler in den Logo-Einstellungen sowie ein Problem, das bei LocaleConfigManager::updateConfigTranslations() Übersetzungen gelöscht werden, behebt. Alle Änderungen und bekannten Probleme findet ihr in den Release-Notizen.

8.0.2

  • Fixed: Problem mit gelöschten Übersetzungen bei LocaleConfigManager::updateConfigTranslations()
  • Fixed: Probleme mit den Logo-Einstellungen

Joomla!

Am 27. Januar wurde die zweite Beta-Version zu Joomla! 3.5 veröffentlicht. Genaue Angaben dazu, welche Fehler der ersten Beta behoben wurden, gibt es nicht – die Version hat aber noch zwei bekannte Probleme, die der Veröffentlichung vom finalen Release im Weg stehen: So gibt es auf einigen Servern ohne utf8mb4-Support Probleme bei der Aktualisierung und einen unschädlichen Fatal Error, wenn die Session abläuft.

Ghost

Die Macher der Blog-Software Ghost haben am 12. Januar Version 0.7.5 vorgestellt. Der Release bringt from- und to-Attribute für die Helper {{tags}} und {{#foreach}} und verbessert die Performance des Backends, wenn mit einer großen Anzahl von Beiträgen gearbeitet wird. Alle Änderungen könnt ihr im Changelog einsehen.

0.7.5

  • Fixed: Tag-Bilder nicht in den Sitemaps
  • Fixed: Backend langsam und nicht responsive, wenn große Zahl Beiträge durchsucht oder navigiert wird
]]>
Florian Brinkmann
Newsletter mit WordPress: 5 Plugins für Erstellung und Management http://t3n.de/news/newsletter-wordpress-5-plugins-673869/ 2016-01-30T13:03:26Z
Mit Newslettern können Leser regelmäßig mit Infos direkt in der Inbox versorgt und so an das eigene Angebot gebunden werden. Wir stellen euch fünf Plugins für WordPress vor, die euch Newsletter …

Mit Newslettern können Leser regelmäßig mit Infos direkt in der Inbox versorgt und so an das eigene Angebot gebunden werden. Wir stellen euch fünf Plugins für vor, die euch direkt aus dem heraus verwalten lassen.

Ein Hinweis vorab: In die Übersicht haben wir nur Lösungen aufgenommen, die das Double-Opt-In-Verfahren, also die Bestätigung der Newsletter-Anmeldung durch den Nutzer, unterstützen.

1. MailPoet

Ein Blick auf den Newsletter-Editor von MailPoet. (Screenshot: WordPress.org)
Ein Blick auf den Newsletter-Editor von MailPoet. (Screenshot: WordPress.org)

MailPoet gibt es als kostenlose Version sowie in verschiedenen Stufen als Premium-Angebot. Mit der kostenlosen Version könnt ihr maximal 2.000 Abonennten haben, die aber in unendlich vielen Listen organisieren. Ihr könnt den Newsletter entweder manuell verschicken oder nach bestimmten Aktionen: wenn sich ein neuer Nutzer für den Newsletter anmeldet, wenn ein neuer Inhalt erstellt oder wenn ein neuer Nutzer zur WordPress-Installation hinzugefügt wurde. Daraufhin könnt ihr sofort einen Newsletter, beziehungsweise eine Nachricht verschicken – oder zeitversetzt.

Den Newsletter-Inhalt könnt ihr via Drag & Drop zusammensetzen und neben normalen Inhalten auch automatisch ermittelte, wie die letzten fünf Beiträge, einfügen. Zudem könnt ihr Schriften und Farben anpassen und ein anderes Design nutzen. In den Einstellungen des Plugins können Dinge wie der Text des Abmelden-Links und die Bestätigungsmail verändert sowie Formulare für die Anmeldung zum Newsletter erstellt werden.

Neben der kostenlosen Version gibt es noch die Versionen „Blogger“ für 75, „Freelance“ für 189 und „Agency“ für 299 Euro pro Jahr. Der einzige Unterschied zwischen den Premium-Versionen ist die Anzahl der Websites, für die die Premium-Version mit Updates und Support für ein Jahr installiert werden kann. Das geht von einer Website über vier bis hin zu unendlich vielen in der „Agency“-Version. In den bezahlten Versionen gibt es unter anderem kein Abonnenten-Limit, ihr könnt exklusive Premium-Themes für den Newsletter nutzen, Kampagnen mit Google Analytics tracken und mehr.

2. Newsletter

So sieht es im Bereich des WordPress-Plugins „Newsletter“ aus. (Screenshot: eigene Installation)
So sieht es im Bereich des WordPress-Plugins „Newsletter“ aus. (Screenshot: eigene Installation)

Bei dem WordPress-Plugin „Newsletter“ gibt es ebenfalls eine kostenlose und eine kostenpflichtige Variante – aber auch die kostenlose ist ohne Beschränkung der Abonennten. Auch mit „Newsletter“ könnt ihr tracken, wie viele eurer Abonennten den Newsletter geöffnet haben. Neben einer HTML-Version könnt ihr eine Text-Version bereitstellen – für die HTML-Mail gibt es vorgefertigte Designs, es kann aber auch ein eigenes erstellt werden. Den Inhalt könnt ihr wahlweise mit WYSIWYG- oder HTML-Ansicht einfügen.

Ihr habt die Wahl, ob ein Abonennt die Newsletter-Anmeldung bestätigen muss oder nicht. Eine Checkbox für die Anmeldung zum Newsletter kann in das Standard-Registrierungsformular von WordPress integriert werden oder als anpassbares Formular auf einer Seite oder in einem Widget.

Um automatische Newsletter zu verschicken, die beispielsweise die letzten Beiträge oder anderen automatischen Inhalt verschicken, muss eine der Premium-Versionen des Plugins erworben werden. Der Blogger-Plan kostet diese Woche 39,95 statt 49,95 US-Dollar, für ein Jahr Updates, Support und Dokumentation. Ihr könnt das damit auf allen euren eigenen Website installieren. Wenn ihr es auch für Kundenprojekte einsetzen wollt, müsst ihr den Agency-Plan für 97 US-Dollar kaufen. Neben der Möglichkeit automatisierter Newsletter sind in beiden Premium-Plänen noch weitere Erweiterungen vorhanden: Das Plugin „Reports“ verbessert die internen Berichte, „Follow Up“ ermöglicht das Senden einer oder mehrerer Nachrichten nach der Anmeldung eines Nutzers und eine weitere Erweiterung lässt Nutzer sich via Facebook-Connect quasi mit einem Klick anmelden. Darüber hinaus sind noch Erweiterungen für ein Anmelde-Pop-Up und die Integration der externen SMTP-Services Sendgrid, Mailjet und Mandrill in dem Paket enthalten.

3. Tribulant Newsletters

Das Tribulant-Newsletters-Plugin. (Screenshot: WordPress.org)
Das Tribulant-Newsletters-Plugin. (Screenshot: WordPress.org)

Das Newsletter-Plugin der Firma Tribulant kommt ebenfalls in einer kostenlosen und mehreren kostenpflichtigen Versionen daher. Das Plugin bietet unter anderem die Möglichkeit für verschiedene Templates, den Newsletter als Beitrag zu veröffentlichen, zahlungspflichtiges Abo via PayPal und 2CheckOut, Tracking von Link-Klicks und Autoresponder.

Zudem funktioniert das Plugin mit den Lösungen qTranslate und WPML für Mehrsprachigkeit, erlaubt auch Anmeldeformulare außerhalb der WordPress-Website, bringt die Möglichkeit der DKIM-Signatur mit und ist kompatibel mit Gmail-SMTP. Neben den Kernfunktionen kann das Plugin durch einige Erweiterungen angereichert werden, beispielsweise mit Google-Analytics-Integration und dem Einbetten von Bildern in E-Mails, statt sie vom Server zu laden.

In den Funktionen ist die kostenplose Version mit der kostenpflichtigen identisch – es können aber nur eine Mailing-Liste für maximal 500 Abonennten erstellt werden, und maximal 1.000 E-Mails pro Monat versandt werden. Diese Limits gibt es in der Pro-Version nicht: Für eine einzelne Domain kostet das Plugin einmalig 64,99 US-Dollar, für unendlich viele einmalig 194,78 US-Dollar.

4. Mailchimp

Mit einem Plugin lässt sich MailChimp ins WordPress-Backend integrieren. (Screenshot: mailchimp.com)
Mit einem Plugin lässt sich MailChimp ins WordPress-Backend integrieren. (Screenshot: mailchimp.com)

MailChimp ist sicher einigen ein Begriff. Es gibt ein paar Plugins, um den Dienst in das WordPress-Backend zu integrieren, wobei vermutlich „Integral MailChimp for WordPress“ am interessantesten ist. Das Plugin ermöglicht euch, eure Abonennten zwischen WordPress und MailChimp zu synchronisieren, Anmelde-Formulare als Widgets anzuzeigen und Newsletter direkt aus dem WordPress-Backend zu erstellen und zu verschicken, wobei euch alle Funktionen aus dem E-Mail-Editor von MailChimp zur Verfügung stehen.

Zudem könnt ihr die Öffnungsrate, Link-Klicks und mehr einsehen, sowie Nachrichten nur an bestimmte Zielgruppen schicken. Das Plugin kostet für eine einzelne Seite 99 US-Dollar, für fünf Websites 249 und für unendlich viele 399 US-Dollar. MailChimp selbst ist bis 2.000 Abonennten und 12.000 E-Mails pro Monat kostenlos. Nach/Vorteil ist hier, dass ihr die Daten nicht alle auf eurem Server liegen habt, sondern bei MailChimp.

5. SendPress Newsletters

Die Ansicht eines Newsletters im Backend mit dem SendPress-Plugin. (Screenshot: WordPress.org)
Die Ansicht eines Newsletters im Backend mit dem SendPress-Plugin. (Screenshot: WordPress.org)

SendPress Newsletters lässt euch auch in der kostenlosen Version unendlich viele Newsletter an undendlich viele Abonennten schicken. Dabei könnt ihr entweder über den eigenen Hoster oder über Gmail versenden. Das Plugin bietet eine anpassbare Anmelde-Seite, ein Widget oder eigenes Formular. Neben einer HTML-Version des Newsletters kann eine Text-Version erstellt werden – auch das Tracking von Klicks, Öffnungsrate und Newsletter-Abmeldung ist möglich.

In der kostenpflichtigen Version kann der Newsletter zusätzlich zu Gmail oder dem eigenen Server über Mandrill, Sengrid, Mailgun oder Elastic Email verschickt werden. Außerdem gibt es nähere Infos zu den angeklickten Links, ein Kampagnen-Tracking mit Google Analytics, KissMetrics und ein Jahr Updates. In allen Pro-Plänen sind alle Pro-Module enthalten. Der kleinste Plan kostet 99 US-Dollar für eine Site, für 199 US-Dollar gibt es das Plugin für drei Websites und für 399 US-Dollar für 20. Enthalten sind immer ein Jahr Updates und Support.

PluginEinschränkungen der freien Version im Vergleich zu ProPro-Version
MailPoet- maximal 2.000 Abonennten
- keine Klick-Statistiken
- kein Bounce-Management
- kein Kampagnen-Tracking
- 75 Euro pro Jahr für eine Site
- 189 Euro pro Jahr für vier Sites
- 299 Euro pro Jahr für unendlich viele Sites
Newsletter- gibt keine Pro-Version, nur kostenpflichtige Erweiterungen
- keine automatischen Newsletter möglich
- verschiedene Erweiterungen für bessere Berichte, automatische Newsletter
Tribulant Newsletters- nur eine Liste
- maximal 500 Abonennten
- maximal 1.000 E-Mails pro Monat
- 64,99 US-Dollar für eine Domain
- 194,78 US-Dollar für unendlich viele Domains
Integral MailChimp for WordPress- keine kostenlose Version- 99 US-Dollar für eine Site
- 249 US-Dollar für fünf Sites
- 399 US-Dollar für unendlich viele Websites
SendPress Newsletters- keine automatische Bounce-Behandlung
- Keine eigenen HTML-Templates
- Kein Kampagnen-Tracking
- 99 US-Dollar für eine Website
- 199 US-Dollar für drei Websites
- 399 US-Dollar für 20 Sites

Kennt ihr noch weitere Plugins, die das komplette Management von Newslettern im Backend ermöglichen?

]]>
Florian Brinkmann
Das eigene WordPress-Theme erstellen – #20: Fertigstellung und Hochladen ins Directory http://t3n.de/news/eigene-wordpress-theme-erstellen-fertigstellung-und-hochladen-ins-directory-671197/ 2016-01-15T18:31:37Z
In dieser Artikelreihe geht es darum, ein WordPress-Theme zu erstellen – von Grund auf. Im 20. und letzten Teil geht es um diverse Punkte, wie das Laden der Übersetzungen, Einbinden des …

In dieser Artikelreihe geht es darum, ein WordPress-Theme zu erstellen – von Grund auf. Im 20. und letzten Teil geht es um diverse Punkte, wie das Laden der Übersetzungen, Einbinden des Stylesheets und mehr.

Da es in dieser Reihe um die WordPress-Funktionen geht, werden die Skripte für das Menü und die Lightbox nicht genauer besprochen. Auch die CSS-Datei wird einfach eingebunden. Den kompletten Code findet ihr dann ja auch von diesen Dateien auf GitHub.

Lightbox- und Menü-Skript einbinden

Damit die Bilder, die als Link auf ihre volle Größe eingebunden werden, nach Klick auf den Link in einer Lightbox dargestellt werden, muss ein Skript eingebunden werden. Wir nutzen dafür eine leicht angepasste Version des Skripts von Osvaldas Valutis und platzieren es in einer lightbox.js innerhalb des js-Ordners.

Damit das Menü mit dem Menü-Button auf kleinen Viewports angezeigt werden kann, benötigen wir ebenfalls ein JavaScript, das im js-Ordner in die menu.js geschrieben wird. Um die Skripte einzubinden, nutzen wir die wp_enqueue_script()-Funktion, die auch Abhängigkeiten von Skripten berücksichtigen kann.

function bornholm_scripts_styles() {
    wp_enqueue_script( 'bornholm-menu', get_template_directory_uri() . '/js/menu.js', array( 'jquery' ), false, true );
    wp_enqueue_script( 'bornholm-lightbox', get_template_directory_uri() . '/js/lightbox.js', array( 'jquery' ), false, true );
}
add_action( 'wp_enqueue_scripts', 'bornholm_scripts_styles' );

Die Funktion bornholm_scripts_styles() kommt in die functions.php und wird an den Action-Hook wp_enqueue_scripts gehängt. Als ersten Parameter übergeben wir an die beiden wp_enqueue_script()-Aufrufe eine ID des Skripts, gefolgt von dem Pfad. Mit get_template_directory_uri() wird die URL zu dem Theme oder – falls es sich um ein Child-Theme handelt – zum Eltern-Theme ausgegeben. Mit dem dritten Parameter geben wir an, dass zuerst das Skript mit der ID jquery geladen werden soll. Mit dem nächsten Parameter kann eine Version für das Skript angegeben werden und mit dem letzten, ob das Skript im Footer geladen werden soll – Standardwert ist hier false.

Kommentar-Skript, Stylesheet und Web-Font einbinden

Wo wir jetzt gerade beim Einbinden von Skripten sind, können wir damit auch gleich fortfahren. WordPress bringt ein Skript comment-reply mit, das bei einer Antwort auf einen anderen Kommentar das Kommentarformular per JavaScript direkt unter dem Kommentar einfügt, auf den geantwortet werden soll. Das wollen wir nur einbinden, wenn ein einzelner Beitrag angezeigt wird, Kommentare offen und verschachtelte Kommentare aktiviert sind. An den Anfang der bornholm_scripts_styles() schreiben wir darum folgenden Code:

if ( is_singular() && comments_open() && get_option( 'thread_comments' ) ) {
    wp_enqueue_script( 'comment-reply' );
}

Um ein Skript einzubinden, das WordPress schon registriert hat, genügt der erste Parameter mit dem Bezeichner.

Als Stylesheet wollen wir statt der style.css eine bornholm.css aus dem noch anzulegenden css-Ordner und als Font Roboto von Google verwenden, die wir direkt von dem Schriftdienst Google Web Fonts einbinden können. Die Google Web Fonts bilden eine Ausnahme in den Regeln des Theme Directorys — alle anderen Ressourcen müssen mit dem Theme mitgeliefert werden. Um das Stylesheet und den Font einzubinden, schreiben wir folgenden Code ans Ende der bornholm_scripts_styles():

wp_enqueue_style( 'bornholm-style', get_template_directory_uri() . '/css/bornholm.css', array(), null );
wp_enqueue_style( 'bornholm-fonts', '//fonts.googleapis.com/css?family=Roboto:300,300italic,500,500italic', array(), null );

Wir geben genau wie bei wp_enqueue_script() als ersten Parameter einen Bezeichner an, gefolgt von dem Pfad zu der Datei. Wichtig bei der Google-Web-Fonts-URL: Sie beginnt mit zwei Schrägstrichen, sodass automatisch http oder https verwendet wird, je nachdem, was in der WordPress-Installation eingestellt ist. Als dritten Parameter lassen sich wieder Abhängigkeiten angeben und als vierten eine Versionsnummer.

More-Sprung entfernen, Content-Breite festlegen und Bildgrößen aktualisieren

Standardmäßig fügt WordPress an die URL eines Weiterlesen-Links eine Sprungmarke ein, sodass auf der Einzelansicht eines Artikels direkt an die Stelle gesprungen wird, wo das More-Tag verwendet wurde. Ich persönlich finde dieses Verhalten etwas verwirrend, weshalb wir es für das Theme entfernen werden.

function bornholm_remove_more_link_scroll( $link ) {
    $link = preg_replace( '|#more-[0-9]+|', '', $link );
    return $link;
}
add_filter( 'the_content_more_link', 'bornholm_remove_more_link_scroll' );

Über den Filter the_content_more_link können wir die URL des More-Links filtern. Über den Parameter ist die URL zugänglich, die wir in der Funktion mit einem regulären Ausdruck bearbeiten. Wir suchen in der URL nach einem Abschnitt des Musters #more- gefolgt von mindestens einer Ziffer, und entfernen ihn. Anschließend geben wir die veränderte URL zurück.

Mit der Variable $content_width kann in einem WordPress-Theme die maximale Breite des Inhalts angegeben werden. Diese Angabe berücksichtigt WordPress beispielsweise beim Einfügen von oEmbed-Inhalten, wie YouTube-Videos, oder von Bildern. Diese Variable kann beschrieben werden, ohne in einer Funktion zu stehen.

if ( ! isset( $content_width ) ) {
    $content_width = 800;
}

Wir prüfen zunächst, ob die Variable noch nicht gesetzt ist, und übergeben ihr dann den Wert 800. Um die Bildgrößen, die WordPress generiert, an unser Theme anzupassen, müssen wir die Größen des Thumbnails und der großen Bildgrößen verändern:

update_option( 'thumbnail_size_w', 9999 );
update_option( 'thumbnail_size_h', 200 );
update_option( 'thumbnail_crop', 0 );
update_option( 'large_size_w', 800 );

Diese Funktionsaufrufe können einfach über den add_image_size()-Aufrufen notiert werden, die in zwei früheren Teilen behandelt wurden. Wie ihr seht, kann mit update_option() eine bestehende Bildgröße verändert werden, indem als erster Parameter der Bezeichner übergeben wird, der verändert werden soll, gefolgt von dem neuen Wert. Mit thumbnail_size_w sprechen wir die Breite der Thumbnails an, die wir auf 9999 stellen, über thumbnail_size_h ändern wir die Höhe. Wir möchten nicht, dass Thumbnails beschnitten werden, und übergeben deshalb für thumbnail_crop den Wert 0. Um die großen Bilder an unsere Content-Breite anzupassen, übergeben wir an large_size_w die Breite 800.

Nachdem diese Änderungen vorgenommen sind, werden in den Medien-Einstellungen die neuen Werte angezeigt. Angwendet werden sie allerdings nur auf neu hochgeladene Bilder – schon vorhandene müssen beispielsweise mit dem Plugin Regenerate Thumbnails neu erzeugt werden.

Übersetzungen laden

Durch den konsequenten Einsatz von Gettext-Funktionen wie __() und _x() im Zusammenspiel mit der korrekten Text-Domain, haben wir das Theme auf die Übersetzung vorbereitet. Themes im Directory können seit einiger Zeit auf translate.WordPress.org übersetzt werden, ohne eigene Übersetzungen mitliefern zu müssen. Es können aber weiter eigene Übersetzungsdateien mit hochgeladen werden, die dann eventuelle Übersetzungen von translate.WordPress.org überschreiben würden.

Wir möchten keine Übersetzungen mitliefern sondern die von der Übersetzungs-Plattform nutzen.

function bornholm_load_translation() {
    if ( ( ! defined( 'DOING_AJAX' ) && ! 'DOING_AJAX' ) || ! bornholm_is_login_page() || ! bornholm_is_wp_comments_post() ) {
        load_theme_textdomain( 'bornholm' );
    }
}
add_action( 'after_setup_theme', 'bornholm_load_translation' );
function bornholm_is_login_page() {
    return in_array( $GLOBALS['pagenow'], array( 'wp-login.php', 'wp-register.php' ) );
}
function bornholm_is_wp_comments_post() {
    return in_array( $GLOBALS['pagenow'], array( 'wp-comments-post.php' ) );
}

Das Laden der Übersetzung wird in der bornholm_load_translation() durch den Aufruf von load_theme_textdomain() und die Übergabe der Text-Domain als Parameter bewerkstelligt. Damit wir die Übersetzung nur laden, wenn sie auch benötigt wird, machen wir vorher ein paar Tests. So soll die Übersetzung nicht geladen werden, wenn ein AJAX-Request ausgeführt wird, außerdem weder auf der Login-Seite noch auf der, die nach dem Abschicken eines Kommentars aufgerufen wird. Auf AJAX können wir mit ( ! defined( 'DOING_AJAX' ) && ! 'DOING_AJAX' ) prüfen, für die anderen beiden Fälle haben wir zwei kleine Hilfsfunktionen geschrieben.

function bornholm_is_login_page() prüft mit in_array(), ob die aktuell angezeigte URL, die über $GLOBALS['pagenow'] ermittelt werden kann, die wp-login.php oder wp-register.php ist und gibt in diesen beiden Fällen true zurück. Nach demselben Prinzip geht bornholm_is_wp_comments_post() vor, die auf die wp-comments-post.php prüft.

Die Readme und der Screenshot

Fehlen uns jetzt noch eine Readme und ein Screenshot, der im Backend und im Directory angezeigt wird. In die readme.txt kommen neben einem Changelog noch Lizenzinformationen für jede fremde Ressource. Wenn ihr ein komplexes Theme mit etwas komplizierteren Funktionen erstellt habt, ist das auch ein guter Platz, um einen Schnelleinstieg in der Theme zu beschreiben.

Der Screenshot für das Theme. (Screenshot: WordPress Theme Directory)
Der Screenshot für das Theme. (Screenshot: WordPress Theme Directory)

Oben ist der Screenshot für das Theme abgebildet, der ein Seitenverhältnis von 4:3 haben sollte und nicht größer als 1.200x900 Pixel sein darf. Auch hier muss darauf geachtet werden, dass die Bilder, die auf dem Screenshot zu sehen sind, unter einer geeigneten Lizenz stehen.

Hochladen ins Theme Directory

Wenn ihr mit dem Theme zufrieden seid und mit dem Plugin Theme Check sichergestellt habt, dass keine Fehler ausgegeben werden, könnt ihr das Theme ins Theme Directory hochladen. Alles was ihr dazu braucht, ist ein kostenloser WordPress.org-Account.

Nachdem ihr es hochgeladen habt, wird ein Ticket im Theme-Trac erstellt, dem sich nach einer gewissen Zeit ein Reviewer annimmt. Aktuell kann das ein paar Monate dauern, da die Reviewer eine Gruppe Freiwilliger sind und es davon weniger gibt als Theme-Autoren, die ihr Theme hochladen. Wenn ihr Lust habt, könnt ihr auch selbst ein Reviewer werden.

Wenn der Reviewer Fehler findet, müsst ihr sie korrigieren und eine neue Version des Themes über die normale Upload-Seite hochladen. Sobald der Reviewer zufrieden ist, kommt ihr in eine Liste mit Themes, die von einem Admin angeschaut werden müssen. Eventuell findet der noch Sachen, die der erste Reviewer nicht gefunden hat, es kann also sein, dass vor dem Live-Schalten noch weitere Anpassungen notwendig sind. Wenn ihr weitere Fragen zu dem Prozess habt, könnt ihr im #themereview-Channel vom WordPress-Slack nachfragen.

Danke für eure Aufmerksamkeit

An dieser Stelle Danke an alle, die bis hierher mitgelesen haben. Ich hoffe, es war alles verständlich und ihr habt ein bisschen was gelernt. Natürlich ist dieses Theme nicht perfekt, und ich habe schon beim Nachfolger einige Dinge eleganter lösen können, beispielsweise die Zählung der Kommentare und Trackbacks. Das kommt mit der Zeit, und man findet immer etwas, was man später anders und besser löst – für den Einstieg ist diese Reihe aber denke ich nicht die schlechteste Adresse :)

Den Code gibt es wie immer auf GitHub, der letzte Stand des Repositorys entspricht dem des fertigen Themes.

Die weiteren Teile unserer WordPress-Reihe:

]]>
Florian Brinkmann
Von WordPress-Beiträgen zur Print-Ausgabe: Dieses Plugin macht’s möglich http://t3n.de/news/wordpress-beitraege-zu-print-670454/ 2016-01-14T09:17:12Z
Mit dem Plugin „Eight Day Week Print Workflow“ können die Inhalte für Print-Produkte in WordPress geschrieben und nachher für InDesign exportiert werden. Wir stellen euch das Plugin hier kurz vor.

Mit dem „Eight Day Week Print Workflow“ können die Inhalte für Print-Produkte in geschrieben und nachher für InDesign exportiert werden. Wir stellen euch das Plugin hier kurz vor.

Die Agentur 10up hat für ihren Kunden Observer eine Lösung entwickelt, um den bisherigen Print-Workflow, der in einem Word-Prozessor begonnen hat und erst nach InDesign und InCopy sowie dem Druck für die Online-Stellung in WordPress integriert wurde, umzustellen. Ziel war, diesen Prozess umzudrehen und in WordPress zu starten. Ergebnis ist ein WordPress-Plugin, das unter dem Namen „Eight Day Week Print Workflow“ veröffentlicht wurde und kostenlos nutzbar ist.

„Eight Day Week Print Workflow“: Komplette Print-Ausgaben in WordPress verwalten

Der erste Schritt zur Nutzung des Plugins ist es, für jeden Print-Artikel einen normalen WordPress-Beitrag anzulegen, da das Plugin mit den normalen Beiträgen arbeitet. Dabei kann jedem Autor der Ausgabe ein Account angelegt werden und eine Nutzerrolle gewählt werden, sodass er nur seine eigenen Beiträge bearbeiten kann.

Anlegen einer Publikation im WordPress-Plugin „Eight Day Week Print Workflow“. (Screenshot: eigene Installation)
Anlegen einer Publikation im WordPress-Plugin „Eight Day Week Print Workflow“. (Screenshot: eigene Installation)

Nach der Installationd des Plugins „Eight Day Week Print Workflow“ gibt es einen neuen Menüpunkt „Print“ im WordPress-Backend. Darunter finden sich die Punkte „Print Issues“, „Issue Statuses“, „Publications“ sowie „Article Statuses“. Zudem werden zwei neue Benutzerrollen eingeführt: „Print Editor“ hat vollen Zugriff auf die Funktionen des Plugins, „Print Production“ hat nur Leserechte, kann aber den XML-Export nutzen.

Zuerst muss über den Punkt „Publications“ ein Produkt angelegt werden, dem Ausgaben zugewiesen werden können, wie im Screenshot oben am Beispiel des t3n Magazins zu sehen. Anschließend können für die Artikel und Ausgaben verschiedene Status angelegt werden, die in den Print-Workflow passen. Etwa den Status, dass ein Artikel fertig zur Korrekturlesung oder noch in der Entwurfsphase ist. Danach kann im Bereich „Print Issues“ eine Ausgabe angelegt werden, wie im folgenden Screenshot mit der t3n Nr. 40 gezeigt.

Anlegen einer Ausgabe mit den Artikeln. (Screenshot: eigene Installation)
Anlegen einer Ausgabe mit den Artikeln. (Screenshot: eigene Installation)

In dem Bereich gibt es die Möglichkeit, verschiedene Abschnitte der Ausgabe anzulegen und dieser die entsprechenden WordPress-Beiträge zuzuordnen. Eine Umsortierung der Bereiche sowie der Artikel innerhalb eines Bereichs ist per Drag-&-Drop möglich. Der „Print Editor“ kann entsprechend der Rückmeldungen von Autoren die Artikel-Status anpassen und nach Fertigstellung eines Artikels kann dieser als XML exportiert und in InDesign importiert werden. Neben der Möglichkeit, einzelne Artikel oder nur die angehakten zu exportieren, können natürlich auch alle auf einmal exportiert werden.

Das Plugin ist in Modulen aufgebaut, die sich einzeln via Filter deaktivieren lassen. Zudem gibt es Filter, um die dargestellten Informationen in der Artikel-Tabelle und in der Print-Ausgaben-Tabelle sowie den Export von Artikeln anzupassen. Nähere Informationen dazu gibt es im GitHub-Repo des Plugins.

]]>
Florian Brinkmann
Das eigene WordPress-Theme erstellen – #19: Die Customizer-Einstellungen im Theme anwenden http://t3n.de/news/eigene-wordpress-theme-erstellen-4-669013/ 2016-01-09T08:23:43Z
In dieser Artikelreihe geht es darum, ein WordPress-Theme zu erstellen – von Grund auf. Der 19. Teil setzt die Auswirkungen der Customizer-Einstellungen im Theme um.

In dieser Artikelreihe geht es darum, ein WordPress-Theme zu erstellen – von Grund auf. Der 19. Teil setzt die Auswirkungen der Customizer-Einstellungen im um.

Im letzten Teil haben wir die Optionen in den Customizer eingefügt, allerdings passiert bei einer Veränderung der Werte nicht besonders viel. Darum müssen wir die Werte nun im Theme nutzen, um die Einstellungen auch sichtbar zu machen. Die Werte aus dem Customizer lassen sich mit der get_theme_mod()-Funktion ermitteln, der die ID von der Einstellung übergeben wird, deren Wert gesucht ist – optional als zweiter Parameter lässt sich ein Standard-Wert angeben. Die ID ist immer der erste Parameter, den wir im letzten Teil an die add_setting()-Methode übergeben haben.

Anzahl der Galerien aus derselben Kategorie in Galerie-Einzelansicht

Bisher legen wir in der sidebar-gallery.php die Anzahl der zu zeigenden Galerien mit der folgenden Zeile fest:

$number_of_galleries = 3;

Diese Zeile wird ersetzt, damit in $number_of_galleries der korrekte Wert aus dem Customizer gespeichert wird:

$number_of_galleries = get_theme_mod( 'number_of_galleries_from_same_category_on_single_gallery_page', 3 );

Als ersten Parameter übergeben wir an get_theme_mod() wie besprochen die ID der Einstellung und in diesem Fall als Standard-Wert 3. Um die weiteren Galerien nur anzuzeigen, wenn die Zahl größer als 0 ist, wird der weitere Code ein wenig angepasst:

if ( $number_of_galleries > 0 ) {
    $category_ids = bornholm_get_the_category_ids( $post->ID );
    $args         = array(
        'orderby' => 'name',
        'include' => $category_ids,
    );
    $categories   = get_categories( $args );
    $exclude_id   = $post->ID;
    foreach ( $categories as $cat ) {
        $title = sprintf( _x( 'More galleries from %1$s', '1 = name of category', 'bornholm' ), $cat->name );
        bornholm_get_galleries_from_category( $cat, $exclude_id, $number_of_galleries, 'h3', $title, false );
    }
}

Mit Ausnahme der if-Bedingung ist der Code bereits aus Teil 10 bekannt. Damit wäre bereits die erste Anpassung vorgenommen und die erste Customizer-Einstellung funktionstüchtig gemacht.

Galerie-Titel auf alternativer Startseite, Portfolio-Seite und Einzelansicht verstecken

Der Nutzer hat durch Checkboxen die Möglichkeit, Titel von Galerie-Vorschauen auf der alternativen Startseite, der Portfolio-Seite und in der Einzelansicht einer Galerie zu verstecken. Diese drei Einstellungen werden in der Funktion bornholm_alternative_front_page_gallery_teaser() umgesetzt, die ebenfalls im 10. Teil besprochen wurde. Hier hätte übrigens im Nachhinein die Funktion besser allgemeiner benannt werden können.

Die Funktion muss für die Umsetzung ein bisschen erweitert werden, der aktualisierte Code innerhalb des article-Elements sieht so aus:

<?php $images_child = bornholm_get_gallery_images( $post->ID );
$hide_gallery_titles_on_alternative_front_page = get_theme_mod( 'hide_gallery_titles_on_alternative_front_page' );
$hide_gallery_titles_for_galleries_from_same_category = get_theme_mod( 'hide_gallery_titles_for_galleries_from_same_category' );
$hide_gallery_titles_on_portfolio_page = get_theme_mod( 'hide_gallery_titles_on_portfolio_page' );
$page_template = basename( get_page_template( $post->ID ) );
if ( ( $hide_gallery_titles_on_alternative_front_page == 1 && $page_template == 'alternative-front-page.php' ) ||
    ( $hide_gallery_titles_for_galleries_from_same_category == 1 && get_post_format() == 'gallery' && is_single() ) ||
    $hide_gallery_titles_on_portfolio_page == 1 && $page_template == 'portfolio-page.php' ) {
    bornholm_gallery_header( '', $images_child, 'thumbnail', $post );
} else {
    bornholm_gallery_header( 'h3', $images_child, 'thumbnail', $post );
} ?>

Nachdem die Bilder ermittelt worden sind, wird für jede der drei Einstellungen der aktuelle Wert aus dem Customizer ermittelt – dafür kommt wieder get_theme_mod() zum Einsatz. Über die Nutzung von basename( get_page_template( $post->ID ) ) gelangen wir an den Dateinamen des gerade angezeigten Seiten-Templates.

Nun muss für alle drei Fälle geprüft werden, ob die Option im Customizer angehakt ist und das gerade angezeigte Seiten-Template dem entspricht, für das die Option gedacht ist. Bei der Option für die Einzelansicht der Galerien wird mit get_post_format() == 'gallery' geprüft, ob der Beitrag vom Typ gallery ist und mit is_single(), ob es sich um eine Einzelansicht handelt.

Wenn eine dieser Kombinationen wahr ist, wird der Header ohne Überschrift ausgegeben, indem für die Heading-Ebene ein leerer String übergeben wird. Wenn keine der Bedingungen wahr ist, wird der Galerie-Teaser mit Überschrift angezeigt.

Den Titel in den Galerie-Widgets verbergen

Zusätzlich zu den eben besprochenen Optionen kann der Nutzer auch für die zwei Widgets die Anzeige des Titels deaktivieren. Dafür müssen Änderungen in den beiden Widget-Dateien innerhalb des inc-Verzeichnisses vorgenommen werden – wir beginnen mit der class-featured-galleries.php, wobei folgender Teil angepasst werden muss:

<div>
    <?php bornholm_gallery_header( 'h4', $images, 'thumbnail', $post ); ?>
</div>

Die angepasste Version sieht wie folgt aus:

$hide_gallery_titles_on_featured_galleries_widget = get_theme_mod( 'hide_gallery_titles_on_featured_galleries_widget' ); ?>
<div>
    <?php if ( $hide_gallery_titles_on_featured_galleries_widget == 1 ) {
        bornholm_gallery_header( '', $images, 'thumbnail', $post );
    } else {
        bornholm_gallery_header( 'h4', $images, 'thumbnail', $post );
    } ?>
</div>

Zuerst wird erneut der entsprechende Customizer-Wert ermittelt. Innerhalb des divs wird dann geprüft, ob die Checkbox zum Verstecken der Titel angehakt ist, also den Wert 1 hat. In diesem Fall wird als Überschriftenebene wie aus dem vorangegangenen Fall bekannt ein leerer String übergeben, andernfalls h4, um den Titel anzuzeigen.

Die Anpassung in der class-recent-galleries.php läuft entsprechend ab – folgende Stelle muss verändert werden:

<div>
    <?php bornholm_gallery_header( 'h4', $images, 'thumbnail', $post ); ?>
</div>

Und das ist die angepasste Version:

$hide_gallery_titles_on_recent_galleries_widget = get_theme_mod( 'hide_gallery_titles_on_recent_galleries_widget' ); ?>
<div>
    <?php if ( $hide_gallery_titles_on_recent_galleries_widget == 1 ) {
        bornholm_gallery_header( '', $images, 'thumbnail', $post );
    } else {
        bornholm_gallery_header( 'h4', $images, 'thumbnail', $post );
    } ?>
</div>

Die Vorgehensweise ist identisch mit der eben erläuterten und unterscheidet sich lediglich in dem Variablennamen und der ID, die an get_theme_mod() übergeben wird.

Anzahl der kleinen Vorschaubilder in der Blog-Übersicht

In der Blog-Übersicht werden für jeden Beitrag mit dem Post-Format „Galerie“ unter einem großen Vorschaubild zwei kleine dargestellt. Diese Anzahl kann der Nutzer im Customizer anpassen und durch Eingabe von 0 die kleinen Bilder komplett entfernen. Damit die Änderung auch angezeigt wird, muss in der content-gallery.php folgende Zeile angepasst werden:

$number_of_small_images = 2;

Wir ersetzen sie mit dem folgenden Code-Schnipsel:

$number_of_small_images = get_theme_mod( 'number_of_small_images_from_gallery_in_blog_view', 2 );

Hier ist nichts Überraschendes zu sehen: Mit get_theme_mod() holen wir uns den Wert und geben als Standard 2 an. Der Rest der Datei kann unberührt bleiben.

Kategorie-Hierarchie auf der alternativen Startseite

Bisher werden die Beiträge auf der alternativen Startseite immer hierarchisch nach ihren Kategorien angezeigt. Um das mit der Option im Customizer zu verbinden, muss folgender Teil in der alternative-front-page.php angepasst werden:

$args = array(
    'orderby' => 'name',
    'parent'  => 0
);
$show_child_category_hierarchy = true;

Um eine hierarchische Anzeige zu verhindern, wird weder der parent-Schlüssel in das Array eingefügt, das die Kategorien ermittelt, noch $show_child_category_hierarchy mit true gefüllt. Der angepasste Teil sieht wie folgt aus:

$galleries_on_alternative_front_page = get_theme_mod( 'hierarchy_of_gallery_on_alternative_front_page' );
if ( $galleries_on_alternative_front_page == 0 ) {
    $args = array(
        'orderby' => 'name',
    );
    $show_child_category_hierarchy = false;
} else {
    $args = array(
        'orderby' => 'name',
        'parent'  => 0
    );
    $show_child_category_hierarchy = true;
}

Nachdem der Wert aus dem Customizer ausgelesen worden ist, wird überprüft, ob die Checkbox nicht angehakt ist. Ist das der Fall, wird dem Argument-Array nur der Schlüssel orderby übergeben und der Wert für $show_child_category_hierarchy auf false gesetzt. Ist die Checkbox angehakt, wird das bereits bekannte Array genutzt.

Anzahl der Galerien pro Kategorie auf der alternativen Startseite

Bisher werden pro Kategorie drei Galerien angezeigt, bevor der Link auf die Kategorie-Übersicht ausgegeben wird. Zuständig dafür ist diese Zeile aus der alternative-front-page.php:

$number_of_galleries = 3;

Diese Zeile ersetzen wir mit der folgenden, um die Einstellung aus dem Customizer zu verwenden:

$number_of_galleries = get_theme_mod( 'number_of_galleries_on_alternative_front_page', 3 );

Darstellung der Galerien auf der Portfolio-Seite

Für die Portfolio-Seite kann der Nutzer neben der ungruppierten Anzeige wählen, ob die Galerien nach Kategorien oder nach Kategorien inklusive ihrer Hierarchie gruppiert sind. Es kommt also lediglich der Teil dazu, der das Ergebnis der Anpassung in der alternative-front-page.php war. Der zu verändernde Teil aus der portfolio-page.php ist folgender:

$args = array(
    'posts_per_page' => '-1',
    'tax_query'      => array(
        array(
            'taxonomy' => 'post_format',
            'field'    => 'slug',
            'terms'    => 'post-format-gallery'
        )
    )
);

Wie der Teil nach der Anpassung aussieht, ist im nächsten Code-Block zu sehen:

$galleries_on_portfolio_page = get_theme_mod( 'galleries_on_portfolio_page' );
if ( $galleries_on_portfolio_page == 'portfolio_page_grouped_by_categories' || $galleries_on_portfolio_page == 'portfolio_page_grouped_by_categories_with_hierarchy' ) {
    if ( $galleries_on_portfolio_page == 'portfolio_page_grouped_by_categories' ) {
        $args = array(
            'orderby' => 'name',
        );
        $show_child_category_hierarchy = false;
    } else {
        $args = array(
            'orderby' => 'name',
            'parent'  => 0
        );
        $show_child_category_hierarchy = true;
    }
    $categories          = get_categories( $args );
    $exclude_id          = "";
    $number_of_galleries = "";
    foreach ( $categories as $cat ) {
        $title = $cat->name;
        bornholm_get_galleries_from_category( $cat, $exclude_id, $number_of_galleries, 'h2', $title, $show_child_category_hierarchy );
    }
} else {
    $args = array(
        'posts_per_page' => '-1',
        'tax_query'      => array(
        array(
            'taxonomy' => 'post_format',
            'field'    => 'slug',
            'terms'    => 'post-format-gallery'
        )
    )
);

Das sieht auf den ersten Blick viel aus, ist aber bereits alles bekannt. Nachdem der Wert des Radio-Buttons aus dem Customizer geholt wurde, wird geprüft, ob die Galerien gruppiert oder gruppiert und hierarchisch angezeigt werden sollen. Ist das der Fall, wird dieselbe Fallunterscheidung für das Argument-Array vorgenommen, wie im Code-Beispiel aus der alternative-front-page.php. Auch die Vorbereitung der Ausgabe entspricht dem bereits behandelten Code dieser Datei, nur dass als Anzahl ein leerer String angegeben wird, damit unendlich viele pro Kategorie ausgegeben werden können.

Sollen die Galerien nicht gruppiert angezeigt werden, wird einfach der Code ausgeführt, der vorher auch schon Teil der Datei war.

Textfarbe des Headers

Eine Standard-Option im Customizer ist die Anpassung der Header-Farbe. Die muss jedes Theme selbst umsetzen, da sich das HTML-Markup, das durch CSS angesprochen werden muss, immer unterscheidet. Dafür muss folgende Funktion in die customizer.php eingefügt werden:

function bornholm_customize_css() {
    if ( get_theme_mod( 'header_textcolor' ) ) { ?>
        <style type="text/css">
            .site-title a {
                color: <?php echo '#' . get_theme_mod('header_textcolor'); ?>;
            }
        </style>
    <?php }
}
add_action( 'wp_head', 'bornholm_customize_css' );

Zuerst wird geprüft, ob für die Header-Textfarbe ein Wert eingesetzt wurde. Ist das der Fall, wird ein style-Element geöffnet und darin für den Selektor .site-title a mit get_theme_mod('header_textcolor') der richtige color-Wert eingesetzt. Die Funktion wird an den wp_head-Hook angehängt, worduch das style-Element im Header ausgegeben wird.

Damit wären wir mit diesem Teil auch schon durch. Viel fehlt jetzt nicht mehr, der nächste Teil wird sich voraussichtlich mit Diversem beschäftigen, beispielsweise mit dem Laden der Übersetzung und der Aktualisierung einiger Bildgrößen. Ob das dann bereits der letzte Teil sein wird, weiß ich aber noch nicht :)

Den Code auf GitHub

Und zum Schluss der Hinweis, dass es den Code zur Theme-Reihe immer aktuell im GitHub-Repo gibt. Den Stand des Themes nach diesem Teil gibt es bei Tag „v0.17“.

Die weiteren Teile unserer WordPress-Reihe:

]]>
Florian Brinkmann
Gefahr für Drupal-Nutzer: Update-Prozess soll das CMS angreifbar machen http://t3n.de/news/drupal-update-sicherheit-669331/ 2016-01-07T10:20:47Z
Der Update-Mechanismus von Drupal soll Nutzern anzeigen, sie hätten die aktuelle Version des CMS, obwohl das Update fehlgeschlagen ist. Außerdem soll sich der Mechanismus auch dazu nutzen lassen, …

Der Update-Mechanismus von soll Nutzern anzeigen, sie hätten die aktuelle Version des , obwohl das Update fehlgeschlagen ist. Außerdem soll sich der Mechanismus auch dazu nutzen lassen, Schadsoftware auf dem System einzuschleusen.

Drupal: Fehlerhafter Update-Prozess sorgt für Probleme

Mehr als eine Million Websites setzen das Content-Management-System Drupal ein. Viele Nutzer von Drupal 7 und 8 könnten allerdings eine veraltete Version einsetzen, ohne es zu wissen. Nach Angaben des Sicherheitsexperten Fernando Arnaboldi zeigt der automatische Update-Mechanismus den Nutzern an, sie hätten die neuste Version, auch wenn der Update-Prozess aufgrund von Netzwerkproblemen fehlgeschlagen ist. So könnten sich Drupal-Nutzer in falscher Sicherheit wiegen.

Drupal: Der automatische Update-Mechanismus ist anscheinend fehlerhaft. (Screenshot: IOActive)
Drupal: Der automatische Update-Mechanismus ist anscheinend fehlerhaft. (Screenshot: IOActive)

Immerhin besteht die Möglichkeit, manuell nach Updates zu suchen. Wie Arnaboldi berichtet, besteht hier aber eine weitere Gefahr. Zumindest unter Drupal 7 lädt das CMS eine XML-Datei von Drupal.org über eine unverschlüsselte HTTP-Verbindung herunter, in der sich die Informationen über aktuelle Updates befinden. Über eine Man-in-the-Middle-Attacke könnten Angreifer dem Drupal-Nutzer daher ein manipuliertes Update unterjubeln. Immerhin scheint Drupal 8 davor allerdings geschützt zu sein.

Drupal: Nutzer sollten sich nicht auf den automatischen Update-Mechanismus verlassen

Derzeit gibt es keinen Patch für die oben erwähnten Probleme. Arnaboldi rät Drupal-Nutzern daher, Updates für Drupal und Add-ons manuell herunterzuladen. Das Problem dabei: Niemand hat vermutlich die Zeit, ständig nach Updates Ausschau zu halten. Wie wichtig es aber ist, das CMS möglichst schnell auf den neusten Stand zu bringen, zeigt ein Fall von Oktober 2014. Innerhalb kurzer Zeit verschafften sich Angreifer damals Zugriff auf Drupal-Systeme, die ein aktuelles Sicherheitsupdate nicht schnell genug installiert hatten.

Ebenfalls interessant in diesem Zusammenhang ist unser Artikel „Drupal 8: Verbesserte Usability, einfacher Export von Einstellungen und responsives Backend“.

via www.theregister.co.uk

]]>
Kim Rixecker
WordPress, Joomla!, TYPO3 CMS und Co.: Die wichtigsten Updates für die wichtigsten CMS (Dezember) http://t3n.de/news/wordpress-joomla-typo3-cms-dezember-668246/ 2016-01-05T07:47:04Z
Bei den großen CMS und einem Blog-System gibt es regelmäßig Updates, die neue Funktionen liefern oder Sicherheitslücken schließen. Die wichtigsten Updates aus dem Dezember stellen wir euch hier …

Bei den großen CMS und einem Blog-System gibt es regelmäßig Updates, die neue Funktionen liefern oder Sicherheitslücken schließen. Die wichtigsten Updates aus dem Dezember stellen wir euch hier kurz vor.

Neos

Bei dem CMS Neos wurde Version 2.1 veröffentlicht. (Screenshot: Neos.io)
Bei dem CMS Neos wurde Version 2.1 veröffentlicht. (Screenshot: Neos.io)

Am 22. Dezember wurde Neos 2.1 veröffentlicht. Die neue Version ist unter anderem komplett kompatibel mit PHP 7 und ermöglicht das gemeinsame Bearbeiten eines nicht öffentlichen Workspaces. Darüber hinaus wurde die Performance bei der Thumbnail-Generierung verbessert. Mehr Informationen zu dem Release gibt es in unserem Beitrag „Neos 2.1 bringt kollaboratives Bearbeiten, PHP-7-Kompatibilität und mehr“.

2.1

  • kollaboratives Bearbeiten von Workspaces
  • PHP-7-Kompatibilität
  • performantere Generierung von Thumbnails

WordPress

Die neue WordPress-Version 4.4 wurde „Clifford“ getauft. (Screenshot: WordPress.org)
Die neue WordPress-Version 4.4 wurde „Clifford“ getauft. (Screenshot: WordPress.org)

Am 8. Dezember haben die WordPress-Macher Version 4.4 des CMS veröffentlicht. Mit dem Release wird die Infrastruktur der REST API in den Core gebracht, ebenso wie die standardmäßige Unterstützung von responsive Images mit dem srcset- und sizes-Attribut. Zudem lassen sich WordPress-Inhalte jetzt einfach auf anderen Seiten einbetten, da WordPress selbst zum oEmbed-Provider geworden ist. Auch ein neues Standard-Theme ist mit dabei. Näheres zu der neuen Version haben wir im Artikel „WordPress 4.4: Das ist neu beim meistgenutzten CMS der Welt“ für euch.

4.4

  • Integration der REST-API-Infrastruktur
  • responsive Images
  • neues Standard-Theme

Joomla!

Von Joomla! wurden im Dezember gleich drei neue Versionen rausgebracht: 3.4.6, 3.4.7 und 3.4.8. Joomla! 3.4.6 wurde am 14. Dezember veröffentlicht und behebt eine kritische und vier weniger kritische Sicherheitslücken. Auch Version 3.4.7, die eine Woche später nachgeschoben wurde, behebt eine kritische Sicherheitslücke und eine leichte.

Der 3.4.8-Release wurde der Öffentlichkeit am 24. Dezember präsentiert und behebt lediglich ein paar Bugs. Ein Update auf mindestens 3.4.7 ist dringend empfohlen, am besten natürlich auf 3.4.8.

3.4.6

3.4.7

3.4.8

  • Fixed: Nutzer konnten nach dem 3.4.7-Update keine Artikel mehr bearbeiten oder erstellen
  • Fixed: Nach Ablauf der Session konnten Nutzer weiter im Backend navigieren, ohne etwas Erstellen oder Bearbeiten zu können

TYPO3 CMS

Das TYPO3-CMS-Team hat am 15. Dezember 6.2.16 und 7.6.1 veröffentlicht, bei denen es sich um Wartungs- und Bugfix-Releases handelt. Wenn die Erweiterung mediace eingesetzt wird, sollte auf 7.6.1 aktualisiert werden. Am 21. Dezember wurden dann 6.2.17 und 7.6.2 rausgebracht, die ein paar Fehler aus der jeweils vorangegangenen Version beheben.

6.2.16 und 7.6.1

  • Fixed: XSS-Lücke im Erweiterungs-Manager
  • Fixed: Mehrere XSS-Lücken um Backend
  • Fixed: Mehrere XSS-Lücken im Frontend

6.2.17 und 7.6.2

  • Fixed: Bugs, die durch vorangegangene Version hervorgerufen wurden

Ghost

Auch bei der Blog-Software Ghost gab es gleich mehrere Updates im Dezember: Am 16. Dezember wurde Version 0.7.3 vorgestellt, die Permalinks und posts_per_page via @blog im Theme zugänglich macht. Außerdem wird bei nicht existierenden Seiten in der Pagination und RSS jetzt ein 404-Fehler zurückgegeben und es gibt die Möglichkeit, die API von externen Seiten zu nutzen.

Am 22. Dezember wurden mit Release 0.7.4 ein paar Fehler aus 0.7.3 korrigiert.

0.7.3

  • Fixed: Shortcuts funktionieren nicht im Editor
  • Fixed: Beschriftungen von Checkboxen werden auf Mobilgeräten abgeschnitten
  • Fixed: Pagination funktioniert nicht im {{#get}}-Helper

0.7.4

  • Fixed: Doppeltes URL-Feld im Bild-Uploader
  • Fixed: Tag-Seiten für Tags starten mit Nummern
]]>
Florian Brinkmann