Add scriptaculos drag-n-sort support for categories management

[tassoman]

Would be so rock n roll adding drag n sort and inline editing for hierachical sorting and priority management of categories in administration? More, with inline name editing.

​| This is a demo, but not hierachical.

Maybe a rewrite of the categories.php page ?

[matt]

Not for now.

🚧 🚧 🚧 🚧 This is a work in progress 🚧 🚧 🚧 🚧

This is an exploration into an alternative to #3352 and #3359. The goal in this PR is to take a similar general approach to #3359, but focus on clearing the cached data when the number of registered blocks changes. This appears to have the same desired result of fresh data once all blocks have been registered, without removing the caching logic altogether.

Details TBC.

Trac ticket:

This is working as advertised for me, thanks @andrewserong !

It seems like a good approach, assuming that the number of blocks alone is enough to determine the validity of any cached theme data.

I guess if it turns out that it's not down the road, get_new_theme_cache_key and others are generic enough to accommodate any changes to the internal cache key logic.

I'll leave to folks with more context to determine the robustness of the approach, but it LGTM!

assuming that the number of blocks alone is enough to determine the validity of any cached theme data.

I was wondering about the robustness of this too. This works fine in core without any plugins, but the way this would break is if someone unregisters a block and registers a new one after wp-template-part has been registered.

I don't expect that someone would unregister and re-register a block with the same name as often, so maybe something like this could work?

{{{php
hash( 'crc32', implode( array_keys( $blocks ) ) )
}}}

I don't expect that someone would unregister and re-register a block with the same name as often

It looks like we're already actually doing this in ​`register_legacy_post_comments_block` which is getting registered after wp-template-part with a priority of 21 vs 10 in core and 20 in gutenberg.

If we make sure that core/template-part (which only registers itself and does not unregister anything) is registered last, the count($blocks) heuristic will work. I opened #3384 to see what that would look like.

@andrewserong do you think this fix might solve ​https://github.com/WordPress/gutenberg/issues/44619? It seems related somehow to ​https://github.com/WordPress/gutenberg/issues/44434.

@andrewserong do you think this fix might solve ​https://github.com/WordPress/gutenberg/issues/44619? It seems related somehow to ​https://github.com/WordPress/gutenberg/issues/44434.

Thanks for the ping @ndiego, yes, it should fix that issue, too, as I believe it's the same underlying problem.

If we make sure that core/template-part (which only registers itself and does not unregister anything) is registered last, the count($blocks) heuristic will work. I opened ​https://github.com/WordPress/wordpress-develop/pull/3384 to see what that would look like.

Thanks for the feedback @ajlende! That's a good point about registration / re-registration of blocks. I think ideally we wouldn't need to depend on the Template Part block being registered in a particular order, but I'm also all in favour of pragmatic fixes to resolve the problem in the shorter-term 🙂

I'll have a play with either pulling in your changes to this PR, or updating the caching logic today and see what I can come up with!

Great points about the issues of robustness @ajlende and @ramonjd! I've had a go at opening up (yet another) alternative PR in #3392 that proposes to add a registered_block_type action and use this as the mechanism to flush the cache instead of adding an extra cache key as in this PR. I _think_ something like that might be preferable so that we don't have to fuss about trying to determine whether or not the list of registered blocks has changed.

One concern I have with the idea in #3384 is that altering the order in which blocks are registered also seems to be a bit brittle, in that we then need to be careful about future changes to the block registration order, and it's still possible for a plugin to accidentally break things if something similar to what the Post Template block does, happens in a 3rd party block.

Happy to keep exploring options tomorrow, if anyone has any extra feedback. Thanks so much for digging in, too, @ajlende! 🙇

Thanks folks! Now that #3359 has landed I'll close this out.