To my mind, that means that we can change how we look at the idea of a "framework" in PHP. The definition has always been pretty loose, but let's think of it as "a set of software components, designed to work together, from which we can pick and choose the functionality we need". That used to mean selecting a framework or CMS like Zend Framework, Symfony or Drupal, downloading an archive and picking the bits we needed of it, usually with a maze of require statements. Extending behaviour meant searching down third-party libraries, downloading and incorporating those, and hoping that the versions of the various libraries you happened to have played nicely together. This wasn't always particularly easy, reliable or enjoyable, and so it was often considered easier to write the required functionality in-house. And we've all spent more years than we want to think about in maintaining that type of application than we really want to think about.
Now, though, a number of inventions and initiatives have come along that give us an alternative. Distributed version-control systems such as Git and Mercurial, and broadly-available, trusted DVCS hosting providers such as Bitbucket and Github, mean we have a standard way of making source code available to end-users. These also give us a standard mechanism for collaboration and contribution of code via wikis, issue trackers and pull requests. Composer and Packagist give us a common vocabulary and resource locator for specifying dependencies and versions according to semantic versioning rules. Together, this means that we can specify our top-level requirements in a composer.json file, sit back and let composer serve us up our own custom codeset.
Of course, while all PHP code can be interoperable, some code is more interoperable than others. However this too has improved over the last few years, through two main mechanisms. The first is the emergence of widely used and reliable libraries and frameworks like as Symfony2 and Doctrine, which now underpin a wide range of projects, providing an implicit compatibility. The second is the work of the PHP Framework Interoperability Group to make compatibility explicit. So far they've normalised autoloading, code standards and logging, and look to be in the process of defining standards for documentation, caching and HTTP request and response access. Collectively, these mechanisms help extend the "Pick and Choose" mentality of a framework across the whole of the PHP ecosystem, and break down the silos that separate different named projects and frameworks.
To make the best of this, however, we also need to stop putting ourselves, and other developers, into silos. Companies and agents advertise for "Drupal Developers", "Symfony Developers" or "Zend Developers", and I'm not sure that either they nor I understand what those terms mean. These projects are all a combination of MVC framework and library; the model should be a matter of the company's own business logic, the view's usually based on either Smarty or Twig, the persistence layers tend to be fairly standardised, and the controller should really be lightweight and keep itself out of the way. If the libraries are well designed and interoperable, then the only things that should be specific to the framework in use should be configuration and routing (or hook mechanism). Once the project has passed its inception phase, the time or expertise needed for either of these mechanisms should be minimal, and we should be looking not for "framework specialists" but once more for "PHP developers".
It's for this reason that this site doesn't use a heavyweight framework such as Symfony2 - although it does have the flexibility to use all of the Symfony and Sension components. Adze, a minor extension to the lightweight Silex microframework, needs only minimal setup to give me a caching Twig-based View layer, a very lightweight Controller, and an adaptable persistence layer via Doctrine DBAL that let me quickly use tools from the entire PHP ecosystem to build whichever custom models I need, in much the same way I'd build them into any larger framework or project. And the flipside of the flexibility afforded by the new interoperability is that I, or anyone, can easily share this code for others to use via my github page and for installation via composer. It may be simple as yet, but by developing it in the public eye and with a mind to wider use, if it does grow, it'll grow in the most useful way possible.
This site is now built from 4 custom modules:
parsingphase/adze-base-site: "wrapper" project of under 200 NCLOC including configuration and build tools, serving as an example functional deployment of the Adze framework.
parsingphase/adze: A very lightweight framework built on Silex, combining various open-source libraries to produce something more "out-of-the-box", with working persistence, templating and user services, and default white-label templates.
parsingphase/blog: A functional blog module built on top of Adze.
parsingphase/phaseorg-styling: A private module containing the styling and resources specific to phase.org. Not required for a "white-label" site.
Well... a quick look in the archive will show that I've not posted in a long time. This site has been operating on extremely old code for a long time, with no working admin interface, and I've been wanting to do a complete rewrite of the codebase to get things working again. Finally I've found some time to do so; I've left my previous client after renewing the contract about 8 times, and taken this chance to sit down and Code Things Right. The site's had too many piecemeal fixes, with legacy code lingering for up to 10 years, and I've refused to do any more partial repairs.
(As as aside... the sitting down thing isn't entirely voluntary. I wanted to start running more seriously in my time off, but managed to come down with shin splints within 3 days of the contract ending, so I am slightly more immune to that particular distraction than I'd like to be.)
But anyway... what do I mean by "coding things right"? I mean coding to the same standards on my own projects as I prefer to work to for my clients. It means code that's clean, tested, documented, passes FIG PSR standards, uses quality third-party libraries, installs via composer and that I wouldn't mind releasing as Open Source for the world to see. And it also means, if it's going to be useful to anyone else, that it needs to work on "white label" templates before I put my site's own styling on it. (For what it's worth, the old site styling *will* return - it may not scream "modernity" but I'm still fond of it).
The new project is based on the Silex micro-framework, as that lets me create a basic framework for all sorts of sites, and plays very nicely indeed with a lot of Symfony, Sensio and other third-party code, saving me no end of work. The templating layer is Twig, and it will surprise essentially no-one that the styling and layout are based on Bootstrap 3. As yet the code is quite crude; some of these tools are comparatively new to me and so the project's getting refactored as it's developed. But I'm deliberately dogfooding and releasing the code at a very early stage to encourage me to keep thinking about and developing it. And yes, I do mean "releasing"; the code's available to clone or download from BitBucket under a MIT licence, but with one key caveat: the code in that repo should be in at least 3 modules rather than just one, and I reserve the right to refactor and break things on a regular basis for the moment. Some idea of what I'm planning to do with it can be found in the TODO file.
More on the project as I develop it... in the meantime, catch me on Twitter, or occasionally on Medium or Quora.