Als Adobe Ende November ankündigte, dass Flash Professional nicht länger Flash Professional heißen würde, sondern ab dem nächsten Update Animate CC und der Fokus stärker auf Animationen mit HTML5 liegen soll, statt auf der aussterbenden Flash-Plattform, war ich sehr gespannt. Lange Zeit habe ich für verschiedene Projekte mit Flash Professional in den Versionen CS4 und CS5 und in letzter Zeit noch mit Flash Professional CS6 und Edge Animate gearbeitet. Edge Animate hat als Animations-Software meiner Meinung nach gut funktioniert, auch wenn es sehr stark Web fokussiert war. Nun aber wurde Edge Animate zugunsten von Animate CC eingestellt – und entsprechend hoch waren nun meine Erwartungen und Befürchtungen, wenn Flash Professional und Edge Animate aufeinandertreffen. Dies ist eine Sammlung meiner ersten Eindrücke:

Screenshot: Hauptfenster von Animate CC

Mein aller erster Eindruck von Animate CC: es fühlt sich immer noch stark nach Flash Professional an – und das ist nicht umbedingt positiv gemeint. Für »alte Hasen« ist das sicherlich gut, aber meines Erachtens krankten schon die letzten Versionen von Flash Professional daran, dass sie einige Features und Eigenheiten von Flash Professional mitschleppten, die den Einstieg m.E. unnötig schwierig machen. Edge Animate, auf der anderen Seite, startete ohne diese ganzen Altlasten und funktionierte daher für Einsteiger deutlich besser.

Timeline

Die Timeline (Zeitleiste) ist in Animate CC leider immer noch so statisch und unflexibel wie sie in Flash Professional war. Die Timeline von Edge Animate, die an die von After Effects angelehnt war, funktionierte für den Einstieg in die Animation viel intuitiver: das Setzten und Verschieben von Schlüsselbildern (Keyframes) ging sehr einfach und nahezu fehlerfrei; in Flash Professional war es immer schwierig und fragil, man konnte sehr leicht unbeabsichtigt Bilder und Schlüsselbilder einfügen, wodurch das Korrigieren von Animationen sehr aufwendig war – und nun in Animate CC leider immer noch ist. Schade, dass Adobe hier nicht die Chance für einen klaren Schnitt genutzt hat.

Farbwähler

Screenshot: Farbwähler in Animate CCDie Farbwähler in Animate CC sind ebenfalls immer noch die seltsamen Farbwähler aus Flash Professional mit ihrer seltsamen Zusammenstellung aus »websicheren Farben«. Auch hier waren die Farbwähler in Edge Animate deutlich moderner und praktischer.

Vektor-Formen

Screenshot: Überlappende Formen in Animate CC
Das Standard-Verhalten beim Zeichnen von Formen ist in Animate CC immer noch genauso unlogisch und fehleranfällig wie es in Flash Professional war: Formen gleicher Füllfarbe verschmelzen zu einer einzigen Form, Formen verschiedener Farbe beschneiden sich, Rahmen sind nicht Teil einer Form sondern eigene Formen (und zwar jede Seite (rechts, links, oben, unten) für sich!) – WTF?! Für jeden, der ein Vektorzeichenprogramm wie Illustrator gewöhnt ist, ein vollkommen ungewöhnliches und unlogisches Verhalten.

Screenshot: Umschalten des »Objektzeichenmodus« im Eigenschaften-Fenster für Formen in Animate CCImmerhin gibt es mittlerweile direkt im Eigenschaften-Fenster einen Button, mit dem dieses Verhalten ausgeschaltet werden kann – und nicht wie früher, tief in den Einstellungen verstecket. Mir ist bewusst, dass dieses Verhalten auch dafür verwendet werden kann, schnell komplexe Formen oder Figuren zu erzeugen, aber sowohl bei mir, als auch bei anderen Einsteigern in Flash Professional, die Illustrator gewöhnt waren, führte dieses Verhalten häufig zu ungewollten Ergebnissen und Fehlern.

Bewegungseditor

Screenshot: Bearbeiten des Bewegungstweens in der Timeline in Animate CC

