It should be noted that this setting DOES NOT suppress the error. Even if the directive is set to ‘Off’ (do not display errors) errors which occur in a script are still triggered and will be processed by the error handler.

</IMPORTANT>

 
PHP does not offer a special display_errors function, but by using the ini_set() function we can control the setting of this directive within our script. The function signature looks like this:

string ini_set ( string $varname , string $newvalue )

blah, blah

The configuration option I would like to address in this article is, of course, error_reporting.

Let’s start digging.

error_reporting

The error_reporting directive (within the PHP ini file) allows you to set the level of errors reported by PHP. By default this is set to ‘E_ALL & ~E_NOTICE’. This ‘tells’ PHP to report all errors, except Notices.

PHP provides a built-in function for getting and setting the error_reporting level: error_reporting(). The function signature looks like this:

int error_reporting ([ int $level ] )

The function accepts one optional argument, a new error reporting level, and returns the old error reporting level. Although the signiture shows that the function accepts an integer, the new level sent can be represented by a predefined constant. In fact it is recommended that you use the predefined constants to ensure future compatibility.

The available constants can be used in combination to build up a bitmask; the bitmask tells PHP which errors to report and which to suppress. Since these constants are actually bitmasks, you will need to use bitwise operators when combining them.

An example of the error reporting setting I use in development is:

$old_setting = error_reporting(E_ALL | E_STRICT);

From the predefined constants chart the setting E_ALL equates to the integer 30719 and means:

All errors and warnings, as supported, except of level E_STRICT in PHP < 6.

From the predefined constants chart the setting E_STRICT equates to the integer 2048 and means:

Enable to have PHP suggest changes to your code which will ensure the best interoperability and forward compatibility of your code.

So basically, this tell PHP to report all errors, notices, and messages generated at the E_STRICT level.

Back to the code…

The variable $old_setting will now be set to: 6135, the default setting for error reporting (using the predefined constants again that would be: E_ALL & ~E_NOTICE).

A small code example:

<?php
//get the current error reporting setting
$current_setting = error_reporting();

//check if error reporting is set to E_ALL | E_STRICT
if (8191 != $current_setting) {
    //not set to E_ALL | E_STRICT make it so
    error_reporting(E_ALL | E_STRICT);
}

//display new error reporting setting

echo error_reporting(); //displays 8191
?>

A more useful example would be to change the error_reporting setting based on the environment the script is being run in.

Let’s say you have a configuration file which defines the constant ‘ENV’, this can be set to ‘production’ (live site) or ‘development’. If the script is run in production then we want to use ‘E_ALL & ~E_NOTICE’ (default), but when running in development we want to use E_ALL | E_STRICT.

config.php:

<?php

//define enviroment
define('ENV', 'development');

Script File:

<?php

//load configuration file
require_once('config.php');

//check ENV constant to see if running in development
if ('development' == ENV) {
    //running in development so change default setting
    error_reporting(E_ALL | E_STRICT);
    //now all errors, notices, and suggestions will be reported
}

That’s it! I’m sure you can see how useful this function can be.

Side Note: If you are unsure what a bitmask is or are unfamiliar with bitwise operators, you may want to checkout this post from joestump.net.

As I’m sure you’re aware Pearsonvue administers the exam. The testing centers are usually apart of other organizations (colleges, tech centers, etc.)

First, I was asked to arrive 15 minutes early so that I could complete the registration process and start my exam ‘on time’. Registration basically consisted of showing two forms of ID and locking away all personal items; including wallets, bags, hats (if I had known this I would’ve combed my hair), and so on. I was then given a laminated piece of paper, a black dry erase marker, and an eraser which I was allowed to use during the exam. The exam ‘proctor’ then lead me to a computer, started the exam application, and wished me luck.

The exam was setup very similar to the practice tests. The screen displays the amount of time left, the current question number and the total number of questions. If you don’t already know, there are 70 questions to be completed in 90 minutes.

For each question you can check a box to mark for review, submit a comment to the test writers, and of course a place to answer the question. Answers range from: true/false, multiple choice, or fill in. Multiple choice can ask for more than one answer or ‘None of the above’ / ‘All of the above’, I hate that.

