Cees-Jan Kiewiet has continued his series covering the use of RecoilPHP and ReactPHP with the second tutorial focusing on the creation of a Munin Node client.

In the previous post we've covered the basics of coroutines. In this post we're going to build a munin-node client specifically to fetch switch port traffic counters. During this post we not just write an munin-node client, we also deal with some domain logic. All code examples contain comments about what is going on and why. There is a lot of knowledge in those as well so be sure to read the comments.

He starts off by talking about his own use of the Munin system to consolidate and manage data from network switches. He then gets to the code, showing the installation of the required packages and some initial Promise setup. He then creates the basic skeleton of the Munin class and adds in the functionality to connect to the node, gather the details and fetching the list of open ports and values. Finally he puts it all together and includes a screencast of the resulting execution.

On his Mdeium.com site Pawel Mikolajczuk has written up a post showing you how to create a custom Twig node and parser to extend the powerful functionality already included in this popular PHP templating package.

If You want to create custom twig node then this tutorial is for You. I will show you step by step how to create custom twig syntax (DSL) called gimme (we build it for our Superdesk Publisher project).

He starts with the required changes to your composer.json file to pull Twig in and a sample index.php file to build the Twig instance and add in the new extension (the "gimmie" handling). He then provides the code needed to create the extension based on Twig_Extension for the new node type. Next is an example of the "gimmie" handling in action in a template, dumping out the user information when the article is requested. He explains what each part of the tag is doing and shares the code to create the parser for its contents. Finally he shares the code required to create the "node" class, converting it over to its parsed PHP equivalent.

The SitePoint PHP blog has posted a new tutorial for those developers out there that like the idea of the Laravel Mix functionality for defining Webpack builds but aren't using the rest of the framework for their application.

If you, like me, just want to get up and running on a project as quickly as possible, you probably don’t want to spend time configuring build tools like Webpack. Laravel Mix solves this problem, and makes asset compiling incredibly easy, but what if you want to use it on a non-Laravel project? This article shows you how to accomplish that.

[...] Laravel Mix, formerly Elixir, could be defined as an API wrapper for Webpack. It has a fluent syntax and is generally easy to use. Setting up versioning, hot reloading, and asset building/compiling is a breeze and requires only a single configuration file and a few lines of code.

The post starts off with the requirements you'll need to create the build - besides the Mix code, naturally (NPM and Node). He includes the commands to get the required packages installed and how to create the initial Webpack "mix" file. They then add a few packages to be installed, create assets to be compiled and run the tool to perform the actual build. There's also a section about "cache busting" and, finally, setting up a local index file to test out the result. The tutorial ends with a few other helpful commands you might want to use during your development.

On the DotDev.co blog there's a recent tutorial posted from Eric Barnes showing you how to combine Laravel Mix and WordPress to make it easier to manage webpack dependencies.

Laravel Mix is a fluent wrapper around the webpack module bundler, and it provides common tools that help you compile CSS and JavaScript. It’s easy to work with, and although it comes baked into the Laravel framework, you can use it anywhere.

This site is using WordPress, and when I created the theme I used Mix to handle the asset compiling; it was simple to setup. Here is a quick overview of how I did it in four steps. Please note, you will need to have a recent version of Node and npm installed on your machine before continuing.

He then walks you through a four step process to set up the integration between the two:

• Step 1. Create the package.json File
• Step 2. Webpack Mix
• Step 3. Create Your style.scss File
• Step 4. Create an app.js

He ends the post with some helpful commands you can use while you're in the development process including compiling for both dev and production environments. More information about Mix can be found in the Laravel documentation.

In the latest post to his site Gonzalo Ayuso shares some of the results of his "playing with RabbitMQ, PHP and node", creating a queue system that both languages could talk to easily.

I need to use RabbitMQ in one project. I’m a big fan of Gearman, but I must admit Rabbit is much more powerful. In this project I need to handle with PHP code and node, so I want to build a wrapper for those two languages. I don’t want to re-invent the wheel so I will use existing libraries (php-amqplib and amqplib for node).

Basically I need to use three things: First I need to create exchange channels to log different actions. I need to decouple those actions from the main code. I also need to create work queues to ensure those works are executed. It doesn’t matter if work is executed later but it must be executed. And finally RPC commands.

He goes through some of the basics of using RabbitMQ , showing the code for each of the languages - pushing a new value into the queue, registering workers, creating Queue builders and using an exchange and receiver to process the message. The post finishes with the last piece in his requirements: creating the functionality to handle RPC commands to get an answer back from the queue.

Gonzalo Ayuso has a new post to his site sharing some of the results of his work combining Docker, Silex, Python, Node and WebSockets, discovering how to create a complete platform with these tools.

I’m learning Docker. In this post I want to share a little experiment that I have done. I know the code looks like over-engineering but it’s just an excuse to build something with docker and containers. Let me explain it a little bit.

The idea is build a Time clock in the browser. [...] Yes I know. We can do it only with js, css and html but we want to hack a little bit more. The idea is to create: a Silex/PHP frontend, a WebSocket server with socket.io/node [and a] Python script to obtain the current time.

He then starts in on the code, first creating the WebSocket server in Node then the Python script that makes an internal request to get the time and return it. Then the Silex route is created to serve up the template for the page and the code it uses to connect back to the websocket. The post ends with the Docker configuration he used to create the Docker environment all of this lives in.

Matthew Weier O'Phinney has a new post to his site today showing you how you can automate PHPUnit runs while doing local development with the help of a little Node.

I've been trying to automate everything this year. When working on OSS, this is usually as simple as setting up Travis CI; in some cases, even that becomes a little more involved, but remains possible.

But that's continuous integration. What about continuous development? With continuous integration, every time I push to a branch associated with a pull request or on the origin repository, a build is triggered. [...] Ideally, I should also be testing locally. [...] I'd like to automate running these as part of my development process. I want continuous development cycles.

He then walks you through the automation setup he's devised for his own local development, adding a few lines to his Composer configuration for scripts to run when "composer check" is called. This is where Node comes in: he uses Gulp (and a few dependencies) to watch the filesystem for changes. With that setup configured and working, he can then just run "gulp" and a Node process executes and watches for those changes. When an update is discovered, "composer check" is executed and a system notification is fired if an error pops up. He's also created a package you can use to set this all up a bit simpler, only requiring a single command to execute.

The SitePoint PHP blog has a tutorial posted for the Drupal users out there showing you how to use plugin derivatives effectively.

In this article we will explore the long answer to that and learn what derivates are and how we can use them. For the latter, we will build an example inside the demo module that can be found in this git repository and which should hopefully help us better understand what’s going on. For a slightly more complex example, the Menu system is great as it provides an individual block for each of its menus (similar to Drupal 7 but using plugins).

They're basically creating a system that allows the dynamic creation of Node Blocks for each of the article nodes but it's just an example of how (and not a recommendation on what you should do). They start in by talking about plugin derivatives - what they are and how they fit into the overall Drupal 8 code structure. The tutorial then shows the creation of the derivative class and explain each part of the code that makes it up. Following this is the other half of the functionality, is the block plugin class that will generate the instances of itself as requested.

The php[architect] site has posted a tutorial showing you how to export Drupal nodes with Drush and a bit of regular PHP. Drush is a command line tool that makes working with Drupal outside of the interface simpler and easier to automate.

Drupal 8 development has shown that PHP itself, and the wider PHP community, already provides ways to solve common tasks. In this post, I’ll show you some core PHP functionality that you may not be aware of; pulling in packages and libraries via Composer is a topic for another day.

The tutorial walks through a more real-world situation of needing to export a CSV file that shows a list of nodes added to the site after a specific date. He points out some of the benefits of doing it the Drush way and starts in on the code/configuration you need to set the system up. He shows how to create the Drush command itself and update it with a method to export the newest nodes (after validating the date provided). He makes use of a SplFileObject to output the results from the EntityFieldQuery query out into to the CSV file. He makes use of PHP's generators functionality to only fetch the records a few at a time. Finally he includes the command to execute the export, defining the date to query the node set and how to push that output to a file.

The SitePoint PHP blog has posted a new Drupal tutorial about allowing multiple editors to work on the same node of content.

have encountered a practical use case where the default configuration options are not enough. Namely, if you need to have multiple users with access to edit a particular node of a given type but without them necessarily having access to edit others of the same type. In other words, the next great article should be editable by Laura and Glenn but not by their colleagues. However, out of the box, users of a particular role can be masters either of their own content or of all content of a certain type. So this is not immediately possible. In this article I am going to show you my solution to this problem in the form of a simple custom module called editor_list.

He walks you through the process, first creating the .info file needed to define the module and the changes needed for the .module file. He creates a few helper functions to get the editor listing for a node and its matching access rules. With the module created he then gets into building the fields, again making helper methods to get the editors for the fields. Finally he "tidies up" and adds an "Authored on" section to the node editor with a helper function to receive and handle the results of this field when the form is submitted.