Gutenberg: Latest posts block inconsistent hooks

[Lewiscowles1986]

Issue Overview

There is/are no hooks in the latest posts block, which is synonymous with the recent posts widget from core wordpress. This is further compounded by putting the block in something called widgets.

Expected Behavior

To be able to use widget_posts_args or similar hook (from recent posts)

Current Behavior

No hook, stuck with literally the latest. The idea is to provide more curated control using a meta-key, with fallback (if it doesn't exist) to using the featured tag the plugin I've authored adds to WP. It's a bit more setup cost for a blog, but it avoids problems with altering publishing dates, which can lead to broken permalinks.

Possible Solution

I've raised an issue, because it looks like Core will need to change to separate the function from the widget, likely into /src/wp-includes/post.php to promote re-use. https://core.trac.wordpress.org/ticket/43174

Related Issues and/or PRs

https://core.trac.wordpress.org/ticket/43174

Why this and not just make Yet Another separate plugin.

• Less effort to maintain (uses built-in WP core code)
• Familiar UI
• Easy to turn off my companion plugin
• Provides opportunities for other devs to extend core WP in Sane ways
• the alternative is this which is overkill, isn't integrated to gutenberg, make new code which needs new tests, more training, is less intuitive

[aduth]

There is/are no hooks in the latest posts block, which is synonymous with the recent posts widget from core wordpress.

Not saying that I necessarily agree or disagree, but where has it been claimed that the Latest Posts block is meant to faithfully clone functionality of the Recent Posts widget?

[Lewiscowles1986]

It doesn't matter if you said it, the functionality is close enough that it becomes confusing.

If I said, "here have a granny smith" and it wasn't an apple. Would that make your expectation, that I was presenting you with an apple any less valid?

When you use synonyms like latest, recent I think it's fair to assume some expectation of parity is not unreasonable.

Also. Is there a reason that a hook is unreasonable; and what does the least harm to users?

• content creators & back-end
• front-end who are limited because this only does one thing.

I can see an argument "why don't I just make my own recent posts Gutenberg block?", "Why don't they just use categories" (it's singular was my reasoning, tags allow a Venn-effect as well as single from my plugin).

The problem I have with that is that it seems unnecessarily arduous to maintain a filter + a block + a widget (which would likely only add to the synonym problem, or remove core or Gutenberg elements); or just a filter?

[aduth]

The opposing argument could be that, if extending your point that the Latest Posts block serves as a replacement for the Recent Posts widget, the naming of the filter including "widget" becomes confusing to any developer who doesn't have the historical context of the Recent Posts widget.

I'd agree this is made confusing by categorization of this block under "Widgets". And if the "Widget" naming persists and widget blocks are expected to mirror that of the equivalent existing widgets, then I'd agree it makes sense for the filter to be preserved. I expect also that this could impact other blocks; are there filters for the Categories block/widget which aren't being respected? In other words, if this is to become policy, then it's a bigger problem than just your one filter.

Re: the "not saying" is reference to the fact that I don't feel strongly about this one way or the other, and am merely exploring the potential consequences. It's not worth getting irate over some fair discussion, as it is otherwise uninviting for said discussion to take place.

[Lewiscowles1986]

Hi @aduth I'm not Irate, but I am bemused.

The opposing argument could be that, if extending your point that the Latest Posts block serves as a replacement for the Recent Posts widget, the naming of the filter including "widget" becomes confusing to any developer who doesn't have the historical context of the Recent Posts widget.

See your point on latest posts being in a block category "widgets" in Gutenberg, and this screenshot for anyone not in-the-know.

I'll look into the categories block widget and other blocks categorised as widgets; which I now understand are not widgets (another part of the confusion).

Thank you for your time, I realize text is not always the best on the internet but I appreciate the time, effort & skills.

[westonruter]

There is one major concern I have with this (and the PR #4808): because the block uses JS to render the block preview in the editor, if there _is_ a theme or plugin that adds a widget_posts_args filter to customize the WP_Query then immediately the block preview in the editor will fail to reflect what the block will render on the frontend. This is a general problem for dynamic blocks in Gutenberg. The only solution I see to this is #780 wherein the server is used to render the block, just as is being done for previewing shortcodes (#1054). This not only ensures that the block is rendered the same, but it is also DRY since there doesn't have to be two separate implementations of the same rendering logic, one in JS and another in PHP.

[Lewiscowles1986]

I agree, I wrote #5214 to start approaching the issue, but was then signposted to others work. At the end of the day, I'm not sure why a react frontend for the admin-ui and a separate method for rendering the frontend was ever the way. It was a number of repeats of what I felt should be similar functionality. I also didn't understand until today that the admin-ui was rendered via rest-api, because why would it be.

[westonruter]

Rendering with React means that changes can be re-rendered instantly. However, since there are often need to be REST API calls to obtain the data for rendering, there is still a delay while waiting for the server. In theory there can be a better user experience for having JS rendering of dynamic blocks in the editor, but in practice I think the benefits are outweighed by having to duplicate the rendering logic and maintain them separately.

[Lewiscowles1986]

Is this really done? Is it released?