There is a PHP error message so common that the web-o-sphere is littered with literally thousands of posts asking what it means. Dozens of WordPress plugins are affected as well as untold numbers of other applications written in PHP. I encountered this error in PHP apps so often that I have avoided PHP with almost a religious fervor. Today I think I understand the problem.

The PHP user base is constantly asking what these error/alert/notices mean. By and large these questions go unanswered. That indicates an unhealthy state of affairs for the end user. I have read many posts in the PHP community that say turning off the error display is an acceptable way to deal with these errors. I disagree.

Suppression of known faults is not a wise development practice. It leads to obscure problems that are hard to diagnose. It is worthwhile to add a little bit of code that does away with the notices while in debug or system configuration mode. Proper operation with error display enabled confirms that the application code is correctly dealing with environment state.

Here is a simple way to handle the condition in a deterministic manner. For the non-technical reader, please accept my apologies for the geek speak. For the technoids, I have tested this here with success. Your mileage may vary so check with your mechanic if something is less than perfect when you try it.

The Setup
WordPress 3.4.1 running on Apache 2 and Centos 5.
Any and all other plugins are deactivated

By the way, deactivating everything except the new plugin, or whatever, is highly recommended for installing any third party components in anything anywhere.

The Problem
Install something new via WordPress “Add new plugin” install feature. When you activate it WordPress reports “The plugin generated XXX characters of unexpected output during activation. If you notice “headers already sent” messages, problems with syndication feeds or other issues, try deactivating or removing this plugin.
Now there is a truly beneficent message. I wish the US Congress came with a warning like that. In WordPress, this means the program code did not load properly.

If the web site has the PHP error display feature enabled you are treated to the ever popular “undefined index” error in the top part of the web page:
Notice: Undefined index: GoThinGee in .../wp-content/plugins/wp-asaet/wp_amazingly_simple_and_easy_thingee.php on line XXX

Take a peek at the line mentioned in the error message; you are likely to find a snippet of code that looks something like this: if($_POST['GoThinGee']). “$_POST” is an array inside an IF statement. In most cases, the array will have stuff in it, including the value named “GoThinGee”. In the case we are looking at today the array is utterly empty and the error is that the index “GoThinGee” is not part of the array.

It only happens when the application is loaded. This can be considered a “threshold” or “initial state” problem.

The Solution
Adding a bit of defensive code to create a known state in the app environment is all that is needed to avoid the “undefined index” condition. This accomplished by assuring that the array $_POST has a set of index names with reasonable values.

In most applications, it is best to use a human readable value such as the string literal “undefined” to initialize the array. However, the application we used for this article has a large body of existing code that assumes a valid array of empty strings. Using a human readable term such as “undefined” would require changing a great deal of the existing code. For this reason, the initialization value is a pair of single quotes.

This extra code must be added prior to any evaluation of the array $_POST.

// August 20, 2012, mophilly; set default values to stop undefined index errors.
$default_string = '';
$_POST['GoThinGee'] = $default_string;

What this bit of PHP code does is add an index named “GoThinGee” if it does not exist. The new index is initialized with the value of $default_string.

I hope this helps someone.

Here is a link to an interesting article about Code Inspections.

Basically, the idea behind it is that you would take a random subset of specifications (usually about 5%) and have a team of 2-5 inspectors that were qualified to review the article and that would give a figure of the overall errors in the document.

Agile SQC Process

Entry Conditions

• A group of two, or more, suitable people* to carry out Agile SQC is assembled in a meeting.

• The people have sufficient time to complete an Agile SQC. Total Elapsed Time: 30 to 60 minutes.

• There is a trained SQC team leader at the meeting to manage the process.


P1: Identify Checkers: Two people, maybe more, should be identified to carry out the checking.

P2: Select Rules: The group identifies about three rules to use for checking the specification. (My favorites are clarity (‘clear enough to test’), unambiguous (‘to the intended readership’) and completeness (‘compared to sources’). For requirements, I also use ‘no optional design’.)

P3: Choose Sample(s): The group then selects sample(s) of about one ‘logical’ page in length (300 non-commentary words). Choosing such a page at random can add credibility – so long as it is representative of the content that is subject to quality control. The group should decide whether all the checkers should use the same sample, or whether different samples are more appropriate.

P4: Instruct Checkers: The SQC team leader briefly instructs the checkers about the rules, the checking time, and how to document any defects, and then determine if they are major defects (majors).

P5: Check Sample: The checkers use between 10 and 30 minutes to check their sample against the selected rules. Each checker should ‘mark up’ their copy of the document as they check (underlining issues, and classifying them as ‘major’ or not). At the end of checking, each checker should count the number of ‘possible majors’ (spec defects, rule violations) they have found in their page.

P6: Report Results: The checkers each report to the group their number of ‘possible majors.’ Each checker determines their number of majors, and reports it.

P7: Analyze Results: The SQC team leader extrapolates from the findings the number of majors in a single page (about 6 times** the most majors found by a single person, or alternatively 3 times the unique majors found by a 2 to 4 person team). This gives the major-defect density estimate. If using more than one sample, you should average the densities found by the group in different pages. The SQC team leader then multiplies the ‘average major defects per page density’ by the ‘total number of pages’ to get the ‘total number of major defects in the specification’ (for dramatic effect!).

P8: Decide Action: If the number of majors per page found is a large one (ten majors or more), then there is little point in the group doing anything, except determining how they are going to get someone to write the specification ‘properly’, meaning to an acceptable exit level. There is no economic point in looking at the other pages to find ‘all the defects’, or correcting the majors already found. There are simply too many majors not found.

P9: Suggest Cause: The team then chooses any major defect and thinks for a minute why it happened. Then the team agrees a short sentence, or better still a few words, to capture their verdict.

Exit Conditions

Exit if less than 5 majors per page extrapolated total density, or if an action plan to ‘rewrite’ the specification has been agreed.


* A suitable person is anyone, who can correctly interpret the rules and the concept of ‘major’.

** Concerning the factor of multiplying by ‘6 ‘: We have found by experience (Gilb and Graham 1993: reported by Bernard) that the total unique defects found by a team is approximately twice that of the number found by the person who finds the most defects in the team. We also find that inexperienced teams using Agile SQC seem to have about one third effectiveness in identifying the major defects that are actually there. So 2 x 3 = 6 is the factor we use (Or 3 x the number of unique majors found by the entire team).