[ Jump to content ]

arne.xyz

delivered in beta


ClassicPress 1.5.0 was released a few days ago with support for PHP 8. And this solves a lot of problems I had on this blog in the last few month: On the homepage was the title “Archive” visible, which should not be visible; and on my archive page nothing was shown at all—except for the title; and all I’ve got was mysterious error messages in the logs … Guess I should have better looked at the requirements (which are now, btw, a bit outdated), than I would have seen that I was using the wrong PHP version. Lesson learned.

So now I can start tinkering on this blog again and not try to hunt this weird behavior of ClassicPress.


This post is # 003 of 100 Days To Offload.

Just some days ago I saw a video of Linus Tech Tips about battery-draining standby modes of Windows laptops (and sometimes MacBooks).

Now I came across Sleep Aid (via Michael Tsai), a macOS tool to diagnose and solve standby aka. sleeping issues on Macs. From the blog post Hot Bag MacBook about it:

Have you ever travelled somewhere to find that your MacBook is nice and warm, with next to no battery left? If so, these are the common causes of a “Hot Bag MacBook” that we’ve found so far.

This could be handy.


This post is # 002 of 100 Days To Offload.

100 Days To Offload:

The whole point of #100DaysToOffload is to challenge you to publish 100 posts on your personal blog in a year.

Posts don’t need to be long-form, deep, meaningful, or even that well written. If there are spelling and grammar mistakes, or even if there’s no real point to the post, so what? What’s important is that you’re writing about the things you want to write about.

Your posts could be how-to guides, or links to another post you have found interesting. They could include your own thoughts about that post, or a response to it. It could be a simple update about what you have done that day. Tell us about your dog, your cat, your fish tank, or whatever hobbies you have. Someone will find it interesting.

Just. Write.

A few days ago I stumbled upon this: Writing 100 blog posts on my blog in 365 days—can’t be that hard, right?! Challenge accepted.


This post is # 001 of 100 Days To Offload.

Screenshot of the intersection of two Instagram story ads: the first is for Adobe Creative Cloud, the second for Affinity 2.0

The ad targeting of Instagram is on point again.

Cover von Adobe Flash CS5: Das umfassende Handbuch

Geöffneter Buchrücken mit DVD von Adobe Flash CS5: Das umfassende Handbuch

Verschenke mein Fachbuch Adobe Flash CS5: Das umfassende Handbuch aus dem Verlag Galileo Design (heute: Rheinwerk-Verlag) von 2010, inkl. DVD. Ohne Mängel, nur der Buchumschlag hat Gebrauchsspuren.

Ich kaufte es mir Ende 2011 für die Vorbereitung meiner Kurse für angehende Online-Redakteure, die etwas über Flash lernen sollten – heute taugt es nur noch für das moderne Antiquariat.

Das Buch kann sehr gerne bei mir in Wuppertal abgeholt werden. Versand ist auch möglich, wenn die Versandkosten in Höhe von 6,99 € (Paket bis 5 kg) übernommen werden. Anschreiben!


Bibliographische Informationen: Nick Weschkalnies & Sven Gasser: Adobe Flash CS5: Das umfassende Handbuch. Galileo Design, Bonn, 2010. ISBN-13: 978-383621-564-0. DNB: #1001391713.


Auch online bei: ebay, ebay Kleinanzeigen, nebenan.de


Update 11.12.2022: Das Buch hat ein:e neue:n Besitzer:in gefunden.

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
</IfModule>

On AWS

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
http://phpthumb.sourceforge.net

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
http://phpthumb.sourceforge.net

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).