Since I cannot give you examples of actual questions, or any real detailed information about the questions asked, let just say you definitely need a good basis in the topics listed on the Zend Certification page (scroll to the bottom). You, of course, don’t need to know everything contained in the topics listed, but have the knowledge to make an educated guesses, when you run up against a question you don’t know.

After completing all the questions, a review screen is displayed which tells you the questions marked for review, and whether you answered the question. I get very apprehensive when taking exams, and have a tendency second guess all my answers, consequently my review screen showed that I had marked all but a few questions for review.

You then have options to ‘end the exam’, ‘review the questions marked’, or ‘review all questions’. Since I had about half the exam time left, I chose to review all questions.

On my second pass at the questions, I only left about 5 which I wanted to go over once more if I had the time, which I did.

Upon clicking ‘end exam’, it calculates your score, in about 5 (very long seconds), then displays whether you’ve passed or failed. Since I’m writing this post you should know that I passed, else I would have just never mentioned the exam again .

BTW – If you don’t already know, learn how to convert hexadecimal and octal, you may only have one question which asks, but it is one question you are guaranteed to get right, if you know how.

My first advice it to purchase the Practice tests, which are offered by Zend, and given by php|architect. I was originally just going to study for the exam from the multitude of books I currently own, but 10 tests for $22 USD, I figured WTF.

So far I have taken ( and passed:) ) 4 practice tests. What is most impressive is at the end of the exam, you get a break down of how you did on each section and what your final score would be if this were the real exam. Such as:

For each section (and the final grade) it is possible to receive: fail, pass, or excellent. I believe ‘fail’ and ‘excellent’ are fairly self explanatory. Pass means that you are within a narrow margin of the passing score and may want to refresh your knowledge of the material. As you can see, I need to do some studying on ‘streams and network programming’. Which is why you may have seen my request for a good tutorial about sockets, on twitter.

Another nice thing about the practice test is that you gives you a feel for the type of questions the exam will ask. I don’t want to say they are trick questions, but you really need to read the question and carefully review the code provided, because it is not always as simple as it seems. Let’s just say, if you saw the code in your everyday project you would be scratching your head wondering why the coder made the function so complicated, when it could be written so much more simply.

There is also a study guide published by php|architect. The study guide provides a nice overview of all the topics, divided into chapters corresponding to the sections of the exam. It should not be seen as a comprehensive resource of all the material on the exam, but is intended to provide a synopsis of the material and is sold as such.

You can purchase the study guide, practice tests, and an exam voucher in one bundle on zend.com, if you decide the study guide would be a benefit to you.

If you have already taken the exam, please comment and let everyone what the real exam is like.

As time moved on and I became more familiar with PHP I began to stop frequenting PHPBuilder and similar sites, preferring instead to go directly to the PHP documentation and figure out what needed to be done from there. This is both good and bad. I’m sure everyone has seen the comment ‘RTFM‘, but sometimes this is not the best option. The manual will tell you almost all you need to know about the technical specifications, but it will not tell you how different functionality relates and the best practices for using that functionality. This is why tutorials are sometimes a much better resource than the manual itself.

Back to the topic of PHPBuilder. At some point the site fell off my radar, and eventually lost its spot in my bookmarks. I had not visited in numerous years, but it recently appeared in some search results which brought it back to mind, so I decided to take a look around and see what happened to the site.

I am happy to report that the site has remained publishing complete and informative articles on many aspects of programming with PHP and has stayed true to being a resource for PHP developers.

A quick glance at the homepage gives the user a nice snap shot of what is going on in the PHP community as well as new additions to the articles section and the community forums.

There are a number of articles which were written as a series such as Peter Shaw‘s (1) “The ABC’s of PHP” which was written in ten different parts. If your new to PHP and looking for a good primer then I recommend this series. Of course many other topics are covered in the articles section which is broken down into different categories.

