As it is now, I end up having to use a painful combination of globalising long lists of variables, and preparing all code paths in functions and class members, but eval()ing it in the global scope.

There are still some instances where I really do have to run the code in a function scope — it is just too swkward to bend the code into the global scope, but despite tracking WordPress’ globals with each iteration, it turns out that the majority of plugins are written assuming that they themselves are in the global scope.

Then you have to clean up the mess they make afterwards.

The problem is that none of this can be undone — with tens of thousands of plugins and themes all working on the assumption that they are in the global scope, nothing will ever be able to wrap WordPress 100% cleanly and reliably.

WordPress in general has excellent, clean and easy to follow code, but this was a decision that has sent them down the wrong path. Forcing all plugins and themes into a function scope, while more painful initially, would have completely removed all of these issues.

Right now I have even resorted to “compiling” plugins — parsing the files before they are executed, grepping all the “global xxx” definitions, and proactively making them global before they are defined. Huge pain, but necessary if I want wordpress to run at specific points in a third-party application — e.g. during user authentication.

During my tenure as Chief Technology Officer at a medical imaging software company, I let the programming staff know that using a global variable was cause for termination. That’s how seriously bad a practice it is.

I won’t go into the details, but any global can be replaced by either passing a variable into a function, or in the case of a true singleton, a global function. Unfortunately, this will probably never happen because there is now so much code out there that relies on existing ones, which, by the way, is one of the real problems with globals. Once you start to use them, it’s very work intensive to get them back out. I’m surprised there hasn’t been more outrage from educated professionals on this subject.

And about WordPress 2: no need to search for my comments on it — I haven’t bothered to upgrade to WP 2 yet. And from what I’ve read about it around the net I’ll wait a bit more… (also because I have little time right now).

I read this entry a couple of months ago (searching for evidence why all-globals is bad), found it interesting, bookmarked it, and promptly forgot about it.

Recently I started hacking around in WP a bit, and my reaction was very similar to yours. Trying to “make things easier” for newbies by using all globals is foolhardy. Sure, you’re saving them learning a bit about OO — but you’re also training them that this is a good thing. I recognize that blogs are meant to be more accessible/hackable to the non-technical than other apps. But I still believe that “dumbing down” by using poor coding practices is a bad trade-off with spillover effects outside the particular project at hand.

WP 2 looks marginally better in this regard, but only marginally. I suppose I should search your blog and see if you’ve commented on it.

So whenever they are used, such connections must be prominently documented, and here — like in almost all other places in the WordPress code where I’ve looked — there were no comments in mysql2date() to indicate that locale.php must be loaded first.

I haven’t written a patch because I only just traced through the code this morning before heading to [Uni][eth], and because I’m not sure that just moving things around a little in wp-settings.php would be enough — I might mess up some other code elements which share a weak link.

The choice of mysql2date() was random, and I didn’t expect to find such a problem at first; I expected to use the function as an example of the kind of integrity checks that must be maintained when using global variables: have they been properly initialized. At first I thought that everything was fine, and that the variables were guaranteed to be loaded — but then I looked at the code again and realized that it wasn’t as bullit-proof as it appears.

As for your last point, then I think it’s pretty easy to say who is to be blamed if I don’t fully understand the call order in WordPress: the developers who neglected to comment their code. I know how to both read code and how to debug code — but I much prefer to do the first. Having comments in the code is a great way to make it readable.

About the scope rules of PHP, then I believe I can say that I indeed understand them. That’s not so hard afterall — they are documented in the manual.

In what way would you suggest that not using global variables would have fixed the problem with mysql2date()? Since you seem to have tracked down the issue to thoroughly to know the answer to this question, why haven’t you written a patch for the specified bug?

Your analysis of the failure of the plugins_loaded bug doesn’t mention that the plugin hook init is a better choice for the operation you’re trying to accomplish. plugins_loaded would let a plugin affect the locale settings, which would be impossible if the locale settings were loaded first. init occurs after the locale settings are set, and so manke much more sense for use in this case. Note that the call to sink init hooks is 23 lines down the file from the plugins_loaded hook.

So who can be blamed if you don’t fully understand PHP’s scope rules or WordPress’ call order?