For many years, PHP has been a stable, inexpensive platform on which to operate web-based applications. Like most web-based platforms, PHP is vulnerable to external attacks. Developers, database architects and system administrators should take precautions before deploying PHP applications to a live server. Most of these techniques can be accomplished with a few lines of code or a slight adjustment to the application settings.

The five tips they list range from general "best practice" kinds of things to a bit more specific:

• Manage Setup Scripts
• Include Files (using ".php" not ".inc")
• MD5 vs. SHA
• Automatic Global Variables (no longer an issue in recent releases, 5.4.x)
• Initialize Variables and Values

Unlike Zend Framework 1, the view layer in Zend Framework 2 separates the variables assigned to each view model. This means that when you are in the layout view script, you don't automatically have access to variables that were assigned the the action's view model and vice versa.

He includes snippets of code with an example controller and a sample view that fetches a value from a child ViewModel instance. He also shows how to access layout and configuration values in the view.

In this third post of the PHP's Source Code for PHP Developers series, we're going to expand on the prior posts to help understand how PHP works internally. In the first post of the series, we looked at how to view PHP's source code, how it's structured as well as some basic C pointers for PHP developers. The second post introduced functions into the mix. This time around, we're going to dive into one of the most useful structures in PHP: variables.

He starts with one of the most important variable types used in PHP's source - the ZVAL. This is one of the keys to PHP's loose typing and can be thought of as "a class with only public properties". He gets into more detail with the properties of this "class" (value, refcount__gc, type and is_ref__gc). Also included is a look at how it's actually used - creating new ones, getting the value of them, converting their types and how the internal PHP functions parse their variables.

There's a lot more covered about variables in the post so if this is interesting stuff to you, be sure to read it all. They've done a great job of explaining one of the more complicated parts of the internals that power PHP.

In this third chapter of the series I'm going to discuss one that bases its functionality on the loader class that comes bundled with CI. [...] By means of this method, it is very simple to replace in one single step all the variables included into multiple views with actual data. Therefore, in the next few lines I'm going to discuss how to use it to generate a dynamic web document, which will display some database contents.

After a quick review of loading views sequentially, they look at the new stuff - a "master view" that can load multiple other views inside. To pass information into this master view, they use the "$this->load->vars()" method included in the framework.

If your application requires JavaScript in order to work than you have probably been looking for an efficient way to pass CakePHP controller variables to your scripts. I already mentioned this technique in my talk at CakeFest this year, but here is the full explanation.

His method sets up a new function in the controller that automatically pushes PHP arrays out to a Javascript block in your application's layout. The widget system makes it a simple process.

They go through each, explaining what they are, how they're used and when you'd want to use them in your code. They explain the data types and how those fit with each "container" and some basic things like valid names and how to assign things correctly.

They even get get into working with variables from GET and POST requests as well as working with the scope of variables and getting the metadata about them (is it an integer? is it empty?)

These days, the way to develop is to have E_ALL and maybe even throw in E_STRICT if you are really hard core. That of course means having all your variables initialized before they are used.

In his view, defining them is good, but it's more "elegant" to use the settype function to make it more clear where they are defined. He also includes a function, using settype, that ensures that the entered values are what they should be (i.e. and int is an int).

Of the six options they provided:

• Object code caching
• Template systems
• Distributed object-caching systems
• PHP variables that can be set
• Output Compression
• Other things that may help

Be sure to cast your vote for their latest poll question - "Which is the Most Common Database Problem?"

The videos, seven in all now are done with a voice-over talking about what the feature is and includes bits of code to help explain the discussion.

Topics so far include:

• Includes
• Configuring WAMP
• PHP Variables, Part 1 and Part 2

You can get complete information on these screencasts from the KillerPHP site.

She describes what they are with an illustration using a simple PHP script and breaking it out into the compiled version's parts - both in PHP4 and the PHP5 versions. Of course, representing what they are needs a flipside, so she presents a look at what they are *not* as well. There's also a brief mention of the special status that globals and static variables get outside the norm.