PHP applications come in many shapes and sizes. Some used locally from command line, and more commonly, for web based applications. More often than not, regardless of size or type, some form of configuration variables will be stored for global access. [...] Each options has its pros and cons. Here each of these options is explored to see which method is right for your application.

He looks at four different options:

• an ini file that can be parsed/modified directly by PHP
• an XML file slightly more complex, but still simple for PHP to use
• a PHP file with things like PHP arrays defining settings
• and a database with one or more configuration tables

Each type comes with some example code and format to give you an idea of how they'd work.

After reading this thread, I thought I'd spend some time writing about what I feel are some measures you can take to landing a job in PHP. This first part is going to concentrate on the kind of technical matters I think any PHP developer should at least have knowledge of, if not some kind of experience.

He suggests: as much programming experience as possible, experience with the full development lifecycle, knowing how to work with external libraries and frameworks, being able to adapt to development tools, knowing web application security, and some work with web services and a touch of system administration. He's not saying that you have to have all of these - just that the more you know, the better off you could be.

The previous update (0.9.26) updated the utility with an improved randomness fixing a few issues with an ini setting and the uploadprogress extension as well as adding in a few new settings and updates to the randomizing functions that come included in PHP.

The 0.9.27 update (the most current) updates the patch with a lazy loading change that allows it to work correctly on systems that have it disabled by default (causing the previous patch to not work).

You can grab this latest release, 0.9.27, from the suhosin website.

Someday I'll look back on this post and think it's super lame, but my recent submission of two tests for PHP's putenv() function made it into PHP_5_3! I've officially made a contribution it's a red letter day, folks. Without Atlanta PHP and PHP's Testfest, none of this would have been possible.

His tests ran with putenv() and the safe_mode_allowed_env_vars/safe_mode_protected_env_vars settings in use. You can see the inclusion in this commit message (by Lars Strojny).

From his blog:

You can purchase both a print and electronic (PDF) copy directly from the php|architect site - no need to subscribe and a single issue only costs $3.50 USD.

He summarizes the functionality in three different methods of handling: "page/file based", "action based", and "component based". He also notes that the interesting fact is that the "page/file based" method seems to be so dominant in the PHP world, only emphasizing the fact that PHP is more of a "get it done" language than anything.

I've just install the last version of PHP6 dev and I've decided to test the famous new feature, the PHP Unicode Support. I will not explain new things about PHP6 or Unicode or TextIterator, it's just my discoveries test on this features.

He steps through the process he followed - enabling Unicode support, testing various output methods (including just an echo and using the TextIterator) as well as some of the manipulation methods (next/first/current) that can be used to get certain characters out of a string.

One thing that I think Symfony gets right is that it appears to use partitioned PHP code for its templates, in the spirit of Paul's Savant system.

I noticed in the Symfony demo that there is no separation of scope between variables passed to the template from the controller and local variables in the template. I'd like to see them scoped properly ("$this->products") but I can certainly understand why they did it this way. Using "$this->" in the template everywhere quickly gets messy.

He mentions a few other items he saw as well, including a way to correct the above mentioned problem (two ways - one more single-instance, the other more global).]]> Wed, 20 Feb 2008 07:12:36 -0600 http://www.phpdeveloper.org/news/4851 http://www.phpdeveloper.org/news/4851 a new tutorial that looks at one of the most "pervasive" sites to come along in a long time, del.icio.us and how to interact with it's API via PHP.

Who's that with the catchy URL that's getting all the clicks?

Why, it's del.icio.us! No matter where you are on the "Web 2.0" lash or backlash, the pervasive influence of this little bookmark aggregator can't be denied.

The site offers a myriad ways of accessing its database, from HTML and RSS feeds, to JSON data, to browser integration of various types. Let's take a look at the public API, which offers flexible and easy access to del.icio.us.

In his example, he creates a script that, given the contents of an email message, filters out the URL, breaks it into its parts and sends it off to the del.icio.us API to be bookmarked under his account.]]> Fri, 15 Feb 2008 13:04:10 -0600 http://www.phpdeveloper.org/news/4627 http://www.phpdeveloper.org/news/4627 Mike Naberezny has posted this new item on his blog today with a look at why __get() is a perfectly good alternative to __autoload() in a class structure.

__autoload() is a magic function introduced in PHP 5 that provides a mechanism for on-demand loading of classes. After its inclusion in PHP, many argued that using such a feature is too magical or not a good design practice. Putting the religious debates over the appropriateness of __autoload() aside, its implementation does have one significant drawback: it is a function declared in the global scope. Once a function is declared, it cannot be redeclared. This means __autoload() can't be used effectively in shared libraries, since any other code could have already declared it.

Similar lazy-load functionality can be achieved on the class level by using __get().

He gives a short code example where the __get() call mimics the functionality of __autoload(), but the resulting object created is public, not global...]]> Wed, 09 Jan 2008 06:47:54 -0600