On his site Joe Ferguson (maintainer of the Laravel Homestead project) has posted the first part of a "missing manual" series for Homestead. In this first part he covers the use of site parameters.

In the early days of Homestead there used to be a “params” option at the top level of your Homestead.yaml file. These parameters would be copied into the environment for the virtual machine just like you would set environment variables on your production systems. Laravel ultimately moved to using “.env” files and this feature was removed from Homestead.

Some users pushed back and still wanted to be able to easily push parameters to the individual site’s configuration file (virtual host file) so a new feature was implemented where you could add a “params” key to your Homestead.yaml site definition and they would be copied into the virtual host configuration file.

Joe then shows how to add the params section back into the Homestead.yaml file and get the settings loaded into the Homestead instance (involves destroying the Vagrant box and restoring it).

On his Medium.com site D. Nagy Gergo shares some "neat Laravel features" he's come across in his time developing with the framework.

We passed a year again, (oh, Happy New Year, before we forget), so we decided to collect some features from the Laravel framework that added in the previous year.

There were two big version changes, 5.4 in January and 5.5 in August. Of course, the big releases brought huge changes, but we try to focus on those that added during the year, without any bigger announcement.

In his list he includes functionality like:

• the "tap" and "when" methods for collection handling
• API route handling
• new Blade directives around Guards
• using "artisan" to build out correct model factories
• the "firstWhere" method to find and return the first match in a model

Each of the items in the list include a brief summary of the feature and a link to more information about it in the manual.

On the Laravel News site today they've posted about an effort that's been started to help create simple and community-driven man pages (documentation, manual pages) for command-line tools.

The TLDR pages (too long; didn’t read) is a command-line project that aims to simplify man pages with useful, terse examples of commands. This CLI tool gives me even less reason to memorize the tar and curl flags.

The way the TLDR command works after you’ve installed it is by passing it a command for which you’d like to learn practical uses without combing the full manual.

The article shows how to install this tldr package via npm and make it global on your system to be able to use it anywhere. There are also options for other languages if Node.js isn't your thing. You can find out more about the tool and what features it offers over on the project homepage. They also link to the repository if you'd like to contribute back to the documentation.

On the Delicious Brains site Ian has written up a lengthy post sharing how they automate their acceptance testing for their PHP applications.

Have you ever had the joy of carrying out acceptance tests? For our team at Delicious Brains, testing our releases, in the past, has been one of the most dreaded tasks on the to-do list. We hold our plugins to a high quality standard so it’s a must but manual tests are brain-numbingly tedious and can take hours of expensive developer time.

Recently, we decided it was high-time to fix that. [...] Read on for more about how the automation of testing our plugins ahead of release is shaping up – including how we manually tested in the past and a look at some of the automated acceptance tests we’ve already implemented.

He starts by defining what acceptance testing is and how they're different from other types of testing. He then shows the manual method they were using to run their tests previously and what prompted the move towards automation. He talks about the tools that they use for their automated testing including Codeception and Docker. Configurations and scripts are included that make the automation work and some of the issues they came across during the move from manual to automated processes.

Matt Stauffer has a post to his site today sharing a step-by-step guide to setting up your Laravel application for zero downtime deploys when using the Envoyer/Capistrano combination.

The reason you're getting zero-downtime deploy from these tools is because the entire deploy process—clone, composer install, etc.—doesn't happen in the directory that is currently serving your site. Instead, each new release gets its own separate "release" directory, all while your site is still being served from its current "release" directory.

All of these release directories are just subdirectories of releases. Each directory here represents one of your deploys, and each directory individually has everything needed to serve your site. [...] So, once the build process is complete for each new release, your deploy tool will delete the current symlink and create a new current symlink that points to your latest release. Boom. Now that release is live.

