In a new post to his site Joe Ferguson has included a screencast showing how to add MySQL 8 support to Laravel Homestead for your local development.

My friend Beau Simensen has been doing awesome stuff building and streaming his work on astrocasts.com. He’s inspired me to start streaming again and last night I spent some time adding a feature to Laravel Homestead to add MySQL 8 as an option.

In the video Joe walks through the whole process including how Homestead is set up (via Vagrant) and all of the configuration changes you'll need to make to get MySQL 8 support up and running. The video runs about an hour and a half but it's a great resource if you're looking to use this latest version of MySQL in your application.

On the AWS Developer Blog they've posted an announcement about the release of support for Amazon S3 Select in the AWS SDK for PHP. This "select" functionality allows for more powerful queries on the contents currently in your S3 buckets.

We’re excited to announce support for the Amazon Simple Storage Service (Amazon S3) SelectObjectContent API with event streams in the AWS SDK for PHP in version 3.67.11. Using Amazon S3 Select, you can query for a subset of data from an S3 object by using simple SQL expressions.

Amazon S3 streams the responses as a series of events, instead of returning the full API response all at once. This enables your applications to process the parts of the response as the application receives them. To support this new API behavior, the AWS SDK for PHP supports processing these events from the API response.

The post goes on to give a few examples of the use of the "select" functionality, querying the contents of a CSV file using the familiar SQL format. Example code is also included using the SelectObjectContent and EventParsingIterator to select and retrieve the results.

Tomas Votruba has a new post to his site about an update that's been made on Statie, a static site generation tool, to support Twig templates natively.

Statie supports YAML and Symfony Dependency Injection for some time. But you wanted more! You wanted Twig. Sculpin and all the other PHP generators have it.

So there you go! Enjoy.

He shares the three steps needed to set up a sample Twig template and have it rendered as easily as the normal Statie templates:

1. Prepare Layout _layouts/default.twig
2. Create Template contact.twig
3. Enable Twig

Template contents and configuration change examples are included as well as instructions on how to update to this latest (v5.4) version. He includes tips on the naming and locations of the template files as well as a mention of his package to help translate from Latte to Twig templates.

StarTutorial.com has posted a new tutorial in their series introducing commonly used design patterns. In their latest article they cover the State pattern.

[The State pattern] allows an object to alter its behavior when its internal state changes. The object will appear to change its class.

In the example situation, a worker at a customer support company and his state when dealing with customers (happy/angry/moderate). They codify this in a SupportRep class with a "state" value to track his mood. They expand on this with some additional conditions for number of calls to change the state as time goes on. This requires several if/else statements to be added. They refactor this to reduce the clutter using the State pattern, passing off the logic to various "state" classes.

Matthew Weier O'Phinney has made a post on the Zend Framework blog about the release of PHP 7.2 support for Zend Expressive, now in version 3.

With Expressive 3 complete, we were able to turn our sights on another important initiative: PHP 7.2 support across all components and Apigilty modules.

The short story is: as of today, that initiative is complete! If you are using the Zend Framework MVC framework, Expressive, or Apigility, or any of the ZF components standalone, you should be able to perform a composer update to get versions that support PHP 7.2.

The full story is much longer.

He starts with a look at the path to get to PHP 7.2 support including the considerations for not breaking backwards compatibility as much as possible. He then moves on to the approach they took with changes to the Composer and Travis-CI configuration changes to make it easier to run the tests on multiple PHP versions (with multiple PHPUnit versions too). The post ends with a look ahead at four things coming soon including a PSR-7-based zend-mvc v4, work on the documentation and more tutorials/guides to help devs make the most of Zend Expressive.

On the Delicious Brains site they have a new post that makes a suggestion to the WordPress plugin developers out there: stop supporting legacy versions of your plugins and move on.

I recently saw this tweet from Danny van Kooten which reminded me of one of the many major gripes developers have with WordPress – supporting ancient PHP versions:

"STOP SUPPORTING PHP 5.2 IN YOUR NEW PROJECTS. No one using it is actively installing plugins, trust me."

Yes, (unbelievably) WordPress still supports installations of PHP 5.2.4! As plugin developers, we can’t change that over night but we have the power to stop supporting these legacy versions in our plugins where we have control over the codebase.

