On the TutsPlus.com site there's a new tutorial posted introducing you to task scheduling in Laravel, a feature that allows you to run code in the application periodically similar to a cron job.

In this article, we’ll go through one of the exciting features of the Laravel web framework—task scheduling. Throughout the course of this article, we’ll look at how Laravel allows you to manage scheduled tasks in your application. Moreover, we’ll also end up creating our own custom scheduled tasks for demonstration purposes.

The Laravel framework allows you to set up scheduled tasks so that you don't have to worry about setting them up at the system level. You can get rid of that complex cron syntax while setting up scheduled tasks since Laravel allows you to define them in a user-friendly way.

The article starts with a brief introduction to cron jobs, how they're set up and some issues that come along with them. Next the article describes the "Laravel Way" of handling task scheduling, showing how to use Laravel's artisan command to run the scheduler. With the basics laid out, the author then walks through how to create a custom task either using a closure/callable, making an artisan command or using the exec command. Code examples are included for each and more information about scheduling options and functionality can be found in the Laravel manual.

On the SitePoint PHP blog Christopher Pitt is back with another interesting article, this time talking about two "delicious evils of PHP" - the eval and exec functionality.

I want to look at two PHP functions: eval and exec. They’re so often thrown under the sensible-developers-never-use-these bus that I sometimes wonder how many awesome applications we miss out on.

Like every other function in the standard library, these have their uses. They can be abused. Their danger lies in the amount of flexibility and power they offer even the most novice of developers. Let me show you some of the ways I’ve seen these used, and then we can talk about safety precautions and moderation.

He then talks about some of the "interesting" things you can do with these two pieces of functionality including:

• Dynamic Class Creation
• [Creating] Domain Specific Languages
• Parallelism (with exec)

He ends the post with some advice how to avoid issues with the topics he's mentioned and how to "stay safe" while still using these two dangerous pieces of functionality.

Matthew Turland came across an interesting bug when working with the Cares Document Checker he's developing related to linting (running a syntax check) on a given PHP file.

While doing a lint check on a code block, a parse error was occurring on a line that contained a comment in the original source file. [...] Presumably what was happening was, even though the var_dump() call showed that actual newlines were being interpreted correctly, the r was also being interpreted rather than taken literally. This caused the comma following it to generate the error I was receiving.

An alternative to the method he was using, shell_exec, is proc_open, a function that opens a resource to handle a command execution and allows for more than just the "point and shoot" execution that things like shell_exec, or system.

Matthew Turland came across someone having an issue running his PHP-based IRC bot (Phergie) an an environment where the exec function wasn't allowed:

This causes a warning in the Quit plugin, which uses exec to automatically detection of the full path to the PHP CLI binary on non-Windows systems that it will later use that path to initiate a new PHP CLI process to "restart" the bot.

It check this setting for the future, it was recommended that he look at the SPL ReflectionFunction class (a part of the Standard PHP Library) that would let him check the disabled status of any PHP function (looking at the result of the isDisabled call).

Matthew Turland came across someone having an issue running his PHP-based IRC bot (Phergie) an an environment where the exec function wasn't allowed:

This causes a warning in the Quit plugin, which uses exec to automatically detection of the full path to the PHP CLI binary on non-Windows systems that it will later use that path to initiate a new PHP CLI process to "restart" the bot.

It check this setting for the future, it was recommended that he look at the SPL ReflectionFunction class (a part of the Standard PHP Library) that would let him check the disabled status of any PHP function (looking at the result of the isDisabled call).

New on the Developer Tutorials blog today is this look at handling background processes from your PHP script:

You've checked and double checked the integrity of user input, and you’re doing some serious processing. There's only one problem: it's too slow. There's a simple solution: forking your processing script, and running the code as a background process asynchronously. It can email your user when it's done: they'll wait. In this tutorial, I'll show you how to get started with background processes in PHP.

Akash gives examples of the three keys to background processes - starting the script via an exec, talking to the process by passing additional parameters and including code to monitor the state of the background process via something like a MySQL "sessions" table that the script writes to.

On the PHP Discovery blog, there's a new post reminding PHP developers of some of the more dangerous ways that remote execution could effect your site and some of the common entry points it can have.

PHP has numerous ways to execute raw PHP code unless you the programmer stops it. Best way in preventing these methods is making sure you check the input of what your users are inputting, and making sure you escape all malicious actions that a hacker,cracker, kiddy scripter might want to do to your website.

He summarizes four of the things from the Pro PHP Security book from Apress (by Chris Snyder and Michael Southwell) that can leave holes in you application for would-be explots - preg_replace, shell_exec/exec, eval (which we all know is only one letter from "evil" anyway) and require/include.

On the PHP Discovery blog, there's a new post reminding PHP developers of some of the more dangerous ways that remote execution could effect your site and some of the common entry points it can have.

PHP has numerous ways to execute raw PHP code unless you the programmer stops it. Best way in preventing these methods is making sure you check the input of what your users are inputting, and making sure you escape all malicious actions that a hacker,cracker, kiddy scripter might want to do to your website.

He summarizes four of the things from the Pro PHP Security book from Apress (by Chris Snyder and Michael Southwell) that can leave holes in you application for would-be explots - preg_replace, shell_exec/exec, eval (which we all know is only one letter from "evil" anyway) and require/include.

Nessa has two posts that talk about how to use PHP to display the versions of software running on the local machine.

I've been working on this application for work that does some simple server reporting, part of which involves displaying the versions of major software running on the machines. [...] I need to be aware of this to make sure that customers are being moved to servers with compatible versions. It's also good in tracking and planning upgrades.

In the first post she recommends using the exec function in PHP to run system commands to get things like the cpanel version, python version and what perl you have installed.

Part two shows a little bit different way to get some of the same information - using the data in the /proc/version file as a single resource to get OS information.

Nessa has two posts that talk about how to use PHP to display the versions of software running on the local machine.

I've been working on this application for work that does some simple server reporting, part of which involves displaying the versions of major software running on the machines. [...] I need to be aware of this to make sure that customers are being moved to servers with compatible versions. It's also good in tracking and planning upgrades.

In the first post she recommends using the exec function in PHP to run system commands to get things like the cpanel version, python version and what perl you have installed.

Part two shows a little bit different way to get some of the same information - using the data in the /proc/version file as a single resource to get OS information.