On The Bakery (the CakePHP site) an official announcement has been posted welcoming Phinx to the CakePHP family. The Phinx library is a popular tool for framework-agnostic database migration handling.

We are very excited to announce that Phinx has joined the CakePHP team. The Github project has already been moved to the CakePHP organisation. The project itself will stay MIT-licensed but be gradually transformed into a Cake Software Foundation project. Other great news is that the current way to install and update Phinx remains unchanged.

As you are aware, CakePHP has been using Phinx since 3.0.0 for database migrations. The CakePHP Core team welcomes the opportunity to look after and maintain the project and will now start making changes to bring the code in line with the CakePHP (our) coding standards. As well as cleaning up issues and PR’s soon. We will be following up with our plans for the code and setting roadmaps in the coming weeks.

Rob Morgan, the original author of the library has also added some of his own commentary in a post to his site:

I’ve been busy lately. Juggling startups and open source work is no easy feat. I managed to do it for the past 5 years, but beyond 30 its proving to be more difficult. Phinx is not accelerating at the pace I’d like it to be. In fact so far this year we’ve only managed to ship 6 releases. I decided that the best strategy moving forwards is to find a new home for Phinx. One that has an active and loyal community and one that delivers great software. I’m pleased to announce that I’ve found the right fit.

He points out that the only real thing changing for now is the location of the repository. He looks back on the journey that got him and the project to where it is today and how much the support from the PHP community meant during that time.

The Symfony Finland blog has posted a guide with a simple frontend workflow for those working in Symfony-based applications. He shows how to easily integrate and work with Gulp from inside of your application with relative ease.

In Symfony 2.7 the team introduced the asset component. It allows for a standard method for linking to front end assets in your bundles, but has no say in how assets are built. It is agnostic to whether assets are built with Gulp, Grunt, Webpack or some other tool.

[...] All files placed in the Resources/public -directory within a bundle is made available to the web server using a Symfony Command for assets install. Since Symfony 2.6 it has featured symlinking to the real asset directories, making the requirement to run the command limited to the times you add new bundles.

He shows how to use the assets component and its related commands to set up the symlink for a new bundle. He then helps you get the foundation command line tool installed and create a simple Gulp configuration file to build out your SASS files and compile them. From there using the setup is as easy as adding a tag to the Twig template, making a call to the asset method and pointing to the required resulting CSS file from the compile.

In his newest post Anthony Ferrara looks at some of the things he calls the foundations of object-oriented design, as set of three things (and principles) to keep in mind when working on OOP applications.

It's quite easy to mix up terminology and talk about making "easy" systems and "simple" ones. But in reality, they are completely different measures, and how we design and architect systems will depend strongly on our goals. By differentiating Simple from Easy, Complex from Hard, we can start to talk about the tradeoffs that designs can give us. And we can then start making better designs.

He starts with the "simple vs easy" concept and how sometimes making the two meet can be difficult. He includes an example of interdependent interfaces and how they add complexity (and, in turn, make them less easy to use). He also talks about accidental versus essential complexity and how, sometimes, "accidental" isn't always a bad thing. Finally, he wraps it up with a few principles to remember in your development including recommendations to reduce (accidental) complexity and keeping the target developers in mind, making it easiest for them to use.

PHPBuilder.com has posted a new article (an excerpt from the "Foundations of PEAR" book from APress) focusing on the authentication aspect and components PEAR has to offer.

After all, nearly all authentication is identical in its basic functionality, and there’s usually no good reason to spin off your own code if it’s already written for you.

They talk about three packages - the Auth package, Auth_HTTP, and the Auth_PrefManager. They describe the Auth package in depth in this article - common uses, related packages, required packages, what the constructor is like and descriptions of the functions the package provides.

PHPBuilder.com has posted a new article (an excerpt from the "Foundations of PEAR" book from APress) focusing on the authentication aspect and components PEAR has to offer.

After all, nearly all authentication is identical in its basic functionality, and there’s usually no good reason to spin off your own code if it’s already written for you.

They talk about three packages - the Auth package, Auth_HTTP, and the Auth_PrefManager. They describe the Auth package in depth in this article - common uses, related packages, required packages, what the constructor is like and descriptions of the functions the package provides.

DevShed starts up another series, a pair of tutorials seeking to help you create an extensible website engine in PHP 5. Basically, a slightly more complex setup than just pulling the content from a database into your application.

Over the course of this two-part series, I'll walk you through the development of a highly extensible and "pluggable" website engine with PHP 5, which will allow you generate web pages on the fly based on a predefined (but simple) database structure.

They start things off by setting up the core of the system - the layout and structure of how the pages will flow. To help make this an easy task, they also create the simple template with links down the side to the different "pages". Finally, they finish off this part of the series with the database structure and push some of the sample content in to give you an idea of how it's all formatted.

DevShed starts up another series, a pair of tutorials seeking to help you create an extensible website engine in PHP 5. Basically, a slightly more complex setup than just pulling the content from a database into your application.

Over the course of this two-part series, I'll walk you through the development of a highly extensible and "pluggable" website engine with PHP 5, which will allow you generate web pages on the fly based on a predefined (but simple) database structure.

They start things off by setting up the core of the system - the layout and structure of how the pages will flow. To help make this an easy task, they also create the simple template with links down the side to the different "pages". Finally, they finish off this part of the series with the database structure and push some of the sample content in to give you an idea of how it's all formatted.

Zak Greant has posted a series of items on his blog pertaining to the just passed php|works conference he attended. The topics range from eZ systems out to Mozilla. Here's the list:

• php|works 2006: Mozilla Report
• php|works 2006: Mozilla agenda
• php|works 2006: eZ Report
• php|works 2006: The eZ Plan
• php|works 2006: General Followup

Each of the posts summaries som eof his experiences at the conference (specifically in promoting eZ systems and the Mozilla Foundation), and a bit of the happenings following.

Zak Greant has posted a series of items on his blog pertaining to the just passed php|works conference he attended. The topics range from eZ systems out to Mozilla. Here's the list:

• php|works 2006: Mozilla Report
• php|works 2006: Mozilla agenda
• php|works 2006: eZ Report
• php|works 2006: The eZ Plan
• php|works 2006: General Followup

Each of the posts summaries som eof his experiences at the conference (specifically in promoting eZ systems and the Mozilla Foundation), and a bit of the happenings following.

Something's mentioned in this entry on Rami Kayyali's blog that no one in a community wants to hear - he gets the feeling that the PHP community is shrinking.

The PHP community is shrinking by the day, at least that's how I feel. I consider the community to consist of the extremely enthusiastic evangelists, those who make stuff instead of benchmarking them. We have a growing base of young developers who only need a small portion of PHP's capabilities and a shrinking base of developers who want to make things happen. We need chaos, not community rules. We need a CPAN, not a PEAR, a Smarty or a Zend Framework; these projects give me a feeling of being the "chosen" ones.

He preceeds this with a bit about his history with PHP, like how he used to feel when major updates were made. But somewhere along the line it got to be about something else - the debates between which was better (ASP vs. PHP, PHP vs. Java, etc), looking more at things like which quotes were faster, etc. Even the release of PHP5 couldn't make up for these community changes.

So, his suggestion is that we, as a community, stop worrying about if PHP is "enterprise ready" or competing with the wide array of other languages/environments out there and just get back to what PHP does best - getting back to its web development foundations where its real power lies.