Für eine E-Commerce-Site wäre besonders wichtig, dass der bestehenden URLs weiterhin gültig sind und eingehende Links nicht im 404-Nirwana enden. Die negativen Auswirkungen auf den Umsatz wären gewiss. Nicht so bei einem Amt wie dem BSI. Da hat man sich die Sache daher leicht gemacht.

Wer über eingehende Links auf die Site kommt, egal ob von einer Suchmaschine oder von anderswo, wird mit der Nachricht begrüßt, dass keine der bisherigen URLs mehr gültig ist. Wenn schon eine systematische Umleitung nicht möglich war, dann könnte man etwa das alte CMS noch irgendwo weiterlaufen lassen, den Titel der angefragten Seite ermitteln und an die Suchmaschine der neuen Site weitergeben – vorausgesetzt, die Suche wäre einigermaßen schnell und präzise.

Der Lösung des BSI besteht darin, Kurz-URLs für den Schnelleinstieg zu bieten. Die Liste enthält aber keine URLs, sondern Begriffe, die wohl als Links gedacht waren, aber keine sind. Somit ist auch diese Umstiegshilfe für den Besucher der Site wertlos.

Während man lange Zeit beim URL-Schema akzeptieren musste, was das CMS vorgab, bieten viele moderne Systeme die Möglichkeit, das Aussehen der URLs fast beliebig zu gestalten. In ihnen spiegelt sich in der Regel keine physikalische Verzeichnisstruktur mehr wider, sondern eine eigenständige Logik. Unter den Bedingungen des Web 2.0 ist es allerdings gar nicht so einfach, eine konsistente und plausible Systematik zu entwickeln. In einem Projekt auf Basis von Drupal, an dem ich seit einiger Zeit arbeite, war das URL-Schema für mich ein wesentlicher Aspekt beim Entwurf der Site-Struktur. Hier ein paar Entscheidungen, die ich dabei zu treffen hatte:

