„WordPress ist scheiße!“ Oder: Warum WordPress kein CMS ist

Der findige Leser wird in diesem Moment vermutlich denken: „Moment mal, dies ist doch ein WordPress-Blog. Warum steht dann in der Überschrift, dass WordPress scheiße ist?“. Zugegeben, die Überschrift klingt schon ein wenig reißerisch, aber eigentlich geht es darum zu erklären, warum WordPress eben nicht scheiße ist.

„WordPress ist scheiße!“

Wenn man einen Entwickler zu WordPress befragt, wird er vermutlich sofort auf die miese Programmstruktur zu sprechen kommen. Und wenn man sich den Code mal ansieht, kann man das auch durchaus verstehen. Es werden kaum bekannte Design-Patterns verwendet, vieles basiert noch auf prozeduralen Programmcode und an vielen Stellen sieht man richtige Worst-Practice-Beispiele, für die man im Geschäftsalltag wohl ordentlich was auf die Mütze bekommen würde. Trotzdem ist WordPress eines der meistgenutzten Websoftware der Welt. Wie kann das sein?

WordPress ist einfach

WordPress läuft auf wirklich jedem Host und ist super einfach zu installieren. Man braucht keine Vorkenntnisse und auch keine große Einarbeitungszeit. Genau DAS ist es, was die große Mehrheit will. Komplexe Systeme wie TYPO3 oder Drupal sind vielleicht besser zu individualisieren, bieten mehr Funktionen und sind skalierbarer, aber für die breite Masse sind diese Vorteile doch völlig uninteressant. Brauche ich für meinen privaten Blog ein Asset-Manager oder eine kleinteilig einzustellende Rechteverwaltung? Nein – und genau so geht es den meisten anderen auch.

WordPress ist usable

Ich habe selten ein Stück Software gesehen, das für den Nutzer so gut zu bedienen ist. Man braucht nur wenige Klicks, um einen Artikel zu veröffentlichen, einen Kommentar freizuschalten oder um auf die aktuellste Version zu aktualisieren – das nenne ich effizientes Arbeiten. Und das alles kommt ganz ohne viel Schnickschnack oder Effekte aus. Vom Usability-Konzept können sich selbst bekannte CMS mehrere Scheiben von abschneiden.

WordPress ist kein CMS

So, genug gelobt. Kommen wir nun zum problematischen Teil von WordPress.
Es gibt viele, die versuchen aus dem eigentlich genialen Blog-System ein richtiges und vollwertiges CMS zu machen. Sie installieren Plugins für Multimandaten-Seiten, Mehrsprachigkeit, verbesserte Berechtigungen, erweitertes Caching, SEO, WYSIWYG-Editoren, und so weiter und so weiter, nur damit sie am Ende sagen können: „Hier hast du ein WordPress-CMS. Es kann genauso viel wie jedes andere CMS, lässt sich aber so einfach wie WordPress bedienen“. An dieser Stelle kommt die bereits angesprochene Skalierbarkeit ins Spiel. WordPress ist einfach nicht darauf ausgelegt, komplexe Erweiterungen und Plugins einzubinden. Das ist schon alleine wegen der fehlenden Design-Pattern eine schlechte Idee und steigert die Instabilität des gesamten Systems. Außerdem verliert man durch jedes dieser Plugins immer mehr an Usability und das einst so einfache Bedienkonzept geht den Bach runter. Denn sind wir mal ehrlich: So gut die Usability von WordPress auch ist, so sind die Plugins meist auf einem viel geringeren Niveau anzusiedeln.

TL;DR

WordPress ist das beste Blog-System, das es derzeit gibt. Bitte macht daraus nicht etwas, was es eigentlich nicht ist. Wer einen Blog oder eine Homepage mit ein paar einfachen Seiten und News braucht, für den ist WordPress perfekt geeignet. Wer wirklich die Funktionen eines CMS braucht, wird nicht drumrum kommen auch ein vollwertiges CMS einzusetzen.

TYPO3 Fluid > POST-Parameter in Paginate-ViewHelper übernehmen

Manchmal benötigt man für eine Pagination zusätzliche Übergabeparameter. Zum Beispiel, wenn man für eine Listenansicht zuvor ausgewählte Filter, Sortierungen oder sonstige Parameter verwendet. Mit Hilfe des Standard-ViewHelpers Paginate von TYPO3, lässt sich das kinderleicht umsetzen:

View Code HTML5
<f:widget.paginate objects="{myObjects}" as="paginatedObjects" configuration="{itemsPerPage: 5, addQueryStringMethod: 'POST,GET'}">
...
</f:widget.paginate>

