The PHPFreaks.com website has posted a recent tutorial looking at a tool that can help you protect you and your web applications from possible malicious users - PHPIDS.
PHPIDS (PHP-Intrusion Detection System) is a simple to use,
well structured, fast and state-of-the-art security layer
for your PHP based web application. The IDS neither strips,
sanitizes nor filters any malicious input, it simply
recognizes when an attacker tries to break your site and
reacts in exactly the way you want it to. Based on a set of
approved and heavily tested filter rules any attack is given
a numerical impact rating which makes it easy to decide what
kind of action should follow the hacking attempt.
They look at the installation of the tool, an example configuration (that sets up some logging and caching settings) and a PHP script to enable the functionality. Then you can use the auto_prepend Apache directive to load it on each page and protect your site quickly and easily.
Ray Cheung posted his comparison of the Zend Framework and CakePHP a little while back to share some of the thoughts and research he did to pick one over the other for his application.
A lot of people have been asking for some comparison articles for some of the popular frameworks. [...] Overall, both these frameworks are good to use as per your requirements. CakePHP is suitable for developers new to MVC and those who require stricter conventions. ZF is a choice for those who need better control over the application design and built-in support for renowned Web services. Both the frameworks are developing fast and the choice is entirely yours.
He includes brief overviews of each framework and comments on documentation and configuration issues surrounding them.
Commentors on the post include Nate Abele (of CakePHP) and Wil Sinclair (of the Zend Framework).
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.
Kevin Waterson has posted a new tutorial today looking at a key part of any web application - the configuration settings and how they can be stored.
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.
On the Zend Developer Zone there's a new article that looks to answer the question in its title - "Why should I care what server my application is running on?" (by Eddo Rotman)
Imagine this - you develop an application on your machine and then, when you come to deploy it to the production server, all of a sudden, you encounter various errors and failures. Or maybe, when you decide to switch your hosting provider, your application stops behaving the way it should. How about this -... one day, out of the blue (well, out of your IT manager's whim) your application just misbehaves. Sounds familiar?
Times like can never be completely avoided (yes, there'll always be bugs) but you can take some steps to help prevent most of the major failing points. He points out some of the key configuration directives to watch out for, differences in some functions' responses based on the OS, and the differences in character sets between a unix-based and Windows based environment (like rn versus just n).
Stefan Priebsch has posted an overview of some of his experiences with test-driven development in PHP. Specifically, he talks about it in the context of a small CMS he's been working up.
The CMS I am using is a small engine that puts together (potentially multi-lingual) page content, templates, and a site structure, and creates semi-static pages. It does not have a sleek GUI frontend, because by nature I am not afraid of a text editor, and most of the time get quicker results by just writing HTML than fighting with one of these what-you-see-is-what-you-might-get HTML editors.
He talks about the configuration files containing the app's settings (inspired by the YAML Symfony uses) and his work towards the "best matching pattern" algorithm. This is where the TDD came in - he cheated a little with some base classes (tests first!) and then came up with the tests for checking template names and more complex template interactions.
The post includes drops of code here and there as well - examples of the unit tests and of the configuration files.
This new post on the Symfony blog today looks at using the framework's built-in support for the YAML format. They include a few examples of the code to make the files and how to use them.
Here is a short tutorial about my discovery of the new YAML parsing library that comes with symfony 1.1. As you may know, YAML files are a place symfony developers spend time writing configuration, it is very important they have a good tool to manipulate data and debug files.
They include code showing how to pull in a sample file, access the properties inside of it and how to take a multi-dimensional PHP array and push it back out (automagically) into a new YAML formatted file.
On the Ibuildings blog, Ian Barber has a reminder to PHP developers out there used to their servers "just working" because of the popularity of LAMP. He recommends digging a little deeper to the "behind the scenes" of how the server is configured.
PHP programmers generally know what a good systems architecture should look like, but it is often a reality of development that they will have little input on the system itself until the last minute. In fact, it's far from uncommon for a developer to be faced with an off-the-shelf dedicated LAMP server, and left up to their own devices.
He recommends getting to know things like the package manager for your distribution (apt, yum, yast, etc), stripping down the modules your installation is using, check that all of the packages in use need to be enabled and ensure that the network connection is set up correctly and is what you need for the site.
In a new post to his blog today, Eirik Hoem gives an example of using the parse_ini_file function to work with .ini files as configuration for your application.
When doing complex applications it's often nice to have some sort of system for handling settings. PHP has a nice function called parse_ini_file which can be used to create a basic but still usable setting file feature. A simple class which loads the configuration file and offers some methods to retrieve the values for a given key is all that's needed.
His example code gives a sample ini file with database connection information and a MyConfigClass that parses the file and can get or set values in it.
Whether you're an enterprise developer working in a large shop or setting up a blog for yourself, you've almost certainly been tasked with keeping your development code in sync with some type of stable release. Whether a project is big or small, you still need to ensure that the core code you work with remains consistent.
The tutorial walks you through the setup of a basic AIR application, how to pull the configuration XML into it and parsing it to use in the interface. The next step is the sync, grabbing your config and pushing it out to other multiple configs across your sites (via a REST service).