He talks about how, despite the fact that the WordPress project itself strives for ultimate backwards compatibility, it's just not run on older versions of PHP as much. They share some statistics about the number of WordPress installs on each version of PHP starting with v5.2. The results show that the overwhelming majority are on v5.6 with a split between <=5.3 and >=7.0 for the remainder. They also share some statistics from their own plugins finding that the >=7.0 takes the lead.

The post then shares some of the reasons for making the upgrade to only support newer versions of the language including security updates, speed and developer experience. It finishes up with some of the steps to follow to inform users of the intent to deprecate old support and when to make the move.

The HHVM project has made an announcement on their site about the latest update for the PHP language processor, v3.24 and how, among the list of changes, they're completely dropping support for PHP 5.

HHVM 3.24 is released! This release contains new features, bug fixes, performance improvements, and supporting work for future improvements. [...] 3.24 is the final release targeting PHP5; this includes source-level compatibility for PHP5 extensions (ext_zend_compat). We recommend migrating to Hack or PHP7.

As 3.24 is supported though 2018-12-17, this means that support will end at roughly the same time as PHP5 itself is scheduled to become unsupported (2018-12-31).

Other updates in the release include the retiring of support for Debian 7 Wheezy and Ubuntu 17.04 Zesty, the inclusion of "using" blocks and the addition of the XHP Attribute Spread Operator. You can find out complete details about this release from the HHVM blog.

In a post to his site Brandon Savage shares some of his thoughts about PHP package development and suggests how to figure out what versions of the PHP language it should support.

Everybody likes “the new hotness.” [...] Perhaps, then, it shouldn’t be so surprising that people get tremendously excited when a new version of PHP comes out. People look forward to the new features, whether they be the trailing commas in list() syntax or counting of non-countable objects.

[...] A new version of PHP can pose challenges to open source package maintainers. There are questions, like what is the minimum version we will support and how soon can we take advantage of the new features we’ve been waiting on? I want to offer up some thoughts, both as a package maintainer and a user of many open source packages.

He goes on to suggest that package authors should support down to the last currently supported version of the language (v5.6 at the time of this post). This allows users of the package that may be restricted and don't have the "new hotness" to keep using the package. He points out that this doesn't mean that you shouldn't use new features, just that older versions should be supported along with the newer ones for those depending on the package. He makes three suggestions as to how he thinks package maintainers should approach the issue:

• maintainers should feel comfortable in bumping up the requirement to the latest (in a major release)
• maintainers should also ensure that the support is still there for older versions that can't use the newer features
• maintainers should bump up this minimum version when it falls out of active support

Supporting old versions of a language isn’t fun and isn’t glamorous. But it’s important. It’s important because there’a segment of the population who can’t upgrade yet. It’s important to make components accessible to a larger, broader audience who is struggling to find best practices and use modern packages. And it’s important for those users who are tied to a legacy version, and are struggling to get upgraded. But it’s the right thing to do for the community.

Fabien Potencier has a new post to his site covering the addition of support for private repositories to the features Symfony Flex provides.

Many Flex early adopters asked for it. The Symfony Flex server now supports private recipes repositories as announced during my keynote at SymfonyCon Cluj.

Creating a repository for your private recipes is easy. Create a regular Github repository (probably a private one) to store the recipes. The directory structure is the same as for the official Flex recipes repositories. Then, register the repository as a recipes repository. Done.

The private repositories will behave just like the other public ones in your application. You can also use them to override aliases. There are a few differences between public and private, however, like auto-merge not being supported.

In a new post to his site Derick Rethans talks about the new DateTime support in MongoDB and includes some PHP examples showing the changes in action.

In the past few months I have been working on adding time zone support to MongoDB's Aggregation Framework. This support brings in the timelib library that is also used in PHP and HHVM to do time zone calculations.

He then splits the rest of the post up into parts for the changes that this integration brings:

• Time Zone Support for Date Extraction Operators
• The $dateToParts Operator
• The $dateFromParts Operator
• Changes to the $dateToString Operator
• The $dateFromString Operator
• Using Date Expressions in $match

The post ends with a few notes about these changes, noting that it's currently only in the development release and "should be considered experimental" and subject to change. He then points out a few issues that will probably require updates to these features.