During the development of CakePHP, we also wanted to update migrations to be compatible. However, we had stumbled into a tedious dependency graph. Currently phinx relies on cakephp/database. While cakephp/migrations depends on phinx. In order to do a major release on cakephp/migrations (to provide CakePHP 5.

As I use webcomponents more, I found myself wanting a way to define the HTML for webcomponents with a non-trivial amount of light DOM contents in a more reusable programatic way. So far, I’ve found that modelling webcomponents as template fragments is a reasonably ergonomic solution. It enables usage such as:

When re-building docket with htmx, I wanted to retain the confirm dialog experience I had with react. Instead of taking on a dependency for this, I chose to build my own combining HTMX and Webcomponents. The resulting UX feels snappy and similar to a client rendered experience. My end result looks like this:

I wanted to share a CSS and webcomponent layout that I’ve been pretty happy with in a few projects. With webcomponents now widely supported, I was able to remove one of the last bit of inline scripts I had left in docket converting it to a webcomponent. The layout offers a layout with a 250px sidebar and content area.

After updating docket to use htmx, I wanted to share my experience. First and most important, HTMX is more than just a client side framework. Instead of using a JavaScript library to render your application in the browser, you have incrementally load HTML as your application’s state changes.

Webcomponents are starting to get more traction now that they are fully supported across browsers. I have recently been rebuilding my personal todo list software Docket with HTMX and Webcomponents.

I recently came across this video on Youtube and while the author makes some convincing arguments for using bitfields. I’d like to share my experiences having worked with them in a few applications. A long time ago, I also thought that bitfields were neat.

I’ve been working on content for my CakeFest workshop this year, and thought it would be interesting to see a commonly used authorization pattern implemented as an extension to CakePHP’s authorization system. The pattern I wanted to implement was ‘sudo mode’. Often this pattern is used in applications that have longer session duration.

I have been following the Webauthn standards and browser support since the early days of FIDO compatible keys. I strongly believe that hardware keys are our best path forward to provide phishing resistant, easy to operate authentication, that doesn’t compromise on privacy.

I recently decided to go down a rabbit hole of wanting to learn a new client side library. I was interested in learning more about libraries that aimed to have a minimal footprint even at the cost of providing a more modest API. For this site I have simple requirements, and I wanted to see how simple the ‘simple’ abstractions are these days.

Modern PHP development generally means using a suite of tools to perform code formatting and static analysis. For a long time, I have been using composer to install theses developement tools. While using composer works great, when you’re working on multiple projects it results in duplicate copies of frequently used tools.

Each year I try to learn a new language, framework or technology. This practice encourages me to continuously learn new skills and be a newbie again. This year, I’ve spent the past few months working on a mobile client for Docket . While the mobile web UI works well enough, I wanted to see if the UX could be smoother with a native application.

During my workshop at Cakefest 2022 I covered the new content-type negotiation features shipped in CakePHP 4.4. I wanted to share that information here so it is more easily found in the future.

I do all of my day to day work in vim, specifically NeoVim . One of my favorite plugins as of late has been the CoC plugin. CoC provides language server integrations, autocompletion, linting, and formatting all in one easy use package.

In part 1 I covered the physical/mechanical design of my keyboard project. In this post we’ll dive into the electrical design and touch on firmware development.

Like many others, I’ve been exploring new hobbies and learning new skills as the pandemic continues to keep many of us at home. Lately, I’ve been exploring building custom mechanical keyboards.

Over the last month, I’ve been building a ‘fun’ project that uses CakePHP, TypeScript and React. While I maintain AssetCompress it is poorly suited for react or vue applications.

While looking at performance data for Stickler CI, I noticed that some reviews spent a surprising amount of time talking to the GitHub API. While Stickler CI spending a large amount of time talking to GitHub isn’t that shocking, what caught my interest was the amount of time spent fetching modified files.

Upgrading major libraries that your application depends on can be a tedious and time consuming process. Dealing with deprecations and backwards incompatible changes can consume a significant amount of time and energy. In the past we’ve relied on manually updating code or using find and replace. But in last few years new techniques have emerged that make routine upgrades easier to do.

A few weeks ago I ran into a tricky to solve issue in CakePHP. It involved an iterator that needs be grown during iteration, and nested loops over that same iterator. While infrequent, there are scenarios where you would want to grow an iterator as it is being iterated. My situation is the plugin registry for CakePHP. Plugins support a bootstrap hook method that is used to initialize a plugin.