Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Describe your bug or feature request.
Introducing new availability checkers directly into Commerce Core can break existing stores if they’re enabled by default (see issue #3088598: Add an availability checker which checks if the entity is accessible or not).
Site builders also need a straightforward way to enable or disable individual availability rules without writing custom service overrides.
Proposal
-
Introduce
AvailabilityCheckerWithMetadataInterfacethat availability checkers may implement to expose themselves in the admin UI via provided labels and descriptions. - Add an “Availability” section under Store → Configuration → Order Item Type → type.
-
In this section, list all availability checkers implementing
AvailabilityCheckerWithMetadataInterface, providing checkboxes to enable or disable each individually. - Legacy availability checkers (those without metadata support) remain hidden from the UI and always execute. A deprecation notice will be dispatched to encourage maintainers to adopt the metadata interface before Commerce 4.
- Preserve the execution order of all checkers via service weight.
-
Core‑shipped checkers implementing
AvailabilityCheckerWithMetadataInterface(see #3088598: Add an availability checker which checks if the entity is accessible or not) should be:- Enabled by default on new sites
- Disabled by default on existing sites
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 2025-04-22_21-02.png | 102.66 KB | zaporylie |
Issue fork commerce-3520439
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
zaporylieComment #4
zaporylieI published the MR with the proof of concept. Below is a screenshot from UI with the exposed checker from #3088598: Add an availability checker which checks if the entity is accessible or not.
Comment #5
jsacksick commentedJust one word regarding the UI. I believe the helper text should appear before the options, to at least be consistent with the order version mismatch setting.
Comment #6
jsacksick commented@zaporylie: I kind of changed my mind on this and I now believe we should explore the attributes route as we're here providing metadata which is the right use case for attributes IMHO.
Additionally, I think we should provive an update hook that sets the config based on the available checkers for BC reasons so we don't have to worry about the existing and have conditional logic...
Thoughts?
Comment #7
zaporylieI came to the same conclusion about utilizing a custom Metadata attribute. Additionally, I believe the metadata could also include an ID (separate from the service name), which would then be used in the config sequence to mark the checker as enabled or disabled.
I also think that filtering of checkers should happen in the constructor (as originally proposed) to avoid the performance overhead of limiting the list repeatedly during each call to
AvailabilityManagerInterface::check.The main advantage of using tagged services over plugins is better performance, as tagged services are collected during the container build phase. Introducing extra filtering steps at runtime for every pass would be suboptimal. This approach would only make sense if we were using plugins, which we are not.
Comment #8
zaporylieI’ve updated the PR to use the attribute approach. Generally, it’s working, but there’s a major flaw in the architecture.
Because of how the container works, a single class can represent multiple services. With an immutable Attribute, we lose the ability to vary metadata per service instance.
Given that, I’m considering moving back to the interface approach but using a Metadata value object to keep things cleaner and more structured.
Comment #9
zaporylieWe had an internal discussion that triggered a small but mighty change to the scope of this issue. The idea is to toggle availability checkers on a per-order-item-type basis.
The MR is now updated accordingly.