Wie man sieht, braucht man dem Konfigurations-Attribut lediglich den Wert „POST,GET“ für addQueryStringMethod hinzuzufügen, damit Fluid alle vorhandenen Parameter aus POST und GET an die Seitenlinks anhängt.

Im Übrigens lässt sich das auch bei eigenen Widgets anwenden. Dafür gibt man das addQueryStringMethod-Attribut an den Link-Widget-ViewHelper:

View Code HTML5
<f:widget.link arguments="{page: 1}" addQueryStringMethod="POST,GET">Seite 1</f:widget.link>

JavaScript OOP für PHP-Entwickler

Für PHP-Entwickler ist es relativ schwer sich an die OOP von JavaScript zu gewöhnen. Das liegt daran, dass JavaScript-Klassen Prototype-basiert sind und die Klassen daher anders definiert werden als man es aus PHP, Java oder C# kennt. Um die Umstellung von PHP/Java/C# etwas leichter zu gestalten, habe ich mal ein JavaScript-PHP-Equivalent von zwei einfachen Klassen geschrieben, die exakt das gleiche tun.

Normale Klasse

Fangen wir mal an mit einer einfachen Person-Klasse, die nur einen Namen und die Anrede kennt und die Person ansprechen bzw. verabschieden kann.

Die Klasse in PHP:

View Code PHP
<?php
class Person
{
	protected $name;
	protected $gender;
 
	public function __construct($name, $gender)
	{
		$this->name = $name;
		$this->gender = $gender;
		$this->sayHello();
	}
 
	public function sayHello()
	{
		echo "Hallo $this->gender $this->name.";
	}
 
	public function sayGoodbye()
	{
		echo "Bis bald $this->gender $this->name.";
	}
}

Und die gleiche Klasse in JavaScript:

View Code JAVASCRIPT
function Person(name, gender) {
	if(name && gender)
	{
		this.name = name;
		this.gender = gender;
		this.sayHello();
	}
}
 
Person.prototype.sayHello = function() {
	document.write("Hallo "+this.gender+" "+this.name+".");
};
 
Person.prototype.sayGoodbye = function() {
	document.write("Bis bald "+this.gender+" "+this.name+".");
};

Vererbung

Als nächstes eine einfache Vererbung. Es gibt eine zweite Klasse „Scientist“, die alle Eigenschaften und Methoden von Person erbt und sie um jeweils eine Eigenschaft und eine Methode erweitert.

Vererbung in PHP:

View Code PHP
<?php
require_once 'Person.php';
 
class Scientist extends Person
{
	protected $department;
 
	public function __construct($name, $gender, $department)
	{
		$this->department = $department;
		parent::__construct($name, $gender);
	}
 
	public function research()
	{
		echo "$this->name forscht $this->department.";
	}
}

Und die gleiche Vererbung in JavaScript:

View Code JAVASCRIPT
function Scientist(name, gender, department) {
	Person.call(this, name, gender);
	this.department = department;
}
 
Scientist.prototype = new Person();
Scientist.prototype.constructor = Scientist;
Scientist.prototype.research = function() {
	document.write(this.name+" forscht "+this.department+".");
};

Aufruf der Klassen

Kommen wir nun zum leichtesten Teil – dem Aufruf bzw. Verwendung der Klassen. Hier unterscheiden sich JavaScript und PHP fast gar nicht.

PHP:

View Code PHP
$einstein = new Person("Albert Einstein", "Herr");
echo "<br/>";
$einstein->sayGoodbye();
echo "<br/><br/>";
 
$newton = new Scientist("Isaac Newton", "Herr", "Physik");
echo "<br/>";
$newton->research();
echo "<br/>";
$newton->sayGoodbye();

Und in JavaScript:

View Code JAVASCRIPT
var einstein = new Person("Albert Einstein", "Herr");
document.write("<br/>");
einstein.sayGoodbye();
document.write("<br/><br/>");
 
var newton = new Scientist("Isaac Newton", "Herr", "Physik");
document.write("<br/>");
newton.research();
document.write("<br/>");
newton.sayGoodbye();

Die Ausgabe ist für beide identisch:

Hallo Herr Albert Einstein.
Bis bald Herr Albert Einstein.

Hallo Herr Isaac Newton.
Isaac Newton forscht Physik.
Bis bald Herr Isaac Newton.

Ich hoffe ich konnte euch damit die Unterschiede der beiden Sprachen klar machen. Wer möchte kann sich die Beispiele auch als ZIP-Archiv herunterladen.