We're using render_callback to return a form.
When the form renders on the frontend, it's business as usual. When the form renders in Gutenberg, we make a slight adjustment so that the fields are disabled since it's only for visual reference.
I'm not finding a easy or documented way to make the distinction inside the callback if it's being triggered from the Gutenberg editor. The easiest and most logical thing to me would have some similar DOING_AJAX type flag.
Right now we've resorted to checking if $_REQUEST['context'] exists and equals to edit, but that approach feels dirty.
I wanted to see:
1 - I'm missing something
2 - Thoughts on having a more straight forward (and documented) approach
There isn't a specific flag for this, but you're actually doing it pretty much how I'd suggest.
REST_REQUEST is defined, and true. This ensures that it's being rendered via the REST API. (The context URL parameter can be used outside of the REST API, so it's good to make sure.)$_REQUEST['context'] is set to edit. This should only be set by REST API clients that expect an editor-friendly response, it's also the method that the various REST API endpoints used to decide exactly what their response will look like.That's not very intuitive. In fact, I spent about three hours trying to figure out why neither is_admin(), get_current_screen()-> is_block_editor() nor any of the different workarounds worked for me.
Shouldn't there be a function like is_block_editor() that would be available in all the different contexts of the block editor ("regular" backend, render callback etc.)? Is there a matching issue I could follow?
I definitely agree the current approach is not intuitive at all.
I don't see why I have to do this manually across my various projects.
$is_gb_editor = \defined( 'REST_REQUEST' ) && REST_REQUEST && ! empty( $_REQUEST['context'] ) && 'edit' === $_REQUEST['context'];
I just spent a good few hours chasing down how to do this as well. If there's no intention of adding the functionality it would at least be nice to add it to the documentation for ServerSideRender.
I found the easiest way to differentiate between Editor and Frontend is this
if( function_exists( 'get_current_screen' ) ) {
// in editor
} else {
// in frontend
}
There's one more issue: when the Post is saving, it seems to run render_callback() and the condition above is detected as in Frontend.
The condition from @jaredatch also fail to detect it.
function_exists( 'get_current_screen' ) looks super fragile though :/
@stefanfisk That's true, but I haven't found a solution that works for non-API dynamic block.
The code from @jaredatch weirdly fails when the dynamic block doesn't call any API.
There are definitely better methods than that.
I ended up with:
$is_backend = defined('REST_REQUEST') && true === REST_REQUEST && 'edit' === filter_input( INPUT_GET, 'context', FILTER_SANITIZE_STRING );
Interestingly, there are two requests — only one of which has an edit context.
Most helpful comment
I definitely agree the current approach is not intuitive at all.
I don't see why I have to do this manually across my various projects.