In a post to his site Fabian Schmengler has shown how to use class_alias to prevent breakage while renaming or moving classes around in your application during refactoring.

Sometimes you want to rename a class or move it to a different namespace. But as soon as it is used anywhere outside the package, this is breaking backwards compatibility and should not be done lightheartedly.

Luckily there is a way in PHP to have both, the old class and the new class, while deprecating the old one: class_alias().

He then gets into the details of using this handy function to define the links between the files, necessary in two different places to prevent autoloading breakage. He also offers an alternative, making use of the "autoload.files" option in the Composer configuration (but this means adding each one to that list). He finishes the post by suggesting one more thing as you update your code: making it with an @deprecated annotation to help locate it later (and flag it in your IDE of choice).

The Zend Framework blog has a post announcing the name change of the main Zend Framework repository on GitHub:

Per the GitHub documentation on renames, existing links will be automatically redirected, and will persist as long as we do not create a new repository with the name "zf2". Redirects occur for: issues, wikis, stars, followers and git operations.

The post also includes the instructions on how to update your current "remotes" in your git checkout (so you don't have to re-clone). It also mentions the change and how it relates to Composer - hint: nothing at all because of how Composer works.

An announcement has been made on the Zend Framework blog today about a massive repository rename that will be happening May 3rd, 2016 to move away from the "zf2" naming.

In contrast to Zend Framework 2, which was a complete rewrite and break with the architecture of Zend Framework 1, the Zend Framework 3 initiative is more of an evolutionary change. [...] Another way of putting it: changes to the main repository are happening incrementally, and version 3 will just be a new major version update within the existing repository. However, such evolutionary change poses a slight logistical problem: the repository is currently named "zf2".

In order to make the change to Zend Framework 3 (and beyond) simpler, the repository will be renamed to "zendframework" instead. In the current configurations this namespace already exists and points to the correct locations so, ideally, no changes will need to be made on the Composer installations of current users - just updates to git remote entries to point to the new locations.

In his latest post Matthias Noback talks about a problem common to Symfony bundles (and, well, software in general) - dealing with backwards compatibility and breaks that could be introduced with new changes.

With a new bundle release you may want to rename services or parameters, make a service private, change some constructor arguments, change the structure of the bundle configuration, etc. Some of these changes may acually be backwards incompatible changes for the users of that bundle. Luckily, the Symfony DependenyInjection component and Config component both provide you with some options to prevent such backwards compatibility (BC) breaks.

He breaks the post up into a few different kinds of backwards compatibility breaks that could happen and code examples of each:

• Renaming things
• Changing visibility
• Changing values

Each topic also includes methods for preventing issues with older users who maybe aren't using the new features. This includes things like sane default values for new settings, renaming services and creating new extensions for working with new properties.

Matthew Turland has a new post to his blog sharing a handy trick if you've ever looked for a way to use the DOM functionality on PHP to rename a certain node in an XML document. Since the node_name is read-only, some trickery is required.

A recent work assignment had me using PHP to pull HTML data into a DOMDocument instance and renaming some elements, such as b to strong or i to em. As it turns out, renaming elements using the DOM extension is rather tedious.

His method isn't so much of an update of what's already there as it is to replicate the attributes and child nodes of the node you're targeting and pus those back into the document with a call to replaceChild on the parent.