area17
Refactor and improve list of available blocks
Description
This PR adresses issues regarding performance of having a lot of defined blocks combined with a lot of block editors on a page
It also improves the way we can exclude blocks with a global exclusion list accepting names of blocks as well as allowlist by group and callbacks running on block, allowing for more advanced filter using component methods or regexes for example
It also adds the ability to sort blocks (before they could only be sorted by the order in the directory or in the block list which resulted in a messy list of blocks)
excludeBlocks now also accepts a callback as an argument
It also now only prints templates of all the availableBlocks on the page (it still prints all the repeaters templates and not just the used ones though)
TODO
- [ ] Update documentation
- [x] Allow callback in the allow block as well
- [x] Only display list of all used blocks on the page and not all of them
Great stuff, thank you!
I'm not sure I'm following your point about the ability to sort blocks. The order specified in the array of available blocks passed to the block editor field is already preserved, so I'm curious what you mean.
Ah yes I see what the sortBy was for then, I'll make sure to restore it if a block list is given
The issue is now the rules have gotten a lot more options so it's especially more likely a list of blocks is not given and only working from excluded blocks or a list of groups in which case we can't order by the list of blocks so we need more sorting options
Maybe we can add a config list of block order, only used for sorting
I didn't yet figure out what's causing the js error in the tests as when using the PR anywhere else there is no issue, I can't run dusk on WSL to figure it out
This PR would take care of https://github.com/orgs/area17/projects/3/views/6?pane=issue&itemId=12754007
I need to check why the tests are failing, only the Web tests are failing, it seems due to a js error, how can I debug this (in a normal instance I never encountered any) ?
If you check the artefact at the bottom of https://github.com/area17/twill/actions/runs/9214252760, you'll see this error:
Ah thanks that's very helpful, so weird though that I'm not getting any error myself when it's in the main.blade.php template
Okay I know why, it's because TwillBlocks is registered in the aliases in composer.json, but aliases are not applied when running the tests locally
This PR would take care of https://github.com/orgs/area17/projects/3/views/6?pane=issue&itemId=12754007
That roadmap item isn't about disabling blocks programmatically, but that's a good addition, still! Disabled blocks in the roadmap are about a feature in the CMS UI to let users disable a specific block (so they can keep the content and not render it on the frontend). This can already be achieved easily by adding a field in every block, but we'd like to support it better natively.
@ifox I see, yes it would be nice, much like a "Draft" feature on a block basis