To be fixed in ✨ Create patterns/components for grid management Needs work
To be fixed in ✨ Create patterns/components for grid management Needs work
I started pocing ✨ Bootstrap 5 : Layout > Columns Active and ✨ Bootstrap 5 : Layout > Gutters Active with grid_row_1.
grimreaper → created an issue.
Fixed in ✨ Create patterns/components for grid management Needs work
Back to active.
Find transversal way of handling breakpoints later in 🌱 Generic mechanism to handle breakpoints Active , maybe it will be for UI Suite Bootstrap 5.2.x.
Back to active.
Find transversal way of handling breakpoints later in 🌱 Generic mechanism to handle breakpoints Active , maybe it will be for UI Suite Bootstrap 5.2.x.
Back to active.
Find transversal way of handling breakpoints later in 🌱 Generic mechanism to handle breakpoints Active , maybe it will be for UI Suite Bootstrap 5.2.x.
grimreaper → created an issue.
Only one call remaining and not worth to remove because logic of merging attributes, url options, etc. would had to be duplicated otherwise.
grimreaper → created an issue.
I have tested without changing the interface and it was ok.
https://php.watch/versions/8.0/mixed-type#mixed-variance
https://php.watch/versions/8.0/mixed-type#mixed-covariance
B::baz: Allowed: Narrows down the declared mixed type.
I don't know the current code coverage of the tests but I guess a tests would have failed if this change broke something.
grimreaper → created an issue.
grimreaper → created an issue.
MR updated.
grimreaper → created an issue.
grimreaper → created an issue.
grimreaper → created an issue.
Merged \o/
Remaining phpstan issue to be fixed by 🐛 Fix normalize typing Active
grimreaper → created an issue. See original summary → .
grimreaper → created an issue.
grimreaper → created an issue.
Also fix call to pattern in render array.
grimreaper → created an issue.
Child issues created.
grimreaper → created an issue.
grimreaper → created an issue.
grimreaper → created an issue.
grimreaper → created an issue.
grimreaper → created an issue.
Thanks for opening the issue.
As discussed this would definitively takes its place in ui_styles_page. I was not aware of the possibility to make distinction by routes, I first imagine a global setting like with ui_styles_entity_status to keep stuff simple.
Also putting classes on the body tag makes me think of the theme feature of ui_skins. Maybe this overlap?
But a mechanism that will allow to have different values based on the context I think it is something to be done for ui_styles and ui_skins then.
And I think such mechanism is a "source" plugin system so you could have your source plugin in which you put (configurable or not, as desired) the logic of, for this route I want those styles, for this one I want those styles, etc. Maybe with some kind of weight and a isApplicable method? And in this case it makes me think more about service tag and service collector.
If you are ok with that I will create a change record.
stripes in table is a prop.
It is also ok in Core 10.2 https://git.drupalcode.org/project/drupal/-/blob/10.2.x/core/composer.js...
I also updated the route because it had changes since then in Core's MR.
I will add a comment to point to the core issue then merge.
MariaDB [drupal]> SELECT * FROM file_managed;
+-----+--------------------------------------+----------+------+-------------------+------------------------------------------------------+---------------+----------+--------+------------+------------+
| fid | uuid | langcode | uid | filename | uri | filemime | filesize | status | created | changed |
+-----+--------------------------------------+----------+------+-------------------+------------------------------------------------------+---------------+----------+--------+------------+------------+| 5 | 5f75ac1d-3c39-45ed-9217-49e9a63fcc4a | en | 1 | square-gitlab.svg | /libraries/fontawesome/svgs/brands/square-gitlab.svg | image/svg+xml | NULL | 1 | 1730297429 | 1730297429 |
| 10 | acf3c1fc-d063-4bd9-a989-2193e4984dc1 | en | 1 | gitlab.svg | libraries/fontawesome/svgs/brands/gitlab.svg | image/svg+xml | 1055 | 1 | 1730713012 | 1730713012 |
+-----+--------------------------------------+----------+------+-------------------+------------------------------------------------------+---------------+----------+--------+------------+------------+
So I have tested with the plugin from the issue.
Has the URI is something like "/libraries/fontawesome/svgs/brands/square-gitlab.svg" with a slash at the beginning, Drupal does not detect its size.
And when I delete the media the file is not deleted but if I trigger manually the file entity deletion, then:
- app/core/lib/Drupal/Core/File/FileSystem.php::delete:
...
// Return TRUE for non-existent file as the current state is the intended
// result.
if (!file_exists($path)) {
return TRUE;
}
...
Does not detect the file so it is not deleted.
I tried with the fontawesome module media source plugin. And with it, the thumbnail URI is like "libraries/fontawesome/svgs/brands/gitlab.svg" without slash at the beginning so Drupal detect the file size, and same when I delete the media, the URI is not deleted automatically.
And if I manually delete the file entity then I got:
Warning: unlink(libraries/fontawesome/svgs/brands/github.svg): Permission denied in Drupal\Core\File\FileSystem->unlink() (line 118 of core/lib/Drupal/Core/File/FileSystem.php).
So, Drupal really tried to delete the file and it was only system file permissions which prevented the deletion.
So, I guess for the thumbnail, I think we should copy the file into the public stream wrapper and then use this copy.
On the screenshots, it seems that it is content menu link.
Feedbacks from comment 9 addressed.
I just thought of something about thumbnail.
As it creates a file entity which points to the SVG file in the library, if the file entity is deleted (for any reason: media deleted, so usage drops to 0, manual deletion, etc.), will it delete the SVG file in the icon library?
I need to check that and also test if Fontawesome does not have the same problem.