The TotalPHP site is recommending something that can make your development (and maintenance) life much easier in the long run - using a global configuration file through out your app.
t's one of the basics of PHP and if you read any kind of tutorial or book on the subject it's one of the first things they cover, yet I still see people no using a global 'configuration' or 'include' file. It's one of the easiest things to do and will make your life so much easier! This 'configuration' file will include anything that needs to be run on every page of the website.
They suggest that using this configuration file everywhere (including it over the entire site) can make things easier in the long run. The idea is not without problems, though. It only works until you need something custom for a certain area or page - then you have to hack it to evaluate conditions. For most simple uses, though, its a good way to share information (like database connection details) through out the application.
On the AskAboutPHP.com blog eldee takes a look at helpers, plugins and libraries in the CodeIgniter PHP framework including some examples.
With so many published PHP classes and functions, it would be a shame if we couldn't use them in CI. Fortunately CI (like all good frameworks) provides not one but three ways to integrate 3rd code, by using Helpers, Plugins and Libraries. [...] As I found out during the course of my CI project, Helpers, Plugins and Libraries are nothing more than glorified includes. I can pretty much take any 3rd party code and integrate into my application using any of the 3 methods.
His example uses the Google Graph class as each type (helper, library and plugin) with some example code.
In a new entryKnut Urdalen looks at something that some PHP developers might have forgotten about - the return value of the include statement.
PHP never stops surprising me. I just found out that you're able to return values from the inclusion statements (require, require_once, include and include_once) through an example of Zend_Config.
His example puts an array of values inside the include file with a return statement. This script is included from another and, because of the return, the array data is passed back out into a waiting variable set equal to the include statement.
On the TechFounder blog, Eran Galperin has taken a look at object-oriented templating in PHP applications, comparing the older search and replace method with the inclusion of PHP-based templates.
PHP as a language can be considered a templating system, as in its root it was meant to modify HTML pages dynamically. The need for more structured templating systems arose as PHP applications have grown more and more complex, giving birth to much more specialized and focused solutions.
He illustrates with an object replacement example - parsing the template as a PHP script and replacing any objects found with the corresponding object property value.
Bradley Holt has pointed out the portion of the roadmap for the Google App Engine that includes PHP:
According to the newly posted App Engine Product Roadmap, there are plans to add "support for a new runtime language." [...] Looking at the issue list, support for Java is the most requested item followed by support for PHP, Ruby, then Perl.
Be sure to show your support for the inclusion of PHP into the system by hitting a star rating on this page.
Gopal Vijayaraghavan has posted some opinions about the way that several of the popular PHP frameworks work internally, more specifically in their inclusion schemes.
In the development of things, there comes a point when it escapes the vision and control of one man/one mind. PHP frameworks are such ... beasts. But the simplicity a machine took away can be made to return. And such an attempt at zooming out of the complex file structure bureaucracy of most php projects was inclued.
He points to this image of the Zend Framework's structure as an example of the unneeded complexity several of the frameworks are guilty of (including CakePHP, Symfony and CodeIgniter).
He also includes a suggestion that could help keep the frameworks a bit more accountable:
Now, all that remains is a php-graphviz + svg mode which renders these in-browser as an iframe - or maybe someone can help me with the graph reduction to take a collection of the inclued dumps & create a "package".
Jani Hartikainen has put together a handy script for those out there that like what the Zend Framework is all about but don't really need the whole thing to get the job done. If that's you, this script might be just what you need.
Did you ever want to use just a single component from Zend Framework, but couldn't figure out which files you needed? Well, here's a solution: Zend Framework packageizer script! Just pick the class you want, and you'll get it and all its dependencies in a nice zip file for you to consume.
The packager uses the tokenizer functionality PHP offers natively to look through the files for the package you're after and finds all of the files that might need to be included and pulls them right along into the zip file.
Kevin Waterson has posted a new article to his site today - an introductory look at security in your PHP applications.
One of the great benefits of PHP is its ease of access to new-comers. Its entry level is minimal and so attracts those looking for simple scripts to their sites. It is this same ease of access that becomes a problem as the new-comers begin to deal with input from users. Failure to adequately validate and sanitize data is the leading cause of security problems when dealing with PHP.
He looks at a few different areas that developers need to focus on (and be sure to filter on) like PHP_SELF, protection from email header injections, file inclusion and the use of error reporting to make handling user-generated errors "more correct".
Federico Cargnelutti has posted an interesting overview that graphically shows outlines for a few major PHP projects showing where the includes are coming from.
The includes of the system map out the dependencies of the system, which files depend on which, which subsystem depends on which. When working with a system, it's always useful to map out the dependencies before hand.
On his blog, Jaisen Methaiposted about a very handy feature of PHP5 - the __autoload function.
It's one of the gems in PHP that I find to be relatively under used. It's common for PHP applications to break out classes into their own files. This becomes cumbersome when working on large projects as you wind up with numerous include/require calls for any given page.
He shows an example of its usage (loading class files dynamically from a specified directory) and mentions how it can help to make your code a lot less ugly. Comments on the post range in topics - from comparing it to include paths, how the idea was borrowed from PEAR, and how proper naming conventions can make its use even easier.
