Ist das Theme Thesis ein Risiko für seine Anwender?
19. Juli 2010
Thesis, ein Theme für WordPress, sorgt für heiße Köpfe in diesem auch sonst nicht gerade kühlen Sommer: Matt Mullenweg vertritt die Meinung, dass Thesis die Lizenzbedingungen von WordPress verletzt und korrekterweise unter der GPL lizenziert werden müsste, Chris Pearson hält dagegen. Dass Matt Mullenweg recht hat, steht für mich außer Frage, seit dem Kopien von WordPress-Code in Thesis nachgewiesen wurden.
Was Automattic zu diesem GPL-Kreuzzug treibt, ist mir nicht ganz klar – aber ich vermute handfeste kommerzielle Gründe dafür, etwa die kostengünstige Versorgung von WordPress.com mit einer breiten Auswahl hochwertiger Themes und Plugins.
Aber was von dieser esoterischen Debatte um Softwarelizenzen interessiert eigentlich den gewöhnlichen User? Ist die Lizenz nicht egal, solange das Theme funktioniert und auch nicht mehr kostet als GPL-lizenzierte Premium-Themes?
Ich meine: Nein, es ist nicht egal. Jeder einzelne User hat direkte Nachteile, wenn er/sie #thesiswp etwa an Stelle der GPL-lizenzierten Premium-Themes von WooThemes einsetzt.
Zum Beispiel:
Thesis schränkt die Gestaltungsfreiheit ein: Ein Footer-Backlink ist Pflicht. Nur die Entwicklerversion zum beinahe doppelten Preis hebt einige der Einschränkungen wieder auf.
Thesis ist ein Sicherheitsrisiko: So sagt Mark Jaquith, einer der Hauptentwickler von WordPress:
I’m saying that Thesis is highly insecure, per my own direct (and authoritative) observations and tests.
Durch die restriktive Lizenzierung werden existierende Sicherheitslücken in Thesis später oder gar nicht geschlossen, weil aussenstehende Programmierer wie etwa Mark Jaquith nicht mit ihrer Arbeit Theme-Anbieter unterstützen wollen, die sich aus ihrer Sicht gegen die Rechte der User stellen.
Dass Mark Jaquith mit diesen angedeuteten Sicherheitslücken in Thesis natürlich nicht gerade zur Beruhigung der Fronten zwischen Automattic und DIYThemes beigetragen hat, zeigt, wie emotional und dogmatisch die Durchsetzung der GPL von Matt Mullenweg und seinen Mitarbeitern betrieben wird.
Als Seiteneffekt hat Mark Jaquith mit einer einzigen kleinen Nebenbemerkung aber zigtausende Websites in Gefahr gebracht. Da kann WordPress seit der unglücklichen Version 2.8 noch so viel Aufwand in die Beseitigung von Sicherheitslücken stecken – ein einziger Fehler in einem populären Theme kann ein Scheunentor für Angreifer öffnen, und die Erfahrung mit den diversen WordPress-Hacks der letzten Jahre zeigt, dass sich die pöhsen Buben solche Möglichkeiten nicht entgehen lassen.
Thesis-Anwender erwartet ein heißer Herbst.
Kommentare [9]
Multi-Sites in WordPress 3.0: Wie viele laufen auf einem Server?
12. Mai 2010
Das früher separat entwickelte WordPress MU wandert als neues Multi-Site-Feature in WordPress 3.0 und kann dort mit einer einzigen Zeile in der Datei wp-config.php eingeschaltet werden:
define ('WP_ALLOW_MULTISITE', true);
Mit einer einzigen Installation von WordPress können auf dem Webserver somit theoretisch unbegrenzt viele Blogs betrieben werden.
Theoretisch, wie gesagt. In des Praxis wird vor allem die Kapazität des Datenbankservers eine erste Grenze setzen, ab der die Geschwindigkeit einbricht. Zur Verteilung dieser Last auf mehrere MySQL-Server verwendet WordPress.com die Datenbankklasse HyperDB. HyperDB ist als Open-Source-Projekt frei verfügbar.
Von Andy Skelton kommen ein paar grobe Richtwerte, wie er die Auslegung der Server bei WordPress.com handhabt:
Wir haben 100 Millionen Blogs auf hundert Master-Server verteilt, von denen jeder tausend Datenbanken hält. Demnach sind tausend Blogs in einer Datenbank.
Ist das Problem mit dem Flaschenhals Datenbank aus der Welt, steht die Rechenleistung des Webservers als nächstes Hindernis vor dem eigenen Blogimperium. Richtwerte dazu sind erst dann seriös ermittelbar, wenn die verwendeten Plugins und Themes, Caching und die Methoden zur Trennung zwischen statischen Inhalten (Stylesheets, Mediendateien) und dynamischen Scripts festgelegt sind.
Kommentare [5]
WordPress 3.0 in einer schwierigen Entwicklungsphase
16. April 2010
Die sehr ambitionierten Entwicklungsziele für WordPress 3.0 werfen größere Schwierigkeiten für die Entwickler auf als in der ursprünglichen Projektplanung angenommen wurde. Ein Veröffentlichung von WordPress 3.0 am 1. Mai, wie ursprünglich vorgesehen, wäre nach dem letzten Entwicklerchat bestenfalls nur mit Abstrichen bei den gewohnten Funktionen möglich.
WordPress 3.0 ist als großer Schritt geplant – mit den custom post types, der Integration des Codes von WordPress µ als Multisite-Funktion und der Navigation aus den Woo Themes für die im Core integrierte Menüverwaltung sind drei arbeitsintensive und damit bug-trächtige Brocken neu dazu gekommen.
Die derzeitige Implementierung der Menüfunktionen leidet zudem an einem nur noch als extrem zu bezeichnenden Leistungshunger. Theme-Entwickler haben andererseits kaum eine Chance, das neue Menüsystem zu ignorieren, wenn sie ihre User nicht vergraulen wollen.
Jane Wells’ kritische Zusammenfassung des Developer Chats nennt zwei Alternativen: Entweder werden die Menüfunktionen wieder aus dem Core entfernt und erst in die Entwicklung von WordPress 3.1 eingeplant, oder das Erscheinen von WordPress 3.0 verschiebt sich um eine noch nicht genau festlegbare, aber jedenfalls recht beträchtliche zusätzliche Entwicklungsphase. Am 1. Mai wird wegen der Fülle an währed des Beta-Tests aufgetauchten Bugs wahrscheinlich nur der erste release candidate WordPress 3.0 RC1 erscheinen.
Kommentare [7]
Neu in WordPress 2.9: Vorschaubild für Artikel
13. Oktober 2009
WordPress 2.9 kommt wohl im Lauf des Novembers auf die Server der mutigen early adopters und bringt als Anreiz für einen frühen Upgrade einige Änderungen mit, unter anderem integrierte rudimentäre Bildbearbeitungsfunktionen und die Möglichkeit, einem Artikel ein Vorschaubild zuordnen zu können.
“In echt” sieht der Arbeitsablauf bei der Erstellung eines Artikels mit angeflanschtem Bild vulgo “canonical thumbnail” dann etwa so aus:
Der Inhalt des Artikels wird herkömmlich bearbeitet. Über eine neu dazugekommene Metabox lässt sich das Vorschaubild des Artikels definieren, das über die WordPress-Mediathek erreicht werden kann:
Das Vorschaubild ist im einfachsten Fall bereits in der Mediathek vorhanden. Andernfalls zapft man entweder die lokalen Bildvorräte oder das Web für die nötigen Pixel an und lädt sie ad hoc auf den eigenen Webspace:
Als Resultat all dieser Mühen ist am Ende ein Vorschaubild mit dem Artikel verknüpft:
Ein paar Punkte bleiben noch offen, etwa fehlt in der derzeitigen Fassung eine Löschfunktion, um das Vorschaubild auch wieder loszuwerden.
Offen ist für mich persönlich auch die Frage, warum nicht mehrere Bilder als Thumbnail zugeordnet werden können. Die Möglichkeiten, die Themeautoren mit dem Fernstudium einer unlimitierten Galerie von Vorschaubildern offen stünden, wären den zusätzlichen Aufwand für die Verwaltung einer ganzen Galerie von Artikelbildern sicher wert.
Die Knackpunkt ist aber: Damit das Vorschaubild auch auf der Website öffentlich sichtbar wird, muss das jeweilige Theme mitspielen. WordPress 2.9 wird deswegen einige neue Funktionen für Theme-Programmierer enthalten, die auf die Vorschaubilder zugreifen können.
Im Umkehrschluss heißt das aber: Alle derzeitigen Themes können ohne Änderung mit den Thumbnails nichts anfangen.
Kommentare [5]
Neu in WordPress 2.8.5: Sichere Mediathek
30. August 2009
Die Bemühungen der WordPress-Entwickler gehen in letzter Zeit nach einem öffentlichen Rüffel von Matt Mullenweg vermehrt in Richtung “Perfektion der Sicherheit”, und so dichtet WordPress Lücken beinahe im Wochentakt. Als weitere Sicherheitsmaßnahme gegen Cracker, die über einen geknackten Administrationsaccount in eine fremde WordPress-Seite eindringen konnten, beschränkt WordPress ab der kommenden Version 2.8.5 die in der Mediathek erlaubten Dateitypen.
Eingeschränkte Uploads für Administratoren
Bis dato haben ja Administratoren jegliche Freiheiten in der Auswahl der Dateitypen, die sie ins Medienarchiv ihrer Site laden können: Ob JPEG-Bilder, Flashfilme oder OpenOffice-Dokumente – WordPress speichert uneingeschränkt jeden Dateityp auf der Website. “Gewöhnliche” Benutzer ohne Administratorrechte dagegen dürfen weitaus weniger und müssen sich auf eine bestimmte Auswahl gemäß der sogenannten MIME-Type-Whitelist beschränken.
Ab WordPress 2.8.5 gilt diese Whitelist auch für Administratoren, die damit erstmalig mit der Fehlermeldung “Der Dateityp entspricht nicht den Sicherheitsrichtlinien. Bitte einen anderen versuchen.” oder “File type does not meet security guidelines. Try another.” konfrontiert werden können.
Ungefilterte Uploads konfigurieren
Wer trotzdem weiterhin uneingeschränkte Uploads benötigt, kann die Sicherheitsprüfung über eine zusätzliche Zeile in der Datei wp-config.php komplett ausschalten:
define ('ALLOW_UNFILTERED_UPLOADS', true);
Dateitypen für die Mediathek freigeben
Das vollständige Ausschalten der Sicherheitsmaßnahmen ist in vielen Fällen aber ohnehin nicht notwendig: Über das Plugin WordPress mime-config von WordPress-Entwickler Peter Westwood alias “westi” lässt sich die Liste der erlaubten Dateitypen anpassen und erweitern.
(Quelle: WordPress Core Trac, Ticket 10692)
Kommentare [7]