• Wenn man Texte nicht starr einer Kategorie zuordnen, sondern mit Hilfe von mehreren Begriffen beschreiben möchte (Tagging), dann passt eine Struktur vom Typ http:meine-site.de/Installationspfad des CMS/Kategorie/dateiname.html nicht mehr (z.B. http://website.de/cms/sport/em-spielplan.html). Vorausgesetzt, das Tagging ist wie im Fall des Taxonomiemoduls von Drupal tief genug im System verankert, so kann man diese Metadaten an vielen Stellen des Systems nutzen, unter anderem auch bei der Komposition von URLs. Dann ließe sich jedes Schlagwort beispielsweise über ein eigenes Verzeichnis darstellen, also http://meine-site.de/tag1-tag2-tagX (also zum Beispiel http://meine-site.de/soziale-netze/facebook/opensource/dateiname.html). Da Tags im Gegensatz zu Verzeichnispfaden nicht hierarchisch organisiert sind, lassen sie sich nicht plausibel auf eine solche URL abbilden. Besser eignet sich dafür das Muster http://meine-site.de/tag1-tag2-tagX/dateiname.html, aber auch dieses hat unter Umständen unerwünschte Nebenwirkungen.
• Die Verzeichnispfade in einer URL spielen eine wichtige Rolle, wenn man in einem Tool zur Web-Analyse die Statistik für bestimmte Kategorien ermitteln möchte, weil die Segmentierung nach Kategorien in der Regel über URLs erfolgt. Wenn Verzeichnisse aus aneinander gereihten Tags besteht, dann können diese sehr stark variieren. Selbst jene Texte, die mit den gleichen Schlagwörtern versehen wurden, finden sich dann in unterschiedlichen Verzeichnissen, wenn die Tags nicht immer in der gleichen Reihenfolge vergeben werden. Deshalb ist es hilfreich, wenn das CMS über die Bedieneroberfläche die Auswahl schon vergebener Tags unterstützt und dabei die Einhaltung des gleichen Abfolge von Schlagwörtern gewährleistet (wie das Modul Suggested Terms in Drupal).
• Neuere Web-Projekte begnügen sich häufig nicht mehr mit herkömmlichen CMS-Publizieren, sondern umfassen neben Artikeln oder News auch Weblogs, Foren oder selbst definierte Content-Typen. Es bietet sich an, den Namen des Content-Typen in die URL aufzunehmen, wenn das CMS wie im Fall von Drupal dies zulässt. Es stellt sich jedoch die Frage, welchen Nutzen das bringt. Für den Besucher kann eine solche URL allerdings eine zusätzliche Orientierung bieten, wenn er beispielsweise aus ihr ersehen kann, dass es nicht mehr mit einem “offiziellen” redaktionellen Beitrag zu tun hat, sondern mit einem Blog-Posting. Einige größere US-Sites verfahren so, indem sie für Blogs ein eigenes Verzeicnis oder eine Subdomäne einrichten. Der Content-Typ in der URL kann zudem bei der Web-Analyse zusätzliche Auswertungen ermöglichen.
• Sprechende URLs enthalten die Kategorien oder Tags in den Verzeichnisnamen und den Titel des Beitrags als Dateiname. Das ist angenehm für Besucher und gut für die Bewertung durch Suchmaschinen, die Bindung an diese Informationen kann aber auch lästig sein. Das gilt besonders dann, wenn beim ersten Publizieren nicht ordentlich getaggt wurde oder sich die Überschrift des Textes später noch ändert. Allerdings wäre es in solchen Fällen nicht angebracht, die Änderungen auf die URL durchzuschreiben, weil dies zu toten Links führen könnte. Falls das CMS erlaubt, den Beitrag unter der alten und neuen URL zu erreichen, ist das unter SEO-Gesichtspunkten ungünstig. Ich habe mich dafür entschieden, dem Prinzip des Permalink zu folgen und grundsätzlich die erste erzeugte URL beizubehalten – auch wenn den Inhalt des Textes nicht mehr ganz widergibt.

Entsprechend verschieden sind die verglichenen Kandidaten. Während Alfresco mit dem Anspruch einer umfassenden ECM-Lösung auftritt, das auch Dokumenten- und Records-Management beherrscht, handelt es sich bei Joomla um ein leichtgewichtiges Web-CMS und bei Drupal um eine Software mit ausgeprägten Funktionen für Community-Sites. Die Infoworld sieht aufgrund ihrer angelegten Kriterien Alfresco mit 9,2 Punkten als klaren Sieger vor Plone mit 8,6 Punkten. Die drei restlichen Systeme liegen etwa gleichauf, wobei Drupal mit 8,3 Punkten am schlechtesten abschneidet.

Siehe auch: Das richtige CMS für den professionellen Einsatz

Wenn man nämlich ein Wiki einrichtet, steht man bald vor der Frage, wie man die Startseite gestalten will. Die Wikipedia erwartet die Besucher mit einer redaktionell betreuten Homepage, aber die meisten Wikis bieten dort nur ein wenig ansehnliches Inhaltsverzeichnis. Wenn man den Aufwand der Wikipedia nicht treiben kann und eine rohe Wiki-Übersicht als Eingangsseite nicht haben will, dann bietet sich dort ein Blog als Alternative an. Dieses muss sich keineswegs darauf beschränken, neue Wiki-Einträge vorzustellen. Vielmehr kann es auf herkömmliche Weise die Themen behandeln, um die es im Wiki hauptsächlich geht. Im Unterschied zu Wiki-Einträgen, die eher langlebige Wissensspeicher sind und laufend aktualisiert werden, können aktuelle Blog-Postings den diskursiven Charakter dieses Mediums ausspielen und damit helfen, Besucher auf das Wiki zu lenken.

Im Vergleich zu ausgewachsenen Blog-Systemen sollte man sich von den meisten Wiki-Plugins nicht zu viel erwarten. Häufig verfasst man seine Postings in Wiki-Syntax, Unterstützung für Kommentare oder Trackbacks müssen unter Umständen separat installiert werden. Für das von mir genutzte dokuwiki existieren alle benötigten Plugins, aber eine Blog-Sofftware mit dem Komfort von Wordpress oder Movable Type bekommt man damit nicht. Das zeigen schon die mageren Konfiguarionsoptionen des Weblog-Moduls.

Diese Zielgruppe ist im Allgemeinen nicht besonders geübt in der Verwendung von Programmiersprachen wie PHP und schreibt daher häufig schlechten Code. Eine Folge können Sicherheitsprobleme sein, wie ich selbst feststellen musste. Der WP Scanner von Blogsecurity entdeckte einen Mangel, der es erlaubte, beliebigen Javascript-Code als Parameter an WP zu übergeben:

Systeme, die Designern eine Abstraktionsschicht über der Programmiersprache bieten, beugen solchen Fehlern vor. Bei einer Reihe von CMS haben sich Tag-Bibliotheken bewährt. Beispiele dafür sind etwa Movable Type, Textpattern oder Innovationgate. Dort greift man auf Systemfunktionen mittels Markup zu, eine Technik, die Web-Designer gewöhnt sind.

Das Ergebnis sieht so aus:

Ruft man die Funktion wp_title() nämlich ohne Parameter auf, dann gibt sie ein Separatorzeichen aus (standardmäßig ein »). Soll sie kein Trennzeichen erzeugen, muss man ihr eine leere Zeichenkette als Argument übergeben – nicht gerade intuitiv. Wie wäre es mit: wenn kein Trennzeichen, dann kein Parameter, wenn Trennzeichen, dann dieses der Funktion übergeben? Das hätte mir die mühselige Suche nach der Herkunft des nutzlosen » erspart. Und wer den Separator nicht vor, sondern nach dem Titel haben will, der muss tun, womit man unter WP alle möglichen Defizite behebt: ein Plugin installieren.

Die zahlreichen eigenmächtigen Formatierungen, für die das Script formating.php zuständig ist, erinnern mich an die “Intelli*”- und “Auto*”-Funktionen, die Microsoft über Jahre für Office erfand. Die meisten davon gingen mündigen Benutzern ziemlich auf die Nerven. Immerhin lassen sich die Autokorrekturen, angepassten Menüs oder Assistenten abschalten. In Wordpress hingegen muss man Plugins installieren (etwa WP Unformatted oder wpuntexturize), um den Spuk zu beenden. Um eine Funktion, die bestenfalls optional sein sollte, zu deaktivieren, benötigt man also zusätzliche Funktionen. Besser wäre es, wenn WP die Möglichkeit böte, die Autoformatierung abzuschalten bzw. für bestimmte Zeichen zu unterlassen. Movable Type macht vor, wie es geht: Dort kann man entweder global oder pro Beitrag bestimmen, ob man das HTML-Markup selbst eingeben will oder dem System diese Arbeit überlassen will.

Update: Für eine gründliche und saubere Lösung sorgt das Plugin disableautop. Es schaltet den automatischen Formatierungsunfug komplett ab und überlässt es dem Autor, wie er seine Texte darstellen will.

• Wenn man erfahren will, wie der FileNet-Kauf der IBM nutzt, dann gibt die IBM-Pressemitteilung am wenigsten Aufschluss:
  

  Eine Konvergenz von Herausforderungen, mit denen sich das Business heute konfrontiert sieht … (blabla) … IBMs Übernahme von FileNet zielt darauf, die Information-on-Demand-Initiative voranzutreiben … (blabla) … Kunden profitieren von den kombinierten Fähigkeiten der beiden Firmen … (blabla) … IBM baut auf die fortgeschrittenen CM-Technologien der beiden Unternehmen auf … (blabla) .. hochwertige Lösungen … (blabla)

  Pressemitteilungen sind bei solchen Anlässen meist etewas luftig, aber hier mussten die Marketiers besonders viel Füllmaterial verwenden. Die einzigen halbwegs konkreten Aussagen lauten: FileNet wird in die Einheit “Information Management” von General Manager Ambuj Goyal integriert; sowohl die ECM-Produkte von IBM und FileNet werden weiterentwickelt (wie lange?); die Berater der IBM Global Service werden in beiden Systemen geschult.

• Die zwei häufigsten Interpretationen lauten, dass IBM sich nur Marktanteile kaufen wollte (weil sie fast alles hat, was sie nun mit FileNet erhält), beziehungsweise dass die IBM ihr inkosistentes und unübersichtliches ECM-Portfolio nicht unter einen Hut bekommt und nun bessere Technologie zukauft. Letzteres vertritt der Analyst Terry Schurter von Bloor Research, in dessen Augen besonders die BPM-Kompetenz von FileNet für IBM von besonderem Interesse war. Sue Clarke von der Butler Group hat in ihrer Rund-Mail zwar keine schlüssige Erklärung für den Deal, hält ihn aber für einen bloßen Kauf von Marktanteilen zu teuer.
• Angesichts der rasanten Konsoliderung des ECM-Marktes war absehbar, dass die mittelgroßen Spezialisten in diesem Segment potenzielle Übernahmekandidaten sind. Nach dem Kauf von Hummingbird blieben unter den führenden Anbietern nur mehr FileNet und Opentext als unabhängige ECM-Anbieter übrig. Auf der UserNet-Konferenz, die im Juni in Berlin stattfand, hatte CEO Lee Robert noch davon gesprochen, seine Firma sei “laser focused” auf ECM und könne dank großer Investitionen den IT-Größen Paroli bieten. Er wollte eine eventuelle Übernahme nicht ausschließen, aber kaum jemand dachte wohl an die Möglichkeit, dass IBM der Käufer sein würde. Ich hielt Oracle für einen wahrscheinlichen Kandidaten, nachdem die vollmundigen “Tsunami“-Ankündigungen nur zu bescheidenen Ergebnissen geführt hatten. Die SAP wäre ebenfalls in Frage gekommen, auch wenn die wegen des Ixos-Hintergrunds Opentext näher steht. Aber die IBM? Whilst it was always on the cards that FileNet would be acquired at some stage, it is rather surprising that IBM is the vendor to snap it up. (Sue Clark)
• Von wegen Nutzen für die Kunden, weil sie von den kombinierten Fähigkeiten der beiden Unternehmen profitieren: Priscilla Emery von CMS Watch beklagt nicht nur, dass Kunden aufgrund der Marktkonsolidierung immer weniger Auswahl haben. Vor allem bei Übernahmen mit einer so großen Produktüberlappung wie zwischen IBM und FileNet (oder Opentext und Hummingbird) dürfen sich die Anwender wundern, wo die von ihnen genutzte Software innerhalb eines konsolidierten Portfolios in ein paar Jahren auftaucht.

Diese Empfehlung bezieht sich auf textuelle Informationen mit allgemeiner Ausrichtung. Hochgradig technische oder multimediale Inhalte könnten durch die Beschreibung mit kontrollierten Vokabularen (also dem Gegenteil von frei vergebbaren Tags) besser lokalisiert werden. Ansonsten reiche eine Volltextsuche aus, um an relevante Daten zu gelangen.

Das Ergebnis der Studie ist aus zweierlei Gründen interessant. Erstens ist es kaum einem Unternehmen gelungen, Mitarbeiter zu einer kosequenten und konsistenten Eingabe von Metadaten zu bewegen. Die Beschreibung von Content kostet Zeit und Geld, bringt wegen fehlender Qualität aber meist recht wenig. Ähnliches gilt offenbar auch im Web. Seth Gottlieb behauptet, dass die großen Suchmaschinen entgegen verbreiteter Ansicht die von Benutzern vergebenen del.icio.us/43Things/Rojo/etc.-Tags wegen ihrer geringen Zuverlässigkeit ignorierten.

Insoferne scheint die Prognose von Greg Linden nicht unplausibel, wonach das Tagging von Dokumenten den Mainstream nicht erreichen werde. Vielmehr dürfte es sich nach seiner Meinung auf Daten wie Fotos, Videos und multimediale Inhalte beschränken.

Die erste Prüfung ist nicht schwer: Bis auf die Übereinstimmung mit dem “British Disability Discrimination Act” sind die Hürden für ein halbwegs aktives Weblog leicht zu schaffen. Aber es wenn zur Einschätzung von Inhalt und Layout kommt, wird SiteScore ganz schön streng. Auf meiner Site schaffte es das Tool irgendwie, die Kategorienliste zu extrahieren und die dort vorkommenden Begriffe als relavant für meine Inhalte zu betrachten. Das sollte stimmen und brachte mir ein “Excellent” bei den Google-Suchergebnissen ein.

Um herauszufinden, ob das Tool immer eine so gute Spürnase für die relavanten Begriffe hat, fütterte ich ihm zwei weitere Blogs. Und siehe da, bei vowe.net stellte es nur Kauderwelsch zusammen und gibt Volker, der insgesamt eine sehr gute Note bekommt, folgenden guten Tipp: You can usually increase repeat visitors, by offering useful services or valuable content on your website. Auch mit den Bildern war SiteScore nicht zufrieden: You may wish to add more diverse images to make your website more interesting. Vermutlich liegt es an den Holy-Moly-Fotos ;-)

