Remove xb_visible_when_disabled, instead update \Drupal\experience_builder\Controller\ApiConfigControllers::list() like this:
diff --git a/src/Controller/ApiConfigControllers.php b/src/Controller/ApiConfigControllers.php
index e308597fe..783836733 100644
--- a/src/Controller/ApiConfigControllers.php
+++ b/src/Controller/ApiConfigControllers.php
@@ -19,6 +19,8 @@ use Drupal\experience_builder\AssetRenderer;
use Drupal\experience_builder\ClientSideRepresentation;
use Drupal\experience_builder\ComponentSource\ComponentSourceInterface;
use Drupal\experience_builder\Entity\XbHttpApiEligibleConfigEntityInterface;
+use Drupal\experience_builder\EntityHandlers\ContentCreatorVisibleXbConfigEntityAccessControlHandler;
+use Drupal\experience_builder\EntityHandlers\XbConfigEntityAccessControlHandler;
use Drupal\experience_builder\Exception\ConstraintViolationException;
use Drupal\experience_builder\Plugin\DataType\ComponentTreeStructure;
use Drupal\experience_builder\Plugin\Field\FieldType\ComponentTreeItem;
@@ -69,7 +71,12 @@ final class ApiConfigControllers extends ApiControllerBase {
$storage = $this->entityTypeManager->getStorage($xb_config_entity_type_id);
$query = $storage->getQuery()->accessCheck(TRUE);
// Entity types can opt in to have disabled entities included in lists.
- if (!$xb_config_entity_type->get('xb_visible_when_disabled')) {
+ $require_status_true = match ($xb_config_entity_type->getHandlerClass('access')) {
+ ContentCreatorVisibleXbConfigEntityAccessControlHandler::class => FALSE,
+ XbConfigEntityAccessControlHandler::class => TRUE,
+ default => throw new \LogicException(),
+ };
+ if ($require_status_true) {
$query->condition('status', TRUE);
}
Tighten access control:
diff --git a/src/EntityHandlers/ContentCreatorVisibleXbConfigEntityAccessControlHandler.php b/src/EntityHandlers/ContentCreatorVisibleXbConfigEntityAccessControlHandler.php
index a1bb474b6..ed89c4324 100644
--- a/src/EntityHandlers/ContentCreatorVisibleXbConfigEntityAccessControlHandler.php
+++ b/src/EntityHandlers/ContentCreatorVisibleXbConfigEntityAccessControlHandler.php
@@ -6,6 +6,7 @@ namespace Drupal\experience_builder\EntityHandlers;
use Drupal\Core\Access\AccessResult;
use Drupal\Core\Access\AccessResultInterface;
+use Drupal\Core\Config\Entity\ConfigEntityInterface;
use Drupal\Core\Entity\EntityHandlerInterface;
use Drupal\Core\Entity\EntityInterface;
use Drupal\Core\Session\AccountInterface;
@@ -15,10 +16,10 @@ final class ContentCreatorVisibleXbConfigEntityAccessControlHandler extends XbCo
/**
* {@inheritdoc}
*/
- protected function checkAccess(EntityInterface $entity, $operation, AccountInterface $account): AccessResultInterface {
+ protected function checkAccess(ConfigEntityInterface $entity, $operation, AccountInterface $account): AccessResultInterface {
return match($operation) {
// We always allow viewing these entities.
- 'view' => AccessResult::allowed(),
+ 'view' => AccessResult::allowedIf($entity->status()),
default => parent::checkAccess($entity, $operation, $account),
};
}
diff --git a/src/EntityHandlers/XbConfigEntityAccessControlHandler.php b/src/EntityHandlers/XbConfigEntityAccessControlHandler.php
index f588d457d..828aaee88 100644
--- a/src/EntityHandlers/XbConfigEntityAccessControlHandler.php
+++ b/src/EntityHandlers/XbConfigEntityAccessControlHandler.php
@@ -7,6 +7,7 @@ namespace Drupal\experience_builder\EntityHandlers;
use Drupal\Core\Access\AccessResult;
use Drupal\Core\Access\AccessResultInterface;
use Drupal\Core\Config\ConfigManagerInterface;
+use Drupal\Core\Config\Entity\ConfigEntityInterface;
use Drupal\Core\Entity\EntityAccessControlHandler;
use Drupal\Core\Entity\EntityHandlerInterface;
use Drupal\Core\Entity\EntityInterface;
@@ -34,7 +35,7 @@ class XbConfigEntityAccessControlHandler extends EntityAccessControlHandler impl
/**
* {@inheritdoc}
*/
- protected function checkAccess(EntityInterface $entity, $operation, AccountInterface $account): AccessResultInterface {
+ protected function checkAccess(ConfigEntityInterface $entity, $operation, AccountInterface $account): AccessResultInterface {
$adminPermission = $this->entityType->getAdminPermission();
assert(is_string($adminPermission));
return match($operation) {
User interface changes
Comments
Comment #3
wim leersTests still needed.
Comment #5
penyaskitoThis has new tests, removes
xb_visible_when_disabled, and behaves the same way as HEAD.The only issue is that JavaScriptComponent is singled-out:
This means that Pattern probably should have had the
xb_visible_when_disabledflag too.NR for confirmation.
Comment #7
wim leersComment #8
wim leersComment #9
wim leersComment #10
mglamanComment #13
mglamanComment #14
wim leersComment #15
mglamanRTBC, rerolled @penyaskito work. Called out a few items to discuss which look OK.
Comment #16
wim leersThis lost multiple performance optimizations for the crucial
/xb/api/v0/config/componentresponse — which is what is a critical factor in booting the XB UI! This is a big, and expensive response, and so the existing optimizations must be kept if at all possible.Posted comments on the MR to explain this and pushed commits to bring those back while staying true to the spirit of the issue. There's at least one failure in need of debugging still.
Approved on the assumption that the remaining failure will be fixed while keeping both optimizations (the config entity query optimization as well as the cache tag response header optimization).
Comment #17
mglamanCI failing but Wim made good fixes, I'll address
Comment #18
wim leersDug deeper, because this can't land without passing e2e tests that this caused to fail.
The root cause for all the painful bits that were surfaced here is
type: field.value.datetime. Introduced in 2014. Zero issues mention it! 🤯IOW: they’re not actually default values, but instructions for generating default values — wow! 🤯
I first wanted to open an upstream (core) issue titled
Allow creating a default field value from a valid field value— but then I realized that literally defeats the point of #1989468-4: Weird messing with 'default_value_function' in date widgets ? — the very point is that no hardcoded value makes sense for datetime — only: "now" and "X time before/after now".So, instead opening an XB follow-up. Because this is the first time the shape matching logic and infrastructure ends up … not working. 😬
Comment #19
wim leersAttempted to fix it here, by special-casing the
datetimeanddaterangefield types in::computeDefaultFieldValue(). 🤞Need to shift to other things now…
Comment #20
wim leersManual testing suggests that I succeeded in adding
::processDefaultValue()support? 🤞Comment #21
wim leersFYI: this is wildly out of scope here, but it happens to have been surfaced here 😬😭
Fortunately, all the access control changes are basically trivial, which is why this MR's size is still very manageable. So if #20 passes, then I'm gonna go ahead and merge, so we can all move on and pretend this was a bad nightmare 🧟♀️
Comment #22
wim leersI hope all remaining failures are solved by #3528362: Deterministic Component version hash should depend not only on source-specific settings, but also slots + explicit input schema. Because they are AFAICT all like this:
[versioned_properties] The version 6c1061657e221db7 does not match the hash of the settings for this version, expected 0273dc5c85818057.Comment #23
mglamanThis is postponed because we added lookup keys, right? Can we un-postpone this ticket is adding lookup keys for performance was spun out and blocked on that other ticket? That way we land the new access handlers albeit with a performance hit until lookup keys added?
Edit: we can still keep condition check but just not check lookup keys, so same as it was before
Comment #24
wim leersExcellent call, @mglaman. Will make it so.
Note that lookup keys already exist (
PageRegionuses them too). But it's the combination ofApiConfigControllers::list()being modified hereComponentconfig entity's lookup keys, to keep the intended optimization, even though it's absent in HEAD… that caused it to go unnoticed.
Splitting out is worth it here to A) allow progress, B) improve archeology. Will do so 👍
Comment #25
wim leersDone.
I'm calling it a day — #3528362: Deterministic Component version hash should depend not only on source-specific settings, but also slots + explicit input schema was incredibly tricky too. Braindead now.
Comment #26
wim leersI'll need to file a follow-up next week to bring back https://git.drupalcode.org/project/experience_builder/-/merge_requests/1...
Comment #28
wim leersMerged!
Happy weekend everyone.
Comment #29
penyaskitoCreated #3528847: Implement `lookup_keys` in Component for optimized queries