The Laravel News podcast, hosted by Jacob Bennett and Michael Dyrynda, has posted their latest episode: Episode #64 - Babies, packages, and PHP 7.3.

In it Jacob and Michael cover several topics including:

• a Laravel view components package
• PHP 7.3's planned JSON error handling
• the PHP console tool for live code execution
• the release of PHP 7.3 alpha 1
• the Laravel Events announcement

You can listen to this latest episode either using the in-page audio player or by downloading the mp3 directly. If you enjoy the show, be sure to subscribe to their feed to get updates when new shows are released.

The Delicious Brains site has a tutorial posted showing you how to supercharge your WordPress development with the help of WP-CLI packages.

I think most developers would agree that my-hacks.php. It is my favorite way to set up new WordPress sites, control WordPress with CRON, manage plugins, quickly test code, and a whole host of other tasks that are quicker and easier to complete via the CLI or a shell script.

“What,” you might ask, “could possibly be better than WP-CLI?”. “A lot of things…” I would reply [...] but then I might catch myself and realize that your question was probably scoped to WordPress development and related tools so I would cough loudly and continue, “cough I mean… Packages… For WP-CLI. WP-CLI Packages”

The post then goes on to talk about the WP-CLI package index and some of the packages they like to use including:

• aaemnnosttv/wp-cli-login-command
• binarygary/db-checkpoint
• markri/wp-sec

Each includes a brief summary of what the package offers and a code example of it in use. The post ends with some unfortunate news, however - that the package index is essentially dead.

In a new post to his site Freek Van der Herten covers how some of the changes that happened in Laravel's v5.5 release would impact the packages Spatie shares, some of the more popular PHP packages with a wide range of functionality.

At Spatie we’ve released a auto-discovery facades functionality, LTS releases and how some new functionality replaces (retires) packages Spatie had already released.

Laravel 5.5 is probably the best release yet. But, in all honesty, I think that of every Laravel release. My recommendation is to get your apps upgraded to this version as soon as possible. The reward is that you can make use of all L5.5’s new features and the latest major versions of our packages.

Leonid Mamchenkov has put together a post for those out there trying to get started with workflows in PHP and offers some tips from his own experience.

For a large project at work, we need to integrate or develop a workflow engine. I worked a little bit with workflow engines in the past, but the subject is way to big and complex for me to claim any expertise in it.

So, I am looking at what’s available these days and what are our options. This post is a collection of initial links and thoughts, and it’s goal is mostly to document my research process and findings, and not to provide any answers or solutions yet.

He starts off by defining the requirements of the system he's looking for, both on the technology side and the functional side. He outlines his expected flow and then links to some other resources he found to help define common terminology and some of the standards he found. He found the BPMN v2.0 and tracked down several PHP packages that implement that workflow structure (all linked as well).

The Laravel News podcast has posted their latest episode today - Episode #21: Laracon Live Stream, Laravel 5.3 Collection Where Changes.

In this episode, we discuss Laracon Live Streaming, the new advanced where for Collections, and a few new apps and packages.

Other topics mentioned include the release of the first stable version of the OctoberCMS, the Laravel Password package and an article about anonymous functions. You can listen to this latest show either using the in-page audio player or by subscribing on iTunes or Google Play and also get future episodes as they're released.

Matthew Setter as a post on his site that suggests that microframeworks make for lean applications, such as one he recent built using the Slim framework.

Recently I built a new application using SlimPHP, a PHP microframework, instead of a full-stack framework, such as Symfony or Zend Framework 2. In this post, I start discussing how taking this approach has lead to a leaner application design. [...] Before I get too far along, I want to make one thing clear, I'm not bagging full-stack frameworks. [...] Technically, you don't need to bring in more than you need. However, often times, these frameworks still do have a lot of overhead which you may, typically, never need. [...] Whereas microframeworks, assuming they follow The MicroPHP Manifesto, especially SlimPHP, give you the minimum you need to start building a web application.

He goes on to talk about why he made the choice of Slim for his application and describes a bit about what the application does. He talks about some of his main needs when creating the site and how Slim matched up with most of them (with a little help from a few other packages). He included other libraries for YAML parsing, Markdown output formatting, caching and others to round out the application but Slim was at the heart of it. He ends the post by pointing out that taking this lightweight approach was a perfect fit for his project and that, while there were other choices, Slim fit his needs best.

