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?