In this new post Gonzalo Ayuso talks about "using eval without using eval" in PHP applications - executing PHP code without having to use the eval function to do it.

Yes I know. Eval() is evil. If our answer is to use eval() function, we are probably asking the wrong question. When we see an eval() function all our coding smell's red lights start flashing inside our mind. Definitely it's a bad practice. But last week I was thinking about it. How can I eval raw PHP code without using the eval function, and I will show you my outcomes.

He includes some sample code showing a basic script with a class and a loop executing normally, then an "eval version" that puts it all in a string and executes it. He offers a different method - not an ideal one since it requires being able to write to the local file system, but prevents the need for eval - writing the PHP code to a temporary file and using a "fake eval" to pull it in.

On DZone.com Giorgio Sironi has a new post about an interesting new PHP extension that lets you run javascript inside PHP - v8js (VERY alpha right now).

v8js is a new PHP extension able to run JavaScript code inside V8, Google's JavaScript interpreter that powers for example Chrome and NodeJS. This extension is highly alpha - and its API would probably change in the months ahead. Since documentation is lacking, I invite you to repeat the discovering process I follow in this post in case you find some differences in a new version of v8js.

He gives you the (PECL-based) commands to get the extension and it's needed dependencies installed and enabled. He uses PHP's own Reflection features to look at the extension and find its methods including: "executeString", "getPendingException" and "getExtensions". To show it in action, he implements an old standby to test new languages - the FizzBuzz example - in Javascript, executed inside the PHP. He also includes a quick example of how to load in an external Javascript file and execute the results.

Pavel Shevaev has a quick new post to his blog showing how to get PHP-FPM to execute PHP scripts via a socket request.

We are using APC cache very heavily in our projects and during project deployment the cache must be flushed and warmed up. A common solution to warmup the APC cache is to fetch some special page via HTTP which does the job. The problem with this approach is that it's not reliable enough when PHP is served via several fastcgi back-ends.

To solve the problem, he uses a PHP-FPM module to work with the FastCGI socket and execute any file (as permissions allow, of course). In his case, he uses it to "warm up" his APC cache for the user. A code snippet is provided as an example.

Davey Shafik has a helpful hint for avoiding one of the worst functions to use in PHP - eval.

There are a shed-load of ways to "eval()" code without actually calling the eval() function '" usually done simply to avoid the use of the dreaded "evil()" function, but often times because the system has eval() disabled using "disable_functions" in php.ini. Here is another simple way to avoid eval() without writing out files to the filesystem

His example uses the streams wrapper to natively execute the code from a string variable as a data element, base64 decoded. It's more of a proof-of-concept than anything else, but its an interesting solution to a tough problem to solve at times.

In a new post today Stuart Herbert asks the question "is it possible to secure a shared server with PHP and FastCGI installed on it?" His answer follows...

The challenge with securing a shared hosting server is how to secure the website from attack both from the outside and from the inside. PHP has built-in features to help, but ultimately it's the wrong place to address the problem. [...] Before we can look at performance, the first question is: how exactly do we get PHP and FastCGI running as different users on the one web server in the first place?

He follows through on this, giving a little mini-tutorial on getting the environment installed on an Apache web server. He includes some benchmarks on the difference between using the Apache 1.3.x series and Apache 2 (generated using the ab benchmarking tool).

On his blog recently Felix De Vliegher has posted about work he's done to gather some stats and great some data about how his PHP scripts are working based on a little statistical analysis.

Lately I've been interested in applying static analysis to PHP projects. Static analysis is the process of analysing software code - in our case PHP source code -, without actually executing the (compiled) result of the source code you're analysing.

He mentions some types of analysis and some of the tools that can be used to measure it. He also talks about issues it can help with (like the potential for harm if a part of code is changed) and a pointer to the Pixy software he used to generate the statistics (and images like this).

On the Developer Tutorials blog, Akash Mehta has posted an introduction to working with command-line PHP scripts and cron jobs for site automation.

Scheduled tasks are a fairly common feature in modern web applications. From cleaning out caches every 24 hours to checking subscription periods and even generating reports, more web applications live by the clock than ever before. But how do we schedule the execution of a PHP script on the server side?

He shows the two key things to getting it working - an example of a command-line call to a PHP script (executed through his /usr/bin/php) and an example of a line from a crontab showing how to execute the script at midnight every day.

Finishing off their series on destructors in PHP5 applications today, DevShed has posted this new tutorial showing how to manually run the destructors of your class (in case there's ever a need).

In this final tutorial of the series I'm going to show you how to manually trigger a destructor, and in addition you'll learn how to emulate the behavior of this magic method when using PHP 4.

They not only talk about how to call the destructor manually but they also show how to call multiple destructors at the same time to destroy lots of objects at once. And, as promised, they include a method for being able to use a destructor-like bit of functionality in a PHP4 app as well.

Sebastian Bergmann points out a new feature that PHPUnit (the popular PHP unit testing tool) now has - parallel_test_execution allowing for each test to execute on a separate PHP process.

The advantages of this include full test isolation and the fact that a test can now cause a PHP fatal error or even a segmentation fault of the PHP interpreter without interrupting the test execution.

He does mention, however, that it can cause a bit more overhead for larger testing suites since it needs to create a new process (complete with memory usage) for each running test. There are also coding issues that could be thrown off by this option (he gives an example of an inheritance issue with eZ Components).

He also notes some of his thoughts on how to control/configure the process (like in a configuration file) and via an "@isolated" notation to make it easy to do it dynamically.

On AlternateInterior.com, there's the start of something that could be used to speed up the execution of your app - multi-threading in PHP.

PHP does not have threading anywhere in its massive core. We can, however, fake it by relying on the underlying operating system's multitasking abilities instead of PHP. This article will show you how.

PHP has no built in support for threading. But there can still be times when you've got lengthy code to run and idle CPU cycles you'd like to capitalize on. We can treat child processes as threads.

He (Brian Bosh) uses the example of executing five other PHP scripts inside of another through the use of a multi-threading class he's developed. Included is the code for both the class and the example code to use it.