Eine ebenfalls eigenwillige Auslese von relevanten Begriffen bringt meinem Kollegen Thomas Cloer eine herablassende Empfehlung ein: If your website is more than a month old, you should always aim to score within the top 10 results for a search for your website or company name, at least. Firstly, make sure your website is properly programmed, and makes proper use of title, heading and meta-tags – in particular your homepage. Und dann gibt es gleich noch ein dickes Minus für mangelnden Fleiß: Very Poor in der Kategorie Amount of Text. Das sollte einem Journalisten eigenlich nicht passieren ;-)

Unter den Themen, mit denen ich mich hauptsächlich beschäftige, fand ich zwei Dinge besonders interessant. Zum einen gibt Microsoft bei der Migration seiner Server-Software auf 64 Bit Gas. Das nächste Release von Exchange (”E12″), das sich voraussichtlich auf 2007 verspätet, kommt nur mehr in einer 64-Bit-Ausführung auf den Markt. Das überraschte mich umso mehr, als sich Microsoft auf der TechEd im letzten Jahr noch gar nicht darauf festlegen wollte, ob es eine solche Ausführung überhaupt geben werde.

Der zweite Schwerpunkt meines Konferenzbesuchs galt der neu justierten Portalstrategie von Microsoft. Portale als zentraler Einstiegspunkt für diverse Anwendungen spielten in Redmond bisher eine untergeordnete Rolle. Dafür spricht schon der Zickzack-Kurs bei den Sharepoint Services, die laufend umbenannt und zwischen Office und Windows hin- und hergeschoben wurden. Mit den WSS 3.0 soll sich dies ändern.

