Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Edit Site: New template creation flow. #22586

Merged
merged 6 commits into from
May 28, 2020

Conversation

epiqueras
Copy link
Contributor

Description

This PR continues the work to make page template navigation in the editor page-centric.

#22368, #22449, and #22543 implemented functionality for navigating between pages while resolving and loading their templates. The current template switcher that lets you select from any of your templates doesn't make a lot of sense anymore.

This PR modifies the template switcher to better align with the new page-centric navigation. Now it will only show the currently resolved template and the option to overwrite it for the current page or to revert overwrites.

This means that you can have a category template for all your categories, a page template for all your pages, a post template for all your posts, and then spin up variations for specific categories, pages, or posts, with the click of a button. Then, you can revert just as easily. The GIF below demonstrates the process for a category.

Testing this PR required changing between lots of templates, and this helped catch some related bugs that were solved with a bit of hardening:

  • The lib/compat.php hook that checks for category queries now works for both category slugs and IDs.
  • The site editor now sets an empty query context when there isn't any so that stale rerenders with query blocks don't throw errors by trying to access an undefined object.
  • The useBlockSync hook now guards against potential race conditions:
// Sometimes, when changing block lists, lingering subscriptions
// might trigger before they are cleaned up. If the block for which
// the subscription runs is no longer in the store, this would clear
// its parent entity's block list. To avoid this, we bail out if
// the subscription is triggering for a block (`clientId !== null`)
// and its block name can't be found because it's not on the list.
// (`getBlockName( clientId ) === null`).
if ( clientId !== null && getBlockName( clientId ) === null )
    return;

How has this been tested?

It was verified that the flow shown in the GIF works as expected and that nothing breaks or is cleared when switching between templates.

Screenshots

gif

Types of Changes

New Feature: The site editor's navigation continues to improve, and now supports spinning up variations of the current template for the current page.

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.
  • I've updated all React Native files affected by any refactorings/renamings in this PR.

@epiqueras epiqueras added [Feature] Full Site Editing [Type] Feature New feature to highlight in changelogs. labels May 24, 2020
@epiqueras epiqueras requested a review from noahtallen May 24, 2020 00:12
@epiqueras epiqueras self-assigned this May 24, 2020
@epiqueras epiqueras force-pushed the add/new-site-editor-template-creation-flow branch from de9a3f6 to 782f2b6 Compare May 24, 2020 00:13
@github-actions
Copy link

github-actions bot commented May 24, 2020

Size Change: +56 B (0%)

Total Size: 1.12 MB

