Derick Rethans has shared a post on his site with an experience he had with a mystery of missing breakpoints and some issues he commonly is asked about regarding Xdebug's breakpoint functionality.

Occasionally I see people mentioned that Xdebug does not stop at certain breakpoints. This tends to relate to multi-line if conditions, or if/else conditions without braces ({ and }).

f you set a breakpoint at either line 7, 11, or 12, you'll find that these are ignored. But why is that?

To help explain, he uses the vld tool to show the opcode behind the language's processing. In its results you can see that a EXT_STMT code is missing for the lines where the breakpoints were set. Xdebug doesn't see the marker it's expecting so the breakpoint isn't recognized and execution isn't halted as expected. He offers some suggestions you can use of other tools and functions to make sure the location you've selected can actually accommodate a breakpoint.

The Laravel News site has published the latest part in a series covering the creation of a translation package for use in a Laravel-based application. In this new post they focus on how the package will handle missing translation keys.

In the last installment of this series, we talked about building the frontend translation management tool. In this article, we are going to move away from the frontend and follow the process of building another backend feature.

One of the most frustrating things about translation management in a Laravel application is forgetting to add translations to the corresponding language file. This has the undesirable result of either the translation key or the default language being rendered on the page rather than the translation for the current language.

To remediate this issue, they design the package so that it will search the whole project and return the keys that don't have translations currently defined. They walk you through the creation of this functionality complete with the configuration and code required to locate the missing translations and update the configuration to add them.

In a post to his site Leonid Mamchenkov shares an interesting output bug he came across in his work developing cron jobs and how they handled his errors.

We came across this PHP bug at work today. But before you go and read it, let me show you a use case. See, if you can spot the problem. We had a cron job script which [ran a PHP script and echoed a string when complete].

[...] We use similar code snippets all over the place, and they work fine. This particular one was a new addition. So the cron job ran and “Updating products failed” part happened. Weird. The PHP script in question has plenty of logging in it, but nothing was logged.

After adding more and more logging to the process and PHP script, nothing obvious was standing out. Finally, they noticed that the filename was incorrect but normally that would cause an error in the PHP command line execution. The tricky part here was in how PHP handled its errors. Their error_log and display_errors settings were such that the PHP "missing file" error was being swallowed up and not displayed.

On the Acquia blog Adam Weingarten has shared some tips for writing good (and modern) object-oriented code in PHP:

Recently I began working on a D8 module, but this isn't a story about a D8 module. The work I did provided me an opportunity to get back to my pre-Drupal object oriented (OO) roots. Writing OO code in PHP presented some curve balls I wasn’t prepared for. Here are some of the issues I encountered:

His tips touch on things like:

• Using a code structure that can be autoloaded via PSR-4
• Namespacing your classes
• Working with types and type hinting
• Using docblock comments for autocomplete in IDEs

There's also a few other quick topics he finishes the post out with: the lack of enums in PHP, working with associative arrays, no functional overloading and assigning responsibility to classes.

Ben Ramsey has shared an interesting issue he's come across when installing packages via Composer where it installed a different version than expected when he ran an install. The problem turned out to be from an unexpected place.

For applications I control that are not distributed to the public, I like to hard-lock my Composer dependencies to a specific version. [...] Sometimes a library has updates that haven’t yet been released, and I need to use these right away. Composer allows me to specify the specific commit I want to use for a library. In this way, I can hard-lock a dependency to a specific state, even when there is not yet a release for the changes I need. This has worked well until today, when I tried to do a fresh composer install. After installing, one library contained files and methods that I did not expect. It turns out Composer was grabbing the HEAD of dev-master instead of the specific commit I referenced.

After some investigation into his "composer.lock" file's contents, he found the issue: a problem with the way that BitBucket handles the distribution zip files Composer requests. In his example, the zip file was of the HEAD on the repository, not of the specific commit (GitHub doesn't have this problem). His solution was using the (slower) "--prefer-source" option to grab the correct commit contents...not an ideal solution but it does what he needs.

In the next part of his series introducing the upcoming version of the Laravel framework Matt Stauffer has posted part 16, about generating missing events.