Sie werden die technische Basis für eine Web-basierte Alternative zu Fat Clients bilden. So möchte Microsoft mehrere Office-Server , über die schon seit längerer Zeit spekuliert wird, auf diese Plattform aufsetzen. Dazu zählt eine Software für analytische Anwendungen (”Excel-Server”), der auch die BI-Funktionen des SQL Server 2005 integriert. Darüber hinaus soll es einen Server für elektronische Formulare auf der Grundlage von Infopath geben. Der MS-Project-Server beruht derzeit noch auf einer eigenen Architektur und soll in der nächsten Version auf die Sharepoint Services aufsetzen. Das gilt auch für Microsofts Pläne bei Enterprise Search, die in eingeschränkter Form heute Teil des Sharepoint Portal Server ist. Die Suchmaschine soll auf zahlreiche neue Datenquellen ausgeweitet werden, etwa auch ERP-Systeme wie SAP. Die Zukunft des SPS ist ungewiss, möglicherweise wird es ihn in der heutigen Form nicht mehr geben.

Einer grundlegenden Überarbeitung muss sich der Content Management Server unterziehen. Er kam ursprünglich über den Kauf der kanadischen Firma Ncompass zu Microsoft, das letzte Update erschien vor drei Jahren. Das Web-CMS überschneidet sich in vielen Punkten mit den Sharepoint Services, etwa bei Workflow, Storage, Suche oder Template-Systemen. Deshalb wandert es ebenfalls auf die Portal-Plattform ab. Das Ergebnis wird eine weitgehend neue Software sein, die man nicht einfach per setup.exe über die alte spielen kann. Vielmehr müssen bestehende Installationen migriert werden, Microsoft wird dafür entsprechende Tools anbieten. Interessant an dieser Roadmap für den CMS finde ich, dass sich Microsoft zukünftig zutraut, Internet-Sites auf Basis der Sharepoint Services zu betrieben. Bisher wurden sie nur als Grundlage für interne Anwendungen positioniert.

