I'm cross-posting content to all major social media platforms (via Buffer). Let's connect!

– Twitter: https://x.com/konstruktors
– Bluesky: https://bsky.app/profile/kaspars.net
– Threads: https://www.threads.net/@wpelevator

There is a beautiful blogging platform Bear. https://herman.bearblog.dev/building-software-to-last-forever/

Responded to @kasparsd:

Here is the issue: https://github.com/moby/moby/issues/25526

This week I learned that Docker Swarm has a major bug where it fails to forward the HTTP request IP to the containers. This leads to incorrect IP attribution in the logs and servers thinking the request came from an internal/private IP. No wonder there are so many attempts at creating something between Docker Compose and k8s.

I'm trying out the stale-while-revalidate approach with WP object cache — whenever the main cache entry expires, it attempts to serve a stale version and schedules an update on the shutdown hook after flush()-ing output. Almost like async PHP 😅

Turns out you don't need to extract a ZIP file to rename a directory inside it. I'm adding GitHub sync to the Update Pilot Server and it will handle this automatically. One nuance is that you have to move all entries that are under that directory individually.

Responded to @kasparsd:

The vendor name could also be the reverse hostname such as `com.vendor-name` like iOS and Android apps do for namespacing.

Here is the full report: https://gist.github.com/kasparsd/f5e1544f3eb14023b1f3c34c2ead35ef

Did you know that all WP ZIPs have a directory inside them matching the plugin/theme slug? They are used for the respective plugin or theme directories during install and update. With distributed update servers, I propose we prefix them with "vendor-name." (including the dot).

Here is the first draft for the Update Pilot Server landing page. All feedback is much appreciated! https://wpelevator.com/plugins/update-pilot-server

The Update Pilot client plugin uses the official WP core UpdateURI feature for plugin and theme updates from external sources. Can you think of a reason why the plugins and themes from the same vendor (as identified by the UpdateURI hostname) should have seperate fields for product update keys?

Here is an example of when unit tests could have uncovered the issue. WP REST callbacks are easy to test. https://www.wordfence.com/blog/2024/11/really-simple-security-vulnerability/

Today the Update Pilot client plugin updated itself from the Update Pilot Server over WP REST API 💪🚀

Looks like Jetpack Boost is now adding Photonized image URLs to post content. I believe it was never the intention and it started happening with the block editor REST calls not being is_admin().

Who thought I would be using Euclidean math to calculate the human-readable aspect ratio of image dimensions. That one pixel drift check is mine, though 😅

For some reason the image block doesn't persist the width and height in the post content so WP attempts to resolve them by the image filename. These same dimensions are used to calculate the matching srcset. With Photon-like capabilities this leads to a lot of custom parsing since those filenames are always the same.

Here is the Jetpack Boost onboarding experience. You can't use the plugin without sending all the site data to WP-com. And the declaimer about the site sync is below the fold.

I can't believe that Caddy doesn't support any kind of caching controls out of the box. Even for a local development environment this isn't acceptable. Please correct me if I'm wrong.

This Docker images from WP VIP are some of the nicest and cleanest I've ever seen. https://github.com/Automattic/vip-container-images

Is there a static site generator that also bundles a webserver with local CMS for CRUD operations?

I really wish we could swap out the WordPress image size setting for just the aspect ratio selector and have all the responsive sizes be generated dynamically. How do you approach these settings on your sites?