Der Bewegungseditor zum Bearbeiten von Bewegungstweens (Motion Tweens) ist nun quasi in die Timeline integriert – das ist ähnlich zu Edge Animate, bei dem die animierten Eigenschaften von Objekten ebenfalls als »Sub-Timelines« aufgeführt waren. Allerdings ist diese neue Form des sogenannten »Tween verfeinerns« eine schlechte Mischung aus dem alten Bewegungseditor und der Timeline aus Edge Animate: Das UI ist kompakter, was immer ein großes Manko des Bewegungseditors war, dafür fehlen nun viele Funktionen wodurch sich nun die Schlüsselbilder einzelner Eigenschaften nur noch sehr schlecht bearbeiten lassen: einzelne Schlüsselbilder im Verlauf einer animierten Eigenschaft kann ich setzten und wieder entfernen, aber nicht das Schlüsselbild am Anfang oder am Ende – das war früher im Bewegungseditor einfach möglich; den exakten Wert einer Eigenschaft an einem Schlüsselbild lässt sich nicht mehr im Bewegungseditor ansehen und auch nicht bearbeiten, dadurch lässt sich eine Animation nicht mehr so einfach und präzise anpassen oder korrigieren.

Bewegungstweens und Frame-für-Frame-Export

Bewegungstweens scheinen, zumindest bei Animationen mit HTML5, nicht mehr die bevorzugte Variante zum animieren zu sein: Beim Veröffentlichen erscheint in der Konsole folgende Warnmeldung:

Bewegungs-Tweens werden als Frame-für-Frame-Animationen veröffentlicht. Verwenden Sie nach Möglichkeit klassische Tweens.

Das finde ich äußerst schade (oder wie ich in meinen Notizen schrieb: »WTF?!«), da Bewegungstweens m.M.n. aus Flash Professional (bzw. jetzt Animate CC) eine annähernd moderne Animations-Software machten. Klassische Tweens funktionieren zwar gut, sind aber eine unhandliche und umständliche Art zu animieren, die – in Kombination mit der Timeline (siehe oben) – unpraktisch und fehleranfällig ist, gerade wenn es darum geht das Timing einer Animation zu verändern.

Bei der Ausgabe von HTML5-Projekten arbeitet Animate CC mit CreateJS und zwar ausschließlich: sämtliche Animationen und programmierte Aktionen werden als JavaScript ausgespuckt und in einem canvas-Element angezeigt. Dadurch wirken die Animationen mit dem Bewegungstween nach dem Veröffentlichen ruckelig:

Die gleiche (bzw. sehr ähnliche) Animation mit CSS3-Keyframes, die ich händisch gebaut habe, läuft dagegen flüssig:

Beide Banner finden sich auf GitHub:

Aktionen

Das Einfügen der Aktionen, also dem »einprogrammieren« von weiteren Funktionalitäten, wie z.B. das ein Banner auf den Klick eines Benutzers reagiert, gibt mir etwas Rätsel auf: Zunächst bin ich dem Irrtum aufgesessen, ich könnte wie bisher in ActionScript programmieren und Animate CC würde es in JavaScript übersetzen, dem ist leider nicht so: das eingefügte Script wird direkt ins exportierte JavaScript eingefügt, also nicht cross-compiliert, heißt: in Animationen mit HTML5 kann man nicht mehr mit ActionScript programmieren, sondern man muss mit JavaScript arbeiten.

Also habe ich mich für mein HTML5-Canvas-Projekt aus den vorgefertigten Codefragmenten für HTML5-Canvas-Projekten bedient, allerdings funktionierte das vorgegebene Code-Fragment nicht:

this.clickPane.addEventListener("click", fl_ClickToGoToWebPage_8);

function fl_ClickToGoToWebPage_8() {
    window.open("http://www.freiesmagazin.de/", "_blank");
}

Im Browser wurde nach dem Einfügen dieses Codefragments keine Animation mehr angezeigt, dafür spukte der Browser auf der Konsole folgende Fehlermeldung aus:

TypeError: this.clickPane is undefined

Das Element, das den Klick eines Benutzers abfangen soll, eine über allen anderen Elementen liegende, unsichtbare Fläche, hatte ich in den Eigenschaften den eindeutigen Namen clickPane zugewiesen, aber nach dem Export kann das generierte JavaScript dieses nicht mehr finden – sehr seltsam.

Aus der Rubrik von Codefragmenten für WebGL-Projekte fischte ich dann folgendes Script:

canvas.onclick = function(event) {
    window.open("http://www.freiesmagazin.de/", "_blank");
}

