We want to
* Improve default API output
* Introduce config options and UI for easily adjusting API output
* Re-implement thunder sub-module as configuration instead of using custom processors
Since change API output is a BC-break for existing sites, we'll release this as 3.x The module / Drupal APIs will stay stable.
🌱 [META] custom_elements_ui: 3.x alpha release Active - was closed after alpha1 was out. alpha2 → was released without updating this roadmap.
1. Compatibility-breaking changes
-
📌
Give "use layout builder" less precedence than CE display config
Needs work
-
🐛
drupal prefix is added to configured custom element names
Active
2. Fix significant UI issues
-
📌
Simplify entity-ce-display form and AJAX logic
Active
1. Stabilize the API
-
📌
Pass bundle-specific field definition into formatter::isApplicable()
Active
-
📌
Drop simple and single+simple slot normalziation styles
Active
-
📌
Add prepareBuild step similar to entityprepareView
Active
-
📌
Doublecheck CustomElementsFieldFormatterBase::getSetting()
Active
1. Cleanup / doublecheck
-
🐛
Update path and documentation
Active
1. Make sure we are feature complete:
-
📌
Re-add proper config-schema and test coverage
Active
-
📌
Improve CustomElement::createFromRenderArray() to better handle entites that render to custom elements
Active
-
📌
Check and extend config schema
Active
-
🐛
Old content is cached after modifying CE display
Fixed
-
🐛
Clean up CE display settings on save (or earlier)
Active
2. more bugfixes
-
🐛
Wrong default element name for new non-default CE display
Needs work
-
🐛
"Manage custom element" is not showing in dropdown menus
Fixed
3. New features which are known to cause compatibility breaks (therefore the associated code is marked @internal until it stabilizes)
-
📌
Ability to add a field multiple times
Active
-
✨
Allow configuration of static props
Active
4. New features to be added, possible after stable release:
-
✨
Provide formatters with typed data processing
Active
-
📌
Drupal 11 compatibility fixes for custom_elements 3.x
Active
Active
3.0
Code
@fago I understood from you outside this issue, that we don't want to have ✨ Allow configuration of static props Active be a 'stable blocker'?
So I moved it into "Before or right after being stable" in a new group 3, and I added a new prerequisite 📌 Ability to add a field multiple times Active before it.