Zwei Anwendungen, die zunehmend Bestandteil von Web-CMS werden, möchte Microsoft indes mit den Sharepoint Services ausliefern: Weblogs und Wikis. Sie würden sich in der Grafik im Balken links oben wiederfinden. Wer also in Zukunft einen Windows-Server kauft, erhält die Software für Wikis und Blogs gleich mit dazu.

Insgesamt habe ich den Eindruck, dass Web-Portale bei Microsoft in Zukunft einen ähnlich zentralen Stellenwert erhalten wie bei der IBM. Aufgrund der Bedeutung, die Office für das Unternehmen hat, werden die Fat Clients dadurch nicht abgewertet. Dank einer neuen Synchronisierungsmechanismus sollen sie zukünftig Offline-Funktionen für das Portal bieten.

Ein paar Bilder, die ich von der Veranstaltung und dem Konferenzviertel gemacht habe, gibt es auf Flickr.

Bisher zeichnen sich für Office-Lösungen zwei Konstellationen ab: Umfangreiche Pakete mit ihrer Funktionsfülle, wie sie aus dem PC-Umfeld bekannt sind, wandern vom Client auf Applikations-Server ab. Die Arbeitsplatzrechner beschränken sich in diesem Szenario hauptsächlich auf grafische Darstellungsfunktionen. Vertreter dieser Philosophie sind die Applix Inc. und die deutsche Star Division GmbH.