Und siehe da: Das Script funktioniert. Das Script aus der Codefragment-Rubrik »HTML5 Canvas« funktionierte für mein HTML5-Canvas-Projekt nicht, aber das Script aus der Rubrik »WebGL«.

Weitere Kleinigkeiten

Einige weitere Kleinigkeiten sind mir beim ersten Arbeiten in Animate CC aufgefallen:

Die Zoom-Gesten von MacOS X funktionieren (immer noch) nicht; in Photoshop oder InDesign kann ich mittels der Zoom-Gesten die Ansicht der Arbeitsfläche vergrößern oder verkleinern, aber bei Animate CC leider nicht.

Farben in der kurzen Schreibweise von Hex-Codes, also z.B. #666 für #666666, werden nicht, wie in Photoshop, automatisch auf die sechs-stellige Schreibweise erweitert, sondern es werden einfach für die fehlenden Stellen Nullen eingefügt: aus #666 wir also #000666 statt #666666 – das ist nicht das Verhalten, wie ich es als jemand der mit CSS vertraut ist, es in einer Web-orientierten Software erwarten würde.

Screenshot: Schwacher Kontrast in der Timeline in Animate CC

Auch wenn ich die neue, dunkle Oberfläche von Animate CC (bzw. zuletzt Flash Professional CC) sehr mag, der Kontrast in der Timeline ist viel zu schwach! Gerade die Unterscheidung zwischen leeren Bildern und gefüllten Bildern ist viel zu schwach (im Screenshot sind die leeren Bilder in der Timeline dunkel-grau und die gefüllten Bilder helleres Grau), sodass es schon für mich, als gut sehender Mensch, schwer auf den ersten Blick zu erkennen ist, welche Bilder leer und welche – vielleicht unbeabsichtigt – gefüllt sind. In der hellen Oberfläche ist der Kontrast und die Unterscheidung deutlich besser: leere Bilder sind in der Timeline weiß, gefüllte Bilder hellgrau.

Fazit

Vom ersten Eindruck her, bin ich leider enttäuscht – was ich aber schon befürchtet habe. Es sind meiner Meinung nach viel zu viele Altlasten von Flash Professional in Animate CC, das wird es den alten »Flashern« leicht machen, aber der Einstieg in Animate CC und die Animation macht es damit meines Erachtens unnötig schwerer. Viele gute Ansätze, die sich in der Oberfläche von Edge Animate fanden, allem voran die Timeline, haben es leider nicht in Animate CC 2015 geschafft.

Der reine Fokus auf Animation mittels JavaScript für HTML5 finde ich ebenfalls schade und ist zum Teil, wie in meinem Experiment, anscheinend sogar weniger performant! Damit fehlt mir auch weiterhin eine (gute) Software, mit der ich visuelle CSS3-Keyframe-Animationen erstellen kann.

wp-blank ist ein einfaches Starter-Theme für WordPress mit dem Fokus auf die wichtigsten Funktionen von WordPress und gutes Markup (sauberes und logisches HTML).

Nachdem ich nun seit einigen Jahren für Blogs und Websites individuelle Themes für WordPress baue, und diese Themes in gewisserweise immer aufeinander aufgebaut haben, wurde es Zeit die, meiner Ansicht nach, wichtigsten Funktionen in einem Starter-Theme für den schnellen Entwicklungs-Start zu bündeln.

Im Gegensatz zu den Standard-Themes von WordPress, die Twenty-Reihe (»Twenty Eleven«, »Twenty Twelve«, etc.), soll wp-blank im Quellcode übersichtlicher und verständlicher sein; und im Gegensatz zu anderen Starter-Themes nutzt wp-blank nicht jede verfügbare WordPress-Funktion und hängt auch nicht von einem Frontend-Framework wie Bootstrap ab.

Screenshot des WordPress-Themes wp-blank 1.0

wp-blank soll einen schnellen Start in die Theme-Entwicklung bieten und gutes, sauberes Markup generieren, zudem man dann sein eigenes CSS für ein Design hinzugeben muss. Außerdem nimmt wp-blank Best-Practice-Ansätze aus der Webentwicklung auf, u.a. für Barrierefreiheit (Accessibility), Mikro-Daten nach Schema.org zur Suchmaschinen-Optimierung, Platzhalter-Grafiken mit Verknüpfungen für iOS- und Windows-Lesezeichen und viele weitere Details. Ein vollständige Liste der Features findet sich in der README.