Rafael Dohms has posted some if his own thoughts to his site about The League of Extraordinary Packages and why he supports their efforts to bring a good solid base of curated packages to the PHP ecosystem.

“The League of Extraordinary Packages” is what I have dubbed a collective of composer packages. Its essentially a group of developers who have gathered under a single flag (or in this case a vendor name) and set standards for the packages that live there.

Why does this even matter? Well for one Packagist is an open repository, this means that it is wide open for anyone to join, from the best packages to the most ridiculous ones. Quality control is not one of its roles and quality checking is on average 2-3 clicks per package away.

He talks about the quality control measures The League has in place to only contain good, well-tested and solid PHP packages. He also lists a few of his main reasons for supporting the effort including the fact that it reduces author fragility and provides an extended reach for those packages to reach a wider audience.

I really enjoy the work being done by The League, or The PHPLeague, or Pleague as I prefer to call it. I think it has provided us with some very good packages and given us all something to strive for. Maybe more collectives is what we need.

Phil Sturgeon has a new post to his site introducing a group that you may have heard about but aren't exactly familiar with who makes it up - the members of the League of Extraordinary PHP Packages (or just "The League").

A few months ago I wrote What is The League of Extraordinary Packages?, and it was clearly written in a defensive tone. I wanted to explain a few things about the League because people were attacking it in weird ways. We sat down as a group and discussed a plan for 2015 to solve this. A lot of cool ideas came up, the first of which was to make a Leadership Group. These people have been doing amazing things in the PHP community at large, and have been doing awesome things in the League too. This is an introduction to them, and a thank you for everything they do.

He introduces five members of The League and talks about which project they're associated with:

• Alex Bible
• Ben Corlett
• Kayla Daniels
• Frank De Jonge
• Jonathan Reinink

There's several other packages besides those mentioned here that make up the League's offerings, so be sure to take a look at the list and see if there's anything that might benefit you or your application.

In his latest post Phil Sturgeon talks about a project that's been running for a while, the The League of Extraordinary Packages and aims to clear up some recent misconceptions about the group and what they strive for in the projects they endorse.

This is the story of group of friends, who decided to write some code, but somehow confused and angered everyone with a keyboard. [...] Where should I release this code [I was super excited about releasing]? Should I release it with a vendor name of Sturgeon? That seemed rather egotistical. I could make something up, but what is the point of a single vendor with a single package? I wondered if any of my buddies were having this problem. [...] Being as hungover as I was, I thought long and hard, for about 5 seconds until something amazing happened in my brain... The PHP Super Best Friends Club! The guys loved it, and we started making plans immediately.

He goes on to talk about The League and some of the goals of the organization including the stated desire for quality code and a constant stream of work on the project (no abandoned or stale projects). He talks about how some of the rules for inclusion were created and some of the members of the various projects it includes. He then gets to the "recent misunderstanding" part of things with the clash of the League and the PHP-FIG (see here). He clears up some of the confusion in that thread by stating that:

• League != PHPClasses
• League != PEAR

He finishes off the post talking some about the leadership of the group (hint: it's an organization, not really run by a person or persons) and some of the work he's doing to ensure the future of the League and the packages it includes.

In a recent post to his site Matthias Noback looks at what he sees as the future of packages in PHP including some thoughts about the offerings on PHPClasses.org and the rise of Composer/Packagist.

When you ask me: what is the reason for a PHP developer to write classes? I answer: in order to separate responsibilities and hide data. Many principles have been devised to help developers fulfilling these tasks. But in most cases there was no sign of these principles underlying the code on phpclasses.org. This is why many people have turned their back on phpclasses.org. I was about to do the same. But in response to my tweet some people, including Manuel Lemos, responded that everybody needs a place to learn and try.

He looked a bit more into the PHPClasses site and found some new features not known about (including Composer support). He points out some issues with their approach about publishing packages and how they're released. He contrasts this with how Packagist.org handles the Composer information and package statistics. He looks at some recommended ways to judge the quality of packages and mentions a new book he's writing to help PHP developers create better, more useful (and flexible) packages.