Gutenberg Shim

[gfargo]

• Modifies fm_add_script JavaScript dependencies to include wp-edit-post when Gutenberg is active.
• Includes new script to manually trigger FM fm_added_element event via wp.domReady

[dlh01]

This block will still run even when the screen is available if $current_screen->is_block_editor is false.

[jomurgel]

Even if $current_screen->is_block_editor is false, we'd hit the fallback which returns false also in my testing, which prevented anything from loading. 🤔 This seems like what it's supposed to do, no?

[dlh01]

Sure, I just mean that running the fallback seems redundant if WP_Screen already provided the answer.

[jomurgel]

Oh, right. I agree. Tbh I'm not certain why we have the fallback specifically since all posts should have access to it, but @gfargo might have more information for that.

The answer could be because of the note you left below:

Having said all that: I think fm_enqueue_scripts will also run on the frontend if any Fieldmanager assets are enqueued (via \Fieldmanager_Util_Assets::hook_enqueue()). If so, that could lead to cases where current_screen does not fire, but because the global post from get_the_ID() supports the block editor, wp-post-edit will be enqueued. That might be the intention here — maybe it's why get_the_ID() is used?

But I think in another note about how there is an is_admin() check-in \Fieldmanager_Util_Assets::add_script() to prevent loading on the front end may void that, and then the need for the fallback.

Testing locally, I don't actually find the need for the fallback, but not removing until there's a discussion about this from the author.

[dlh01]

• The use of a template tag seems unexpected here. What is the desired value? The ID of the post being edited?
• I think $GLOBALS['post_ID'] will exist only only in $_POST. For $_GET requests, the ID is in $_GET['post']. So, there is a possibility of undefined-index warnings, and I'm not sure whether the logic here captures all the needed cases.
• Also, any value from a superglobal will need sanitization.
• Having said all that: I think fm_enqueue_scripts will also run on the frontend if any Fieldmanager assets are enqueued (via \Fieldmanager_Util_Assets::hook_enqueue()). If so, that could lead to cases where current_screen does not fire, but because the global post from get_the_ID() supports the block editor, wp-post-edit will be enqueued. That might be the intention here — maybe it's why get_the_ID() is used?

[dlh01]

but because the global post from get_the_ID() supports the block editor, wp-post-edit will be enqueued

Pardon me: Not enqueued, but added as a dependency. However, if a script dependency is not enqueued, is the dependency enqueued, or does the script fail to load?

[jomurgel]

Made several updates here to tackle the following:

• Add a fallback for an older version of WP to avoid errors trying to access functions/properties that don't exist.
• Resolves PHPCS and PHPUnit errors.
• Addressed several notes above.

[jameswburke]

wp isn't always available when this fires.

[kevinfodness]

Fixed via #757