WP::register_globals and reserved names

  • Jamie Perrelet

    (@perrelet)


    1 year, 1 month ago

    Ahoy all,

    I’m reading through the process of how WP constructs it’s main query and have a question regarding the global variables registered in WP::register_globals. This method extracts all the query_vars from the main query and dumps them into the global space:

    // Extract updated query vars back into global namespace.
foreach ( (array) $wp_query->query_vars as $key => $value ) {
    $GLOBALS[ $key ] = $value;
}
    1. What is the reason for this?

    I see that in https://codex.wordpress.org/Global_Variables there is a reserved name list, however the global scope is populated with far more variables than is listed there. For example, the $perma_query_vars are broadcast as globals.

    2. Is the reserved name list exhaustive? i.e Do devs need to be concerned with overwriting any of the other global variables?

    Thanks,

    J

Viewing 4 replies - 1 through 4 (of 4 total)
  • Moderator bcworkz

    (@bcworkz)

    1 year, 1 month ago

    I don’t know the true reason, sorry. I speculate it’s simply for the convenience of various functions that need access to query vars that would otherwise be out of scope.

    The list in the Codex is by no means comprehensive. To avoid possible conflicts with other names, it’s recommended that you prefix all names with some brief, unique string that identifies your particular plugin or theme. For example, my plugin named “Most Awesome Plugin” (map) wants to assign a custom post object to a new global variable. If I used $post, that would mess up all sorts of functions that assume it’s the WP core global $post. So I would name my global $map_post to avoid any conflicts.

    Alan Fuller

    (@alanfuller)

    1 year, 1 month ago

    2. Is the reserved name list exhaustive? i.e Do devs need to be concerned with overwriting any of the other global variables?

    Devs should be concerned with the not over populating the global name space and whildt prefixing is OK in the above example $map_post may conflict with a plugin that handles maps etc.

    Using a namespaced class returning statics is the method I choose to avoid globals.


    Thread Starter Jamie Perrelet

    (@perrelet)

    1 year, 1 month ago

    Thanks for your 2 cents guys. For clarity, I’m asking the question because the answer has implications for a framework we’re currently working on. One of the framework’s features provides the ability to easily define CPTs alongside the structure of an associated model. Like many frameworks, the only code in the global namespace are the view templates themselves. Right now, accessing the instance of a model within a view looks something like:

    $model = Model::get_instance();
$model->get_something();

    We had the thought that it world be much neater if for main queries for a given CPT, the correct model was automatically injected into the global scope. For example, if you have a CPT called ‘event’ and the client requests the ‘events/some-event’ page, a global $event variable would be instantiated with a value holding the correct instance of the associated model. The instantiation would happen at ‘template_redirect’ to provide access to all views:

    <h1><?= $event->get_title() ?></h1>

    The clinch here is that because WP injects  $perma_query_vars into the global space, there will already exist a global $event variable with a string value of ‘some-event’.

    Thus we wish to specifically know whether it is safe to overwrite this type of global variable?
    🙏

    Alan Fuller

    (@alanfuller)

    1 year, 1 month ago

    would having 

    $my_framework_data->event->get....

    be a solution for you?

    (it’s sort of how my plugins do it for template data $data->event except $data is not globally scoped, just scoped for the template handler)

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘WP::register_globals and reserved names’ is closed to new replies.