-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Latest Posts: Fix selected category on existing blocks #21359
Conversation
Size Change: +981 B (0%) Total Size: 840 kB
ℹ️ View Unchanged
|
Do you know If this bug is present on WP 5.4 too? (whether to add the "backport" label or not) |
@youknowriad No, it looks like 5.4 doesn't have the muli-select category feature, so it isn't an issue. |
Hi @ryelle and thank you for fixing this. This PR keeps the category filter in place. I tested and, aside from the empty label in the category list, following the steps you provided, I now see The editor also shows up the same error. I'm trying to track this down as well :) as it was reported by @bph in #21550 |
* Reverts the change to `render_block_core_latest_posts`
f774fe4
to
9aa653e
Compare
While I can see that it would make the UI easier to implement if the full objects were immediately available, I believe the category ID is enough to be able to get these details from the REST API. To me, the attribute data should include the minimal data necessary to be able to reconstruct the block. Or, at least, all the rest of these details can be considered redundant if the ID is known, and redundancy may lead to excessive storage and risk of desync. The second of these is more concerning since, for example, details about the category can change while the ID remains static (including the label). From my understanding of #20781, if all that was needed to support multi-select was the storage of the category ID, then I think ideally the attribute would be an array of numbers. Generally I'd discourage the use of schemaless object attributes whenever possible, as the lack of a well-defined and enforced structure can be a source of bugs (gallery block comes to mind). That all being said, the changes here do seem sensible given the current state of the block, and assuming that this has already shipped in a version of the plugin, this would still be necessary regardless if there's a future change in direction to how the attribute is stored. To the bug itself of the empty label, given all of the above, my ideal implementation would be one where the suggestions passed to the token field are constructed based on entities fetched from the API corresponding to the ID of the category. There appears to be some prior art of this in the Post Tags block: gutenberg/packages/block-library/src/post-tags/edit.js Lines 14 to 15 in f73151e
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment was for 16169. Sorry.
Co-Authored-By: Andrew Duthie <andrew@andrewduthie.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's address it separately. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This fixes two open issues, works as expected and it further removes some code duplication as well. Let's merge it.
@mcsf's changes are working great in testing, if the empty category label isn't necessary for this PR, is it ready to merge? (edit: didn't see @draganescu's approval until I posted this 🙂 ) |
Sad to see this wasn't added in the 8.6.0 release. |
This PR was merged in April, landing in Gutenberg 8.0. |
Oh, my bad then. I still have this issue on the latest Gutenberg release & WordPress release. (Apologies if this isn't the right place for asking these questions - this seemed to be the only place where I could find anything about this bug.) |
Howdy @JJ-Coding - this is the best place! If you install the Gutenberg plugin you should have the update ready. If you use the default Gutenberg shipped with WordPress 5.4 (which is Gutenberg 7.5) you will have to wait for WordPress 5.5 to get the update. |
I re-tested on the latest Gutenberg version and found no issues with this. For the record, I tested with the following deprecated content: <!-- wp:latest-posts {"categories":"6"} /--> |
Hey @draganescu ! Thanks for confirming that I'm not posting in the wrong place - I'd rather not be that guy... I've got the latest Gutenberg plugin installed (v8.6.0) but I'm still experiencing this problem it seems. Just now I copied @mcsf 's code and pasted it into my page and then updated the page. Once the updating was finished I reloaded the editing page and the code that I had pasted in turned into: So it seems to just remove the categories code completely when it updates. Thanks for the quick responses by the way! I really appreciate the help. |
Alright - I've disabled all my plugins and added the code on a seperate test page. That seems to do the trick. Consider my question solved. Thanks again for the responses @draganescu & @mcsf ! |
Description
Fixes #21357 — The selected category attribute in Latest Posts was changed to an array, but no upgrade path was added for existing blocks. This caused problems on the frontend and in the editor, so this PR attempts to fix those. For the frontend, add an
array
check before using the categories attribute, and handle the non-array case. For the editor, I've added a deprecation that should kick in if categories is a string, which will convert categories into the array-of-objects format it expects.This migration ideally needs the whole category object, as right now it displays the selected category as an empty token — would appreciate suggestions on this.
To test
Types of changes
Bug fix (non-breaking change which fixes an issue)