[ Jump to content ]


delivered in beta

A lot has changed over the last decade on the web—and so has WordPress: WordPress has started as a simple blogging tool and has grown into a widely used CMS with a simple interface for (new) users and a huge ecosystem of extensions, themes and developers. That’s great—and a reason why I still use it for other projects and at work—but WordPress has outgrown my needs for a simple blogging tool that I want for my blog. And now, with WordPress 6.0 around the corner, it’s time to switch to ClassicPress. ClassicPress is a fork of WordPress 4.9—or: the pre-Gutenberg era—and so exactly what I want my blogging tool to be: simple.

Lately I had a tough time to figure out how to serve a Unity3D WebGL export via AWS CloudFront from an AWS S3 origin after updating to Unity3D 2020.01 with it’s new WebGL loader. I don’t describe how to connect AWS CloudFront to serve files from AWS S3—Andrew Welch does this neatly in his tutorial (one can skip the last step about Craft CMS, though)—I focus on the special configuration the Unity3D files need.

The new WebGL loader

The new WebGL loader requires that certain files are served in a specific way, contrary to the default web-server configurations.
From the forums:

When hosting such a build on a server, the following http headers should be added to the server responses in order to make the build load correctly:

  • .gz files should be served with a Content-Encoding: gzip response header.
  • .br files should be served with a Content-Encoding: br response header.
  • .wasm, .wasm.gz or .wasm.br files should be served with a Content-Type: application/wasm response header.
  • .js, .js.gz or .js.br files should be served with a Content-Type: application/javascript response header.

The Apache configuration example makes it even clearer:

<IfModule mod_mime.c>
# The following lines are required for builds without decompression fallback, compressed with gzip
RemoveType .gz
AddEncoding gzip .gz
AddType application/octet-stream .data.gz
AddType application/wasm .wasm.gz
AddType application/javascript .js.gz
AddType application/octet-stream .symbols.json.gz

# The following lines are required for builds without decompression fallback, compressed with brotli
RemoveType .br
RemoveLanguage .br
AddEncoding br .br
AddType application/octet-stream .data.br
AddType application/wasm .wasm.br
AddType application/javascript .js.br
AddType application/octet-stream .symbols.json.br

# The following line improves loading performance for uncompressed builds
AddType application/wasm .wasm


The easiest way to serve the Unity3D WebGL files via AWS CloudFront from an AWS S3 origin with the correct configuration is to set the correct Content-Type and Content-Encoding in the S3 bucket. Then CloudFront serves them to the user with the correct configuration directly.

To achieve this, one can set the correct metadata of the files via the AWS S3 management console: Select the file, open the “Actions” menu, select “Change metadata”, set the metadata in the opening pop-over on the right-hand side.

Screenshot: AWS S3 console with opened edit view for file metadata

At one point I wrote a small helper script in Python, using boto3, to set the correct metadata after I uploaded the files manually:

The Process Of Design Squiggle by Damien Newman, thedesignsquiggle.com (CC BY-ND 3.0 US)

Damien Newman versucht mit The Design Squiggle den unklaren, kreativen Prozess des Gestaltens hin zu einem konkreten Ergebnis zu beschreiben:

The Design Squiggle is a simple illustration of the design process. The journey of researching, uncovering insights, generating creative concepts, iteration of prototypes and eventually concluding in one single designed solution. It is intended to convey the feeling of the journey. Beginning on the left with mess and uncertainty and ending on the right in a single point of focus: the design.

So as I pursued my own career in design, I began to write proposals and pitch the process of design using the terms: Abstract, Research, Concepts and then Design.

2009 schrieb er zur Entstehung:

Years ago I dropped a simple illustration into a proposal to convey the design process to a client. It was meant to illustrate the characteristics of the process we were to embark on, making it clear to them that it might be uncertain in the beginning, but in the end we’d focus on a single point of clarity. It seemed to work. And from then on, I’ve used it since. Many many times.

(via Daring Fireball)

Heute gab es auf einer von mir betreuten Website mit MODX ein merkwürdiges Problem: Die Startseite sowie alle weiteren Unterseiten waren plötzlich weiß und zeigten keine Inhalte mehr an – der Zugang zum Backend lief aber zum Glück noch.

Auf der Suche nach der Ursache wollte ich zunächst ins Fehlerprotokoll gucken, aber die Seite im Backend lud sich endlos selbst neu, da das Error-Log zu groß war: 1,1 GB!

Per FTP auf dem Server angemeldet, das Fehlerprotokoll, /core/cache/logs/error.log, heruntergeladen und auf dem Server gelöscht.
Die Startseite und alle Unterseiten waren daraufhin wieder erreichbar – Symptom behoben, aber die Ursache noch nicht.

Beim Surfen durch die Seite füllte sich das Fehlerprotokoll innerhalb weniger Minuten wieder, je nach Unterseite mit vielen Bildern sogar um einige MB pro Seitenaufruf, sodass das Log schon nach kurzer Zeit wieder bei 10, 30 und 80 MB war.

