David Otton has a new neat PHP trick posted today - assigning references to global values.

What follows isn't so much a PHP trick as a fix for something that really should work, but doesn't. Although the manual implies that the behaviour described below is specific to Zend Engine 1, all my tests were performed against Zend Engine 2.2, PHP 5.2.5.

His example compares making a new stdClass both with and without a reference on the it and var_dumps out the result. The method with the reference fails silently, however and isn't able to correctly assign it to the global. He recommends a work-around though - setting it directly to the $GLOBALS superglobal.

If you're just getting started with PHP, some things can be a bit confusing. For a lot of developers, sessions seem to hold a bit of mystery and can be difficult to use. To help combat this, PHP F1 has posted this new tutorial to demystify this super-handy PHP functionality.

In this tutorial I will show you how to work with sessions in PHP. You will learn how to transfer information between pages. [...] Using sessions you can transfer data between various pages. If you are using sessions then each of your visitors will got a unique id. This id will identify various visitors and with the help of this id are the user data stored on the server.

They introduce what sessions are (the concept behind them), some of the php.ini settings that can be used to change how they work and code to work with assigning values to a session, checking for values in them and removing/destroying the session and its information.

If you're just getting started with PHP, some things can be a bit confusing. For a lot of developers, sessions seem to hold a bit of mystery and can be difficult to use. To help combat this, PHP F1 has posted this new tutorial to demystify this super-handy PHP functionality.

In this tutorial I will show you how to work with sessions in PHP. You will learn how to transfer information between pages. [...] Using sessions you can transfer data between various pages. If you are using sessions then each of your visitors will got a unique id. This id will identify various visitors and with the help of this id are the user data stored on the server.

They introduce what sessions are (the concept behind them), some of the php.ini settings that can be used to change how they work and code to work with assigning values to a session, checking for values in them and removing/destroying the session and its information.

For anyone that's using or wanted to use Smarty in the future and has been looking into the Zend Framework, you might have hesitated until you know how to tie them both together. Well, wait no more! This new post from the Zend Developer Zone shows you exactly how.

Inspired by this article I started to play around a bit to integrate the Smarty template engine into the Zend Framework. My ambition was to minimize the required code in the controller actions but stay close to the given Zend_View API. I also wanted to integrate the Smarty caching feature. Here is the code I came up with.

He sets up a directory under his Zend library include path for the templates to live in and starts writing code. The first step is a class that's based off the Zend_View_Abstract class to set the initial Smarty variables. He follows this up with serveral methods - __run, assign, and escape before displaying the results with output().

Finally, he gives an example of how to use the class he's created to spit out a Smarty template with all of the data nicely in place.

More information on the Zend Framework can be found at framework.zend.com, and information on Smarty at smarty.php.net

For anyone that's using or wanted to use Smarty in the future and has been looking into the Zend Framework, you might have hesitated until you know how to tie them both together. Well, wait no more! This new post from the Zend Developer Zone shows you exactly how.

Inspired by this article I started to play around a bit to integrate the Smarty template engine into the Zend Framework. My ambition was to minimize the required code in the controller actions but stay close to the given Zend_View API. I also wanted to integrate the Smarty caching feature. Here is the code I came up with.

He sets up a directory under his Zend library include path for the templates to live in and starts writing code. The first step is a class that's based off the Zend_View_Abstract class to set the initial Smarty variables. He follows this up with serveral methods - __run, assign, and escape before displaying the results with output().

Finally, he gives an example of how to use the class he's created to spit out a Smarty template with all of the data nicely in place.

More information on the Zend Framework can be found at framework.zend.com, and information on Smarty at smarty.php.net

In a new post on his blog today, Michael Kimsal looks at an abnormality that he's disocvered with constants in PHP.

Chalk this up as par for the course in the world of PHP, but it doesn't behave as documented. I noticed today that @ work someone is creating database connections, then define()ing the result into a constant. I presumed this was failing silently and because we were generally connecting to only one database (or so I thought initially) that it was simply using the last open connection and still working.

This does *not* throw an error, but does in fact work. Even going back to PHP 4.3.2 (earliest I've checked). This flies in the face of my understanding of constants for years - well, since 1998 (perhaps earlier) or so.

the issue - that a resource can be assigned to a constant - seems to contradict what's listed in the manual, and he asks later if there are others out there that have seen this same issue...

In a new post on his blog today, Michael Kimsal looks at an abnormality that he's disocvered with constants in PHP.

Chalk this up as par for the course in the world of PHP, but it doesn't behave as documented. I noticed today that @ work someone is creating database connections, then define()ing the result into a constant. I presumed this was failing silently and because we were generally connecting to only one database (or so I thought initially) that it was simply using the last open connection and still working.

This does *not* throw an error, but does in fact work. Even going back to PHP 4.3.2 (earliest I've checked). This flies in the face of my understanding of constants for years - well, since 1998 (perhaps earlier) or so.

the issue - that a resource can be assigned to a constant - seems to contradict what's listed in the manual, and he asks later if there are others out there that have seen this same issue...