The php[architect] podcast has posted their latest episode of their podcast: Episode #10 - Treasure, Old and New with hosts Eric van Johnson and John Congdon.

Our hosts, Eric van Johnson and John Congdon review Treasure, Old & New which is the May 2018 issue of php[architect] magazine.

Eric and John discuss Deadpool, clean code, migrating to AWS, Packagist picks, BDD testing, and more. Oscar takes a look at recent Drupal and WordPress developments. An interview with Steve Grunwell, about Technical Debt, conference speaking, his work at Liquid Web, and more.

You can listen to this latest show either using the in-page audio player or by downloading the mp3 directly. Be sure to subscribe to their feed if you enjoy the show and want to be notified when future episodes are released.

In a new post to his site Joe Ferguson shows you how to move a dependency over to Composer but still require the older version, possibly one that's already included in the codebase as a checked-in source.

A common problem I run into with older applications are dependencies that have been added and loaded from the application’s repository. You would often see a “libraries” folder with a “className.php” type file. If you’re lucky you’ll have the entire folder of the dependency including the release notes to be able to find out exactly what version you’re using.

[...] What if the author hasn’t tagged our older version? Maybe they converted the repository to git from subversion or some other system? You have to go digging into the commit history to find the commit you want to match your current version.

He includes the Composer configuration required for both examples (loading the older version and loading by commit ID) as well as the addition of the "minimum-stability" option. This option allows you to pull directly from the "master" branch if you need to - just be sure to define exact versions of other dependencies otherwise you'll get dev versions of them too.

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.

Michael Dyrynda has written up a new post for the Laravel users out there showing an elegant form handling method he's come up with that doesn't involve the use of the older version of the Laravel Collective HTML package.

On episode 28 of the North Meets South Web Podcast, Jake and I were discussing packages that we always pull into our Laravel projects. Jacob mentioned that he still uses the Laravel Collective HTML package, which was forked from the functionality that was present before Laravel 5, which is something I suggested I hadn't done for a long time.

[...] Jacob went on to explain that a big part of using the form package is because it handles binding form data directly to the forms for you, allowing you to separate form inputs from the create / edit components themselves. [...] I suggested that you can go about this simply enough in your applications by using a combination of the old() helper method and an empty model.

He includes code examples of both ways to generate the form, first using the Collective package then using just the old() helper function to repopulate the form values when the page is rendered. He points out that using this internal method doesn't require yet another package. There are some niceties that are missed with going with the old() method, but there are benefits too.

The /Dev/Hell podcast has released their latest episode today, number 48: Old As Dirt. In this episode hosts Chris Hartjes and Ed Finkler are joined by guest Elizabeth Smith about being "old as dirt" and mentoring other developers.

Our guest this week is Elizabeth Smith, PHP internals veteran and guru of PHP on Windows (she says “I wish every company was as good at giving back to open source as Microsoft”). We talk about being Old as Dirt in relation to a blog post Ed made last week, how to mentor up and coming developers, and the history of PHP on Windows.

They also talk about Ed's The Developer’s Dystopian Future article, PHP-GTK and the PHPMentoring project. You can listen to this latest episode either through the in-page player or by downloading the mp3 directly.

Evert Pot has a quick post about a suggestion mentioned at PHPBenelux related to using namespaces with older code.

If you're running PHP 5.3 and you have to use pesky old code that uses long class prefixes (yea, so, pretty much all PHP code out there), you can still make use of namespace features to shorten them.

He includes a quick example that shows the shift from using the traditional Zend_Controller_Action_Helper_AutoComplete_Abstract to an aliasing with the use/as to just reference it as AutoComplete.

Hasin Hayder asks a question in his latest blog post that some in the PHP community have been wondering for a while now - is the International PHP Magazine dead?

I am a subscriber of International PHP Magazine for years. I bought the subscription looking at the back issues. They were sexy, resourceful and yup, very good. But I think these guys don't care about the magazine anymore. It became just a funny stuff for them. All the readers/subscribers and viewers doesn’t bring any value to them. Look what they are doing actually...

He points out six things that the magazine and its staff are doing including RoR articles in an issue, content on the site that's way out of date and the smaller size of recent issues. Comments to the post point out that there has been issues released but that the magazine is published by a non-technical company that just might be pushing this particular publication aside.

You can file this one under the "bygone days of PHP/FI" category, but Adam Trachtenburg has posted about the old_function hack he uncovered.

I was reviewing Upgrading to PHP 5 today and I came across this lovely section in Appendix B, which I had completely forgotten about.

I must say, I used PHP/FI, but I never resorted to the old_function hack to ease my PHP 3 migration issues.

If you'd like to check out an old manual entry for this one, look here. It allowed you to declare a function using the syntax for PHP/FI2 even though you were in PHP 3.

You can file this one under the "bygone days of PHP/FI" category, but Adam Trachtenburg has posted about the old_function hack he uncovered.

I was reviewing Upgrading to PHP 5 today and I came across this lovely section in Appendix B, which I had completely forgotten about.

I must say, I used PHP/FI, but I never resorted to the old_function hack to ease my PHP 3 migration issues.

If you'd like to check out an old manual entry for this one, look here. It allowed you to declare a function using the syntax for PHP/FI2 even though you were in PHP 3.