REST API in demo does not work due to late hook

[JasonTheAdams]

Greetings!

I'm getting familiar with this and testing things out. Having fun so far!

When I went to use the demo I found that the agent wasn't working because the REST endpoints introduced in the demo weren't being registered. After some inspection, I found that it's because the $proxy_instance->register_hooks() is being called inside of the wp_feature_api_init action callback, which occurs after rest_api_init has already fired.

My solution was to pull it out of the function and call it outside of any function — which makes sense since all it does it hook another function.

Wanted to let y'all know! If someone gives me a sense of how you would like it to work, then I'm happy to submit a PR.

[peterfabian]

Related debugging session findings:

WP Feature API alters the execution of WordPress actions, and maybe it shouldn't.

Normally in WP, this is the sequence of executing actions:

1. init starts
2. init:9999 (WP Feature API executes wp_feature_api_init here, if it's active)
3. init ends
4. parse_request, which calls
5. rest_api_init

Our plugin would execute during 2nd step (wp_feature_api_init) and hook the feature/tool to get it registered later at rest_api_init, running at step 4 (because it enumerates available tools based on registered REST API endpoints).

However, when WP Feature API is active, it instantiates the global WP rest_server object early, and rest_api_init isn't executed after init anymore. Instead, it's executed during init:10:

1. init starts
2. init:10: WP Feature API calls wp_feature_api_register_core_features here
3. This triggers rest_get_server() from WP_Feature::make via WP_Feature::get_rest_alias, which executes rest_api_init action
4. init:9999 executes wp_feature_api_init
5. init ends
6. parse_request
7. rest_api_init is NOT executed, because it's only executed if the global rest_server object doesn't already exist

Thus, anything adding a hook during wp_feature_api_init to register features 'later' at rest_api_init will fail to register them properly.

There is a possibility to add a workaround to our plugin, but it feels like changing the order of actions in WP is probably not desirable here.

Maybe a good solution for wp-feature-api would be to run wp_feature_api_init later (perhaps at rest_api_init:99+) and hook wp_feature_api_register_core_features to wp_feature_api_init.

Similarly, I think WP_Feature_API_Init::register_rest_routes should probably run later than on init:9999, potentially also at wp_feature_api_init. I have a feeling the only reason this call doesn't fail now is because registering the default features forces rest_api_init too early (during init:10).

[JasonTheAdams]

Thanks for laying that out, @peterfabian! I agree, changing the default order of operations for booting WordPress is not ideal. I'd certainly avoid it if possible.

[peterfabian]

Hey @JasonTheAdams , can you please confirm if the latest release solves the problem for you? Thx!