Have you tried adding:
global $INFO;
… in both the config.php and the files in which you are referencing the array? I’ve had lots of problems, which I think are due to variable scoping settings of some sort (they only showed up when I upgraded to PHP5, brand new php ini…).
-d
Seth,
On another note, it’s good practice to prefix your own defined variables with something unique, to prevent them clashing with WordPress variables. Something like $MYVAR_INFO instead of just $INFO. You never know, WP might already have a variable named $INFO (it doesn’t) that would cause your variable to get wiped.
You might also benefit from defining your variables in a custom plugin, and activating the plugin.
– Sean
Thread Starter
Seth
(@seth)
davidchait: Yes, I’ve global’d everything properly, as can be seen by the fact it works when placed after the get_header() call. Something is destroying my global.
forceagainstsomething: I picked $INFO so that it wouldn’t clash with WordPress, but you’re right just the same. My functions use prefixes, though.
I really need this to be a drop-in solution, however, because it’s generic enough to work outside of WordPress, so a plugin is not the answer. Is there a function call somewhere that wipes globals or something?
Seth –
actually, it’s not clear. I find that if I have something included in via a function call (or other various methods) that declares a global, I still need to declare that global inside the file I’m referencing from.
so, for instance, you include your file directly in index.php and reference the global from index.php, everything works fine. INFO isn’t decl’d in index.php. However, you move the include into you header.php, which is actually pulled in via the get_header fn, and somewhere the scope is messed up. In that case, in both the included file AND in index.php I do something like:
global $INFO
… before referencing the thing in either file.
Again, this is something I’ve been having lots of problems with recently on my PHP5 Wampserver local install, yet code up on my hosted server doesn’t seem to run into the same issue. I’m just presuming something changed in how globals get auto-scoped (versus using the GLOBALS superglobal to access things…).
-d