Das Gegenmodell repräsentieren Corel, Lotus und Oracle. Diese Hersteller arbeiten an Büropaketen, die vollständig in Java programmiert sind. Solche Anwendungen lädt der Client über HTML-Seiten vom Netz herunter und führt sie im Gegensatz zum ersten Konzept lokal aus.

Was aus diesen Ansätzen geworden ist, dürfte hinlänglich bekannt sein. Ein Hauptargument für solche leichtgewichtigen Office-Anwendungen war damals, dass der durchschnittliche Benutzer nur einen Bruchteil der Funktionen von MS Office & Co benötige. Die Anbieter der dicken Klöpse konterten zu Recht, dass jeder Anwender jedoch eine andere Teilmenge der großen Funktionsfülle brauche. Tatsächlich konnten einfachere Tools die Office-Schwergewichte nie ernsthaft in Frage stellen.

Was damals die Java-Applets nicht schafften, sollten nun in Zeiten des Web 2.0 Online-Services richten. Jon Udell träumt wieder von simplen, leichtgewichtigen und gehosteten Alternativen zu den dicken Office-Brummern. Bei allem Respekt vor Writley, gOffice oder WebOffice: Ich halte es in dieser Frage mehr mit Tim Bray und bleibe nach den Erfahrungen der 90er Jahre skeptisch.