Wie gesagt ist wp-blank nur ein Ausgangspunkt für sein einges Theme: Jede Funktionalität, die über den Standard hinausgeht, muss in das eigene Theme eingebaut werden und jedes zusätzliche, individuelle Seiten- oder Post-Template muss ebenfalls selbst angelegt werden. Aber genau das ist der Sinn bei wp-blank: ein minimaler aber optimaler Start-Punkt für ein individuelles WordPress-Theme.

Über Fragen, Anmerkungen oder Fehler-Hinweise freue ich mich sehr – wenn möglich am Besten als Issue auf GitHub einreichen.

Download und Sourcen bei GitHub.

Vorletzte Woche Mittwoch hat leider meine MacBook-Festplatte ihren Geist aufgegeben, zum Glück konnte ich aber noch alle Daten auf einer externen, mit HFS+ formatierten Festplatte sichern (HFS+ wird auch »Mac OS Extended« genannt). Um wenigstens etwas weiterarbeiten zu können, wollte ich die externe Festplatte mit meinem Linux-Rechner mounten (derzeit mit Ubuntu 12.04 LTS), dazu habe ich einfach die Pakete hfsplus und hfsutils über apt-get nachinstalliert:

apt-get install hfsplus hfsutils

Beim Versuch die Festplatte über KDE mittels der »Geräteüberwachung« zu mounten, erschien immer die Warnmeldung:

Requested filesystem type is neither well-known nor in /proc/filesystems nor in /etc/filesystems

Allerdings ließ sich die Festplatte ohne Probleme händisch mounten (wobei ich den Mount-Punkt zuvor mit mkdir /media/BackupDisk angelegt habe):

mount /dev/sdc2 /media/BackupDisk

Um aber die Festplatte nicht immer händisch ein- und aushängen zu müssen und um die Geräteüberwachung von KDE nutzen zu können war nur ein kleiner Kniff nötig:

Auf meinem System existierte die Datei /etc/filesystems noch nicht, also habe ich sie kurzerhand mit nano angelegt:

nano /etc/filesystems

Hinein musste nur der (richtige) Name des Dateisystems:

hfsplus

Datei mit STRG + O speichern und schon lässt sich die externe HFS+-Festplatte problemlos über die Geräteüberwachung ein- und aushängen.

In letzter Zeit ist mir aufgefallen, dass ein offener Finder-Ordner mit vielen Dateien den Finder auf meinem MacBook fast durchgehend 100% der Prozessor-Leistung fressen lässt, sodass sogar nach einiger Zeit der Lüfter anspringt.

In einem Forumsbeitrag in der Apple Support Community wird empfohlen, die Datei com.apple.finder.plist aus dem Ordner Preferences im Library-Ordner des Benutzers zu löschen und den Finder danach neu zu starten. Über das Terminal (zu finden im Dienstprogramme-Ordner des Programm-Verzeichnisses) sieht das so aus:

user@mac$ rm ~/Library/Preferences/com.apple.finder.plist
user@mac$ killall Finder

Kurze Erläuterung: Der erste Befehel, rm, löscht die Datei com.apple.finder.plist im Ordner ~/Library/Preferences (wobei das Tilde-Zeichen am Anfang andeutet, dass es sich um einen Ordner im aktuellen Benutzer-Verzeichniss handelt). Der zweite Befehl, killall, beendet den Finder (bzw. seinen laufenden Prozess) komplett, woraufhin sich dieser automatisch wieder neu startet – und dabei eine neue, saubere com.apple.finder.plist-Datei anlegt.

Bei mir läuft nun der Finder mit dem gleichem, vollem Ordner geöffnet seit über einer Stunde im Hintergrund ohne dass der Finder eine nennenswerte CPU-Last verursacht.

In einigen anderen Forumsbeiträgen, die ich bei der Suche nach der Problemlösung gelesen habe, wurde auch angedeutet, dass viele JPEG– oder PNG-Dateien in einem Ordner (oder auch auf dem Desktop) zu hohem CPU-Verbrauch durch den Finder führen könne, da dieser mit diesen Dateien irgendwelche Probleme haben solle – dies konnte ich bisher nicht nachvollziehen, möchte ich aber der Vollständigkeithalber kurz erwähnen.

