Editing/removing templates (Reusable blocks)

[miina]

AC: User can save a Page as a template which will then appear with other pre-defined templates;
AC: User can remove and modify the custom templates;
AC: User can see only the templates added within the AMP Story, other Reusable blocks won't be available.

• Ensure "Save as template" is in context menu for a AMP story page, and instead of it being Saving as Reusable Block (See also [AMP Stories] Add template Inserter #2029 which might have this partly implemented)
• Make sure that Gutenberg only allows reusable blocks to be inserted at points where they are allowed.
• Make sure that the user can modify templates, the relevant blocks, settings, etc. have to exist for the edit page.
• Make sure that only the AMP Stories related Reusable blocks show up in the Inserters.

[westonruter]

• instead of it being Saving as Reusable Block

I don't think we should disallow saving a page as a reusable block. I can imagine it would be useful to be able to have a page re-used across multiple stories, with changes automatically kept in sync.

Still seems like reusable blocks provide the underlying data model we need. Could we not re-use it but then mark them as templates (e.g. adding some postmeta to the wp_block instances) to prevent them from being deleted and/or to present them in the list of templates to insert? At the same time, filtering down the list of reusable blocks to just pages would be simple even without such a postmeta flag.

[miina]

instead of it being Saving as Reusable Block

I think that what was meant here was just the text change (this point was copied from the note added by Thierry).

Another "issue" for reusable blocks is that they lock the template meaning that the added blocks' set can't be modified once inserted to the editor.

It seems like we could use the reusable blocks' logic for creating templates, however, for displaying and inserting to the editor and displaying we would need adjustments or different logic -- instead of inserting a locked template we would just need to insert a set of blocks, and instead of displaying an icon, we would need to display the preview in the "Template Inserter".

Yes, it seems like also the base "static" templates could be using the wp_block post type behind the scenes with an additional post meta which determines that it's locked (the template can't be deleted and perhaps hide it from the Edit Post list).

Note that depending on how much is publicly available in the API we might need to create our own copy of the logic anyway even for small adjustments.

[westonruter]

Another "issue" for reusable blocks is that they lock the template meaning that the added blocks' set can't be modified once inserted to the editor.

They can if you convert it into a regular block:

That essentially forks the reusable block.

It seems like we could use the reusable blocks' logic for creating templates, however, for displaying and inserting to the editor and displaying we would need adjustments or different logic -- instead of inserting a locked template we would just need to insert a set of blocks

So the inserter could present the list of special reusable blocks as templates when then convert to regular blocks prior to insertion?

[miina]

So the inserter could present the list of special reusable blocks as templates when then convert to regular blocks prior to insertion?

Alternatively, parse the content of the wp_block post directly for blocks and insert these as they are.

[swissspidy]

Make sure that the user can modify templates, the relevant blocks have to exist for the edit page.

Worth keeping in mind that it's not just the blocks that need to be available, but also additional UI elements like animation controls or our custom font family picker.

This means we most probably need an additional script that only contains a subset of the logic in amp-story-editor-blocks.js and is only enqueued when editing reusable blocks.

[miina]

Good point. I'm wondering if editing templates in a Modal directly in AMP Story interface would make more sense.

[miina]

@dawidmlynarz Would you mind creating a new view with the small addition of Edit and Delete icons on templates (as discussed) and adding it under this ticket?

[miina]

This means we most probably need an additional script that only contains a subset of the logic in amp-story-editor-blocks.js and is only enqueued when editing reusable blocks.

Any thoughts on which functionality we should omit for the reusable block (template) editor? It kind of would need almost all the functionality. Probably it would even need the template Inserter as well since a template could (or well, in the future will) consist of multiple pages and could be put together from different templates. Basically, a full Story could be a template.

I'm wondering if within editing a template the user should have the possibility to save a new template?
Thoughts?

cc @swissspidy @westonruter

[swissspidy]

I can go through our current list of components and filters tomorrow to see which ones are required and which ones are optional / nice to have. But yeah it seems like we need to require lots of the same things, which might blur the line between story editing and template editing quite a bit.

Re: save new template, I‘d say no, or at least not in the same way. The UI would need to be different as this is quite another context. Thus, I‘d leave this one for later.

[miina]

Hmm, but why not just bring everything over for editing the templates? In case of reusable blocks it's kind of the same -- the interface looks exactly as it looks like for editing a post. So maybe it makes sense that editing templates looks like editing a story.

I'm just thinking that we need all the same editing features and we also need reordering pages and also the Page should have the same ratio and size to look like a Page, etc.

That could be the easiest first step for how to make the templates editable and avoiding the interface breaking when going to an edit page. Maybe then hiding Template Inserter and disabling creating new templates within a template. I have serious doubts about having time to design a separate interface on time. (We could also disable the editing for time being but it still needs to work, ideally within this Sprint.) Thoughts?

What kind of differences had you in mind for the UI?

[swissspidy]

Why not just bring everything over for editing the templates?

withPrePublishNotice, withEditFeaturedImage, withStoryFeaturedImageNotice, are just some of the components that come to mind that would not be needed here. In the future, things like #2028 and #1995 might affect this too.

So maybe it makes sense that editing templates looks like editing a story.
I'm just thinking that we need all the same editing features and we also need reordering pages and also the Page should have the same ratio and size to look like a Page, etc.

Totally agree with that, and didn't mean to imply otherwise. The one thing about the "editing templates looks like editing a story" part is that we need to make sure it is clear for the user that they are editing a story and not a template, and vice-versa.

I have serious doubts about having time to design a separate interface on time.

My thought about the UI was simply that - since you are already editing a template - the possibility to save a new template based on that should probably to be exposed better instead of being hidden in the block toolbar. Nothing to do with designing a separate interface.

[miina]

The one thing about the "editing templates looks like editing a story" part is that we need to make sure it is clear for the user that they are editing a story and not a template, and vice-versa.

Good point, it could definitely get confusing.