Open jbreitenbucher opened 2 years ago
I just wanted to note that random queries are slow by default. So it might not be good to offer this option without pointing out the risks.
I'm wondering why the method used by several Widgets like the Genesis - Custom Featured Post widget can't be used in the Query Loop Block?
Related issue mentioning the performance issues, too: #24934
Any update ?
+1
In general, blocks should provide at least the same functionality that was available in widgets, and then some, rather than taking features away.
+1
Would be great to have all the options we had in WP_Query.
+1 I agree this should be added. Random does slow things down but is needed for a variety of purposes we run across and I find a need for it frequently. I also need it on a per-case/per-block basis (or per-widget) and not globally. An option where the other order options are seems to be the logical place.
+1
The note around it being slow appears applicable when the dataset is large, so perhaps it can either be solved in a similar way to this example: https://github.com/Automattic/vip-go-mu-plugins/blob/ba5fcff8bf5ca5b717675cf75fcb427aab77b5d4/vip-helpers/vip-utils.php#L744-L780.
Noting for posterity's sake that some hosts, such as WP Engine disable 'orderby' => 'rand'
by default unless a site admin explicitly allows it, which could lead to unexpected results for users that aren't aware.
A workaround solution such as the one @pkevan points to looks like a great alternative.
WP_Query already includes rand
as an orderBy
option. So another alternative, if you want to create a random Query Loop right now, could be to edit the orderBy
parameter of the Query Loop block in Gutenberg Code Editor, so it looks like this:
<!-- wp:query {"queryId":5,"query":{"perPage":3,"pages":0,"offset":0,"postType":"post","order":"desc","orderBy":"rand","author":"","search":"","exclude":[],"sticky":"","inherit":false}} -->
With this approach, it would work properly on the site, but you won't see the posts on the Editor side. If you want to make it work in the editor as well, you can always add the rand
option in the REST API using the rest_this-post_type_collection_params filter as suggested here. With something like this:
function add_rand_orderby_rest_api( $query_params ) {
$query_params['orderby']['enum'][] = 'rand';
return $query_params;
}
add_filter( 'rest_post_collection_params', 'add_rand_orderby_rest_api' );
The main point here is consistency and function, not performance.
If rand
is disabled, it can't be used anywhere in WordPress, so that's consistent. If it's slow, the person using the widget can decide to use something else. But the option should be there, in the UI, without resorting to code editing, because WordPress caters for it.
Resolving the performance issue is a matter for the core WordPress team via Trac discussions. The Gutenberg team shouldn't hide options that are native to WordPress.
Team, please add the rand
sorting option to the Query Loop block. One small step for you, one giant leap in consistency for users ;)
+1
@SantosGuillamot I've tried both of your suggestions, and neither of them works. Looking through the Gutenberg code, it's likely that this is because the JS code doesn't know what to do with the new option.
Not sure why #23524 was closed. This was a valid request from over 2 years ago, which should be implemented soon. Plugins should not make decisions (performance or otherwise) for site builders/owners, and should not disable options that are available in core for good reason.
+1 - Maybe add ability to overlay txt onto image... But random would be great.
+1
Ad mentioned above, a lot of hosts (included but not limited to WPEngine) disable random database queries due to performance costs. I don't think that Core should provide a UI to do something that we already know is bad, and unsupported by a number of hosts. IMO, if a user wants to do something that is clearly not recommended, they can install a 3rd-party plugin. Core should not encourage "bad" queries.
It's not for you to decide what's good or bad. If a host disabled this option, it won't work, but if it's available, it can be used. Similarly, if the site owner thinks it slows down the site, they can use something else, but at least they have a choice.
WordPress is a COMMUNITY project and you're ignoring the community here.
In my particular case, sorting testimonials by some other method gives worse user experience than if the page takes another 0.2s to load, so I prefer random sorting. I'm sure others have valid reasons too.
Also, the block editor is based on WordPress core, and unless the core team removes rand
sorting, the editor should make it available in the UI and scripts. Nobody should ever need yet another plugin just to make use of something that's already there.
@galbaras Let's keep it civilized. @aristath makes a good point and is not deciding or ignoring anything, just adding to the conversation.
I agree that core should encourage good performance and safety, cause with the community in mind, many of the people in it won't know what's happening behind the scenes and aren't aware of certain "risks". Core discourages bad practices in many ways already, taking away options from the community for their own safety and benefit.
There's also nothing wrong with using plugins, that's one of the biggest aspects that make WordPress so great and modular. Never needing a plugin for anything, but adding everything to core, is an ideology with a lot of bad consequences.
Core discourages bad practices in many ways already, taking away options from the community for their own safety and benefit.
Well, I disagree with that, too. Both the core team and the Gutenberg team should accept they don't know the circumstances of every site and stop dictating things. Taking away a core option is unacceptable, no matter the reasoning.
There's also nothing wrong with using plugins
I agree, but plugins shouldn't be used to re-enable things disabled by other plugins. That's just ridiculous. It's much better if Gutenberg didn't disable rand
sorting and nobody needed a plugin to re-enable it.
I have enormous respect for @aristath, but in this case, the Gutenberg team is dictating things to people who clearly resent this dictation and want something different. It's easy enough to have a setting for this, and have it turned off by default. An ever safer way, and just as easy, is to have filter for it. Either way, those who know what they're doing can enable it, and Gutenberg can support it, instead of dictating.
+1 This is a much-needed feature… (like many missing features from WP_Query)
Arguing with hosting providers, disabling this is ... really: hosting providers should not interfere with WP core in any way. My personal opinion: this doesn't speak for the hosting provider … WordPress is a software which should work fine for the majority of users, without specific needs for adjusting hosting. (also, I personally never came by such hosting, and I am maintaining many sites since years now)
Bad performance shouldn't be an argument too… another "dead-end like argument". You take away any room for discussion with this.
Most sites are small and never suffer from any performance issues at all. Also, from my personal experience, poor performance is mostly related to bad hosting (and sometimes multipurpose themes). Sticking to WP core, selected plugins and good hosting is key. (good hosting doesn't need to be expensive)
Just come up with clever solutions instead (i.e. provide seeded random, hourly, daily...) , improve WordPress or educate people to use performance optimizations...
Never needing a plugin for anything, but adding everything to core, is an ideology with a lot of bad consequences.
Some kind of ironic, as Automattic basically adds a lot to core with Gutenberg... . Besides this... isn't PHP "the language" to have literally a function for everything in core?
I totally agree with you, core should be slim and "basic". But to be honest, there is still a lot missing from WP core, i.e. a proper UX/UI framework for forms and adminstration views, build-in ACF, build-in permission management, caching, optimization, ...
Also requested in this support-forum post: https://wordpress.org/support/topic/how-can-i-make-a-query-loop-to-display-posts-by-random-order/
+1 on this
I have raised a ticket in wordpress-develop
for the same as there is a requirement for the rand
keyword to be added to the enum of query params of orderby in rest-post-controller
https://core.trac.wordpress.org/ticket/58412#ticket
Also raised a pr for the same ⬆️ https://github.com/WordPress/wordpress-develop/pull/4513
Raised a PR against Gutenberg as well - https://github.com/WordPress/gutenberg/pull/50999 Will be functional only after merging this PR - https://github.com/WordPress/wordpress-develop/pull/4513
Joining request. This is needed option.
I would not worry about if random option is slow or available at the host.
Both can be handled by randomizing selection without using SQL random: you count number of records, then by math random select number from that range, and then select rows taking just one row from the table by randomly selected row number.
To avoid performance issues, we could build a limited random Query Loop and have the option to extend it with a plugin or a snippet for advanced users.
This "random" order would grab only the latest posts. I don't know what would be a good number but 100 sounds like a good starting point. Adding a warning could be enough so the user can decide if shuffling the 100 latest posts is good enough for them.
We could turn off pagination to avoid duplication issues.
Any news? The issue is opened for years now... I think I have the same use case as @galbaras : I need to display testimonials I put into posts (if you have a minimalist workarround it would be great btw!). So I will have arround 10 of these and it wont create any performance issues. And no brain issue as well: I disagree on the point that there is nothing wrong installing plugins, I use as few as possible and this is good practice, as well as in IT in general.
I have a feeling that WordPress is intentionally lacking some basic stuff, to make room for commercial plugins. Query Loop Block looks like proof of concept and demo more than actually useful option, except for very basic site.
All blogs need to have random order of blog post for their readers. If you use alphabetical order or chronological order, users will have difficultly finding posts that they haven't explored before.
As for the same random sorted cache page being served to all users, the cache is frequently automatically purged. It's the closest we can get to how the things should be.
Random sorting is not just a need, it's a desperate need. Which was already met since 10 years ago. Now we the early adopters of WordPress Gutenberg FSE (not developer, but actual bloggers, aka end user of this open source technology) are struggling to have our basic needs met.
Dogpiling onto this that I could really use a random sort on my page and my server can handle it.
It's hung up in the Gutenburg pipeline, it looks like @Vrishabhsk 's pull request might be a solution, but that the Gutenburg developers are doubtful of the usefullness of the feature and don't like the implimentation because of performance impacts and caching limitations: https://github.com/WordPress/gutenberg/pull/50999
Perhaps the best solution would be to write a simple plugin that enables the feature in Gutenburg and doesn't do much else. I know I wouldn't want to go with a shortcode options and extra bulky plugins. But it seems like such a baseline feature, that wordpress already supports, it's honestly puzzling that Gutenburg wouldn't be willing to impliment it. https://github.com/WordPress/gutenberg/pull/50999#issuecomment-1872198798
the Gutenburg developers are doubtful of the usefullness of the feature
That's not how community projects work. Usefulness is determined by the users.
Perhaps the best solution would be to write a simple plugin that enables the feature in Gutenburg and doesn't do much else
I really think that the best solution is for Gutenberg to support everything that WordPress core provides, instead of making decisions on our behalf.
the Gutenburg developers are doubtful of the usefullness of the feature
That's not how community projects work. Usefulness is determined by the users.
I don't actually know what WordPress or Gutenberg 's decision making process is, or how WordPress is framed as a community project vs an open source company project, however in many open source projects what happens depends on who is willing to code it, and also who actually accepts the commits.
What exact counts as a "community project" isn't a monolith, and decision making varies.
I would be very interested to understand the decision making process of WordPress, and the Gutenberg coders though, being a bit of a governance geek myself! :)
I do agree that users should have significant representation for something to really be considered a "community project", but in practice I see a lot of variety among open source projects as to what that looks like and how community aligned they even are.
It's hung up in the Gutenburg pipeline, it looks like @Vrishabhsk 's pull request might be a solution, but that the Gutenburg developers are doubtful of the usefullness of the feature and don't like the implimentation because of performance impacts and caching limitations: #50999
Thanks for finding that. They seem to be misunderstanding a common use case so I tried to explain it. You might have a better way of putting it:
What needs are you aiming to solve with random sorting?
I personally would like a Random order for a loop on my front page that shows links to stories about 3 other photographers that I like. I have category of about 20 photographers I like and want to highlight different ones every time instead of just the most recent, or alphabetically.
I would also like a loop of one single random post from my backlog of photo posts.
You are imagining a loop of all posts on a site, where yes, this could cause a lot of problems with pagination and caching etc. But I think most people would use it to add some variety to a landing page.
I want to show 3-5 random testimonials out of maybe 10. Since sorting comes after data retrieval, I'd say there's no noticeable performance penalty in this case.
I would be very interested to understand the decision making process of WordPress
From what I know, most of the work nowadays is sponsored by a handful of large WP shops, like Automattic, Human Made and XWP, and many tickets are left unattended if their author lacks the skills to submit the code changes, let alone properly tested code. My guess is that random sorting is bad for wp.com in this case, but maybe I'm imaginging things.
Sponsored contributors are still - for the most part - volunteers. Usually, a person has been a volunteer contributor for a number of years and at some point in their career, a company chooses to pay for their time in order for that person to continue doing what they've been doing for years, for free.
Of course there might be exceptions to the rule, but in my years of being a sponsored contributor there was never a "company mandate" that we should focus on something specific. The idea always was "do what you think is best for the project and the web". Again, there might be exceptions to that and I haven't worked for some of the companies mentioned above.
Some of us, sponsored contributors, choose to work on Gutenberg. Others don't. But sponsored contributors still pick their own issues and what they want to implement - just like they have always done, even before they became sponsored. So if a contributor finds something interesting, they'll work on it. If they don't work on it, then they probably don't like the idea or don't think it's in the best interest of the project. Or they just don't have time and are working on more important things. It doesn't have to be something as insidious as what is somewhat implied above. I don't work on this because I don't like it, so I choose to spend my limited time on other projects that I personally believe will be more useful. If a PR comes along from someone else to implement it, I will not block it, but I will not approve it either. If i see it, I'll just ignore it like hundreds of other people ignore my own PRs (sometimes for good reason). I am a single person, who doesn't want this. There are hundreds of other committers and contributors in the project, and each of us has their own mind. BUT... if you see all of them ignoring this request, then they probably don't think it's a good idea either.
You obviously believe this is a good idea, so there's nothing stopping you from doing it. Create a pull-request. Talk to people on Slack. Attend the meetings. Lobby for your idea, and convince people that this is needed. That's what we all do.
To me, this seems like the developers are trying to be our mothers. I find that insulting. We know about performance issues and do not HAVE to choose random sorting and thus don't HAVE to suffer any performance degradation but we really should have the option to make our own choices.
I don't need a mother.
Steven Horn @.***
On Dec 29, 2023, at 10:27 AM, Supaiku @.***> wrote:
It's hung up in the Gutenburg pipeline, it looks like @Vrishabhsk https://github.com/Vrishabhsk 's pull request might be a solution, but that the Gutenburg developers are doubtful of the usefullness of the feature and don't like the implimentation because of performance impacts and caching limitations:
50999 https://github.com/WordPress/gutenberg/pull/50999
Perhaps the best solution would be to write a simple plugin that enables the feature in Gutenburg and doesn't do much else. I know I wouldn't want to go with a shortcode options and extra bulky plugins. But it seems like such a baseline feature, that wordpress already supports, it's honestly puzzling that Gutenburg wouldn't be willing to impliment it.
50999 (comment) https://github.com/WordPress/gutenberg/pull/50999#issuecomment-1872198798
— Reply to this email directly, view it on GitHub https://github.com/WordPress/gutenberg/issues/40481#issuecomment-1872202972, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADIS6XNRCBHEL25WBHOKJU3YL3VP3AVCNFSM5T4HKNIKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBXGIZDAMRZG4ZA. You are receiving this because you commented.
To me, this seems like the developers are trying to be our mothers. I find that insulting. We know about performance issues and do not HAVE to choose random sorting and thus don't HAVE to suffer any performance degradation but we really should have the option to make our own choices. I don't need a mother.
Steven Horn
It seems like what you need is a developer willing to volunteer their time for an idea you want to have in the free software you're using.
At the risk of giving undesired advice, more graciousness and understanding might make that find more likely. Or at least more pleasant for folks reading the thread 😅🤪
I sympathize with the desire for performance and actually doubt most WordPress users do have an understanding of performance or caching, but also see this as a pretty critical feature...
Point taken and something I should consider.
Steven Horn @.***
On Dec 30, 2023, at 3:02 PM, Supaiku @.***> wrote:
To me, this seems like the developers are trying to be our mothers. I find that insulting. We know about performance issues and do not HAVE to choose random sorting and thus don't HAVE to suffer any performance degradation but we really should have the option to make our own choices. I don't need a mother.
Steven Horn @.***
It seems like what you need is a developer willing to volunteer their time for an idea you want to have in the free software you're using.
At the risk of giving undesired advice, more graciousness and understanding might make that find more likely. Or at least more pleasant for folks reading the thread 😅🤪
I sympathize with the desire for performance and double most WordPress users do have an understanding of performance or caching, but also see this as a pretty critical feature...
— Reply to this email directly, view it on GitHub https://github.com/WordPress/gutenberg/issues/40481#issuecomment-1872606404, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADIS6XLYAD5UNJC2P5ZRFZ3YMB6NBAVCNFSM5T4HKNIKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBXGI3DANRUGA2A. You are receiving this because you commented.
Thank you @aristath and @Supaiku for your measured replies.
It seems to me that contributing via a GitHub issue should be the best way to influence the direction of WordPress and Gutenberg, but it's not. Most people don't have access to core contributors to lobby ideas, and there is a need for some central arbitration, rather than every developer doing what they find interesting, when so many people rely on these products.
Also, most site owners can recognise bad performance, even if they don't know about random sorting. If they have one page with random sorting, and its performance is bad, I think most people will figure it out.
Again, my main claim in this thread is this "WordPress provides random sorting as an option in WP Query, so Gutenberg should support it", and "Let users choose their settings and bear the consequences". Assuming we're (mostly, if not all) adults, we'd rather make our own choices.
"WordPress provides random sorting as an option in WP Query, so Gutenberg should support it", and "Let users choose their settings and bear the consequences".
This was exactly my thinking when I first submitted this issue.
Dr. Jon Breitenbucher @j_breitenbucher
On Dec 30, 2023, at 8:33 PM, Gal Baras @.***> wrote:
"WordPress provides random sorting as an option in WP Query, so Gutenberg should support it", and "Let users choose their settings and bear the consequences".
Hey all Some gentlemen just added the order by random in gallery block https://github.com/WordPress/gutenberg/pull/57477 Right decision 😉
Fingers crossed 🤞 was this a signal of fresh air coming up? Let's see. For now, I remain curious... random order for query block has been one of the most requested issues, and constant feedback along the years doesn't seem enough yet.
@t-hamano Aki. Would it be natural for you to perhaps also work on this issue as well?
I recently added a random option to the Gallery block in #57477. In the Gallery block, the rendered Image blocks are simply shuffled using a PHP function, and no SQL queries are executed, so there are no performance concerns.
On the other hand, in the case of the Query Loop, there seems to be a performance issue, as mentioned in this issue.
Also, I can't imagine how it would work if the Query Loop block was used along with the Pagination block. Savvy users will likely remove the Pagination block, but it may be confusing for others.
It should also be mentioned that there are already some ways to intervene with the parameters of the query loop. For example, registering a new variation with registerBlockVariation
function or modifying a query with query_loop_block_query_vars
filter.
@t-hamano Thanks for replying!
Are there any How-to or easy documentation files for the query loop parameter modifications you mentioned? If enabling the random feature is as simple as a few lines in functions.php or a really simple plugin that'd be pretty handy!
@Supaiku
As far as I know, the following documentation is the most helpful:
Extending the Query Loop block – Block Editor Handbook | Developer.WordPress.org
Plugins may also be available that extend the Query Loop block. For example, the following plugins are mentioned as supporting the random order as well.
Thank you @t-hamano just this plugin seems like a good fit for at least my use case - I don't want a plugin that's bloated, but this seems to be pretty straightforward in terms of just extended the needed functionality without bloat. This is great, thank you! I'll give it whirl - the plugin hadn't been mentioned anywhere else and didn't really show up in previous searches.
What problem does this address?
The ability to have dynamic content on a page/post/site template. In current themes I often use a widget that returns random posts from a category to create a dynamic front page.
What is your proposed solution?
The query loop supports the ability to return random posts and I would suggest adding Random to the Order by options for the Query Loop Block.