Darstellungsoptionen der Listdarstellung des MacOS X Finder

Im gleichen Forumsbeitrag von oben wird als weiterer Lösungsvorschlag geraten die Darstellungsoptionen (siehe Screenshot), zu finden in der Menüleiste und Darstellung, der Listenansicht im Finder zu überprüfen: Die Option »Alle Größen berechnen« soll ebenfalls zu hoher CPU-Auslastung durch den Finder führen, da er für alle Unterordner eines Verzeichnisses die Größe berechnet.

Der Standard-Linux-Client von Dropbox, der nur für Ubuntu oder Fedora als kompiliertes Paket zur Verfügung steht, ist nur auf die Desktop-Umgebung Gnome ausgelegt. Versucht man unter Kubuntu den Clienten zu installieren, versucht die Paket-Verwaltung apt-get den Dateimanager Natuilus und den (gesamten) Gnome-Desktop nach zu installieren und dies ist bei einem Linux mit KDE nicht unbedingt wünschenswert.

Eine Lösung für dieses Problem ist bereits auf Englisch dokumentiert, diese Anleitung hier beschreibt eine etwas abgewandelte Lösung (u.a. über die sehr komfortablen Systemeinstellungen von KDE 4.3) mit ein paar mehr Deatails.

Um Dropbox mit KDE zu benutzen, greift man auf das Paket zurück, dass Dropbox für Linux mit reiner Text-Shell zur Verfügung stellt (verfügbar für 32-Bit- sowie 64-Bit-Prozessoren). (Anmerkung: Zwar benutzt dieses Paket für die GUI GTK+, aber der komplette Gnome-Desktop ist zum Glück nicht mehr nötig.)
Nachdem herunterladen und auspacken des Paketes soll der extrahierte Ordner .dropbox-dist (nach der Anleitung auf der Dropbox-Webseite) in das Home-Verzeichnis des jeweiligen Benutzers (/home/benutzername/) verschoben werden. Sinnvoller ist es, meiner Ansicht nach, gerade wenn der Rechner von mehreren Benutzern verwendet wird, den Ordner nach /opt/ zu verschieben (dafür sind allerdings Root-Rechte nötig).
Damit Dropbox kontinuierlich läuft und der Dropbox-Ordner immer synchronisiert werden kann, muss der Dropbox-Client im Hintergrund als Deamon laufen. Dazu sollte der Client immer starten, wenn KDE startet: Dafür geht man in Systemeinstellungen auf »Autostart« (im Reiter »Erweitert«).

[Screenshot: KDE-Systemeinstellungen]

In den Autostart-Einstellungen klickt man auf »Programm hinzufügen«; im Auswahl-Dialog dann auf den blauen Ordner (im Screenshot markiert mit 2.), im sich nun öffnenden Auswahl-Dialog geht man in das eben verschobene .dropbox-dist/-Verzeichnis (in meinem Fall /opt/dropbox/) in dem man die Datei dropboxd auswählt.

[Screenshot: Autostart-Einstellungen von KDE]

Die nun folgenden Dialoge können bestätigt werden und danach sollte der Dropbox-Deamon (dropboxd) unter »Einrichtungs-Datei (.desktop)« auftauchen.

[Screenshot: Autostart-Einstellung von KDE mit Dropbox-Deamon]

Bei der nächsten Neu-Anmeldung in KDE wird dann automatisch der Dropbox-Deamon gestartet. Dabei öffnet sich automatisch das Dropbox-Setup indem dann alle weiteren Einstellungen für Dropbox vorgenommen werden.

[Screenshot: Setup-Assistent von Dropbox]

[Screenshot: Tray-Icon und -Menü von Dropbox]

Im Tray-Bereich von KDE ist nun auch das Dropbox-Icon, dass über den Status des Dropbox-Ordners informiert, über einen einfachen Klick den lokalen Dropbox-Ordner öffnet (in Dolphin oder Konqueror oder des eingestellten Datei-Managers) und über einen Rechts-Klick das Tray-Menü öffnet, in dem alle wichtigen Informationen und Einstellungen zum eigenen Dropbox-Ordners zu finden sind.


