Remove PHP5 warnings about unassigned variables and functions being used

These patches don't apply to HEAD and problem exists in HEAD as well.

A single patch should be made that fixes all of these in HEAD. I'll see what I can do, this is a good start.

fgm, I changed the status on this to CVS since this bug exists in *both* CVS and 4.6.3. To the best of my knowledge, patches like this will only be incorporate in HEAD since they don't adversly affect 4.6.3. However, to keep this distinction clear, I've created a new patch for HEAD, found here: http://drupal.org/node/30930 ... this patch should make it into core for the 4.7 release, just an FYI. If you would like, we could really use your help testing this patch for HEAD so we get right before 4.7 is released. Thanks!

Issue 30930 did not cover the empty()s and isset()s that this bug did. Attaching a new patch for HEAD.

This also resolves an issue where "Array" would print at the end of the various different block areas in PHP 5.1.0. In theme_blocks(), a call to drupal_get_content() was returning Array, which was being concatenated to the rest of the block content. While I think irregardless, the empty() test I added to the end of theme_blocks still applies, discovering the reason drupal_get_content() is returning Array might need more eyeballs in a separate issue.

This also resolves an issue where "Array" would print at the end of the various different block areas in PHP 5.1.0. In theme_blocks(), a call to drupal_get_content() was returning Array, which was being concatenated to the rest of the block content. While I think irregardless, the empty() test I added to the end of theme_blocks still applies, discovering the reason drupal_get_content() is returning Array might need more eyeballs in a separate issue.

Please see this: http://drupal.org/node/34907

Yeah, I just saw that when I went back to the issue list. 34907 seems to fix the Array thing and does not seem to conflict this issue's patch.

Can confirm that this patch applies cleanly over the 34907 patch in HEAD. Any test case I can use? Where were you seeing errors?

The only error I saw wasn't in the original modules_4.patch. In theme.inc, line 512, I got

implode() [function.implode]: Bad arguments. in E:\Web\drupal\includes\theme.inc on line 512.

when adding a comment to a page at ?q=comment/reply/1.

Otherwise, I didn't see errors directly related to this issue. I was just trying to re-roll this issue to work with HEAD in response to http://drupal.org/node/34434 since there have been so many changes to the source. I haven't even submitted a PHP 5.1.0 related patch yet since I wanted to be sure the heated discussion about PHP 5.1.0 compliance on drupal-devel@ died down. I think this issue is more about trying to more clearly define what is being tested in cases of if($var) since you can't tell from that if you're testing for a bool, int, string, array, etc.

Like I said in http://drupal.org/node/30930, it's hard to tell sometimes whether an if statement needs isset, empty, is_null, or something else. That's why I left this and 30930 as code needs review. I was surprised to see Dries commit 30930 so quickly.

1. Why did you change:

-  if ($op == t('Preview')) {
+  if ($op === t('Preview')) {

2. Write 'TRUE' not 'true'.

3. Coding style: use of spaces, write $n++:

+  for ($n = 0; $n < $depth; $n+=1) {

4. What is the monster change to theme_links() about?