I casually browsed the community forums which are alive and well, and seem to have retained the friendly atmosphere I remember. Almost every post has at least one reply, which is always nice to see. One section of the boards that caught my eye was the Code Critique Forum. This is an extremely valuable resource for coders of all levels. I strongly believe this is one of (if not the) best way to become a better coder.

Another section which I do not recall PHPBuilder having is the Code Library. Here you can find code snippets (again broken down into categories) for many of the routine tasks which occur in projects. Even if you are not a fan of using code someone else wrote, reviewing code that others have written is a great way to learn.

Well that is about it, I encourage everyone to go to PHPBuilder and have a look around, I’m sure you will find something you’ve been looking for.

Just an FYI:

I have not and will never accept money for a review of any kind. All the opinions expressed here are mine.

I have been working with this client of a few years now and have a great rapport with them. For this most recent project they have no requirements about which JavaScript library to use just as long as it has the functionality which is required by the project. This left me in a little bit of a dilemma, which JavaScript library should I use?

I have tried many libraries in the past and had used the Yahoo! User Interface Library (YUI) extensively for a previous project. Although it’s a good library I have had the urge to try out Dojo. I first learned about the library when it came coupled with the Zend Framework. After a few small personal projects I never really used either again.

Doing a little research on Dojo‘s current capabilities and verifying that it has the functionality required for my project, I have decided to use Dojo and document my experience here. I’m hoping that even if you currently use a different JavaScript library that this set of posts will inspire you to try something new for a change.

My first task will be to build something similar to the ‘Suggest’ functionality on Google. This afternoon I attempted to find a good tutorial explaining how this is accomplished in Dojo, but could not locate exactly what I wanted. The problem seems to be that all the combo box / auto complete tutorials for dojo create a select menu rather than a simple text box and since this is going to be implemented for a search engine the select menu option is not actually an option. (Get it ‘select menu’, ‘option’…programming humor my wife loves it.)

Over the next few days I will be working on this project and will have one or two more posts detailing how I implement the functionality. If anyone has not heard of Dojo or has never used it here are a few links to get you started.

Dojo Links

• Homepage
• Download
• Documentation
• Hello World Tutorial

My next post will assume you already have Dojo installed and have worked through the ‘Hello World’ tutorial. Here are some brief notes about installing Dojo.

Dojo Installation

When installing Dojo you have three options

• Load the toolkit directly from AOL’s Content Distribution Network (CDN) or from the CDN of Google.
• Download and store the toolkit on your server
• Checkout a copy from the SVN repository (maybe not the greatest idea if your implementing on a live site)

I believe the first two options are completely viable for a live website and each have their pros and cons. I choose to download the toolkit and keep it on my server. The upside is that since I have the files locally I can open them up and browse through the code whenever I would like (you can learn a lot this way).

In my opinion…

When attempting to update an existing site with the newest gadgets available, it is best to take slowly. Implement a few updates at a time, without forcing the users to change the way they use the site. The response received from the users will tell you what is worth it and when you’ve gone too far.

The purpose of this new site remains to be; providing the beginner/intermediate web developer with a source of accurate and informative articles on web development, but will also focus on several new projects and groups which I recently began contributing to.

I hope you enjoy…

udid
|
|-> project
|    |-> branches
|    |-> tags
|    |-> trunk
|         |-> public_html
|         |-> Udid
|
|-> simpletest

Today we will be adding a directory structure for the actual application itself, which means we will be working in the udid/project/trunk/Udid directory. Just as a refresher the public_html directory is our document root and all our PHP code will be stored outside the root in the ‘Udid’ directory.

There is one thing I want to mention before we really get into it. As a general rule I like to define one class per file, this is not a hard and fast rule I adhere to, but for the most part one file = one class. Given this I will use the terms ‘class’ and ‘file’ almost interchangeable for this post.

OK now that that is out of the way…There are two directories I include in ALL my project and they are:

• Documents – this will hold all developer documentation for the project; code documentation, ‘to do’ lists, notes, etc.
• UnitTests – This of course will hold all the unit tests for the application code.

So now our Udid directory looks like:
Udid
|
|-> Documents
|-> UnitTests