He then relates this back to the deployment of a Laravel application with Envoyer which already follows this "symlink deploy" method. There's a few caveats he mentions with this deploy, however, including information that shouldn't be removed in each deploy (like caches or configuration files). He then provides the steps (commands) you can follow with the deploy to manually use the "symlink deploy" method in your own scripting.

On the SitePoint PHP blog there's a tutorial posted helping you get started editing and updating the PHP.net documentation, one of the most widely used parts of the PHP ecosystem.

In this two-part article series, we’ll be covering how to contribute to the PHP project. This will hopefully clarify what steps need to be taken for those looking to become more involved with PHP.

This first part will be covering how to contribute to PHP’s documentation, including how to request a php.net Account and what to do once an account has been granted.

He starts with a bit about why you should contribute back to the PHP project and how the documentation is a great place to start. He then gets into the structure of the documentation, the DocBook structure it uses and points to the online editor for the first time contributors. He includes a video showing how to use the system to resolve this bug showing an incorrect MongoDB Client example. For those that would rather do it locally, he shows how to setup and configure the source and required tools. He then shows the flow of updating the documentation, building the result and verifying the update looks correct.

Finally he talks about requesting a php.net account to push the changes back upstream and provides some general tips on things like style guidelines, page ordering and correctly versioning files.

On the SitePoint PHP blog Daniel Sipos has written up a tutorial spotlighting a powerful feature of Drupal 8, the latest major release of this popular project: the Queue API. Queueing in Drupal allows you to offload tasks to be handled outside of the current web request.

The Queue API in Drupal allows us to handle a number of tasks at a later stage. What this means is that we can place items into a queue which will run some time in the future and process each individual item at that point and at least once. Usually, this happens on CRON runs, and Drupal 8 allows for a quick set up for cronjob based queues. It doesn’t necessarily have to be CRON, however.

They use two examples to help illustrate how to use the queueing system: one that uses the cron-based approach and another that's more manually triggered. They start out with the theory behind it all, talking about the different pieces (objects/classes) and how they fit together to make the queueing system. With that out of the way the article starts in on the code and the "Node Publish" queue, defining its basic structure and hooking it in to the framework. It shows you how to create the cron worker to process the queue and how to build the manual worker to do the same but only when specifically called.

If you've wanted to contribute something back to PHP but aren't familiar with C (or don't feel comfortable enough with it) Sammy Powers offers another solution. In his latest post he shows you how to contribute to the PHP documentation and update the manual for new features, missing information or fixes to current code examples.

If you've been wanting to contribute to PHP internals, starting with the documentation can be a great entry point; especially because it doesn't require dusting off those old C books from college. But knowing where to start can be tricky since information on how to contribute to the docs is scattered across the internet. This article is a step-by-step guide of how to contribute documentation to the PHP manual.

He starts with the "quick and dirty" way of editing the manual through the edit.php.net site, but points out that it's really only useful for smaller changes, not large documentation updates. The rest of the post shows you how to set up the documentation locally and generate the results to validate your changes. He talks some about the DocBook format they're written in, the build process with the PhD (PHP docs generator) and running the php.net test suite against the changes. This ensures that nothing else has broken on the site in the process.

He shows you where to make your changes, how to generate it from either a skeleton or using the docgen script and submitting the changes back to the repository. There's also a few other random changes to make before committing the files back via SVN and pushing them back upstream. He ends the post talking about the GoPHP7-ext project and how to find extensions that are missing documentation or where it's incomplete (easy thanks to an included "check-missing-docs" file included in the repository).

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).

In this latest post to his site Christian Weiske shares three PHP manual viewers he finds useful (besides the actual PHP.net manual) and can be used offline.

The PHP documentation is really good. It covers almost all parts of the language and is filled with examples that help you grasp a function's meaning and usage really fast. And since PHP is a grown language, it's function naming and parameter order are often confusing - requiring you to look up the manual more often.

The three he suggests are:

• pman - PHP manual pages
• the xCHM version of the manual
• Zeal, which also has support for lots of other docs from other languages/tools