Carrington Core¹ loads template files through a function rather than including them directly within the global scope. This means that global variables need to be explicitly brought into scope rather than just being there and available to you.

I’ve considered this a feature, because it means that you’re much less likely to stomp on an important WordPress global variable from within a template, and having the explicit declaration of which variables you want available makes things a bit easier to follow.

However, it also has drawbacks. For anyone already familiar with WordPress theming, there is a “this is broken” reaction when trying to access $post doesn’t work until they declare global $post;. I’m on the fence about which approach is better (enforcing better development best practices or making the platform more accessible to new devs), but I’ve been exploring some options (in case we decide a more accessible platform is better).

View the code on Gist.

You’ll see the three approaches I’m considering in the comments at the start of the function. Each has pros and cons.

Option #1: Selectively bring in globals. This was my initial solution. It makes a reasonable set of global variables available. However, if someone needs to hit a global we didn’t choose to include, I think that becomes more confusing. If the global $post was already in scope (without having to declare global $post;), why would they need to declare global $_wp_using_ext_object_cache; to get that variable?

Option #2: Bring all globals into scope. I think this is an interesting idea, but likely not a good solution. Developers would assume that these variables are global and run into surprises when they find out they aren’t.

Option #3: Bring in all globals. I’m leaning towards this, but it just feels wrong to me – likely due to an overall aversion to globals. It basically makes all templates loaded by Carrington Core work like standard WordPress templates. There is potential for confusion here since all of the globals are present and a developer can interact with them just like their template file is being loaded into the global scope; with a pretty big exception that variables created in the templates are not created in the global scope.

There is also a concern about this change causing problems with existing Carrington powered sites. Previously variables set in template files wouldn’t pollute the global scope or stomp on global variables. With options #1 and #3, this would be a possibility.

So I’m soliciting feedback. Fellow WordPress developers, what say you? Anyone have a “silver bullet” solution? Perhaps no action is the best action?

This post is part of the project: Carrington Core. View the project timeline for more context on this post.