-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Should we provide multi-query comments loops? #36642
Comments
If I'm not mistaken, WordPress comment pagination is using this URL structure right now:
So, if we want to make this backward compatible with the existing URL structure, we need to use the I guess we have a previous example of this. The WordPress archives, which follow this URL structure:
I didn't look at the code, but I did a quick test with a block theme, and it seems that in archives, the Query Loop block is following that structure: But if I add a Query Loop block to a page, it uses the So I guess it may be using the old WordPress URL structure when the query is inherited and the new That would mean you can use two query loops in an archive, one inherited and one custom, and the URLs would be backward compatible 🙂 @c4rl0sbr4v0, would you mind taking a look at the code of the Query Loop and/or related issues to confirm that it works that way? If so, I think it would make sense to implement it that way. |
Just a quick note. I think (not sure tho) that the Can anybody check that? |
It seems that it gets the comment page from a query variable inside the
Sure, what they do is reset the query, so the main query does not interfere with the query loop. They use offset in order to set the first comment to show, instead of pagination variable: gutenberg/packages/block-library/src/post-template/index.php Lines 27 to 29 in 2ecd5a0
And after that, it creates a new one with the arguments got from the block. Query args:
Query created:
After rendering the comment blocks, it resets in order to keep the first query working on the rest of the page/site:
For the query pagination links, what they do is to add a query argument into the HTML tag Create the page key:
Add it as query arg:
I hope this context can help us take a direction |
I meant how does it work when the Query Loop query is inherited, because that's what we should do when the Post ID of the Comment Loop block is inherited as well. |
Does this make sense?
|
When the Query Loop is inherited, if you mean when you are on a post or a page, the post id is got from the global object In case you have a Query Loop block, you assign a I'm not sure if I'm answering your questions 😅, we could consider creating some looms or videos if the communication feels unclear.
Maybe for the comments would be better to call it with a query word inside, in order to keep consistency with the query one. Maybe? Right now in we have page and What do you think about it? |
Uhm. 🤔 As far as I understood, the query ID would be a way to identify a specific query block, right? So, I would prefer something like
I would go for any of these options
But the one I like the most is |
I forgot that the post id could be inherited from either the post/page or a parent Query Loop block and those cases should be treated differently.
Additional questions:
|
After some analysis, and considering the last cases @luisherranz added in the previous comment, this is how I think adding several comment loop blocks with different options should work. Let's first consider two types of URLs:
The criteria for whether one or the other type of URLs should be used would be as follows:
This would cover pretty much all the cases, and would have backwards compatibility as well, keeping the current behavior of WordPress and allowing different comment loops pagination at the same time. This diagram shows all different cases:
From my point of view, it would not be necessary to include both the query ID and the comment query ID, with the second one would be enough. 🙂
I don't know if we have agreed in other issue, but pretty much yes. 👍
There is no other source of post IDs AFAIK. Alright, @luisherranz @SantosGuillamot @c4rl0sbr4v0, let me know what you think. 😊 |
LGTM! 🙂 |
Looks great. Also, it will be better for the UX as they will be able to add as many comments query loops as they want. |
Closed as it has been paused during a long time. Feel free to reopen if needed. |
Summary of the question
If we take a look at the Post Query Loop. It is ready so the user can have multiple queries on the same page.
gutenberg/packages/block-library/src/query/edit/index.js
Lines 81 to 86 in 4d3fb72
Then in PHP we read that queryId and get the info to be able to make different queries on the same page.
gutenberg/packages/block-library/src/post-template/index.php
Lines 18 to 23 in 2ecd5a0
This feature is completely fine for posts. For example, in a blog, you may want to create a couple of "Posts per category" blocks. But you can also add pagination to them. This pagination is working also individually, and, sometimes, can create weird results.
For example, if you create a query loop and set the layout as two columns, you can add a different pagination per column (maybe we have to fix that in another PR).
The question is:
Should we provide multi-query comments loops? Is it a nice feature to have different comment loops on the same page?
Depending on this discussion result, the code for the comment loop and pagination can be more or less complex.
The text was updated successfully, but these errors were encountered: