Create an Image SDC that can be included by other SDCs

@lauriii and I discussed this and decided to make it a beta blocker. Every design system includes components with images, so providing the XB recommended way to do that is important to include in the beta.

This is (slightly) related to ✨ Component restrictions Active per discussion with @lauriii in slack. We want to restrict an SDC on the root canvas instead of a concrete slot, but the mechanism could be similar or even the same API. For now it's fine to hard-code it.

I actually don't think this is exactly the same as what's being worked on there. What we want to do here is prevent exposing the component to the UI at all. Something along the lines of `hide_from_ui: true` property in the SDC schema. The difference is that this is the component indicating it should be hidden from the UI, vs ✨ Component restrictions Active where it would most likely be the canvas indicating what it can accept.

Something along the lines of `hide_from_ui: true` property in the SDC schema

Field types and Views plugins can have a no_ui key in their plugin definition, so we can continue with that pattern here, just in the SDC YAML instead of in a PHP attribute.

Probably worth opening a core issue to propose adding the no_ui key to SDC definitions. We don't need to hold this issue up on that actually landing in core, but it would be good to get some initial feedback on it from SDC system maintainers.

I'll work on the backend infra.

I see two alternatives:

• Add a check for ComponentMetadataRequirementsChecker::check for noUI == TRUE and not create the component config entity. Profit.
• Add no_ui to Component

I'm tempted for 2, even if potentially more complex, because:

• We can track versions when the noUI component changes.
• We can add dependencies/be dependant on.
• I suppose this might be a thing at some point for code components. Where as a site admin I cannot delete a code component because it's in use in some old page, but I want to prevent editors to add it to new pages.

Before moving further would love thoughts on #10 + the MR direction.

re: #10: Another reason for #2. When/if we migrate from LB, we might want people to use/edit pages with layouts, but we might not want people to add layouts to new pages. Those would be no_ui components.

Looks good to me

#10:

I suppose this might be a thing at some point for code components. Where as a site admin I cannot delete a code component because it's in use in some old page, but I want to prevent editors to add it to new pages.

This is already possible: the Component config entity's status needs to change to FALSE.

We can track versions when the noUI component changes.

What is the purpose of this? 🤔 A Component config entity that keeps getting updated but is not available for anybody to instantiate … what value is there in/problem does it solve to then have a log of all changes that were made to that component?

We can add dependencies/be dependant on.

This is definitely true! And that is where the prior point becomes valuable too, I suspect? 🤔

I am still not convinced we need #10.2 aka . For the dependency reason above, the first option in #10 is also not good.

Unless I'm missing something, a hybrid actually makes more sense:

1. Add a check for ComponentMetadataRequirementsChecker::check for no_ui == TRUE and DO create the component config entity. But set status = FALSE.

That means zero new infrastructure, zero config schema changes, but it achieves everything outlined in #10? 🤓🤞

I suppose this might be a thing at some point for code components. Where as a site admin I cannot delete a code component because it's in use in some old page, but I want to prevent editors to add it to new pages.

This is already possible: the Component config entity's status needs to change to FALSE.

Maybe I'm wrong, but that would not render the component on existing pages where it already existed, right? As a content manager, I'd like to be able to not affect existing pages, but still block editors from adding them again.

See also #14 where this might be even more relevant.

Maybe I'm wrong, but that would not render the component on existing pages where it already existed, right?

You're wrong :)

Component's status only controls whether those components are available for content creators to instantiate. Disabling a Component does not and MUST NOT prevent existing instances from working. In fact, that is exactly why Component config entities were introduced: to use (config) dependency management to guarantee that all existing component trees will continue to work (unless of course you're going to start hacking code and/or bypassing validation).

See the original issue that introduced the Component config entity for more detail if you like: 📌 "Developer-created components": mark which SDCs should be exposed in XB Fixed .

#19 Sure, there's no way we could manually disable SDCs as we can now if what you said wasn't true 🤦🏽‍♂️

Repurposed the MR with that info. Sadly the SDC metadata noUi attribute depends on the core change, we cannot really leap ahead unless we decided to re-parse the metadata (which we don't want).

This should be ready. We cannot leap ahead of core though. So they will be visible before ✨ Allow SDCs to be marked to be excluded from UI Active is released though.

As I wasn't explicit and I see now we didn't discuss this: I'd expect we land !1307, and a different MR for the actual component in this very same issue.