On the Tuleap blog there's an article posted showing how they made the switch from RabbitMQ to Redis in their PHP application.

There are various places in Tuleap were message queues are needed but the primary one is to run jobs in background. Historically it was for all system related stuff (creating users, git/svn repositories, etc) that required special unix permissions that we were not eager to grant to a web app.

[...] More recently we add a need to share events across servers, for distributed Tuleap setup for instance. Our good old system was no longer able to deal with that because we needed a real queue management that works across servers. We choose RabbitMQ because we were looking for a queue system, PHP support quite decent and tutorials were good. However, we had to setup a quite complicated queue system.

The post outlines the exchange to exchange binding system they created and includes the code use to make the RabbitMQ-based system work. Then they introduce Redis and how, when they learned about RPOPLPUSH, decided to make the switch. The code for this replacement is also included.

The TutsPlus.com site has a tutorial posted that introduces you to CodeIgniter's hook system and details how it all works. The tutorial goes through each hook already included and shows how to create a custom one to fit your needs.

As a CodeIgniter developer, sometimes you end up in a situation that requires you to alter the core of the framework or the execution flow to fulfill your custom requirements. Of course, it's never recommended to modify the core files as it makes the upgrade process cumbersome. Luckily, the CodeIgniter framework comes with the hooks system, which allows you deal with this scenario.

In this article, we'll start with an introduction to the hooks system in the CodeIgniter framework. Then, we'll discuss the different types of hooks available. And finally, we'll grab this opportunity to explore the creation of custom hooks.

They start with an overview of the hooks system and what kind of functionality it offers to the developer. The article then goes through each of the default ones built in to the framework including system hooks, controller hooks and "overrides" hooks. It then finishes off with a look at creating a custom hook and how to add it into the system for use across the application.

On the Laravel News site there's a new tutorial posted showing you how to create a simple iVR system with Laravel and Nexmo that includes voice responses.

Want to dial your Laravel app, and have it talk back to you? Let’s take a quick look at how to build a really simple IVR (interactive voice response) – a ‘phone menu’ – with Laravel and Nexmo. When it’s done, you’ll be able to pick up your cell phone, dial a phone number, and have your Laravel app control what you hear.

It’s probably easier than you think, let’s get started!

Using a standard Laravel application and a Laradoc environment, they pull in the nexmo/laravel to connect with the Nexmo service. They also add two others to add additional functionality for reading Tweets and RSS feeds. After configuring the application providers to pull in the Nexmo and Twitter functionality they go over to the Nexmo site and create the application they'll use. The tutorial then shows how to generate a command (the AppCreate command), its signature and the code to make the Nexmo API request. They then create another command to link the application to numbers on the Nexmo account.

Finally, they get to the "good" part - creating the code to handle the incoming calls over webhooks. This includes the controller, routes and - based on user input - how the IVR will respond. In their example, when the number is called, the latest tweet from @taylorotwell is fetched and is converted to text, then spoken back to the caller.

On the Paragon Initiative blog they've posted a guide to handling automatic security updates for PHP developers, helping to prevent security-related issues by keeping your libraries up to date.

Most of the software security vulnerabilities known to man are preventable by careful development practices. [...] However, even if you're trying to do everything right, eventually we all make mistakes and ship exploitable software.

[...] By making updates manual rather than automatic, you're forcing your customers to take all the responsibility for making sure that your mistakes don't hurt their business. Only a very small minority of your customers might prefer the responsibility of verifying and applying each update themselves. [...] Automatic security updates reduce the interval between points 2 and 3 from possibly infinite to nearly zero. That's clearly a meaningful improvement over manual patch management.

The post then walks through the aspects of a secure automatic update system that includes offline cryptographic signatures, transport layer security and separation of privileges (who will perform the actual update). The author gets into a bit of detail for each item on the list, explaining how the system should be set up and some tools you can use to start working up the process in your own applications.

In the latest part of his series covering Laravel 5.3, Matt Stauffer has posted this new tutorial covering the new notification system in the latest version of the popular Laravel framework.

In a previous blog post I've covered Laravel's new Mailable feature, which introduces some important changes to how we send mail in Laravel. I'd recommend at least skimming it if you haven't read it yet. In short, the preferred mail syntax is no longer sending mail using the "classic" mail closures, but instead creating a "Mailable" class for each message you want to send—for example, the "WelcomeNewUser" mailable class.

In Laravel 5.3, we have another new feature for communicating with our users: Notifications.

This notification system makes it simpler to send messages to your user when you don't care as much how they get it, just that they do. He walks you through the creation of your first notification class and breaks it down into its main parts, explaining each one. He shows how to define the different handlers for the notification types (like "toEmail") and how to trigger the notification, passing in either a single user or all users in the system. He then talks about the channels that are available to notifications and how to integrate several including Nexmo, database and the "broadcast" channel.