Sometimes it can seem like a lot of work to create an event, create its handler, and bind the two. Create a command, create its handler, bind the two. I've often wished for a workflow that handled the whole process together in one. The artisan commands for generating commands and events are a good start--they both create their own entity and (optionally) its handler. But you still can spend an hour writing the command and handler, and then waste another 15 minutes trying to figure out why it's not working, only to realize you never actually bound the two together.

The solution to this in Laravel 5 is the "event:generate" handling with the artisan command line tool. He includes a look at the event handlers directories and files before executing the command and what changes post-execution, including the sample code generated for the event.

Hari KT has a new post to his site today about a book he's been working around around the Aura framework that provides the missing manual for v2 of the project. He's publishing it as a book over on Leanpub too, so it's easy to grab...and for free too.

Aura has an awesome collection of libraries for different purpose. [...] If you are new to aura, there is probably something you may want to figure out yourself. Some of the components have version 1 and version 2 releases. There is a question of which branch corresponds to which version. [...] But people new to aura may be having hard time to find the specific documentation or may be stuck sometime. [...] I was talking with Paul M Jones regarding the documentation lately, and he too shared some concerns. Talking with him gave me some inspiration to start the missing manual for the aura framework.

The goal of the book it to provide a good resource for people to learn about the framework/components and their use and to help promote Aura. The book is available for free either on Github or Leanpub (or, to help support Hari and the project consider purchasing a copy).

Lukas Smith has a new post to his site that asks the question "what's needed to REST in Symfony 2?" In it he talks about some of the current issues surrounding REST support in Symfony (bundles) and a "call to arms" to create something better.

I think we already have quite a nice toolchain for REST in Symfony2 with Bundles like FOSRestBundle, JMSSerializerBundle, NelmioApiDocBundle, FSCHateoasBundle and HautelookTemplatedUriBundle. What is great about these Bundles is that they are all nicely integrated with each other. But there are still some limitations which should be addressed.

Some of the still outstanding issues he points out include issues with content-type and routing, dynamic content in the NelmioApi bundle, Behat context testing, JSONP support and more. He suggests gathering together a product backlog of these items and possibly making a kickstarter to fund its development.

In a new blog post on PHPClasses.org today Manuel Lemos has gathered together some of the things that PHP doesn't have (yet). Most of them are things that developers have expressed a desire for in the core and either have yet to make it into a RFC or are still just being implemented in "userland" code.

The PHP development process is still a bit frustrating. Many developers hoped that PHP had certain features but those are still missing due to several reasons. One way to see those features happen is to write code to implement the features and then submit the code to the PHP core. However that is not a guaranteed process. Even if you provide the necessary code, other developers may object to the addition of those features and the effort is wasted.

Among the things he lists as features that are desired but not implemented yet are things like:

• Aspect oriented programming
• Annotations
• Class generics
• Introspection of private variables and functions
• Named parameters

There's a summary of each of the features mentioned and in some cases links to RFCs that presented the same ideas. If you're interested in presenting your own ideas to the PHP project for inclusion, you can "demystify" the RFC process by checking out this post from Chris Jones with lots of good suggestions and the flow of how the process (usually) works.

In a new post to his site Michael Kimsal poses an interesting question about something he's noticed in several frameworks - and not just PHP ones: there seems to be a lack of authentication/authorization functionality coming bundled in.

Why do almost no web frameworks provide any default authentication/authorization functionality, with default examples of best practices for common use cases. The standard response I’ve gotten for years was/is “well, everyone’s needs for authentication are different”. No, they are not. A (very?) large majority of web applications (which is what most web frameworks are used to build), require some form of user login and authorization management, and often self-registration, dealing with lost passwords, etc.

He points out that by not having something a user can immediately deploy that's been well tested and relatively risk-free, it can introduce security holes as a developer is "left to fend for themselves". He suggests that the "not everyone's the same" mentality that seems to go with authentication/authorization isn't as valid as once thought. He does point out that both Symfony2 and Zend Framework 2 come with ACL functionality, but no common user handling. He mentions ones in a few other tools used in other languages too like Devise in Ruby, Spring Security in Grails and a membership system in ASP.NET.