yeah, even as I did it it felt wrong LOL. More just an experiment to see if it would work, definitely not advocating it now in the cold light of morning. Bypassing the lazybuilder if it is unsaved is definitely the better way to go.
Experimentally:
eva.module:
function eva_entity_view(array &$build, EntityInterface $entity, EntityViewDisplayInterface $display, $view_mode) {
$type = $entity->getEntityTypeId();
$views = \Drupal::service('eva.view_displays')->get($type);
foreach ($views as $info) {
$longname = $info['name'] . '_' . $info['display'];
if ($display->getComponent($longname)) {
if ($view = Views::getView($info['name'])) {
if ((empty($info['bundles']) || in_array($display->getTargetBundle(), $info['bundles'])) && $view->access($info['display'])) {
$view->setDisplay($info['display']);
// Hand over to lazy builders, so that the cache contexts of the view
// don't bubble to the whole page if they would make it uncacheable.
$view_cache_metadata = $view->display_handler->getCacheMetadata();
if ($info['uses exposed'] && $display->getComponent($longname . '_form')) {
$build[$longname . '_form'] = [
'#lazy_builder' => [
'eva.lazy_builders:displayView',
[
$entity->getEntityTypeId(),
$entity->id(),
$entity->isNew(),
json_encode($entity->toArray()),
$info['name'],
$info['display'],
TRUE,
],
],
'#cache' => [
'contexts' => $view_cache_metadata->getCacheContexts(),
'max-age' => $view_cache_metadata->getCacheMaxAge(),
'tags' => $view_cache_metadata->getCacheTags(),
],
];
}
$build[$longname] = [
'#lazy_builder' => [
'eva.lazy_builders:displayView',
[
$entity->getEntityTypeId(),
$entity->id(),
$entity->isNew(),
json_encode($entity->toArray()),
$info['name'],
$info['display'],
],
],
'#cache' => [
'contexts' => $view_cache_metadata->getCacheContexts(),
'max-age' => $view_cache_metadata->getCacheMaxAge(),
'tags' => $view_cache_metadata->getCacheTags(),
],
];
}
}
}
}
}
LazyBuilders.php:
/**
* Builds either the view or the view exposed form for the attached view.
*
* @param string $entity_type_id
* The entity type ID of the attaching entity.
* @param string $entity_id
* The ID of the attaching entity.
* @param bool $entityIsNew
* Whether the entity is new.
* @param string $entity_values
* The values of the entity.
* @param string $view_id
* The ID of the attached view.
* @param string $view_display_name
* The name of the view display to show.
* @param bool $show_exposed_form
* (optional) Whether to show the exposed form, or the rest of the view.
* Defaults to FALSE.
*/
public function displayView($entity_type_id, $entity_id, $entityIsNew, $entity_values, $view_id, $view_display_name, $show_exposed_form = FALSE) {
$entity_storage = $this->entity_type_manager->getStorage($entity_type_id);
$entity = $entityIsNew ? $entity_storage->create(json_decode($entity_values,JSON_OBJECT_AS_ARRAY)) : $entity_storage->load($entity_id);
...
This seems to correct the issue I was seeing, but no idea on any other implications past my corner case.
Fixing services dependency injection is straightforward:
in eva.services.yml:
eva.token_handler:
class: Drupal\eva\TokenHandler
arguments: ['@token']
Drupal\eva\TokenHandler: '@eva.token_handler'
eva.lazy_builders:
class: Drupal\eva\LazyBuilders
autowire: true
in LazyBuilder.php:
...
use Drupal\Core\Entity\EntityTypeManagerInterface;
use Drupal\eva\TokenHandler;
...
/**
* The entity type manager.
*
* @var \Drupal\Core\Entity\EntityTypeManager
*/
protected $entity_type_manager;
/**
* The token handler.
*
* @var \Drupal\eva\TokenHandler
*/
protected $token_handler;
public function __construct(
EntityTypeManagerInterface $entity_type_manager,
TokenHandler $token_handler
) {
$this->entity_type_manager = $entity_type_manager;
$this->token_handler = $token_handler;
}
You can then switch your \Drupal::service calls out for the appropriate $this-> call.
There is however an issue I ran into in testing that I am struggling to resolve. When using Layout Builder and the block_content module (both core), new blocks that have an EVA field on them cause a WSOD. This is because prior to saving layout, the custom block entities exist in a limbo state, where they have no ID and thus cannot be loaded from entity. This breaks the entity load in displayView().
Unfortunately, passing the entity itself from eva_entity_view() to the LazyBuilder isn't possible, so I'm testing out passing values for spot-recreation instead. Kind of clunky, but that's the only thing I can think of.
Excellent! Thank you!
This is an excellent and long overdue feature. Only thing I noticed is that in testing, the autocomplete widget seems to strip out the grouping. Any workaround?
Looks like some of this may be answered in the new Icon API, but not sure that would backport into this module.
There's a couple of things going on. I am not sure why their composer.json doesn't resolve the dependency issue. It's also odd that the readme has you go through a bunch of steps to install the NPM, when the statement in their on composer should install it. That should really be updated, as the method described creates a ton of bloat.
I any case, I copied and pasted the package data for apache/echarts into my main composer.json and it let things install fine, and does pull down the latest version at time of install.
Alt text is not always necessary, in that some images are considered "decorative" in that they are not needed for the content. A good example of this is things like thumbnails for a news story link. There is a module to allow for this, the Decorative Images Module, which allows for blanked alt text.
There shouldn't be a case where the title attribute is filled in but alt is not, though the inverse is fine. Right now, Blazy seems to obstinately fill the title in, even if it is left blank intentionally, and seems to be pulling in the media item label if nothing else (blazy/src/Theme/Attributes.php:494)
I think this is what you want here:
Alt filled, title filled
Current: GOOD Expected: GOOD
Alt filled, title empty
Current: GOOD Expected: GOOD
Alt empty, title empty
Current: GOOD Expected: GOOD
Alt empty, title filled
Current: GOOD Expected: BAD
Can confirm this seems to work as expected. Thanks!
Is it possible to put in a check for browser and version to simply skip the relevant check?
R_H-L → created an issue.
It is the Extended Support Release
I work for an academic institution, so they control the version on machines,
R_H-L → created an issue.
Apologies, it looks like we were applyingthe patch from this issue: https://www.drupal.org/project/layout_builder_browser/issues/3206268 →
Which was causing the problem. this can get closed
Given that entity_reference_revisions is currently the 6th most installed across the current codebase, I'd say the demand is there for the functionality to be in core. It's useful in a few places, such as referencing certain revisions of custom content entities as we do in custom blocks for Layout builder, but I admit ours is a corner case. Paragraphs uses this same model and without being able to reference a revision of a child element, reversion is complicated.
#22 is 100% the case, and the disconnect is something we hear about from our users. We have run into plenty of times where an editor made changes to the Body of a Node, then didn't understand why the changes did not show up, not realizing that they had replaced the body in the display. From an editor UX perspective, this kind of unified experience would be ideal. Other node options could exist in a similar sidebar/modal/layout builder interface.
The sidebar is fine for many fields, especially as it can be resized by the user, or resized by developers with CSS as we do now. Modal is another option.
Can my last fix (#8) be considered?
Using Placeholder::DATA . ' x1' instead resolves the issue for me.
We are having good luck with aspect ratio setting, thank you for that.
One thing we have also notice however is a small broken image tag issue, that comes from the srcset placeholder insert you do in src/Theme/BlazyTheme.php:215. The constant is set to "about:blank" in src/Media/Placeholder.php:22, which results in a brief broken image icon on slow connections, and a network issue. This is independent of the placeholder settings in the config. This should instead be a blank string "".
In our view, we don't use the fields for anything other than sorting/filtering; we are rendering the node directly. I have gone in and enabled "use field template" on the two sorting/filtering fields (ID and Authored on) and it made no change.
However, setting the Aspect ratio may have solved the issue. We will have to test. I will get my frontend guy on it and report back.
@gausarts:
Since we do not use slick for these views, I don't think they apply. These are using just a normal node display mode as the output, The display mode does implement Layout Builder and does not use slick, but uses the Blazy Media responsive image formatter. We don't use rewrite results.
Looks good to me.
Happy to provide a poke to action :)
This is a fantastic module/library.
Testing this in 9.5, #50 breaks the a tag extra attributes. The tag gets put in as just the bare '/node/x' without any data attributes.
Awesome. Seems to work, and scans within our accordion panels, as expected. Thank you!
Unfortunately, all of our sites are access controlled by Single Sign On, so I can't give access.
Altered the code to make that call nullsafe
e.shadowRoot?.querySelectorAll(`:is(${n})`+s)
Which then resulted in the element being removed entirely from the DOM so that's less than ideal. Could a feature be added to have an "Always Scan these" for hidden things like accordions, or is there a method for making them scannable?
I did also try some other selectors, including base tags and none worked.
With the widespread adoption of the HTML dialog element, this should become more a matter of modernizing modals. This element supports chaining dialogs, styling, form awareness, good accessibility, and a host of other benefits.
Simple example:
<dialog id="first-dialog">
<p>Greetings, one and all!</p>
<button data-role="open-dialog" data-target="#second-dialog" onclick="document.querySelector(this.getAttribute('data-target')).showModal()">Show second dialog</button>
<button data-role="close-dialog" onclick="this.closest('dialog').close()">Close</button>
</dialog>
<dialog id="second-dialog">
<p>Surprise!</p>
<button data-role="close-dialog" onclick="closest('dialog').close()">Close</button>
</dialog>
<button data-role="open-dialog" data-target="#first-dialog" onclick="document.querySelector(this.getAttribute('data-target')).showModal()">Show dialog</button>
Commit looks good, merged and new release created. Thank you!
I know this is an old issue, but you have to remove the access check:
$query = \Drupal::entityQuery('group')
->accessCheck(FALSE);
$gids = $query -> execute();
We ended up rebuilding the relevant piece. It looks like this was a weird collision between the APC and views_field_formatter, since clearing the specific view cache tag worked. We switched to the EVA module and rebuilt, and it corrected the issue. Safe to close for now.
Manually updated the code, should work
Is there a plan to commit this and roll it live?