Now it is time to make some design decision about the structure of the application code itself. The directory structure really should be looked upon as an organizational task, i.e. What is the best way to organize the files we will be creating? The organization needs to make sense to you or your team of developers. One way to test yourself when you are deciding on a structure is to attempt to explain it to someone (if no one is available then write it down). If you find yourself going back over parts of the structure or having trouble finding the words to truly explain everything, then it is probably time to go back and try to reorganize. (I guess this post will be a good test for me, huh?)

So here goes…

One of my pet peeves about many PHP applications is that the PHP, HTML, and CSS are completely muddled together. I have to admit the PHP community in general has been getting better at the separation of presentation and business logic, but in many personal project that I’ve seen this is still an issue. For this project we will be using a template system where we define actual HTML templates. Since we will need a place to hold these template files I create the directory ‘Templates’ beneath ‘Udid’.

I also know there will be generic classes we need to define which are not a part of any one section of the application, but are used by multiple aspects of the application such as database classes, iterators, an ‘emailer’ etc. These classes are also not limited to this one application, but can be used over and over again in project after project. I often think of these classes as books in a library, available to everyone. Consequently I will call the directory which holds these classes the ‘Library’.

Finally we will need a place to store all the core components of our application and I’ve decided to call this storage area the: ‘Core’. Honestly I’m not crazy about this name, in the past I’ve used; Engine, Backend, etc. but I don’t really like them either so for this project we are calling it ‘Core’.

We have now added three other directories and the current structure looks like this:

Udid
|
|-> Core
|-> Documents
|-> Library
|-> Templates
|-> UnitTests

We have one last directory to address and the base application structure will be complete. That directory is the ‘Core’. We cannot just start creating files in the ‘Core’ without some sort of organization or we’ll end up with an application core which consists of a long list of files with no organization except for maybe some naming conventions. Since this is where the majority of our development time will be spent, we need to define some parameters about where files should exist.

For this project we will be using the Model View Controller (MVC) design pattern. This is an organizational pattern to help separate different parts of the application code. As with all design patterns there is a lot programming theory associated with it and there is no way I can fully explain it here. If you are not familiar with this design pattern I urge you to search the net for more information. For our purposes the basic idea of each section is:

• Model – Contains application data and business logic. Objects which represent the data, and the processes to change that data.
• View – Extracts data from the model and shapes it for presentation.
• Controller – Receives requests and directs it for proper processing. Basically interpreting the request for the Model and View.

Since we will be using this pattern I have decided to create one directory for each section below ‘Core’. These will hold the files associated to each section. Now some may argue that the ‘Templates’ directory should be located below ‘View’, but I disagree. I want a place for templates that can easily be found, and is not located within the application code itself. I use this reasoning because I want other people who may not be PHP programmers to be able to find the templates and alter the display of the application.

There is one final directory I would like to include and that is a directory to hold phpDocumentor. We will use this to generate documentation for the code. This directory will be stored beneath the top ‘udid’ directory.

We have finally completed the development and application structure:

udid
|
|-> project
|    |-> branches
|    |-> tags
|    |-> trunk
|         |-> public_html
|         |-> Udid
|              |-> Core
|              |    |-> Controller
|              |    |-> Model
|              |    |-> View
|              |
|              |-> Documents
|              |-> Library
|              |-> Templates
|              |-> UnitTests
|
|-> simpletest
|-> phpdoc

We can now import this directory structure to SVN and export our working copy.

Thanks for reading. Until next time…

UDID – User Designed/Defined Information Directory
(Of course it is an acronym, you expected something else?)

There is a legitimate reason for naming the project before even setting up the development area. The project will be stored under the ‘Udid’ directory, and all of the class names will reflect the position of the file within the project’s directory structure. I will explain more about this when we get into writing classes and actually coding, but if you would like more information about this type of setup you can read about the Zend Framework naming conventions for classes.

OK now we have a name and it’s time to setup the directory structure. First we create the ‘udid’ directory and beneath that we create a ‘project’ directory; such as:

udid
|-> project