• Textpattern hat eine Importroutine für MT, mit der sich die Inhalte eines Blogs transferrieren lassen. Sie übernimmt Postings und Kommentare, Trackbacks blieben bei meinen Versuchen auf der Strecke.

  

• Beim Import von MT-Daten kann man als Quelle zwischen der MySQL-Datenbank und einer MT-Exportdatei wählen. Bei Letzterer übernahm Textpattern aber nur den “Entry Body”, nicht jedoch das “Extended Entry”.
• Textpattern verwendet als Zeichensatz UTF-8, MT 2.x hingegen standardmäßig iso-8859-1. Wenn man auf ein neueres System umsteigen will, empfiehlt sich m. E. ohnehin, auf UTF-8 zu wecheln. Immer mehr Blogs verwenden diesen Zeichensatz und wenn man selbst bei Latin1 bleibt, macht sich das zunehmend in verunstalteten Trackbacks bemerkbar. Die Konvertierung erfolgt, indem man die Inhalte aus Movable Type in eine Exportdatei schreibt und diese mit einem dazu fähigen Editor (etwa MS Word) als UTF-8 speichert. Da aber das Einlesen der MT-Exportdatei nicht richtig funktioniert, bleibt als Alternative die Konvertierung der MySQL-Datenbank. Man schreibt alle Datensätze über einen SQL-Dump (etwa mit phpMyAdmin) in eine Textdatei, wandelt diese um und schreibt die Informationen in eine neue Datenbank zurück.
• Ein wesentliches Anliegen bei einer Migration ist natürlich, dass man die bisherigen URLs für seine Postings beibehalten kann. MT 2.x verwendet für jeden Eintrag standardmäßig das Format EntryID.html. Versucht man die Daten mit Hilfe einer MT-Exportdatei zwischen zwei MT-Installationen auszutauschen, dann funktioniert das nicht verlässlich, weil beim Import die IDs neu generiert werden. Schon deshalb habe ich beim Einlesen meiner Texte nach Textpattern die Importquelle MySQL gewählt. Leider gingen die EntryIDs von MT dabei über den Jordan, Textpattern nummeriert die Einträge neu durch. Textpattern bietet ein flexibles URL-Schema, das diverse URL-Muster für Postings vorsieht. Dazu zählt auch die Möglichkeit von Dateinamen, die aus der ID bestehen. Da sich diese aber beim Import verändern. nützt diese Flexibilität aber wenig. Für mich besteht darin das größte Hindernis für den Umstieg.

  

• Alle Autoren, deren Texte importiert werden, müssen namensgleich bereits in Textpattern existieren. Die Importfunktion legt diese nicht an, sondern übernimmt die Posting ohne Bezug auf den Autor, wenn dieser dem System nicht bekannt ist.
• Die Importroutine übernimmt mehr oder weniger vollständig die Daten. Eine Migration der MT-Templates erfolgt nicht. Textpattern hat sein eigenes Templating-System und ein insgesamt eigenes Konzept für die Organisation und Präsentation der Inhalte. Ich habe mich damit noch nicht auseinandergesetzt, aber nach meinem ersten Eindruck wirkt es elegant und durchdacht. Eine Umstellung würde aber bedeuten, dass man das neue System erlernen und das vorhandene Layout in TXP-Templates übertragen muss.

Vorläufiges Fazit: Der Importvorgang wartet mit zu vielen Hürden auf. Wenn man viele Posting hat, dann sind die Qualitätseinbußen und die unerwünschten Nebenwirkungen zu groß. Meines Erachtens besteht in diesem Fall die beste Lösung darin, die alte MT-Installation für existierende Inhalte beizubehalten und Textpattern parallel zu installieren. Da beide Systeme für die Namen der Tabellen eindeutige Präfixe verwenden, können sie sich bei kleineren Hosting-Paketen mit nur einer MySQL-Datenbank ohne Weiteres eine DB teilen.