Composer Timeouts

Das fette Statamic CMS auf meinem HP laufen zu lassen, brauchte einige Fixes und Stunden. Von PHP curlProblemen bis node finfo errors war alles dabei – in und außerhalb von Laragon ging es am Ende.

Zuerst mein Github Token gesetzt
, dann brauchte cURL eine Defintion der .pem, was Laragon intern schon erstellte aber in meinen chocolatey nachgetragen werden musste (auch fileinfo und exif Extensions).

[curl]
; A default value for the CURLOPT_CAINFO option. This is required to be an
; absolute path.
curl.cainfo = "C:\laragon\etc\ssl\cacert.pem"

Ich bekam trotz Setzen höherer timeouts immer einen exit nach 60s mit composer. Andere hatten anscheinend auch das Problem. Das Setup ging mit dem „Peak“ Starter-Kit einfach nicht.

composer -V
composer self-update
composer config --list --global

Alles zeigte OK – auch 600s timeout per Env.

composer global update statamic/cli

Ich installiert esomita lels in mehreren Schritten und bekam die Sache wohl so hin, wie gedacht.

composer update
php artisan key:generate
php please make:user
php please starter-kit:install studio1902/statamic-peak

Die Installation war also nicht so einfach, der Editor macht dagegen einen guten Eindruck. Alles sieht dank Laravel recht professionell aus aber hat auch eine menge Balast. Wenn man bedenkt, was da alles installiert wird… Ca. 200MByte, nur um die HTML Sachen (und Socials) zu generieren. Wenn man da Hugo sieht, wie viel schneller und leichter da alles geht – nur ist das eben ein SSG. Statamic scheint aber auch langsam. Die Blog Artikel, die dessen Geschwindigkeit loben, konnte ich nicht nachvollziehen. Man muss wohl immer half oder full cache nutzen. Dann stellt sich die Frage, warum man überhaupt das Ding statt Hugo dann nutzt, wenn man am Ende doch nur statische Seiten ausliefert. Hier war viel falsches Marketing dabei, denn WordPress ist im default Zustand mit Sicherheit schneller.

Das Flatfile Dateinformat ist nett aber eben alles YAML mit .md Endung, sobald man den Block Editor nutzt. Insofern zwar nachvollziehbar aber eben doch nicht ganz so geeignet für meine Zwecke. Dabei sah ich, dass erst Ende September dynamic folders eingebaut wurden. Nach so vielen Jahren eine Funktion, die ich auch als extrem wichtig sehe. Ich will ja jede einzelne Post in einem container, weil da viele Daten gemischt werden: Video, Thumbs, Bilder, GPX. So richtig bin ich also noch nicht von dem Teil überzeugt. Hugo nervt, weil es keine partial rebuilds schafft. Angesichts der Geschwindigkeit kann man das aber vielleicht verschmerzen.

Ich denke nun, dass doch der pydanny Blog als Basis für den Anfang das beste ist. Das ist quasi auch alles flatfile-Basiert aber mit 1-2000 Seiten und RAM cache vielleicht die einfachste Lösung. Jetzt Laravel zu lernen, lohnt sich für eine Site nicht. Ich werde bei Gelegenheit mehr it Statamic machen, weil es eben als flexible WP-Alternative für Solo preiswert ist. Mit Python komme ich aber vielleicht schneller an’s Ziel, wenn ich mir meine eigenen Blöcke in Markdown definiere. Hugo und Python kann man sicher auch mixen, wenn ich Hugo-generierte JSONs in Python lade. Ansonsten besser keine Speed-Optimierungen für 0 Nutzer.