Unter meinem Windows XP Professional SP3 hatte ich lange Zeit das Problem, dass sich der Internet Explorer 7 nicht installieren lies. Weder über Windows Update noch manuell. Die Installation ist jedesmal ohne weitere Fehlermeldung abgebrochen und die Tipps aus der Microsoft Knowledge Base (die einem dankenswerterweise als Link direkt auf den Desktop gelegt werden) halfen auch nicht. (Sie können sogar u.U. noch mehr Probleme machen als beheben!)

Heute habe ich, da sich der Internet Explorer 7 immer noch nicht installieren lies, versucht die Beta des neuen Internet Explorers 8 zu installieren. Dort brach die Installation ebenfalls jedesmal – ohne ersichtlichen Grund – ab und die Tipps aus der Knowledge Base für die neue Version halfen genauso wenig wie die für den IE7.
Im Log-File zur Installation, dass man schnell über den »Ausführen«-Dialog (Windows-Taste + R) mit der Eingabe von %windir%ie8_main.log öffnen kann, stand bis auf folgende Zeile nichts auffälliges oder brauchbares: ERROR: |Inst. IE >>> Internet Explorer installation completed with errors, exitresult=0x00000000, exitcode=0x000003f5
Im Log-File des Internet-Explorer 7, dass unter %windir%ie7_main.log zu finden ist, steht übrigens die gleiche Fehlermeldung.

Nach kurzer Suche mit dieser Fehlermeldung fand sich die Lösung in einem Forum: Der Adobe Reader 9 ist schuld!

Problemlösung

Da der Adobe Reader 9 die Installation einer neuen Internet Explorer-Version blockiert hilft nur: Adobe Reader deinstallieren; den Internet Explorer per Setup oder Windows Update installieren; Neustarten und dann ggf. den Adobe Reader wieder installieren.

Eigentlich mag ich WordPress ganz gerne. Seit Version 2.0 arbeite ich (fast) durchgehend damit; mittlerweile betreibe ich zwei Weblogs mit der aktuellen Version 2.6. Da ich mich im Moment intensiver mit WordPress auseinandersetze, fallen mir natürlich auch Dinge auf, die mir nicht so gefallen.

Bevor ich mich den zwei konkreten Punkten widme, die mir Ärger machen, ein kleiner Gedanke zum Konzept von WordPress: Ich finde WordPress mittlerweile für ein Blog-Software ziemlich fett: Mit fast 5 MB ist es leider kein Leichtgewicht mehr. Als CMS kommt es sicherlich schlank und komfortabel daher; aber als Blog-Software ist WordPress schon reichlich aufgeblasen und fett. Dafür ist es sehr flexibel, kann sehr vielseitig verwendet und erweitert werden; es gibt eine große Community die Erweiterungen und Themes entwickelt.
Dies ist aber ein generelles Problem bei der Software-Entwicklung: Große Gegensätze, die schwer gemeinsam zu erreichen sind (klein und simpel gegen flexibel und anpassbar); in der Wirtschaft wird so etwas auch Zielkonflikt genannt.
Auch wenn heute Webspace in rauen Mengen verfügbar und erschwinglich ist, sollte man sich überlegen ob eine große, Speicherplatz-fressende Anwendung sinnvoll ist oder ob man lieber auf etwas schlankeres zurückgreift. Gerade wenn sich Web-Applikationen auf einem Server häufen, so wie bei mir, sollte man über Alternativen nachdenken: Im Moment laufen auf über meinen Webspace zwei WordPress-Installationen, jede mit ungefähr 5 MB und die dritte steht kurz vor der Tür …