Die Ursache für das große Error-Log war das Modul phpThumb(), das reihenweise Fehlermeldungen wie folgende generierte:

[2018-03-15 13:20:18] (ERROR @ /mnt/web###/##/##/########/htdocs/project/website/core/components/phpthumbof/model/phpthumbof.class.php : 156) [pThumb] Resource: 1 || Image: /home/strato/http/premium/rid/##/##/########/htdocs/project/website/assets/gallery/12/126.jpg  
Could not generate thumbnail
phpThumb debug output:
	[0] => phpThumb() v1.7.14-201608101311 in file "phpthumb.class.php" on line 229
	[1] => setSourceFilename(/home/strato/http/premium/rid/##/##/########/htdocs/project/website/assets/gallery/12/126.jpg) set $this->sourceFilename to "/home/strato/http/premium/rid/##/##/########/htdocs/project/website/assets/gallery/12/126.jpg" in file "phpthumb.class.php" on line 294
	[2] => $AvailableImageOutputFormats = array(text;ico;bmp;wbmp;gif;png;jpeg) in file "phpthumb.class.php" on line 969
	[3] => $this->thumbnailFormat set to $this->config_output_format "jpeg" in file "phpthumb.class.php" on line 980
	[4] => $this->thumbnailFormat set to $this->f "jpeg" in file "phpthumb.class.php" on line 987
	[5] => $this->thumbnailQuality set to "75" in file "phpthumb.class.php" on line 997
	[6] => resolvePath: /home/strato/http/premium/rid/##/##/########/htdocs/project/website/assets/gallery/12/126.jpg (allowed_dirs: Array
) in file "phpthumb.class.php" on line 1140
	[7] => resolvePath: iteration, path=/home/strato/http/premium/rid/##/##/########/htdocs/project/website/assets/gallery/12/126.jpg, base path = /mnt/web###/##/##/########/htdocs/project/website in file "phpthumb.class.php" on line 1159
	[8] => resolvePath: stop at component 4 in file "phpthumb.class.php" on line 1175
	[9] => resolvePath: stop at path=/home/strato/http/premium in file "phpthumb.class.php" on line 1178
	[10] => resolvePath: no match, returning null in file "phpthumb.class.php" on line 1180
	[11] => !$this->config_allow_src_above_docroot therefore setting "" (outside "/mnt/web###/##/##/########/htdocs/project/website") to null in file "phpthumb.class.php" on line 1344
	[12] => $this->sourceFilename set to "" in file "phpthumb.class.php" on line 894
	[13] => phpThumb() v1.7.14-201608101311

Error messages disabled.

edit phpThumb.config.php and (temporarily) set
$PHPTHUMB_CONFIG['disable_debug'] = false;
to view the details of this error in file "phpthumb.class.php" on line 4126
	[14] => resolvePath: /home/strato/http/premium/rid/##/##/########/htdocs/project/website/assets/gallery/12/126.jpg (allowed_dirs: Array
) in file "phpthumb.class.php" on line 1140
	[15] => resolvePath: iteration, path=/home/strato/http/premium/rid/##/##/########/htdocs/project/website/assets/gallery/12/126.jpg, base path = /mnt/web###/##/##/########/htdocs/project/website in file "phpthumb.class.php" on line 1159
	[16] => resolvePath: stop at component 4 in file "phpthumb.class.php" on line 1175
	[17] => resolvePath: stop at path=/home/strato/http/premium in file "phpthumb.class.php" on line 1178
	[18] => resolvePath: no match, returning null in file "phpthumb.class.php" on line 1180
	[19] => !$this->config_allow_src_above_docroot therefore setting "" (outside "/mnt/web###/##/##/########/htdocs/project/website") to null in file "phpthumb.class.php" on line 1344
	[20] => SetCacheFilename() _src set from md5($this->sourceFilename) "" = "d41d8cd98f00b204e9800998ecf8427e" in file "phpthumb.class.php" on line 3520
	[21] => SetCacheFilename() _par set from md5(_farC_w970_dpi150_q75) in file "phpthumb.class.php" on line 3553
	[22] => starting ExtractEXIFgetImageSize() in file "phpthumb.class.php" on line 3314
	[23] => skipping getimagesize() because $this->sourceFilename is empty in file "phpthumb.class.php" on line 3326
	[24] => getimagesize("") failed in file "phpthumb.class.php" on line 3357
	[25] => $this->useRawIMoutput=true after checking $UnAllowedParameters in file "phpthumb.class.php" on line 1595
	[26] => ImageMagickThumbnailToGD() aborting because $this->sourceFilename is empty in file "phpthumb.class.php" on line 1640
	[27] => ImageMagickThumbnailToGD() failed in file "phpthumb.class.php" on line 3364
	[28] => SetOrientationDependantWidthHeight() starting with ""x"" in file "phpthumb.class.php" on line 3293
	[29] => SetOrientationDependantWidthHeight() setting w="970", h="0" in file "phpthumb.class.php" on line 3309
	[30] => EXIF thumbnail extraction: (size=0; type=""; 0x0) in file "phpthumb.class.php" on line 3421
	[31] => starting SourceImageToGD() in file "phpthumb.class.php" on line 3679
	[32] => Not using EXIF thumbnail data because $this->exif_thumbnail_data is empty in file "phpthumb.class.php" on line 3751
	[33] => $this->gdimg_source is still empty in file "phpthumb.class.php" on line 3803
	[34] => ImageMagickThumbnailToGD() failed in file "phpthumb.class.php" on line 3805
	[35] => phpThumb() v1.7.14-201608101311

