WordPress, das CMS
21.01.2010 in: Webdesign und Wordpress
Robert Agthe (@polarity) hat darüber gebloggt, warum WordPress »als CMS nicht geeignet« sei. Da hätte ich gerne kommentiert, aber ich entscheide mich nicht gerne zwischen einer Registrierung und dem Zugriff auf mein Twitterkonto. Wer meine E-Mail-Adresse haben will, soll herkommen. Wer in meinem Namen twittern möchte, kann sich die Mühe sparen.
Also schreibe ich hier, wo jeder kommentieren darf, gerne auch anonym. Alle nicht belegten Zitate entstammen Roberts Artikel.
Ich möchte seine Argumente auf- und angreifen, weil ich sie schon zu oft gelesen habe – und weil ich unterstelle, daß er meine Kritik an der Sache gut aushält.
Zunächst zum Begriff: WordPress ist ein CMS, denn man kann Inhalte damit verwalten, Nutzerrechte steuern, Themes und Erweiterungen (Plugins) einsetzen.
Daher finde ich die Frage, ob man WordPress als CMS verwenden könne, so sinnvoll, wie die, was Wasser als Flüssigkeit taugt.
Dann die Argumente gegen WordPress:
Sicherheit
Wie das mit weit verbreiteter offener Software so ist, existieren viele Kenntnisse über die Existenz und Ausnutzbarkeit von Sicherheitslöchern.
Security by obscurity nennt der Sicherheitsexperte das Prinzip, auf wenig verbreitete Software zu setzen, den Nutzernamen geheimzuhalten oder gar vor Open Soucre zu flüchten. Und dabei verzieht er das Gesicht. Das funktioniert nur bei Passwörtern, sonst nicht.
Wer sein WordPress aktuell hält, alle Plugins und Themes vor der Installation einmal gründlich ansieht und auf einem Referenzsystem testet, der wird auch nicht gehackt. Und wer sich das nicht zutraut, der beauftragt eben jemanden damit. Google hilft.
Der WordPress-Code glänzt gewiß nicht mit dem Leitmotiv »Sicherheit«, und er kann und wird verbessert werden. Aber er ist auch nicht per se unsicher. Ganz bestimmt nicht so sehr, daß man einen »kompletten Re-Write des Core-Systems« benötigt. Zumindest nicht als Programmierer.
Zu viel Code
Das heisst man benutzt Software die vollgestopft ist mit Features die nicht umbedingt beim Einsatz als CMS benötigt werden. Diese Features sind aber weiterhin über URLs erreichbar, wobei sie hier unnütz ein Sicherheitsrisiko darstellen.
Wenn ich ein Feature nicht nutze, dann kostet mich das nichts. Die Dateien mögen auf der Festplatte liegen, aber wenn sie nicht verarbeitet werden, stört das niemanden. Speicherplatz ist billig.
Ob ein Feature, das ich nicht brauche, von außen noch benutzt werden kann, liegt ganz allein in meiner Hand. WordPress arbeitet weiter, wenn ich Trackbacks abschalte oder auf Tags pfeife.
Bekannte Sicherheitslücken bestehen im aktuellen WordPress-Code nicht. Wer öffentlichen Zugriff auf unbenötigte Features gestattet, der hat sich so entschieden. Oder er kennt sich mit WordPress gar nicht aus – dann aber muß er sich die Frage nach harten Fakten gefallen lassen.
Und doch will ich das Argument gelten lassen: WordPress bringt viel Code mit, den kaum jemand braucht: Die Importskripte etwa, zwei Themes, eine umfangreiche Bildbearbeitung oder die Post-per-Mail-Funktionalität. Mit den Core-Plugins gehen die Entwickler den richtigen Weg. Das wird Robert sicher ebenso gefallen wie mir.
Zu wenig Code
Spannend, die Kombination beider Vorwürfe habe ich bisher noch nicht erlebt.
Gleichzeitig fehlen Funktionen, die evtl. mit Amateur-Programmierer Plug-ins ausgeglichen werden müssen. In vielen CMSystemen existieren mächtige Tools zum bauen von dynamischen Menus.
Niemand muß ein schlechtes Plugin benutzen. Punkt. Genau deshalb ist es ein Plugin: Ich kann es durch ein anderes ersetzen, und zur Not auch selbst schreiben.
Wer sich an ein paar Grundregeln hält und PHP beherrscht, der schafft das auch.
Die angesprochene Funktionalität für ein »dynamisches Menu« beispielsweise möchte ich auf keinen Fall im Core sehen. Dafür existieren so viele unterschiedliche Techniken, daß niemand die eine auswählen kann. Und viele Websites brauchen das auch gar nicht.
Ich sähe dennoch gerne eine scharfe Qualitätskontrolle im Pluginverzeichnis. Die schlechten Plugins erschweren nämlich das Finden der guten.
Performance
Wordpress ist kein Performance Wunder. Objektorientierten Code sucht man im Quelltext vergebens und selbst eine neu und leere Installation strotzt nicht vor Geschwindigkeit. Installiert man noch mehrere Plugins und hat viele Seitenzugriffe kann der Seitenaufbau schon mal etwas langsamer werden. In der aktuellen Version benötigt Wordpress nach der Installation bei jedem Aufruf der Startseite "21 Datenbank Abfragen"!!
Hier fliegt so viel durcheinander … ich brauche eine Liste:
- WordPress besteht überwiegend aus Klassen und Objekten. Datenbankzugriff, Feedreader, ZIP, E-Mail, Widgets, Bildbearbeitung, Import und Export, FTP, HTTP, SSH, Arbeiten am Dateisystem, Upgrades, der Object-Cache, Nutzerverwaltung, Fehlerbehandlung, Übersetzung – alles in Klassen. Für viele dieser Objekte existieren prozedurale Schnittstellen, die Rückwärtskompatibilität gewährleisten und die Arbeit in den Themes erleichtern sollen. Die kann man benutzen. Man muß nicht.
- OOP ist ein Werkzeug, kein Ziel. Wer auch dann Klassen und Objekte verwendet, wenn er sie nicht braucht, wird ganz einfach schlechten und langsamen Code schreiben.
- Prozeduraler Code wird nicht langsamer verarbeitet. Meistens passiert genau das Gegenteil. Im Detail sitzt der Flaschenhals oft woanders, und nicht immer steht die Performance an der ersten Stelle einer strategischen Entscheidung für oder gegen OOP.
- Wie schnell WordPress läuft, das hängt auch von dem ab, der es installiert und verwaltet. Je nach dem zugrundeliegenden System kann ein Flatfile-Cache hinzugezogen werden, ein Query-Cache, beides oder nichts. WordPress bietet hierfür nur die Schnittstellen an, die Ausführung liegt bei jedem selbst. Und so soll es auch sein.
Mich beeindruckt beispielsweise Jens Grochtdreis’ Blog. Pfeilschnell!
Ich verwende hier nur einen Query-Cache; in anderen Blogs, die seltener aktualisiert werden, bevorzuge ich Flatfile-Caches. - Für Plugins gilt immer noch: Erst den Code ansehen, testen, dann installieren – oder eben nicht. Wer diese Schritte überspringt und sich über Performance-Probleme wundert, weiß gleich, wem er die Schuld zuschieben darf. Dazu muß er nicht einmal aufstehen.
- Die Zahl der Datenbankabfragen sagt wenig über die Performance aus, die Dauer schon mehr. Und wer sich daran stört, kann das Problem mit einem passenden Caching-System leicht aus der Welt schaffen.
Zu viel Volumen
Wordpress ist in der aktuellen Version rund 10MB groß (fast nur Quellcode).
Ja … und? Speicherplatz kostet wenig, Arbeitszeit aber viel. Dieses Argument stammt aus dem Zeitalter der Floppy-Disk, und dort sollten wir es auch lassen. Ob eine Software nun 10 MB oder 100 MB braucht, spielt keine Rolle. Ob sie ihren Job erledigt, das zählt.
All die hier zitierten Argumente sprechen auch »gegen« fast jedes andere bekannte System: TypoLight, MODx, Drupal, Joomla! oder Zikula. Genauer gesagt: Sie gingen dort ebenso am Kern vorbei.
Genug der Kritik, ich finde sicher auch eine eigene Perspektive.
Wann WordPress nicht paßt …
Wofür eignet sich WordPress wirklich nicht?
- Kleine Websites. Wer nur zehn Einzelseiten braucht und diese auch noch selten aktualisiert, der muß die Software zwar immer noch aktuell halten, zieht aber kaum Gewinn daraus. Das Labor beispielsweise betreibe ich mit einem rudimentären Template-System, mehr brauche ich da nicht.
- Sehr große Websites. Zwar kann man die auch mit WordPress betreiben, aber wenn man ein Templatesystem möchte, dessen Bearbeiter kein PHP verstehen (oder anwenden sollen), dann paßt WordPress nicht. Auch spielt WordPress noch nicht mit jeder Datenbank problemlos mit. Immerhin existieren schon »Referenzplugins« für SQLite und PostgreSQL.
- Ein Intranet. Ich weiß zwar, daß andere das schon gemacht haben, aber ich denke, daß es Systeme gibt, die hierfür besser geeignet sind. Das Synchronisieren unterschiedlicher E-Mail-Programme und Terminkalender, eine gestaffelte Sichtbarkeit nach innen und außen – alles möglich, aber dafür wurde WordPress einfach nicht geschrieben, und das Umsetzen nähme viel Zeit in Anspruch. Und Zeit ist, ja immer noch, teuer.
- Spezialaufgaben. Wer ein Wiki braucht, einen umfangreichen Shop, eine Bildergalerie oder nur ein Gästebuch, der kann WordPress benutzen, sollte aber nicht. Die Spezialisten erledigen solche Aufgaben meistens schneller, und sie verlangen weniger Vorarbeit dafür.
… und wann doch
Wann entscheide ich mich für WordPress – und warum?
Dies Frage hat Alex Denning anderen und mir neulich gestellt, und aus den Antworten kann der Leser schön die vielen Zugänge sehen. Für mich wiegen drei Punkte besonders schwer:
- Das enorm benutzerfreundliche Backend. Ich kann jemanden davor setzen, der sich sonst nur auf Word versteht, und er wird zurechtkommen. Wer nur schreiben soll, dem kann ich alles aus dem Weg nehmen, was ihn stört. Und dazu muß ich nicht einmal Code anfassen.
- Die mächtige API. Ich kann für fast jede Aufgabe ein Plugin schreiben oder die Funktionalität in die
functions.phpsetzen. Wenn ich die Kriterien lese, entsteht der Code schon vor meinem inneren Auge. Die exzellente Dokumentation und die hilfreiche Community rundherum ebnen der Weg noch mehr. - WordPress verzichtet auf eine separate Templatesprache. Wie schon geschrieben: Darin kann man ein Manko sehen. Die Websites, die ich als Einzelkämpfer erstelle, profitieren davon, denn sie laufen schnell, und ich muß zu PHP keine zweite Sprache lernen. PHP ist schon eine Templatesprache.
Ich entscheide mich für WordPress – oder ich schlage es vor – wenn ich eine Nutzerverwaltung brauche, ein verständliches Backend, Funktionalität, die mit guten WordPress-Plugins vorliegt, und wenn keines der oben genannten Ausschlußkriterien zutrifft. Oh, und wenn ich ein Blog brauche.
Dann benutze ich WordPress, das CMS, als CMS.
Newsfeed
Bei Punkt 2 und 3 der Pro-Argumente stimme ich dir zu. Genau das sind aus meiner Sicht die Stärken von Wordpress. Bei Punkt 1 muss ich widersprechen. Man kommt mit dem Backend zurecht, aber benutzerfreundlich ist was anderes. Ich finde es ziemlich langsam und ohne JavaScript ist es so gut wie nicht zu gebrauchen, was sich vor allem auf einem mobilen Gerät bemerkbar macht. Und obwohl TinyMCE ziemlich soliden HTML Code generiert kommt es dennoch zu manchen Merkwürdigkeiten, die man ohne HTML-Kentnis nicht beheben kann.
Thomas, Du schreibst mir aus dem Herzen. Unterschreibe ich alles, wobei ich zum Thema Sicherheit erst durch Dich zu der differenzierteren Bewertung kam. Hier noch einmal Danke dafür!
Zwar erfüllt WordPress auch ohne Plugins schon die von Dir geschriebene Definition eines CMS, gleichwohl kann man es nicht nur als Blogsoftware, sondern mit Hilfe von Plugins und den "statischen" Seiten wie ein "klassisches" CMS einsetzen. Auf Webseiten-Infos.de habe ich das so incl. Blog realisiert (ok die "statischen" Seiten könnten langsam mal mit mehr Inhalt gefüllt werden).
Ja Du hast jetzt natürlich versucht meine Argumente gegen Wordpress zu entkräften. Ich könnte jetzt jeden Deiner Argumente wiederum entkräften, würde mich aber unnütz Zeit kosten. Deshalb versuch ich es Allgemeiner.
Wenn man Dinge für etwas einsetzt für was sie nicht geschaffen hat, geht man Kompromisse ein. Und das, so wollte ich ausdrücken, ist unnötig. Es gibt ein haufen Software die speziell auf Anwender zugeschnitten ist. Wenn ich wollte könnte ich sogar aus Wordpress einen Shop machen, ein Podcast System, ein Forum usw usw.
Ich lese raus, das du dich einfach gut mit Wordpress auskennst und es deshalb einsetzt. Man sollte sowas aber trotzdem überdenken und nicht etwas machen, nur weil man es kann.
Unnötig Arbeit / Geld
Trotzdem Unnötig.
Kunden machen gern selber. Und viele haben keine Ahnung was sie da installieren. Ob das Plugin System Performant ist, mag ich auch bezweifeln. Stichwort DB abfragen.
Unnötig und Klassen zu verwenden heisst nicht Objektorientiert zu Programmieren. Das ist keine Garantie für intelligenten Code, aber sollte verpflichten.
Performance == Dauer. Jede DB Query kostet Zeit und Memory. Wenn mal 1000 User gleichzeit drauf sind, geht die Performance schnell in den Keller. Unnötig ein Cache System einzusetzen, wenn der Hund woanders begraben ist.
Soviel wie nötig, so wenig wie möglich. ;) Je weniger Code desto besser. Für alles.
@David: Vielleicht hätte »leicht verständlich« besser gepaßt. Ich lasse das jetzt aber so stehen, damit dein Kommentar weiterhin gilt. Mit dem Tempo habe ich selten Probleme. Das hängt vielleicht auch von der Serverkonfiguration ab. An der Zugänglichkeit wird gearbeitet – endlich. Vielleicht hast du ja Lust, dort mitzuhelfen?
@Robert Agthe:
Ich kann mit WordPress Geld verdienen, deshalb informiere ich mich stetig darüber. Und ich setze es nicht nur ein, weil ich es kann. Das wollte ich hier eigentlich verdeutlichen …
Das Prüfen und Testen der Updates fällt bei jedem System mit einiger Komplexität an. Es ist nie unnötig.
Dann wurden sie aber vorher hoffentlich über die Risiken aufgeklärt. Wenn sie dann doch Probleme einbauen, liegt das nicht an WordPress. Auch hier gilt: Das passiert bei jedem System. Meine Kunden verwenden normalerweise kein Administratorkonto.
Aber unterschiedlich viel. Die Logik zum Ermitteln des Flatfile-Caches kann unter Umständen länger dauern als das Abholen eines gecachten Querys. Welche Lösung für dein System am besten paßt, kann und darf WordPress nicht vorschreiben. Und auch dieser Punkt gilt nicht spezifisch für ein System.
Meiner Meinung nach habt Ihr beide Recht, bis auf feine Ausnahmen auf Beiden Seiten.
Bei Dir ist's das Menü, wo Du auf keinen Fall eine vernünftige Lösung im Core haben möchtest. Mir ist nicht ein CMS bekannt, was wie Wordpress einfach den kompletten Strukturbaum rausrotzt.
Eine benutzbare Lösung, Menüpunkte zu sortieren, oder Kinder nur bei aktiven Parents anzeigen zu lassen, sind m.M.n. ein absolutes Muss für einen CMS-Core.
Steht bei Wordpress auf der Roadmap wahrscheinlich weit hinter Video bearbeiten ;)
Schöne Liste, die wie immer zur Diskussion anregt und notwendig ist. Auch um bestimmte Themen immer wieder hoch zu halten und so auch indirekt Einfluss auf die Entwicklung zu nehmen. Meiner Meinung nach ist bei WordPress viel passiert und die Aussichten auf 3.0 stimmen mich positiv. Meiner Meinung nach ist die Wahl eines CMS immer ein Kompromiss, sofern man nicht eine Eigenentwicklung hat und wer vielleicht in einer solchen involviert war/ist wird merken, auch da werden Kompromisse gemacht. Ständig.
Grösstes Problem ist die Performance-Frage die sich auf Front- und Backend auswirken und damit auch das grösste Hinterniss in der Benutzerfreundlichkeit darstellen. Der Adminbereich ist meiner Meinung nach sehr aufgeräumt und Kunden kommen sich schnell zurecht, vor allem wenn man das was nicht benötigt wird dem Kunden vorenthält. So kriegt i.d.R. kein Kunde Zugang zu diversen Admin-Funktionen. Zu 99% gilt: Bilder/Dokumente hochladen & Texte pflegen und das klappt mit WP ziemlich gut & einfach.
Thomas, ich stimme Dir zu unf finde es gut, dass Du Dich so ausführlich zur konkreten Kritik an WP und im Allgemeinen geäußert hast. Würde ich auch unterschreiben.
Wordpress ist zunächst mal nicht grundsätzlich böse. Ich selbst nutze es seit über 5 Jahren und konnte die meisten immer wieder geäußerten Kritikpunkte für mich selbst noch nicht nachvollziehen bzw. erfahren. Ausgenommen die Backend-Performance, die schon mal nerven kann.
Zum Thema Sicherheit allgemein: Hier ist es wie in anderen Bereichen auch. Man muss erst mal so attraktiv für Hacker werden ;-) WP hat in De etwa 75% Anteil. So gesehen, möchte auch kaum einer die anderen Systeme hacken.
Zum Thema Javascript und Backend. In vielen CMS wird man ohne aktiviertes JS im Backend nicht weit kommen. Man kann das auch als Systemvoraussetzung betrachten. Ich kann mich auch nicht beschweren, dass eine Software nicht auf meinem Alt-PC mit 256 MB RAM läuft. Wir Webdesigner haben die Aufgabe, das Frontend bzw. die Website auch ohne JS nutzbar zu machen.
Noch allgemeiner: Es sollte jeder zunächst mal konkret seine Anforderungen an ein CMS dokumentieren und damit beginnen, verschiedene System zu evaluieren. Und nach einem mehr oder weniger umfangreichen Bewertungs- und Auswahlprozess, landet man dann womöglich bei WP - oder eben auch nicht. Und somit kann natürlich die oft zitierte Backend-Performance zum ausschlaggebenden Punkt gegen WP werden. Je nach Anforderungen aus dem Redaktionsbereich.
Noch was. Die Diskussion, ob WP ein CMS ist, oder nicht, finde ich genauso müßig wie z.B. JAVA vs. PHP bzw. Erwachesenen-Programmiersprache vs. Kinderprogrammiersprache :-)
@Björn: David hat mit dem Hinweis auf die Zugänglichkeit ohne Javascript ein wesentliches Problem angesprochen: Wenn das Backend die BITV-Kriterien erfüllen muß, kann ich WordPress kaum einsetzen. Mit sehr viel Aufwand oder einem selbst geschriebenen Backend ließe sich das hinbiegen, aber ich möchte so eine Arbeit nicht machen.
Aus dem Stegreif fällt mir aber keine Alternative ein. Blöd.
@Thomas Scholz: Da bin ich voll dabei. Wie gesagt, ist das eine Anforderung unter vielen. Und wenn diese zu erfüllen ist, dann scheidet WP natürlich zunächst mal aus.
Wenn man der Logik folgt, daß ein Blog aktuelle Informationen liefert,
könnte es ein Problem sein, dauerhaft mit dem "WP-CMS" gut gelistet zu sein. Da Google WP als Blog erkennt, soll solch ein Mechanismus greifen.
@mike:
Hier sind wir an dem Punkt, den ich aus Robert Aghtes Artikel herauslese: Wordpress ist für große Websites in denen viele Seiten in mehreren Ebenen organisiert sind, ungeeignet. Man sollte nicht krampfhaft auf jede Aufgabe Wordpress anwenden, nur weil man es gut „kann“, auch da gebe ich ihm recht. Wo die Seitenstruktur flach und überschaubar bleibt, ist die komplette Darstellung des Menüs sogar von Vorteil, da man sich nicht erst bist zur gewünschten Seite durchklicken muss sondern direkt zum Ziel gelangt.
Da hast du, Thomas, ja eine schöne Diskussion angestoßen. Björns Beitrag trifft es meiner Meinung nach sehr gut: Erst nachdem einem die Anforderungen bewusst sind, kann man sich für das passende CMS entscheiden und muss davor wohl unweigerlich etwas ausprobieren.
WordPress als CMS einzusetzen sehe ich grundlegend nicht als Problem. Ich kenne viele Webseiten - auch mit größerem Umfang - die gut mit WordPress laufen. Zudem finde ich es selbst doch sehr einfach damit zu arbeiten. Bevor ich eine undurchsichtige Sprache für die Template-Erstellung erlerne, verbringe ich doch lieber ein paar Stunden mehr in der Einrichtung von WordPress. Meines Erachtens nach ist ein wichtiger Pluspunkt die gute Dokumentation (engl.)! In vielen Fällen reicht ein Blick in den WP-Codex und man wird fündig.
@David: Ich finde ja man hat durchaus viele Einstellungsmöglichkeiten: wp_list_catgories.
@Markus Thies: Auch Stunden später verstehe ich nicht so recht, worauf du hinauswillst. ☺ Magst du das nochmal anders ausdrücken?
@Fabian: David meint vermutlich wp_list_pages(). Hier braucht man wirklich ein oder zwei Tricks, wenn man nur einen Teil des Baums ausklappen will und die IDs der Seiten nicht kennt. Ich überspringe in solchen Fällen gerne die prozedurale Schicht und greife die benötigten Informationen direkt über das DB-Objekt ab.
Wer nur schnell so etwas zurechtfrickeln möchte, mag das sicher nicht – aber der wird sich an einem »großen« System erst recht die Zähne ausbeißen.
@Thomas Scholz @Thomas Scholz: Es gibt Diskussionen darüber, daß Google zwar Blogbeiträge sehr schnell gut rankt, aber auch schnell wieder zurückstuft.
Das macht auch Sinn: ein Blogbeitrag ist i.d.R. eine aktuelle Meinungsäußerung, die jetzt "wichtig" sein kann, morgen aber nicht mehr so sehr.
Wenn man WP als CMS für dauerhafte Artikel nutzt, kann dies möglicher Weise ein Nachteil sein. Wenn Google Deine ausgefeilten Artikel "für die Ewigkeit" nur als Blogbeitrag gewichtet. Dann vermutet Google morgen, daß der Artikel nicht mehr aktuell ist. Da WP im Header steht, kann man die Suchmaschinen Vielleicht nicht vom Gegenteil überzeugen.
Soweit mir allerdings bekannt, ist dies nur eine Vermutung und nicht gesichert.
@Markus Thies: Ah, jetzt verstehe ich es. Darin sehe ich kein Problem: Man kann sehr zeitgebundene und langfristig »gültige« Texte ja sauber auseinanderhalten, indem man Posts und Pages benutzt. Inzwischen kann jeder auch eigene Typen anlegen, die sich in den beiden Formen vielleicht nicht ausdrücken lassen.
Rein von den Rankingdaten her habe ich den von dir angesprochenen Unterschied noch nicht feststellen können. Was gut verlinkt ist, das steht weiter vorne.
Am Beispiel dieser Website ist mir der prominente Platz der Artikel nicht mal so angenehm: In den Sitelinks für meine Seite steht ein Artikel derzeit an erster Stelle, der so viel Aufmerksamkeit nicht verdient. Erst dann kommen die Links auf die Angebote und die Seite »Über mich«. Der erste Treffer unterhalb ist auch ein Artikel:
Ich sehe also diesen Effekt nicht. Falls es ihn doch gibt (in meinem Header steht nirgendwo »WordPress«), so dürfte er gerade bei diesem CMS am schwächsten ausfallen, denn viele Leute benutzen es ja nicht nur als Blog.
Zwei Dinge, die mir aufstoßen.
1.) WordPress IST ein CMS! Wie soll man WP dann nicht als CMS nutzen können? Was ist denn die Verwaltung von Posts, Pages, Medien, Kategorien etc. sonst als die Verwaltung von Content, also Content Management? Die Frage ist nur, inwieweit man WP anpassen muss, um die eigen gesetzten Bedingungen zu erfüllen. Nur weil WP z.B. keinen integrierten Generator für Menüs hat (was übrigens mit 3.0 kommen soll), heißt das nicht, dass es kein CMS ist.
2.) Wordpress schreibt man WordPress. :-)
Ich versteh die Diskussion überhaupt nicht. Jedes System hat wohl seine Vor-und Nachteile. Ich setze WordPress zu 80% als CMS für Kunden ein. In erster Linie wegen der Benutzerfreundlichkeit. Warum soll ich einem Kunden ein Werkzeug wie z.b. Joomla an die Hand geben, bei dem ich eine mehrtägige Einarbeitungszeit beim Kunden einkalkulieren muss. In der Regel sind die Endkunden nunmal keine Programmierer und haben weder etwas mit HTML-CSS oder PHP zu tun. Wer schon einmal mit einschlägigen CMS gearbeitet hat, weis was ich meine.
Für mich ist und bleibt WP, auch als CMS, die Nr.1.
Zu der Diskussion auch noch mal mein Senf dazu (und das ganze in diesem Blog, weil ich das mit meinen Twitter-Zugangsdaten ebenso kritisch sehe - demnächst will noch jemand meine Kreditkartennummer, wenn ich was kommentieren will...).
WordPress ist, wie Oliver Schlöbe es schon geschrieben hat, ein CMS. Über eine Datenbank wird Content im Frontend mittels Template präsentiert. Dieser Content wurde zuvor im Backend erfasst und kann auch dort verwaltet werden.
Die Kritik an der Schreibweise von WordPress trifft es auch auf den Punkt. Es ist nur eine Kleinigkeit, aber ... nun gut, kommen wird zur grundsätzlichen Frage.
Welches CMS man verwendet, hängt im Wesentlichen davon ab, womit man selber und der Kunde als Anwender am besten zurecht kommt. Bei größeren Projekten ist zudem der entscheidende Faktor, mit welchem zeitlichen Aufwand man bei der Projektumsetzung rechnen muss und ob sich die notwendigen Arbeitsschritte auch auf mehrere Personen verteilen lassen.
Bei uns in der Agentur ist Typo3 in den meisten Fällen das CMS unserer Wahl. Warum Typo3 "nicht empfehleneswert" sein soll, kann ich für meinen Teil nicht nachvollziehen - genauso wenig wie die Kritik an WordPress von Robert Agthe.
WordPress setzen wir zwar nicht so oft wie Typo3 ein, aber dennoch bietet sich bei bestimmten Projekten (nicht nur Blogs!) geradezu an - wie bereits gesagt, der Kunde als Anwender ist nicht unwichtig.
Joomla ernsthaft für größere Projekte zu empfehlen, führt bei mir zu Kopfschütteln. Entweder nutzt man PHP als Template-Engine (wie bei WordPress) oder man abstrahiert die Templates (wie bei zum Beispiel bei Typo3). PHP, HTML und eigene Marker wild zu mischen, dürfte wohl kaum performant sein.
SEO: Ein CMS ist nur die technische Grundlage. Entscheiden ist das, was man inhaltlich daraus macht. Selbst das beste CMS nutzt nix, wenn der Kunde damit seine Visitenkarte ins Netz stellt.
@tboley: So ist es bzgl. SEO.
Justin Tadlock hat das treffend zusammen gefasst: http://justintadlock.com/archives/2009/03/28/rule-1-the-guide-to-wordpress-seo
@tboley:
ich wollte gerade was ganz schlaues schreiben, aber da ist mir tboley zuvor gekommen.
Das WordPress ein CMS ist, sind wir uns einig. Weil CMS = Content Management System = Redaktionssystem. Und WP ist nun mal ein Redaktionssystem ("Verwalter von Inhalten").
Man mag dies als Korinthenkackerei bezeichnen, aber es vor allem für Einsteiger wichtig, wenn wir die Dinge beim richtigen Namen nennen.
Die Frage bleibt ob man WordPress als "klassisches" CMS einsetzen kann? Ich bin der Meinung das man es auf jeden Fall einsetzen kann. Gewiss, WP hat da ein paar Nachteile, aber ich bin gespannt ob mir jemand ein CMS nennen kann, welches keinen einzigen Nachteil hat.
Ich hatte schon mit Redaktionssystemen gearbeitet, die 50.000+ Euro gekostet haben und auch diese hatten die eine oder andere Macke und mussten an mehreren Stellen für den Kunden angepasst werden.
Grüße
Also ich sehe WordPress auch als CMS und nutze es auch oft so? Warum? Weil ich damit gut zurecht komme und ich weiss was ich machen muss. Es gibt viel Hilfe im Netz wenn es doch mal wo klemmt und die Leute die es dann letztendlich nutzen müssen kommen auch ganz gut damit zurecht. Aber die Diskussion gibt es ja auch im Grunde ständig wieder.