Currently the BlockContentUuidLookup which extends the CacheCollector is providing the cache id directly in the constructor as a string parent::__construct('block_content_uuid', $cache, $lock); which makes it impossible for overwrite when extending the service. And it may be necessary to do so for example if you have the Multiversion, Workspaces or any other module which has content versioning and cache properties may match.
Inside BlockContentUuidLookup create a new private variable cacheId predefined with block_content_uuid as value. Create also a public method to set the cache id setCacheId which provides the possibility to extend this service and provide a new cache id either by setting it in the extending class or using the calls declaration for the services.
For example, this solution may fix the issue in Multiversion reported here: https://www.drupal.org/project/multiversion/issues/3022195 → as cache id by which the blocks are stored would no longer be the same, there for on different workspaces same block content entities will be separated in the cache storage. The UUID to ID relations would be retrieved for each space and won't be mixed.
Closed: works as designed
11.0 🔥
Last updated
The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Curious if you are still experiencing this with D10?
$this->cid has protected visibility, therefore could be overridden by a subclass in its constructor with
public function __construct(.....
parent::__construct....
$this->cid = 'foo';
...
I don't see any need to provide a setter. If you disagree please feel free to re-open and provide more info.
Thanks