I can confirm that we need to investigate here because of the size calculation with the new navigation :/
I have no clue how I encountered this but the merge request was a quick fix for that, thanks π
I agree that removing the type="checkbox"
needs to be there but I am still wondering what could be the reason that the contextual menu doesn't render properly in a custom theme.
pdureau β credited yannickoo β .
In case that people are still interested in seeing how to solve this nowadays: You can use the combination of Menu Item Extras β and UI Icons to get this working πͺ
yannickoo β created an issue.
yannickoo β created an issue.
yannickoo β created an issue.
Hello @weseze, can you provide me an example of the values you are using for the attributes so I can have another look on that? Let's try to get another fix that also works in your case out asap!
Hey @just_like_good_vibes! I would recommend to use the Embedded Content β module and provide a way to provide plugin derivatives for all SDCs.
Here you can find an example implementation of an Embedded Content plugin
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
Hey bessonweb, unfortunately this is not supported by the module since it only acts on the field value.
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
π£ Drupal 7 has officially reached it's EOL in January 2025, we are closing this issue accordingly
yannickoo β created an issue.
Hey peter.thorndycraft, thank you for creating this issue. In order to replicate your described problem I would need to get some steps to reproduce since I didn't have any problems with HTML chars.
Thanks!
Hey aaron.ferris, thanks for your MR! This has been handled over in π Config form arguments error Active but you got credited as well πͺ
Thanks to everyone who contributed here! The MR has been merged and will be released with the next version of Linked Field!
Hey Daniel, thank you very much for this contribution! Really nice to see that the Link Attributes & Linked Field modules work smoothly together π€ I had to adjust the MR a bit so that class
and rel
are merged correctly and support for delta has been added as well.
Merging this and will be shipped with the next release π’
yannickoo β made their first commit to this issueβs fork.
Thanks to everyone for fixing this important issue! The merge request !20 has been merged and will be released with the next version πͺ
Thank you very much Damien! The MR has been merged and will be released with the next version π
yannickoo β created an issue.
@dalin the cool thing about the new Icon API is that any extension can provide an icon pack so it might be totally enough to have a custom module with an images
folder that contains screenshot of your different paragraph types.
You can easily let Drupal scan your folder for any *.png
files and tell Drupal how to render your "icons" e.g.
paragraph_icons:
extractor: path
config:
# One icon per listed source, allowed extensions: svg, png, gif, relative to
# this file or to drupal root if start with a `/`. Remote icons are allowed too
# Format can be mixed but only one template is possible. If same id (name here)
# later will override.
# If an icon does not exist, it will be ignored and a log message will be created.
sources:
- images/gallery.png
- images/another-image.png
- images/text-paragraph.gif
- https://www.drupal.org/files/drupal-wordmark.png
template: '<img src="{{ source }}" width="270" height="160" alt="{{ icon_id }}">'
That would register and provide four different screenshots that could be referenced like paragraph_icons:gallery
, paragraph_icons:another-image
, paragraph_icons:text-paragraph
, paragraph_icons:drupal-wordmark
.
No matter if we have nicely prepared SVG files or just screenshots, the new Icon API would allow us to expose them easily and use them by just their ID π₯
yannickoo β created an issue.
Hey! I just want to mention that I have suggested using the new Icon API β for managing paragraph icons over in 2854585#24 β¨ Improve icon selection in paragraphs type form. Needs review , that could bring this here to another level π
Hello together π What do you think about changing the direction here completely and make use of Drupal's new API for icon management β ?
That would allow themes or modules to define icon packs that can be easily referenced in the Paragraph type configuration like my_icon_pack_name:gallery
and can be rendered via PHP or Twig:
PHP:
$build['icon'] = [
'#type' => 'icon',
'#pack_id' => 'my_icon_pack_name',
'#icon_id' => 'gallery',
'#settings' => [
'size' => 64,
],
];
Twig:
{{ icon('my_icon_pack_name', 'gallery', {size: 64}) }}
There is a really cool widget that is available when installing the UI Icons β module that allows you to choose icons via autocomplete:
When storing simple IDs of icons we don't need to care about storing paragraph icons anymore and they can easily survive deployments π
yannickoo β created an issue.
Hey I just checked the implementation in the MR and I am not sure if we want to rely on the breakpoints that are defined in the YAML file. What would you think about using a JS condition for this, e.g.
if ('ontouchstart' in window)
Hey! First of all thanks for the contribution!
I'm currently reviewing the MR and I think this modules should provide attribute for the menu links (which covers the <li>
and the <a>
elements. I don't see big reasons to allow site managers to add attributes to the <ul>
element itself and those could be rather added via a dedicated menu.html.twig
file.
What do you think?
yannickoo β created an issue.
yannickoo β created an issue.
yannickoo β created an issue.
It seems like shadowrootmode="open"
attribute is influencing the behavior of a cloned <responsive-img>
element. After removing that attribute everything works as expected π
yannickoo β made their first commit to this issueβs fork.
joachim namyslo β credited yannickoo β .
Oh wow I didn't know that the toolbar looks so crazy without Gin theme π€―
The big problem is that the regular toolbar does not open on hover, only when clicking. Having a simple Edit link could work but then we lose all the ability to choose one of the other local tasks.
Gin solves it in a really nice way: On wider viewports you expand the tray when hovering and on narrow screens you get the "click to open" behavior which simply shows all the other local tasks.
β‘οΈ I have attached a patch β so you can quickly test that without polluting the MR
Regular toolbar with "Edit" link that has icon
Regular toolbar with hidden "Edit" link when on entity edit form
Gin toolbar (wide) with separated "Edit" link
Gin toolbar (narrow) with try that opens on click
I would love if we could somehow get the UX that Gin provides otherwise I find that standalone "Edit" button a bit tricky from UX perspective :/
joachim namyslo β credited yannickoo β .
Thanks for your effort @dydave! I had to think about this for a longer while and also asked other people what they could easily understand to navigate around easily.
New suggestions that I really like and never saw in Drupal before:
- Page Tools
- Page Actions
- Quick Actions
- Actions
@dydave I think we can keep the other one open since we still need to figure out which labels could be a good replacement for Local Tasks π
Hey @dydave, I just took the time to quickly implement this request. The idea is to show an Edit button instead of Local Tasks if there is an entity edit form URL available. Like that editors could simply click that button to edit an entity which is a node in many cases.
A while ago it was possible to show the local tasks inside the vertical Gin toolbar β¨ Add option for node local tasks in toolbar Closed: won't fix . That issue was closed due to the functionality that Admin Toolbar Tools module provides. In order to make editor's life as easy as possible this is what I suggest:
Entity pages
In case that the local task links contain a route that has the pattern entity.TYPE.edit_form
we use that URL for the button itself and also rewrite the label from Local Tasks to Edit so editing an entity is just one click away.
All other pages
If there is no entity edit form URL available we just take the current behavior which is showing Local Tasks.
yannickoo β created an issue.
yannickoo β created an issue.
leymannx β credited yannickoo β .
joachim namyslo β credited yannickoo β .
joachim namyslo β credited yannickoo β .
heroicnick β credited yannickoo β .