Closed tbradsha closed 2 months ago
This sounds like a great idea, @tbradsha
This is a great idea that would also unlock "open in a new window" option – it's a blocker for enabling the block on learn.wp.org. See the discussion at https://github.com/WordPress/Learn/pull/2264#issuecomment-1978637591 for more details.
Technically, I can think of two solutions:
Upvote. Would love to see this keep moving. I know the solution won't be quick but it will be the best one for the future. Even live chat iFrames have this feature and it makes the experience 100% contained and much more accessible.
Thanks.
Technically, I can think of two solutions:
- The plugin would register a new user-facing page that would render a single block with query-provided parameters.
- A version of the code editor + preview could be hosted on, say, playground.wordpress.net/editor.html – that way anyone could embed it in any context.
I think both 1 and 2 are good ideas, but for consistency within the plugin, I think it is better to provide a user-facing page on the same server so the code editor version is consistent with the one shown in the original block.
Planning to work on this.
I am focusing on this now. I've done a lot around WordPress but haven't don't have any experience with rendering a completely custom page for the front end.
The current plan is to:
@adamziel @bgrgicak please let me know if you'd recommend a different or simpler path.
Does that mean that every page preview will generate a temporary page?
It would be great to avoid DB writes if we can.
If I would build this I would try to do it like this:
something.com/current-post/?playground-preview={steps[]}
playground-preview
query string` I would override the templateplayground-preview
and load PlaygroundThe template would probably be something like this:
wp_head();
// Load Playground here
wp_footer();
The Sandbox plugin does something similar but it uses a admin page.
Does that mean that every page preview will generate a temporary page?
It would be great to avoid DB writes if we can.
The idea was to just be hooking into the rendering of an in-memory WP_Post object that is never persisted to the database.
The template would probably be something like this:
Thanks, @bgrgicak! The example helped me remember wp_head()
and wp_footer()
.
It looks like something like this should work well enough without requiring use of templates:
add_action( 'init', 'playground_demo_block_init' );
function playground_demo_render_full_page() {
wp_head();
// NOTE: Actually block attrs should be taken from query params
$block = array(
'blockName' => 'wordpress-playground/playground',
'attrs' => array(
'align' => 'full',
'codeEditor' => true,
'constants' => 'eyJXUF9ERUJVRyI6dHJ1ZSwiV1BfU0NSSVBUX0RFQlVHIjp0cnVlfQ==',
'files' => array (
'W3siY29udGVudHMiOiIiLCJuYW1lIjoidGVzdC54eXoiLCJyZW1vdGVVcmwiOiIifSx7ImNvbnRlbnRzIjoiIiwibmFtZSI6ImluZGV4LmpzIiwicmVtb3RlVXJsIjoiIn1d'
),
),
'innerBlocks' => array (),
'innerHTML' => '',
'innerContent' => array (),
);
echo render_block( $block );
wp_footer();
die();
}
if ( isset( $_GET['playground_full_page'] ) ) {
add_action( 'init', 'playground_demo_render_full_page', 9999 );
}
I have a good start on this and plan to create a draft PR for it in the morning. Besides styling and UI tweaks, the main remaining problem is that the full page version isn't showing the correct files.
This is working well, can close.
Right now the block-viewing experience is limited to its iframe container. It'd be nice to have a user-facing link to launch a full window version.