No release, weekly updates, and 🔥 tip

No release

No release today with Taylor and Dries on vacation. There may be one later in the week when they return. If so, I'll highlight the updates in next week's post.

A reminder subscribers to a Shifty Plan automatically receive a PR bumping Laravel, as well as other packages, anytime there is a new release.

This automation is a nice way to stay up-to-date and periodically kick-off your CI builds. However, they're really just a bonus for subscribers. The main value of a Shifty Plan are the included Shifts, access to the Workbench, and webhooks.

Weekly Journal

Last week I had more Human Shifts. In the process of upgrading those applications, I found a bug in the Laravel 9.x Shift. Apparently for some projects the conversion to anonymous migrations was being skipped.

Over the weekend, I pushed a patch for this. However, since there's no way to rerun this for affected projects, I decided to make the automated task within the Workbench free.

So, if you're reading this, and you recently ran the Laravel 9.x Shift (or have a project you'd like run this automation on) you may run the Adopt anonymous migrations task within the cloud-based Workbench.

I also finished and deployed the code I worked on during my live stream last week. I plan to continue development on a related feature in my live stream tomorrow.

Yesterday, Saurabh and I finally finished adding a "team view" to the Shifty Plan dashboard. This allows any team member to see Shifts run by other team members. This was the last long-standing feature request from subscribers.

This week I'll continue squashing any additional tweaks I noticed during the recent Human Shifts, as well as pair with Jess to finish v1.0 of the Workbench desktop app.

🔥 Tip

During the recent Human Shifts I came across an interesting bug. An application was using policies with a before filter. However, I noticed the policy method being called did not exist.

What was confusing was the application was known to be running in its current version (Laravel 5.4). So I read the documentation which stated the before filter would not call the policy method if it returned true or false. Which it did.

After going down the rabbit hole of digging through the source code, I finally read the latest Policy documentation. For the most part, its content and example code were exactly the same. With the exception of the following note, which perfectly addressed my bug.

The before method of a policy class will not be called if the class doesn't contain a method with a name matching the name of the ability being checked.

So, when faced with an odd bug in Laravel, it's worth scrolling the respective documentation page and reading any of these important notes.