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

Explore Editing Content Areas beyond the post content using Gutenberg. #13489

Closed
youknowriad opened this issue Jan 24, 2019 · 17 comments
Closed
Labels
Customization Issues related to Phase 2: Customization efforts [Type] Task Issues or PRs that have been broken down into an individual action to take
Milestone

Comments

@youknowriad
Copy link
Contributor

Sometimes, we refer to these as "page templates". The idea is to be able to edit a large content area within Gutenberg and save things in and outside post content.

If we consider the current Gutenberg editor as an editor bootstrapped with the following template (A template containing two blocks a post title block and a post content block)

[ { name: 'core/post-title' }, { name: 'core/post-content' } ]

From that point, Gutenberg should be able to be bootstrapped with any block template,. The blocks inside the post-content block would be saved into the post content (like today) and the blocks outside this area constitues a template object, that could potentially be saved to a template CPT.

@youknowriad youknowriad added this to the Future milestone Jan 24, 2019
@youknowriad youknowriad added [Type] Task Issues or PRs that have been broken down into an individual action to take Customization Issues related to Phase 2: Customization efforts labels Jan 24, 2019
@draganescu
Copy link
Contributor

draganescu commented May 2, 2019

@youknowriad isn't there a great overlap between sidebars (widget areas) and content areas? I ask because I imagine that if a theme registers header, footer and other areas all as widgets and, in the meantime, blocks in siderbars gets implemented, themes registering "content" areas becomes a bit useless.

@nathanrice
Copy link

@youknowriad Related to what @draganescu mentioned ... depending on how the decision falls on widget areas vs block areas, one could imagine that the block areas would need a way to limit what blocks are allowed in that block area.

For instance, if registering a "Header" block area, you might only want a heading, paragraph, or image ... and, alternatively, you might want to blacklist something like the "playlist" block, or others.

Am I thinking about this correctly?

@youknowriad
Copy link
Contributor Author

@nathanrice Good thinking yeah. I think this is something that we probably want build on top of the current InnerBlocks APIs (that probably needs to be improved). We have ways to restrict the available blocks in an innerBlock area using a prop.

@jasmussen
Copy link
Contributor

I took the liberty of creating a few mockups for this. I've tried my best follow existing patterns for the editing canvas but explore how it might look if all blocks existed inside theme-defined content areas, instead of everything existing inside post_content. It pictures a Header area instead of a Title area, but the principle would be the same.

Here we are, hovering the Header area:

Block Areas, header hovered

Here's what happens on click:

Block Areas, header selected

Note that the above mockup includes inspiration from #16998, #17088 and the breadcrumb bar from #17089.

@mapk mapk added the Needs Design Feedback Needs general design feedback. label Oct 8, 2019
@melchoyce
Copy link
Contributor

Would this be what you see when you edit a page, or is this a separate design interface?

@jasmussen
Copy link
Contributor

Would this be what you see when you edit a page, or is this a separate design interface?

Excellent question. I did some explorations for the Full Site Editing plugin, around that very question. On the one hand we have user-test data that suggest when you can see the whole page, footer, header and everything in the editor at once, it is intuitive and obvious for everyone to edit any part. On the other hand, there are use cases where you just want to tap out a quick post and not have to worry about the rest of the site. The challenge was: can we accommodate both? Based on an initial idea seeded by Matías, we landed on this idea, as yet unused:

Content Zooming

In this, the Preview button has been replaced with a "View dropdown", which defaults to Full Page, i.e. you see everything. But you can choose "Fit Content" to see just the post editor as you know it from today. Or you can choose the Preview Externally button, to see what you'd get with the Preview button today. This button would probably be dependant on the theme actually registering block areas in the first place.

@melchoyce
Copy link
Contributor

Ah, cool. I specified page because I imagined posts would continue to just exist in their standalone editor, and CPTs could specify which view they default to. In this case it sounds like posts and pages would be treated the same, correct?

We'll want to massage that microcopy a bit, but I dig the dropdown idea.

@jasmussen
Copy link
Contributor

jasmussen commented Oct 8, 2019

We'll definitely want to tweak and discuss and massage, the drop-down idea I also feel has potential, but it needs a good long time in the oven.

Edit: Forgot to answer your question:

In this case it sounds like posts and pages would be treated the same, correct?

My answer: maybe, probably. The drop-down could be there for both, but have different defaults. I think it's one of those answers we have to await it presenting itself.

@jasmussen
Copy link
Contributor

jasmussen commented Oct 9, 2019

One of the challenges we will face when you can edit multiple block areas in a single window is, how do we save changes? How do we make it obvious what changes you save? I've tried a couple of ideas, but none of them were sufficiently obvious. A notable challenge was figuring out how to make clear that you could make global changes while just editing a draft post. But then Riad came up with an idea which I have mocked up here:

Publishing Block Area Changes

Basically, if you only change the post or page, the Update button works as it always have.

But as soon as you make a change to a block area, the Update button opens a modal dialog that lists all the changes about to be published together. This solves the "draft post" conundrum by explicitly letting you choose which changes to publish — so the post or page can remain a draft even if you publish a change to the Header.

Future improvements could include a diffing/history tool right in that publish dialog.

@hacknug
Copy link

hacknug commented Oct 9, 2019

Pretty clever. Love the idea of (maybe, one day) being able to get visual diffs before saving <3

@oxyc
Copy link
Member

oxyc commented Oct 9, 2019

This would be great to use with reusable blocks as well, I've seen lot of users (me included) forget to press save on the block and instead continue on editing and just save the post.

@CalumChilds
Copy link

Just one question about this: would there be a separate interface for editing the site layout or would this appear on every single post or page that is being edited?

@enriquesanchez
Copy link
Contributor

@jasmussen Thinking about the option of 'Fit to Content' (and sorry if this is obvious), in the case where there's more than one section of content on a page, what would 'Fit to Content' do?

@jasmussen
Copy link
Contributor

Thinking about the option of 'Fit to Content' (and sorry if this is obvious), in the case where there's more than one section of content on a page, what would 'Fit to Content' do?

Not obvious, and one of the things to hash out. The current idea is that "Fit to Content" would show the editor exactly as it is today. Just post_content, no block areas. However depending on how things go, and this speaks to the question by @Wingo5315: you might want to edit individual block areas in isolation, i.e. just header, or just the footer. I'm not sure the dropdown would be the right place to navigate to those template parts, but it might be.

@mapk
Copy link
Contributor

mapk commented Mar 10, 2020

Looks like much of this is being tackled in more specific issues for full site editing. To review those issues, here's a link to the Project Board: https://github.com/WordPress/gutenberg/projects/35

I'm removing "Needs Design Feedback" for now.

@mapk mapk removed the Needs Design Feedback Needs general design feedback. label Mar 10, 2020
@youknowriad
Copy link
Contributor Author

Now that we've made some progress in this project, I'm closing this issue in favor of this overview issue #20791

@janw-me
Copy link
Contributor

janw-me commented Mar 22, 2021

This was what I was looking for, but how do I import the exported zip?
Anybody can point me in the right direction?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Customization Issues related to Phase 2: Customization efforts [Type] Task Issues or PRs that have been broken down into an individual action to take
Projects
None yet
Development

No branches or pull requests