Filename Size Change
build/block-directory/index.js 6.48 kB -1 B
build/block-editor/index.js 105 kB +12 B (0%)
build/block-library/index.js 119 kB -4 B (0%)
build/blocks/index.js 48.1 kB +3 B (0%)
build/components/index.js 190 kB +2 B (0%)
build/core-data/index.js 11.4 kB +1 B
build/data-controls/index.js 1.29 kB +4 B (0%)
build/data/index.js 8.42 kB -2 B (0%)
build/edit-navigation/index.js 6.63 kB +5 B (0%)
build/edit-site/index.js 14 kB +34 B (0%)
build/format-library/index.js 7.71 kB +1 B
build/list-reusable-blocks/index.js 3.13 kB +3 B (0%)
build/media-utils/index.js 5.29 kB +2 B (0%)
build/nux/index.js 3.4 kB +1 B
build/rich-text/index.js 14.8 kB -4 B (0%)
build/server-side-render/index.js 2.67 kB -1 B
ℹ️ View Unchanged
Filename Size Change
build/a11y/index.js 1.14 kB 0 B
build/annotations/index.js 3.62 kB 0 B
build/api-fetch/index.js 3.4 kB 0 B
build/autop/index.js 2.83 kB 0 B
build/blob/index.js 620 B 0 B
build/block-directory/style-rtl.css 788 B 0 B
build/block-directory/style.css 788 B 0 B
build/block-editor/style-rtl.css 11 kB 0 B
build/block-editor/style.css 11 kB 0 B
build/block-library/editor-rtl.css 7.21 kB 0 B
build/block-library/editor.css 7.21 kB 0 B
build/block-library/style-rtl.css 7.68 kB 0 B
build/block-library/style.css 7.68 kB 0 B
build/block-library/theme-rtl.css 684 B 0 B
build/block-library/theme.css 686 B 0 B
build/block-serialization-default-parser/index.js 1.88 kB 0 B
build/block-serialization-spec-parser/index.js 3.1 kB 0 B
build/components/style-rtl.css 17.1 kB 0 B
build/components/style.css 17.1 kB 0 B
build/compose/index.js 9.31 kB 0 B
build/date/index.js 5.47 kB 0 B
build/deprecated/index.js 771 B 0 B
build/dom-ready/index.js 568 B 0 B
build/dom/index.js 3.11 kB 0 B
build/edit-navigation/style-rtl.css 857 B 0 B
build/edit-navigation/style.css 856 B 0 B
build/edit-post/index.js 302 kB 0 B
build/edit-post/style-rtl.css 12.2 kB 0 B
build/edit-post/style.css 12.2 kB 0 B
build/edit-site/style-rtl.css 5.52 kB 0 B
build/edit-site/style.css 5.53 kB 0 B
build/edit-widgets/index.js 8.05 kB 0 B
build/edit-widgets/style-rtl.css 4.59 kB 0 B
build/edit-widgets/style.css 4.59 kB 0 B
build/editor/editor-styles-rtl.css 425 B 0 B
build/editor/editor-styles.css 428 B 0 B
build/editor/index.js 44.6 kB 0 B
build/editor/style-rtl.css 5.06 kB 0 B
build/editor/style.css 5.06 kB 0 B
build/element/index.js 4.65 kB 0 B
build/escape-html/index.js 733 B 0 B
build/format-library/style-rtl.css 502 B 0 B
build/format-library/style.css 502 B 0 B
build/hooks/index.js 2.13 kB 0 B
build/html-entities/index.js 622 B 0 B
build/i18n/index.js 3.56 kB 0 B
build/is-shallow-equal/index.js 711 B 0 B
build/keyboard-shortcuts/index.js 2.51 kB 0 B
build/keycodes/index.js 1.94 kB 0 B
build/list-reusable-blocks/style-rtl.css 226 B 0 B
build/list-reusable-blocks/style.css 226 B 0 B
build/notices/index.js 1.79 kB 0 B
build/nux/style-rtl.css 616 B 0 B
build/nux/style.css 613 B 0 B
build/plugins/index.js 2.56 kB 0 B
build/primitives/index.js 1.5 kB 0 B
build/priority-queue/index.js 789 B 0 B
build/redux-routine/index.js 2.85 kB 0 B
build/shortcode/index.js 1.7 kB 0 B
build/token-list/index.js 1.28 kB 0 B
build/url/index.js 4.02 kB 0 B
build/viewport/index.js 1.84 kB 0 B
build/warning/index.js 1.14 kB 0 B
build/wordcount/index.js 1.17 kB 0 B

compressed-size-action

Copy link
Member

@noahtallen noahtallen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really cool stuff here! Not really any major concerns from me. As we've been mentioning, moving a lot of this logic into a store would make the code cleaner and separate "business logic" from the UI components a bit better. But that's a separate task. I also imagine the UI for this will eventually change, so I'm not all that concerned about how it looks or its UX. I think the main thing is adding a way to override a template in the first place

/**
* WordPress dependencies
*/
import { useSelect, useDispatch } from '@wordpress/data';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting, so instead of creating an arbitrary template, we would now have to override the base template level-by-level on a certain page type until we get to the desired specificity? I imagine we'll want to make it easier to "zoom in really far" in one go in the future

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are only two levels of specificity:

  • Page type, e.g., category, page, post.
  • Page-specific, e.g., a specific category, specific page, specific post.

@@ -33,8 +33,13 @@ export default function PageSwitcher( {
const path = getPathFromLink( _page.link );
return {
label: _page.title.rendered,
type: 'page',
slug: _page.slug,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the template slug?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The page slug.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🙃 I realized that's what the variable is called, but was originally wondering if it had to do with the page page instead of the page cpt

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, the page page's slug is the same as the page CPT slug in this case. It's what we need to generate its specific template slug.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, that makes sense

import TemplatePreview from './template-preview';
import ThemePreview from './theme-preview';

const TEMPLATE_OVERRIDES = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the path forward for supporting more of the possible overrides in the template hierarchy? Will we just add more keys here, or make it more dynamic?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both are viable. It depends on what templates we need to support.

} );
onAddTemplateId( newTemplate.id );
};
const unoverwriteTemplate = async () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably prompt the user for confirmation before deleting a template

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think we need to work it into the "Review Changes" sidebar somehow.

