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

Query block: Allow inheriting the global query arguments #27128

Merged
merged 26 commits into from
Dec 8, 2020

Conversation

aristath
Copy link
Member

@aristath aristath commented Nov 20, 2020

Description

Fixes #25377

Related: #25790.

Adds a setting to customize the query, or inherit the global query.

What needs to be done:

  • Add a setting to toggle global or custom query
  • Default to inherit the global query
  • Write deprecation script so for existing query blocks the new setting defaults to custom-query instead of global
  • Figure out what to show in the preview <-- This is the real blocker

Peek 2020-11-20 10-29

Types of changes

  • Added a checkbox to enable custom-queries (disabled uses the global query)
  • Breaking change: Existing query blocks will default to the global query (see comment below for the default value.

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.

@aristath aristath changed the title Add a "customize query" checkbox Allow inheriting the global query arguments Nov 20, 2020
@github-actions
Copy link

github-actions bot commented Nov 20, 2020

Size Change: +119 B (0%)

Total Size: 1.21 MB

Filename Size Change
build/block-editor/index.js 128 kB +40 B (0%)
build/block-library/index.js 149 kB +221 B (0%)
build/block-library/style-rtl.css 8.35 kB +6 B (0%)
build/block-library/style.css 8.35 kB +4 B (0%)
build/components/index.js 172 kB -5 B (0%)
build/components/style-rtl.css 15.3 kB -2 B (0%)
build/components/style.css 15.3 kB -2 B (0%)
build/compose/index.js 10.1 kB +11 B (0%)
build/core-data/index.js 15.4 kB +5 B (0%)
build/edit-navigation/index.js 11.1 kB +8 B (0%)
build/edit-post/index.js 306 kB -7 B (0%)
build/edit-site/index.js 24.7 kB -1 B
build/edit-widgets/index.js 26.3 kB -4 B (0%)
build/editor/index.js 43.4 kB -155 B (0%)
ℹ️ View Unchanged
Filename Size Change
build/a11y/index.js 1.14 kB 0 B
build/annotations/index.js 3.8 kB 0 B
build/api-fetch/index.js 3.42 kB 0 B
build/autop/index.js 2.83 kB 0 B
build/blob/index.js 665 B 0 B
build/block-directory/index.js 8.72 kB 0 B
build/block-directory/style-rtl.css 943 B 0 B
build/block-directory/style.css 942 B 0 B
build/block-editor/style-rtl.css 11.2 kB 0 B
build/block-editor/style.css 11.2 kB 0 B
build/block-library/editor-rtl.css 9.07 kB 0 B
build/block-library/editor.css 9.07 kB 0 B
build/block-library/theme-rtl.css 789 B 0 B
build/block-library/theme.css 790 B 0 B
build/block-serialization-default-parser/index.js 1.88 kB 0 B
build/block-serialization-spec-parser/index.js 3.06 kB 0 B
build/blocks/index.js 48.1 kB 0 B
build/data-controls/index.js 827 B 0 B
build/data/index.js 8.97 kB 0 B
build/date/index.js 31.8 kB 0 B
build/deprecated/index.js 769 B 0 B
build/dom-ready/index.js 571 B 0 B
build/dom/index.js 4.95 kB 0 B
build/edit-navigation/style-rtl.css 881 B 0 B
build/edit-navigation/style.css 885 B 0 B
build/edit-post/style-rtl.css 6.49 kB 0 B
build/edit-post/style.css 6.47 kB 0 B
build/edit-site/style-rtl.css 3.93 kB 0 B
build/edit-site/style.css 3.93 kB 0 B
build/edit-widgets/style-rtl.css 3.13 kB 0 B
build/edit-widgets/style.css 3.13 kB 0 B
build/editor/editor-styles-rtl.css 476 B 0 B
build/editor/editor-styles.css 478 B 0 B
build/editor/style-rtl.css 3.85 kB 0 B
build/editor/style.css 3.84 kB 0 B
build/element/index.js 4.62 kB 0 B
build/escape-html/index.js 735 B 0 B
build/format-library/index.js 6.74 kB 0 B
build/format-library/style-rtl.css 547 B 0 B
build/format-library/style.css 548 B 0 B
build/hooks/index.js 2.27 kB 0 B
build/html-entities/index.js 622 B 0 B
build/i18n/index.js 3.57 kB 0 B
build/is-shallow-equal/index.js 698 B 0 B
build/keyboard-shortcuts/index.js 2.54 kB 0 B
build/keycodes/index.js 1.93 kB 0 B
build/list-reusable-blocks/index.js 3.1 kB 0 B
build/list-reusable-blocks/style-rtl.css 476 B 0 B
build/list-reusable-blocks/style.css 476 B 0 B
build/media-utils/index.js 5.31 kB 0 B
build/notices/index.js 1.82 kB 0 B
build/nux/index.js 3.42 kB 0 B
build/nux/style-rtl.css 671 B 0 B
build/nux/style.css 668 B 0 B
build/plugins/index.js 2.56 kB 0 B
build/primitives/index.js 1.43 kB 0 B
build/priority-queue/index.js 789 B 0 B
build/redux-routine/index.js 2.84 kB 0 B
build/reusable-blocks/index.js 2.92 kB 0 B
build/rich-text/index.js 13.4 kB 0 B
build/server-side-render/index.js 2.77 kB 0 B
build/shortcode/index.js 1.69 kB 0 B
build/token-list/index.js 1.27 kB 0 B
build/url/index.js 2.84 kB 0 B
build/viewport/index.js 1.86 kB 0 B
build/warning/index.js 1.14 kB 0 B
build/wordcount/index.js 1.22 kB 0 B

compressed-size-action

@aristath
Copy link
Member Author

aristath commented Nov 20, 2020

@ntsekouras I started working on a proof of concept for this one, but there's still some things that need discussing and some decisions:

Default value

Should the setting default to custom query, or global query? If we default to the global query, then perhaps we'll need to write a migration/deprecation script so that existing FSE themes don't break. On the other hand we may not need that considering the experimental nature of FSE themes and the fact that we have a warning in their dashboard that says

You're using an experimental Full Site Editing theme. Full Site Editing is an experimental feature and potential API changes are to be expected!

So... breaking changes are to be expected.

What should we show in the preview?

The simple implementation I pushed here doesn't change what the preview shows. So users can change the preview context by switching the checkbox and tweaking the arguments of the query. That will change the preview, and when they switch to the global query the arguments they chose are still used for the preview.
If we don't want to go that route, I see 2 options:

  1. Show placeholders for everything. It's actually not a bad option, and gives a good idea of what the final result will be
  2. Add a "preview as" dropdown, where they'll be able to select if they want to preview a category, tag, search etc.

Opinions?

@aristath aristath requested a review from ntsekouras November 20, 2020 09:05
@ntsekouras
Copy link
Contributor

Hey Ari 👋 - I really appreciate you're working on this!

This is something I have explored myself without a clear solution yet. I think my main obstacle is this:

Figure out what to show in the preview

The simple implementation I pushed here doesn't change what the preview shows.

This is the main problem to me and changes in FSE navigation and previews make it even harder... Maybe this will help about the context detection more #27124 ..?

Add a "preview as" dropdown, where they'll be able to select if they want to preview a category, tag, search etc.

Actually I think this is discussed and probably will end up like that.

Show placeholders for everything.

That is not a bad option, yes. I'd like to try it out though to see how it feels.

I would love some other opinions on this as well.

Should the setting default to custom query, or global query?

I believe it should default to global but that will probably be best integrated during the init of Query (Placeholder). We should be able to detect the current global context and allow/propose the user to select between the current global or just have a custom Query.

In my mind this message could be like 'You are in news category template, do you want to have this context...?' Not with this wording but I think you get what I mean. Makes sense? Also check this issue about Query init: #27031.

We will still need the option though for changing after creation..

Write deprecation script so for existing query blocks the new setting defaults to custom-query instead of global

On the other hand we may not need that considering the experimental nature of FSE themes and the fact that we have a warning in their dashboard that says

IMO this is not necessary now since there are almost always breaking changes here, is experimental and the block themes are so few for now. However these changes are needed as Query block now matures and evolves..

@gziolo gziolo self-requested a review November 20, 2020 11:09
@gziolo gziolo changed the title Allow inheriting the global query arguments Query block: Allow inheriting the global query arguments Nov 20, 2020
@aristath
Copy link
Member Author

aristath commented Nov 20, 2020

Hmmm there's also another solution that is pretty simple and can work...
Instead of hiding the controls, we can just change their labels so they still work, but they only affect the preview:

Peek 2020-11-20 13-25

I pushed that change just now and it works beautifully! So with that combo, users can do whatever they want for the preview and see what it will look like on different contexts, and the frontend will still inherit the global query 😉
Of course it needs tweaking, but the current state of this PR works and it's enough to convey the concept before making a decision

@ntsekouras
Copy link
Contributor

Hmmm there's also another solution that is pretty simple and can work...
Instead of hiding the controls, we can just change their labels so they still work, but they only affect the preview:

I think this could work well and I'd like to try it!
I'll test the concept a bit of how it feels, but overall this will handle:

  1. Decouple the context detection in site editor which is difficult for many reasons:
    • template resolution complexity (template-hierarchy and fallbacks)
    • many changes in FSE navigation and preview
  2. Be able to adjust a Query block in a context where no results would be found. Now it's not possible to manage the InnerBlocks if the query returns no results.

@ntsekouras
Copy link
Contributor

ntsekouras commented Nov 20, 2020

The preview idea of Ari :#27128 (comment) seems promising and with some design, it could probably serve us well.

-cc @jasmussen @jameskoster @kjellr @mtias

@ntsekouras ntsekouras added the Needs Design Needs design efforts. label Nov 20, 2020
Copy link
Contributor

@ntsekouras ntsekouras left a comment

Choose a reason for hiding this comment

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

This will need the design but I'm very happy with this going forward! Great idea Ari 💯

@@ -26,8 +26,18 @@ function render_block_core_query_loop( $attributes, $content, $block ) {
'post__not_in' => array(),
);

$use_global_query = ( isset( $block->context['query']['customQuery'] ) && false === $block->context['query']['customQuery'] );
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the property could be renamed to useGlobalQuery and therefore invert the logic/checks in code. Also this should be a top level property of Query block (changes in block.json etc..)

packages/block-library/src/query-loop/index.php Outdated Show resolved Hide resolved
@jasmussen
Copy link
Contributor

I pushed that change just now and it works beautifully! So with that combo, users can do whatever they want for the preview and see what it will look like on different contexts, and the frontend will still inherit the global query 😉

Help me understand what the purpose of the preview is?

While there are some aspects of the controls, how they stack in the sidebar, the verbiage and using a toggle instead of a checkbox, having the help text be contextual, generally this toggle seems to make sense to me:

Screenshot 2020-11-20 at 15 07 28

It tells me that when it's off, the inherited query affects the loop. But that when it's toggled, it's the query fields below, and not the global query, that affects the loop.

Is that correct?

@aristath
Copy link
Member Author

aristath commented Nov 20, 2020

Help me understand what the purpose of the preview is?

"Preview" may have been the wrong word to use, but since we don't have the global $query in the editor and we don't actually know where the block will be used on the frontend, we need a way to allow users to "preview" their block as if they were visiting a blog archive, category archive etc.

It tells me that when it's off, the inherited query affects the loop. But that when it's toggled, it's the query fields below, and not the global query, that affects the loop.

Correct.
When the checkbox is toggled on, the arguments affect the actual query that will be saved.
When the checkbox is off, the arguments are used for the preview only. So on the frontend the global $query will be used, but with the arguments users can check their query on different contexts. Maybe they want to preview it as a category archive, a tag archive, or even as search-results.

The verbiage and UX does need to be improved, this was just a proof of concept to figure out what we can do. But as a concept I think it can work - as long as we figure out the verbiage etc to convey that the query arguments are so that they can preview their block on different contexts 🤔

@jasmussen
Copy link
Contributor

jasmussen commented Nov 20, 2020

Oh, thanks for explaining! But the feature is still primarily meant to act as a mechanism to customize the query on a per template basis, right? And the preview aspect is an additional feature on top?

Permit me to walk through this:

  • You open up the site editor, on the Home Page which uses the Index template
  • You decide that you want this homepage to show all posts, except those in the "Work" category, so you check the box and customize the category field to exclude the work category
  • You save and publish and voila, the homepage now shows all posts except the work category.

That seems to be the primary use case, please correct me if I'm wrong.

The ability to change the content that gets loaded into a template is definitely a legitimate use case. Perhaps the theme has only an Index template, and if you want to customize the date archive or the search results, it's fair for you to want to be able to see that.

However my instinct is that this act of previewing needs better real estate than the query toggle in the sidebar. The feature should probably affect the whole page, and since it is conceptually related to the template hierarchy, could even be a primary action. I'd appreciate thoughts by @jameskoster as I know he's worked on related things — could this have a place in the same template dropdown dialog in the top center of the screen? Or should it indeed be a choice in the Preview dropdown menu?

@gziolo
Copy link
Member

gziolo commented Nov 20, 2020

I'm wrapping up the day, but I had this thought that maybe we could try using the new experimental API for block variations transforms, so it could work this way:

  • the default version of the block is Query that takes all global query arguments and hides all controls in the UI that become obsolete
  • there is another block variation registered for the inserter that is titled Custom Query that works the same way as today
  • we also register block variations scoped to transforms similar to Navigation block (see Block variations transformations #26687) that allows users to switch between those two variants (switch from custom to default would mean users lose their attributes but they can always use undo).

@gziolo
Copy link
Member

gziolo commented Nov 20, 2020

I pushed that change just now and it works beautifully! So with that combo, users can do whatever they want for the preview and see what it will look like on different contexts, and the frontend will still inherit the global query 😉
Of course it needs tweaking, but the current state of this PR works and it's enough to convey the concept before making a decision

One downside of using preview mode that I can think of (on the technical level) with this approach is that attributes that are modified are stored inside the saved content even when they aren't used during rendering.

@jameskoster
Copy link
Contributor

jameskoster commented Nov 20, 2020

The relationship between template and query are closely linked, which makes me a little apprehensive about adding this customisation option. It may be that I'm missing something obvious though.

Rough example – should the UI really allow someone to change their single-product template so that it loads post content instead? I worry this would be confusing to use, and potentially undermine the whole purpose of having semantic templates altogether.

Allowing some controls to be customised might make sense though, like the number of entries to display. But even that should probably be governed somewhat by the template. In the same example as before, it wouldn't make much sense to change the number of entries displayed on a single template.

However my instinct is that this act of previewing needs better real estate than the query toggle in the sidebar. The feature should probably affect the whole page

Agreed on this. I know this PR is only a draft, but I'd also add that there's something awkward about the UX of choosing a preview in the block settings.

I would be tempted to consider splitting this in to two issues and exploring accordingly:

  • We need an affordance that allows people to either
    1. Preview a specific query in the template they're editing in some kind of view-only mode
    2. Switch fluidly between dedicated modes for editing template / content (IE Site Editor and Content Editor)
  • Investigate if/how the global query should be customised on a granular level, based on the template being edited – and how folks might add "custom" queries alongside the global one. This feels somewhere along the lines of what @gziolo is suggesting.

@aristath
Copy link
Member Author

The main problem we have with inheriting the global query is that we don't know what to show in the editor (what I call "preview" above). Assume for example that the theme only has an index.html and a single.html file - which is I suppose where most themes will start. Then the author adds a category template because they want their categories to be shown differently. In that template, they add a query block and set it to inherit the global query.
So... what should they see in the editor? Obviously not the latest 10 posts, they'll need to see some category. But which category? Do we pick one at random? Do we let them choose?
In the editor, we don't have the ability to determine the context of the template, because it all depends on the template's title - which can also change at any time. I can create a template for categories and while editing it I change my mind and say "Nah, this is better for tags" so I change the title to tag. So we can't really auto-detect the context and/or build a pseudo-query because the template hierarchy needs to account for too many factors and 3rd-party plugins, post-types, etc, not to mention that the context can change at any time by changing the template's title.
The simplest solution was to say "This is the query used. We don't know where your visitors will end up seeing it on the frontend, so you can just use the arguments below to test different cases and preview what it will look like as a category, tag, etc".
The initial implementation of this PR was to hide the unused query filters etc. It was a lot cleaner as a UI, but there was no way for users to customize what they see in the editor - which is where the amendment came in.

One downside of using preview mode that I can think of (on the technical level) with this approach is that attributes that are modified are stored inside the saved content even when they aren't used during rendering.

Correct. But that is not necessarily a downside... In the example above where the query block is used inside a category template, the fact that it saves these attributes - even if they are not used - means that I won't have to re-edit them to get the preview right every time I edit the template.

Rough example – should the UI really allow someone to change their single-product template so that it loads post content instead? I worry this would be confusing to use, and potentially undermine the whole purpose of having semantic templates altogether.

Right now there is no global-query inheritance. So without the global query, there is no such thing as a semantic template anyway... There are only custom queries everywhere and they are not URL-aware. This PR adds a way to make them semantic and not all queries are forced to be custom queries (which is their current state).
A query block will be used on archives, not on single post templates. Single post templates can use the post-title, post-content, etc directly. If an author adds a query block in a single-post archive, then it would be to show for example related products, latest posts, etc - in which case the query will have to be custom anyway.

@jasmussen
Copy link
Contributor

In the editor, we don't have the ability to determine the context of the template, because it all depends on the template's title - which can also change at any time. I can create a template for categories and while editing it I change my mind and say "Nah, this is better for tags" so I change the title to tag.

Much appreciate your further explanation here. To me, this only reaffirms that this deserves better real-estate than being attached to just a single block that may or not (🙈) be present in the template.

I wonder if a path forward is to help land #25309 and see if that preview dropdown can be a place to configure the query preview? It feels an obvious place to integrate it, it's global to the whole page, it's query block agnostic, and it affords a place to provide helper text to explain the limitations.

@aristath
Copy link
Member Author

One other option that I think we should really consider is to show placeholders for context-aware blocks instead of their "content". I'm referring to this:
Screenshot_2020-11-23 Add New Post ‹ My Blog — WordPress

If we show placeholders - which by the way sounds like a reasonable solution if they are using the global query - then we can just hide all filters and there's no need to worry about the preview.
We already have these kinds of placeholders in some blocks so we can simply expand that logic to cover all other post-related blocks (like post-date). If they all show placeholders, then it's a great solution that will show the outline and overall layout they're building, which is what the query block using a global query should really be about.

@aristath
Copy link
Member Author

I've been going back and forth in my mind, trying to figure out the minimum viable implementation we can have for this, so we can start moving it forward, and polish as we go.
Here's what I'm thinking:

  • We shouldn't worry about the Appearance > Templates aspect of the implementation because as mentioned above, the behavior of that is expected to change soon.
  • Right now, users can create from the site-editor a minimum amount of templates: front-page, post, page, archive, search-results, 404. Screenshot_2020-11-26 Site Editor (beta) ‹ My Blog — WordPress Of those templates, only archive and search-results will actually use the query (well, and of course the index but that will exist in all themes anyway). None of these templates actually require changing the context of the preview.
  • A context change would only be extremely vital if the post-type changes. In all other cases it's not. I mean sure, a category archive would show posts from a specific category, but it would still show posts, so the preview would still be a realistic representation of the result - even if it doesn't show posts from that specific category. Besides, there is currently no way to create a category archive from the UI so it would only happen if a user manually creates a template for it in their theme or from Appearance > Templates.
  • Right now - the only way to create a CPT template is via the Appearance > Templates menu, not from the site-editor. So a change in the preview is irrelevant anyway. The Templates will be moved and eventually use the site-builder UI. When that happens we can revisit changing the context of the query to only show posts of that category - if we even deem it necessary then.

With the above in mind, I tested manually creating a CPT using this code: (pasting here to make testing easier)

add_action( 'init', function() {
    register_post_type(
        'recipe',
        [
            'labels'             => [
                'name'                  => _x( 'Recipes', 'Post type general name', 'recipe' ),
                'singular_name'         => _x( 'Recipe', 'Post type singular name', 'recipe' ),
                'menu_name'             => _x( 'Recipes', 'Admin Menu text', 'recipe' ),
                'name_admin_bar'        => _x( 'Recipe', 'Add New on Toolbar', 'recipe' ),
                'add_new'               => __( 'Add New', 'recipe' ),
                'add_new_item'          => __( 'Add New recipe', 'recipe' ),
                'new_item'              => __( 'New recipe', 'recipe' ),
                'edit_item'             => __( 'Edit recipe', 'recipe' ),
                'view_item'             => __( 'View recipe', 'recipe' ),
                'all_items'             => __( 'All recipes', 'recipe' ),
                'search_items'          => __( 'Search recipes', 'recipe' ),
                'parent_item_colon'     => __( 'Parent recipes:', 'recipe' ),
                'not_found'             => __( 'No recipes found.', 'recipe' ),
                'not_found_in_trash'    => __( 'No recipes found in Trash.', 'recipe' ),
                'featured_image'        => _x( 'Recipe Cover Image', 'Overrides the “Featured Image” phrase for this post type. Added in 4.3', 'recipe' ),
                'set_featured_image'    => _x( 'Set cover image', 'Overrides the “Set featured image” phrase for this post type. Added in 4.3', 'recipe' ),
                'remove_featured_image' => _x( 'Remove cover image', 'Overrides the “Remove featured image” phrase for this post type. Added in 4.3', 'recipe' ),
                'use_featured_image'    => _x( 'Use as cover image', 'Overrides the “Use as featured image” phrase for this post type. Added in 4.3', 'recipe' ),
                'archives'              => _x( 'Recipe archives', 'The post type archive label used in nav menus. Default “Post Archives”. Added in 4.4', 'recipe' ),
                'insert_into_item'      => _x( 'Insert into recipe', 'Overrides the “Insert into post”/”Insert into page” phrase (used when inserting media into a post). Added in 4.4', 'recipe' ),
                'uploaded_to_this_item' => _x( 'Uploaded to this recipe', 'Overrides the “Uploaded to this post”/”Uploaded to this page” phrase (used when viewing media attached to a post). Added in 4.4', 'recipe' ),
                'filter_items_list'     => _x( 'Filter recipes list', 'Screen reader text for the filter links heading on the post type listing screen. Default “Filter posts list”/”Filter pages list”. Added in 4.4', 'recipe' ),
                'items_list_navigation' => _x( 'Recipes list navigation', 'Screen reader text for the pagination heading on the post type listing screen. Default “Posts list navigation”/”Pages list navigation”. Added in 4.4', 'recipe' ),
                'items_list'            => _x( 'Recipes list', 'Screen reader text for the items list heading on the post type listing screen. Default “Posts list”/”Pages list”. Added in 4.4', 'recipe' ),
            ],
            'description'        => 'Recipe custom post type.',
            'public'             => true,
            'publicly_queryable' => true,
            'show_ui'            => true,
            'show_in_menu'       => true,
            'query_var'          => true,
            'rewrite'            => array( 'slug' => 'recipe' ),
            'capability_type'    => 'post',
            'has_archive'        => true,
            'hierarchical'       => false,
            'menu_position'      => 20,
            'supports'           => array( 'title', 'editor', 'author', 'thumbnail' ),
            'taxonomies'         => array( 'category', 'post_tag' ),
            'show_in_rest'       => true
        ]
    );
} );

I then created 2 sample posts in that CPT, and manually created from Appearance > Templates an archive-recipe template. When I then visited the site-editor, I could select the template under "all" templates. When I selected that template, the context of the query properly changed and showed me the 2 recipes I had created instead of the posts. The frontend worked fine, and the site-editor was also working brilliantly.

Note1: I had to push an extra commit to make the query in site-editor work for the post-type.
Note2: I had to comment-out these lines to make the frontend work correctly for my CPT because of an issue currently tracked on #27177

So... the question now is this: Should we merge a change that works and covers everything we need now? Or should we work on things and try to make the context changes for taxonomies etc - even if they are not vital at this point? We can always work on them after an initial implementation gets merged IMO, and keep polishing it.
If we decide to merge a minimum-viable-implementation for the global query (which I think we should as it's a hard blocker for FSE themes), then we can start with this PR as a base, and work on the UX concept. Hiding the query args was a wise call, but what do want to call the option? And should the prop be saved under query or at the root level?

@bobbingwide
Copy link
Contributor

Besides, there is currently no way to create a category archive from the UI so it would only happen if a user manually creates a template for it in their theme or from Appearance > Templates.

Is this documented as a requirement on the Site Editor?
If so, where?
If not, where are these requirements documented?

BTW. Where you used search-results did you mean search ?

@aristath
Copy link
Member Author

aristath commented Nov 26, 2020

Is this documented as a requirement on the Site Editor?
If so, where?
If not, where are these requirements documented?

No, these are not requirements. They are not documented. I assume the reason they are not documented is because the UI is still in flux. There is no way to create these from the site-editor yet. Eventually I'm sure it will be possible, but not at this point. So there's no reason to document something that is not yet finalized. Right now, you can not create a category-archive from the site-editor, because the UI for those has not been built yet. But you can create them from Appearance > Templates. Eventually those 2 will probably be merged in some fashion, so Appearance > Templates will use the site-editor and we'll be able to do everything there (emphasis on the eventually part of the sentence)

BTW. Where you used search-results did you mean search ?

Yes, I only wrote it like search-results not because that is the name of the template but because the title of the template when you go to create it from inside the site-editor is "Search Results" (see screenshot in my previous comment) 😄

@aristath aristath marked this pull request as ready for review December 4, 2020 13:31
@aristath aristath requested a review from gziolo December 4, 2020 13:33
@carolinan
Copy link
Contributor

+1 for merging a minimum-viable-implementation.

@aristath
Copy link
Member Author

aristath commented Dec 8, 2020

To sum up the posts above and what I've been thinking lately:
I think the concept of this PR is ok to merge after someone reviews and approves the code...
A context change is only necessary if the post-type is different, and that part works fine. Changing context for taxonomies etc is not something that should be a blocker for this PR since with the current implementation of the site-editor users can't create templates for specific categories, tags etc and it all falls under archive - which works perfectly fine. Once we have the basics in, we can start adding more context-aware queries as the site-editor progresses.

Copy link
Member

@gziolo gziolo left a comment

Choose a reason for hiding this comment

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

I haven't tested with the latest changes but it's something we can land with the remark I left in my comment. It isn't ideal but it isn't simple to solve. Wr shouldn't block this functionality for the sake of perfection though.

@aristath aristath requested review from nerrad and ntwb as code owners December 8, 2020 13:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Query Loop Affects the Query Loop Block Needs Design Needs design efforts.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Query block: Add a way to inherit the global $query
8 participants