In his latest post Larry Garfield talks about the Composer problem that was recently brought up by the Gentoo linux project and is related to how Composer packages and system-level shared libraries differ.

This is not a new complaint; Other distributions have complained about Composer's impact before. But fundamentally I think the issue stems from having the wrong mental model of how modern PHP works when viewed from a distribution or sysadmin perspective.

In a recent heated GitHub thread, several people referred to PHP "linking" to 3rd party libraries, as if they were shared C libraries. That is simply not the case. Neither "static linking" nor "dynamic linking" really applies to PHP. From a sysadmin perspective, PHP is closer to highly complicated bash scripts than anything else.

Larry starts with a bit of history on the subject, pointing out the two methods most developers used PHP code: copy/pasted from the web or installed via PEAR. He talks about the common issues with both approaches. He then talks about how modern PHP development and Composer related and how, from a sysadmin perspective, Composer is the "compile" step of PHP and only supports static links. He also makes some suggestions to the distribution packagers around how to handle these system-level Composer dependencies (and how to treat it like a "binary" if needed).

The mistake here is trying to treat dependent packages of modern PHP applications like shared libraries. They're not. The community has spoken, and PHP simply doesn't work that way anymore. Fighting that is a losing battle. But by viewing composer as a compiler, distributions can still slot PHP into their typical workflows and get all of the security update ease that they're looking for.

On the Symfony Finland blog Jani Tarvainen has written up a new post sharing some of the things that eZ Platform adds to Symfony and what kind of functionality it brings with it on top of the usual Symfony featureset.

eZ Platform is a Content Management System built with the Symfony Full Stack framework. While this may be clear to developers who have worked with, it maybe somewhat vague for the unitiated, especially when compared with Concrete5 or Drupal, which have adopted Symfony components into their core. [...] The relationship between Symfony and eZ Platform is very similar to Expression Engine using Code Igniter or EPiServer using ASP.NET MVC.

He then goes on to talk about the things Symfony includes by default including the request/response structure, internationalization handling and Twig integration. From there he lists out the things that the eZ Platform adds on top of the standard Symfony including:

• a content repository
• dynamic routing
• a user interface
• user and permission management

He ends the post with a look at some of the other bundles and features eZ Platform also provides around HTTP caching, image manipulation and more.

On the Tighten.co blog they've posted their own review of Statamic, the flat-file based content management system with a Laravel backend. Statamic is a project that hopes to provide easy content management, responsive layouts and plenty of features to make an easy-to-use and robust CMS.

Among the developers I know who used to use ExpressionEngine but have since left, most work in Craft and/or Laravel. I kept hearing folks mention Statamic, but all I knew about it was that it was flat file, which wasn't particularly compelling to me.

Fast forward two years, and they've re-written the entire application to run on Laravel (now released as v2 beta). [...] Their documentation is hilarious, the community is welcoming and helpful, and the code—granted, I'm only a few weeks in—seems super easy to work with. So, what's the deal? Why have we set up Tighten's blog on Statamic?

The post then goes on to talk about the "quest" for a good Laravel-based content management system. They also talk about some of the essentials they see a CMS needing to be effective: good user interaction (UI/UX), how much and how difficult it is to customize and how it is configured. For each point they talk about how Statamic does things and their own verdict on the software and how good it does at filling these requirements.

In this tutorial on the Zaengle blog Jesse Schutt shows you how to use a Laravel application as an "intermediary" between several services and tie them together so a single action could kick off a series of events.

One of our clients recently came to us with the following workflow they'd like the Zaengle team to implement for them: They wanted to compose a blog entry in their CMS. Upon publishing of the entry, they wanted the content of the blog entry to be emailed to a filtered group of their customer database (stored in Marketo). Finally, they wanted to be able to track email metrics from within their customer database.

[...] After brainstorming with the team and client, we decided that since there were at least 3 different systems in play (CMS, Customer Database, & Mail Processor), we needed to write a custom application that would bring all of them together.

He then walks you through the solution they came up with, showing how it makes use of webhooks, API requests and work with their own database. He talks briefly about some of the benefits of the setup and how they arranged the testing of the data flow between the pieces of the system.

On the Coding.bmail.net blog they've posted a guide to what they've called an advanced logging system in PHP for careful developers - essentially a logging system that's as "error proof" as possible and that works with as little user exposure as possible.

Being aware of all the activity and problems under the hood is essential when running big websites with lots of users, many features and, as it is usual in such cases, weak spots that must not be left untracked.

In order to be the first in knowing when errors or other events of interest happen we need a well designed logs manager. My code will provide such a feature, for PHP based websites.

They briefly outline how the complete setup will work, failing back to email if the database connection isn' available and logging based on environment. It also includes error levels and, on development only, a method for showing the errors being logged. While a good bit of this functionality could be handled by something like Monolog they do include some additional features like the email fallback, output of the errors in development mode and custom error/exception handlers.