@@ -175,15 +202,6 @@ export default function TemplateSwitcher( {
</>
) }
</DropdownMenu>
<AddTemplate
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removing this will definitely break the dirty state entity e2e tests. Not sure what the best path forward is for those e2e tests considering that the UI is likely to continue changing a lot.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we update them to use the API directly?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 Maybe? Like the WP API or the block-editor API? I feel like the e2e test ought to be going through real user actions at the end of the day. Otherwise, the unit tests on useBlockSync would be good enough, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I agree. It's just that the UI will probably change a lot with the new designs coming up. Using the WP API, for now, would let us have some sort of safety net, without having to have significant test rewrites as we iterate.

That said, we don't have that many tests right now, I think it makes sense to update them in this PR.

};
const unoverwriteTemplate = async () => {
await apiFetch( {
path: `/wp/v2/templates/${ template.value }`,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the core/data controls handle this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah

@epiqueras
Copy link
Contributor Author

@noahtallen Can you take a look at why the tests are failing, please?

It's not even opening the inserter.

@epiqueras
Copy link
Contributor Author

@noahtallen Fixed them! This is ready for review 🚀 🚀 🚀

Copy link
Member

@noahtallen noahtallen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's pretty incredible how flexible the entity system is. In the site editor I can open a category page showing a list of posts and update the post content of a post right from there. I can even update reusable blocks inside of post content. It's pretty cool that it works!

Overall, I think this is an improvement in that it forces you to only create templates that will actually work with your site's pages. (So you can't create dangling templates that you won't see any more.)

On the other hand, I found it difficult to navigate back to the "home page" or index template, because at first I didn't know which entity to select to see it. how easy would it be to add a "home" icon to the current homepage?

One final thing I noticed is this bug, where you can't select "All posts" after selecting "sample page":

Screen Shot 2020-05-27 at 3 11 13 PM

That console error logs every time I click "all posts".

Additionally, I noticed the whole editor screen flashes white when you navigate to "sample page" at first. Is something causing the editor component to remount?

@epiqueras
Copy link
Contributor Author

On the other hand, I found it difficult to navigate back to the "home page" or index template, because at first I didn't know which entity to select to see it. how easy would it be to add a "home" icon to the current homepage?

9ffec57

One final thing I noticed is this bug, where you can't select "All posts" after selecting "sample page":

8640002

Additionally, I noticed the whole editor screen flashes white when you navigate to "sample page" at first. Is something causing the editor component to remount?

Yes, the entire block list is changing. I don't see white, though; I see the editor's background color.

@noahtallen
Copy link
Member

Yes, the entire block list is changing

Interesting. I wasn't really expecting the toolbar and stuff to disappear when that happened.

Nice home icon. Gets the job done for now!

Copy link
Member

@noahtallen noahtallen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving with the expectation that designs will improve in the future and that we'll be able to clean up the code a bit more by integrating it to the edit-site store

@epiqueras epiqueras force-pushed the add/new-site-editor-template-creation-flow branch from 9ffec57 to 72de844 Compare May 28, 2020 17:32
@epiqueras
Copy link
Contributor Author

The failed tests are unrelated. I think they are caused by an axe update.

@epiqueras epiqueras merged commit 30cd85a into master May 28, 2020
@epiqueras epiqueras added this to Done in Phase 2 via automation May 28, 2020
@epiqueras epiqueras deleted the add/new-site-editor-template-creation-flow branch May 28, 2020 18:20
@github-actions github-actions bot added this to the Gutenberg 8.3 milestone May 28, 2020
@ellatrix ellatrix mentioned this pull request Jun 16, 2020
12 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Feature New feature to highlight in changelogs.
Projects
No open projects
Phase 2
  
Done
Development

Successfully merging this pull request may close these issues.

Removing a Template Part dirties the entity state with inner content removed.
2 participants