Error messages disabled.

edit phpThumb.config.php and (temporarily) set
$PHPTHUMB_CONFIG['disable_debug'] = false;
to view the details of this error in file "phpthumb.class.php" on line 4126
	[36] => SourceImageToGD() failed in file "phpthumb.class.php" on line 374

»Could not generate thumbnail« war zunächst das Offensichtlichste und Verständlichste an der Fehlermeldung. Eine Google-Suche danach brachte nur ein Ergebnis, dass leider keine Lösung aber einen wichtigen Hinweis lieferte: Irgendetwas stimmt mit den Pfaden zu den Bild-Dateien nicht.

In der Haupt-Konfigurationsdatei /core/config/config.inc.php fiel mir bereits auf, dass es zwei absolute Pfade gibt (Zahlen/IDs durch »#« ersetzt):

  1. /home/strato/http/premium/rid/##/##/########/htdocs/project/website/
  2. /mnt/web###/##/##/########/htdocs/project/website/

Diese waren verschiedenen Einstellungen zugeordnet; jedoch ohne erkennbaren Grund, warum die erste Variante bei der einen Einstellung und die zweite Variante bei einer anderen. Bei anderen MODX-Websites bei anderen Hostern, wie All-Inkl.com oder Uberspace, sind die Pfade bei allen Einstellungen identisch.

Strato nutzt zwei absolute Pfade für Websites. Einmal den, ich nenne es mal, »offiziellen« /home/strato/http/premium/rid/##/##/########/htdocs/; und den »inoffiziellen« (wahrscheinlich physischen) Pfad /mnt/web###/##/##/########/htdocs/.
Ein Blick in die PHP-Konfiguration zeigt auch: der erste Pfad steht auch in den üblichen Server-Variablen wie _SERVER["DOCUMENT_ROOT"]; der zweite Pfad tauch in – für mich bisher ungewöhnlichen – Server-Variablen wie _SERVER["RZ_path"] auf.

Nach einigen Versuchen und wiederholtem Lesen jeder Zeile der Fehlermeldung, war schließlich klar was genau die Ursache für die Fehler-Tirade ist: phpThumb arbeitet mit dem zweiten, »inoffiziellen« Pfad, bekommt aber von MODX die Pfade zu den Bild-Dateien in der ersten, »offiziellen« Variante. Und dann, beim »auflösen« der Pfade passiert das, was in den Zeilen 7–11 bzw. 15–19 der Fehlermeldung steht: phpThumb verlässt den Bereich, den es lesen darf (docroot also Document Root) und findet die Bild-Datei nicht – denn für phpThumb sind diese beiden Pfade nicht identisch und kann sie nicht, wie anscheinend Strato, synonym verwenden.

Die Lösung ist also, die Pfade an phpThumb anpassen: in der /core/config/config.php und der /connectors/config.core.php alle Pfade auf die zweite Pfad-Variante umstellen, schon findet phpThumb die Bild-Dateien und die Fehlermeldungen hören auf.

Photo des Spielfelds des Cityspiels Wuppertal

Bei der Finisage der Ausstellung »Stoffwechsel: Hofaue im Dialog« spielten wir gestern Abend das Cityspiel Wuppertal aus dem Jahr 1994, herausgegeben von David Marketing – eine zähe Runde. Das Spiel ist eine krude Mischung aus bekanten Spiele-Mechaniken: Monopoly, Mensch-ärgere-dich-nicht, Schiffeversenken, …

Ziel ist es, die vier Elemente seiner Logos von (bekannten) Wuppertaler Firmen und Institutionen auf möglichst wertvollen Wuppertaler Grundstücken zu platzieren. Die Regeln, auf knappen zwei Seiten erklärt, lassen allerdings viele Unklarheiten zurück; die beiden Würfel würfelten unnötig oft 1 und 2. Irgendwann kürzten wir es ab auf »wenigstens ein Logo fertigstellen«.

Detail-Photo vom Spielfeld mit vier fast fertigen Logos

Gewonnen hat am Ende übrigens die Bergische Universität Wuppertal (die im Spiel noch Bergische Gesamthochschule Wuppertal heißt).

Delivered In Beta von KS12.

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.


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.


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.


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.


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:


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.


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, also 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 für mich wichtigsten Funktionen in einem Starter-Theme für den schnellen Start in die Entwicklungs 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 sein Design hinzugeben muss. Außerdem nimmt wp-blank die 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 Code 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:


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 auf dem Desktop zu einem hohem CPU-Verbrauch durch den Finder führen können, 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.

Screenshot: Darstellungsoptionen von 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.