Is there a plugin specific way of modifying the superglobals in a direct manner prior to them being used? Assuming the following code was in a plugin called aaa, one might imagine that this would run quite early in the request lifecycle. While the code runs, when other plugins use the data it has not been altered.

// file location: wp-content/plugins/aaa/aaa.php

function interfere_with_things(){

    // skip anything not applicable
    if($_SERVER['REQUEST_METHOD'] !== 'POST' || empty($_POST['something'])){return;}

    // change something in the $_POST
    $_POST['something'] = str_replace('cats', 'dogs', $_POST['something']);

}

add_action('init', 'interfere_with_things', 1);

Is there a plugin specific way of modifying the superglobals in a direct manner prior to them being used? Assuming the following code was in a plugin called aaa, one might imagine that this would run quite early in the request lifecycle. While the code runs, when other plugins use the data it has not been altered.

// file location: wp-content/plugins/aaa/aaa.php

function interfere_with_things(){

    // skip anything not applicable
    if($_SERVER['REQUEST_METHOD'] !== 'POST' || empty($_POST['something'])){return;}

    // change something in the $_POST
    $_POST['something'] = str_replace('cats', 'dogs', $_POST['something']);

}

add_action('init', 'interfere_with_things', 1);

• wp-query

• What variables are you changing that other plugins would using? 'something' is not a WordPress global, or one that other plugins would use. Do you have a specific example? – Jacob Peattie Commented Mar 27, 2020 at 5:52
• Are you the one responsible for defining the data that exists in the superglobals or is it from another plugin or theme? – Adam Commented Mar 27, 2020 at 7:06

1 Answer 1

Yes, there are points during the WordPress request life-cycle that provide hooks for you to make modification to the request and other parameters available, more on that in just a moment.

Consideration...

You can modify superglobals, as you are aware, but in doing so you may be introducing unexpected behaviour into your application especially if you are performing sanitization/validation on a key-value pair in one area of your application but which is then accessed in another area of your application, using different superglobals, be it under your control or the control of another plugin (or theme).

For example you may do:

// assume value of: $_POST['something'] → cats
$_POST['something'] = str_replace('cats', 'dogs', $_POST['something']);

And someone else does:

// value is now: $_POST['something'] → dogs
echo $_REQUEST['something']; // → cats

If someone else (or you) unintentionally uses $_REQUEST instead of $_POST, you can expect different results if you have not altered both superglobals.

Recommendation...

I'd recommend you change your approach to modifying data by determining:

• what your actual use case is
• who needs to use the data (you only and or other plugins/themes)
• determine a logical entry point for where that data is made accessible to others

Here is a (contrived) example:

function someone_else_interfere_with_things( $data ) {
    return 'megaladons';
}

add_filter( 'interfere_with_things', 'someone_else_interfere_with_things', 10 );

function interfere_with_things() {
    // ... do sanity checks here

    $data = isset( $_POST['something'] ) ? $_POST['something'] : 'default';
    $data = apply_filters( 'interfere_with_things', str_replace( 'cats', 'dogs', $data ) );

    echo $data; // megaladons!!!
}

add_action( 'init', 'interfere_with_things', 1 );

Other plugins/themes or elsewhere in your own code, you then rely upon the custom filter interfere_with_things where there is a common understanding that at this point other code can expect to modify values in a prepared state that is consistent.

If someone else then goes off and pulls things out of superglobals, that's on them at that point.

Alternative hooks to init

If you are still set on modifying globals earlier in a request life cycle then you may want to consider other hooks such as:

• plugins_loaded
• after_setup_theme
• request
• parse_request
• among others...

All of which fire earlier than init.