Zwei große Ärgernisse verderben mir leider im Moment etwas den Spaß mit WordPress:

  1. Seit Version 2.6 gibt es ein Versions-System für Artikel, wie man es aus Wikis (wie Wikipedia) oder auch aus Content Management Systemen kennt. Dieses Version-System ermöglicht einem, einen veränderten Artikel zu einer früheren Version zurückzusetzen, falls einem die veränderte Version aus irgendeinem Grund nicht gefällt.
    Dies kann sehr sinnvoll sein, wenn ein Weblog von mehreren Personen betrieben wird oder wenn man seinen Lesern erlaubt, eigene Artikel zu verfassen.
    Für mich ist diese Feature allerdings ein Ärgernis, denn es müllt meine Datenbank mit Einträgen zu. Jedes mal wenn ich einen Rechtschreibfehler korrigiere oder ein Stichwort hinzufüge, wird ein neue Version in der Datenbank angelegt. Und das leider nicht in einer eigenen Tabelle, sondern in der Tabelle für die generellen Blog-Einträge.
    Im Moment überarbeite ich gerade diesen Blog (dot.PsiLab alias PsiLab Journal) und meinen rein privaten Blog (»aber aber Arne …«) von Grund auf; ich bin dabei alte Einträge aus alten Blog-Versionen, die hier einmal liefen, wiederherzustellen und aufzuarbeiten. Dabei müssen zum Teil einzelne Beiträge öfters überarbeitet werden. Auf »aber aber Arne …« komme ich bei knapp 90 Blog-Einträgen (inklusive Unterseiten) auf fast 800 Datenbank-Einträge!
    Zudem verwässert dieses Versions-System einen Weblog mit fortlaufender ID für Beiträge. Früher waren Beiträge in diesem Weblog über dot.psilab.de/42 erreichbar. Wenn ich dies in der neuen WordPress-Version machen würde, würden sich bei einem regulären Blog-Betrieb (Eintrag erweitern, korrigieren, etc.) zum einen die IDs ständig ändern, weil ein Eintrag immer die ID der letzten Version bekommt. Und zum anderen können die IDs, die auf die alten Versionen verweisen, nicht mehr verwendet werden! So sind fortlaufende IDs nicht mehr möglich. Jetzt würden sich quasi die IDs 60, 42 und 327 aneinander reihen, statt 41, 42 und 43
    Update: Mit automatischem Speichern und Artikel-Speichern/-Vorschau habe ich für diesen einen Eintrag alleine schon 45(!) Versionen in der Datenbank. Und das bevor ich ihn überhaupt veröffentlicht hatte!
  2. Kategorien, Link-Kategorien und Stichworte sind dasselbe. Ein Umstand der mich in den letzten Tagen des öfteren die Haare raufen lies: Wenn ein Stichwort der Name einer Kategorie ist, wird die Kategorie als Stichwort hinzugefügt. Da bei mir die Stichworte aber nur klein geschrieben sein sollen/dürfen, ist dieses Feature wirklich ärgerlich.
    Das Problem rührt wohl daher, dass diese drei Kategorie-Arten in einer einzigen Tabelle in der Datenbank liegen. Was vielleicht auch noch kein Problem wäre, wenn in dieser Tabelle zweimal die gleiche URL-Form erlaubt wäre. Dies ist aber leider bei der Standard-Installation von WordPress nicht der Fall. Zwar wird bei der internen Verarbeitung von Kategorien und Stichworten unterschieden, aber nicht in der Datenbank und an der Benutzer-Oberfläche.
    Ein konkretes Beispiel, um das Problem etwas zu veranschaulichen: Ein Blog-Eintrag soll in die Kategorie »Foo Bar«, diese Kategorie hat die URL-Form foobar. Im Blog kann man diese Kategorie durch /category/foobar erreichen. Nun soll dieser Beitrag mit dem Stichwort »foobar« versehen werden. Das Stichwort soll ebenfalls die saubere URL-Form foobar haben; später soll sie dann über /tags/foobar erreichbar sein. So simpel dies klingt, so unmöglich ist dies im aktuellen WordPress. Man kann dies, mit Standard-Bordmitteln, nur erreichen, indem man entweder der Kategorie oder dem Stichwort eine unsaubere URL-Form gibt (z.B. für das Stichwort die URL-Form foobar-tag). Das ist leider, wie bei vielen Workarounds, nicht schön gelöst und sauber.

Schön wäre es, wenn es spätestens in WordPress 2.7 für das erste Problem eine Lösung gibt, die schon einige Plugins bereitstellen: Ein- oder Ausschalten des Versions-Systems oder dieses auf eine bestimmte Anzahl an alte Versionen für die Artikel limitieren. Dabei würde ich mir dann auch noch weitergehend wünschen, dass es ein Aufräum-Tool gibt, dass alte, nicht benötigte Versionen löscht und die IDs wieder aufräumt.
Für die Lösung des zweiten Problem muss wohl die Datenbank oder zumindest die Kategorie/Stichwort-Tabelle angepasst werden; was wirklich wünschenswert wäre, denn der oben angerissen Workaround ist wirklich hässlich.