The ‘project’ directory will hold all the files directly associated to the project. The reason I have created this directory and did not just store the project code within ‘udid’, is because we will be using some third party applications to help with development and I do not want that third party code to actually be associated to the project code. For example we will be using Simple Test for unit testing. We will be placing Simple Test within ‘udid’, but not within ‘project’. So now we have:

udid
|-> project
|-> simpletest

As you know we will be using SVN to store the code, so we are going to be using what I learned as the traditional setup for a SVN project, not because it is the traditional way, but because I’ve used it before and it has worked well for me. This structure is:

project
|-> branches
|-> tags
|-> trunk

These three directories have very specific purposes:

• branches: Experimental development branches. Branches are used when you decide to make some dramatic changes to the code base, but your not really sure how it is going to work out, so you do not want to code within the ‘trunk’ but you may want to merge the code within the trunk at a later time.
• tags: This directory is used to store the project at certain milestones, i.e. version releases.
• trunk: Main development thread

So this is what our directory structure looks like so far:

udid
|
|-> project
|  |-> branches
|  |-> tags
|  |-> trunk
|
|-> simpletest

OK, for the rest of this post we will be working in the ‘trunk’ to setup the actual directory structure for the project code…

At some point a long time ago I got into the habit of creating a subdomain for each new project I work on, this I find convenient because the subdomain’s document root is its own and is not cluttered with other directories, files, etc. As an added bonus the document root can be anywhere on the system. Consequently the directories below ‘trunk’ look like this:

trunk
|-> public_html
|-> Udid

Obviously ‘public_html’ is the document root, and ‘Udid’ will store all the back-end PHP code. Notice the PHP code will be stored outside the document root (where a browser is unable to access it directly). I prefer to setup my projects this way as an added security measure. For more information about the security aspects of this; check out Chris Shiflett‘s article: Security Corner: Secure Design (be sure to read the comments).

For now ‘public_html’ will remain empty and ‘Udid’ will hold the directory structure for the application. So this will be the development directory structure we’ll be using…

udid
|
|-> project
|    |-> branches
|    |-> tags
|    |-> trunk
|         |-> public_html
|         |-> Udid
|
|-> simpletest

Please note, I have still not imported the project into SVN, you can actually do the import as soon as you have the first directory created, but I like to wait until I have the basic structure of the application set, which brings us to the topic of the next post. What is the directory structure of the application itself; or what directories will be created below Udid: ‘udid->project->trunk->Udid’?

I will post this structure in the next few days, and import the project into SVN, so we can finally get down to some code! Thanks for reading.

Even if we try to account for all aspects in the design phase, I know there will be situations where decisions made early on will have negative effects later down the road. I will document everything as it happens, because I find that I learn more from mistakes, and hopefully you will to.

I will mainly be working on this project solo, which means I will not only be dealing with PHP and MySQL, but also HTML, CSS, JavaScript, etc. Since I believe many developers work alone I hope that this will interest most readers.

I personally like to start a project with a name, simply because it gives the project an identity, but… In this case I cannot decide on an appropriate name so I am going to skip this step for the moment and move onto some actual code design, one of the most important and exciting steps.

First let’s set down some general guidelines:

• Version Control: Subversion (SVN)
• PHP Version: The project will be written in PHP5 and will not support PHP4. Let’s face it PHP4 is dead and if your server is still running 4 you NEED to upgrade.
• MySQL Version: I will be using MySQL 5, again if your not on 5, what are you waiting for?
• HTTP Server Platform: Apache
• Browser Support: Firefox, Internet Explorer, AOL Browser, Netscape, Opera, Safari. This is just a list off the top of my head, basically we are going to attempt to support as many browsers as possible.

Again these are just general guidelines; eventually the project will be able to support multiple database servers, different HTTP server platforms, etc. Initially these are our targets for support; no reason to bog the development process down with attempting to support everything under the sun, but… Since we want the project to be as flexible as possible, we will need to account for this NOW in our framework design.

OK, now that we have our guidelines; the next step will be to start coding right? Wrong, next we will decide on a directory structure, and create the SVN repository to hold our project.

I hope you are as excited as I am to get this thing underway, please check back soon.