Thanks to you, Sascha, for the fast turnaround, review and merge.
Co-maintainer here. I tested the patch but couldn't figure out how (or where) to use the new formatter in a practical way.
For example, one place where I see Media Thumbnails being used is in the Media Library's default (table) view at /admin/content/media. Unfortunately, the formatter doesn't work in this context because the Views field config requires a single Image Style formatter for all media types. To work around this limitation, I created a Thumbnail view mode for all media types: Raster Images (and other media types) display the Thumbnail field with the 100x100 image style, while the Vector Image media type uses the main SVG field with 100x100 dimensions applied. Then, I updated the Media Library view to use a Rendered entity field with the new Thumbnail view mode and removed the Thumbnail field.
In this case, a potential solution could be to adjust the Image formatter when used on an SVG's Thumbnail field to calculate dimensions based on the selected image style, combined with the module's "Inline SVG" and "Apply dimensions" features. While this is an opinionated approach, alternatives like injecting settings into the Image formatter or creating a UI for SVG-specific settings per image style are less desirable.
In summary, and basically to restate what @mandclu said above, we need a better understanding and a practical situation where the Thumbnail field on the Vector Image media type is actually useful or required.
Before:
After:
jwilson3 → created an issue.
Rivet table styles are responsive out of the box in my testing.
I was able to reproduce this issue on a clean install. I'll work on a fix.
Sorry, I'm not going to add that CSS without the additional context I asked for, including screenshots. If this is related to views, I need a list of steps to duplicate the bug, including steps on how to create a view that exhibits problems.
You're free to subtheme the Rivet theme and add any custom CSS you need, as this methodology is exactly how Drupal base themes are intended to be used.
On Drupal 10, I was able to add both a field for the Alt text using the approach in #3, as well as an exposed filter using a grouped dropdown of the "Image (alt)" field using different potential values in the dropdown:
- Empty
- NULL (has a special meaning in the database, but essentially the same as "Empty").
- Possibly too short (alt text less than 10 characters long).
- Possibly too long (alt text more than 100 characters long).
jwilson3 → made their first commit to this issue’s fork.
Needs more clarification. Where or how you were creating tables that broke? Please add screenshots and ideally a code snippet of a broken table. I'm just trying to clarify whether this is an issue we should solve in this theme, or whether this needs to be filed in the upstream repository: https://github.com/indiana-university/rivet-source
Thanks.
I'm currently unable to install the Rivet theme on Drupal 11, because it depends on the IU_Paragraphs module which itself has dependency conflicts in composer.
However, I've created an MR that should resolve this error, I hope. I wonder if you'd be able to test the patch to confirm?
Just a note that it looks like a commit was added as part of the solution on 🐛 Error when trying to access Pantheon Search Admin page Active in release 8.1.10 that may fix this issue in another way, but I'm not entirely certain:
https://git.drupalcode.org/project/search_api_pantheon/-/merge_requests/...
Updated issue summary to describe both workarounds.
Thanks. I found the existing issue here 🐛 slick.theme.css overrides Blazy CSS Active . If I'm reading the project's git commit graph correctly, then upgrading to 3.0.4 → should fix the issue.
The resolution I proposed above seems to be better than the one taken on the original issue, so I'll leave it up to the maintainer to make a decision whether you want to re-introduce the CSS in a way that it only affects Olivero theme.
Thank you everyone for working on this! 🙏
I've created a follow-up 🐛 Overqualified CSS to fix Slick Views on Olivero theme breaks any theme and any view Active .
jwilson3 → created an issue.
Sadly, the CSS change associated with this issue from commit 299772e4 is having unintended consequences on my theme.
We have code like this:
.view-events-today .view-content {
display: flex;
flex-direction: row;
flex-wrap: wrap;
gap: 2rem;
}
But do to the extensive and generic overqualified CSS provided by this module, our display: flex
is overridden with a .block .view .view-content { display: block; }
. Why was this change made?
- /* Fix for unnecessary Olivero Grid surprises causing Slick excessive height. */
- div[class*="view-slick"],
- div[class*="view-slick"] .view-content,
- div[class*="view-blazy"],
- div[class*="view-blazy"] .view-content {
+ /* Fix for unnecessary Olivero Grid surprises causing Slick excessive width. */
+ .view,
+ .view .view-content,
+ .block .view,
+ .block .view .view-content {
display: block;
}
It seems like there must be a better way to scope this to fix something specifically for the Olivero theme.
@sourav_paul, thanks for confirming.
Let's move this issue then to Gin theme!
jwilson3 → created an issue. See original summary → .
Let's open a follow-up instead.
This needs a little more work for featured slot which should not sit against the rail at certain screen sizes.
Ultimately what worked:
composer:
variables:
DRUPAL_CORE: 10.3.6
Would be nice to get the D11 change added to the info.yml file. Thanks.
jwilson3 → created an issue.
jwilson3 → created an issue. See original summary → .
jwilson3 → created an issue. See original summary → .
jwilson3 → created an issue.
jwilson3 → created an issue. See original summary → .
jwilson3 → created an issue.
jwilson3 → created an issue.
Note: Gin admin theme pictured above. Untested with Claro admin theme. If this doesnt apply to drupal core, then it should be moved to the Gin issue queue.
jwilson3 → created an issue.
jwilson3 → created an issue.
This needs work. The MR is impossible to review or even use in its current state because it is polluted with out-of-scope changes.
I suggest opening a new MR that contains only the necessary changes for the HTTP GET implementation.
I also suggest using the methodology documented in the Change Record resulting from core issue #956186.
Change Record #3193798: Ajax request type can be set to GET (POST by default) →
Tested on Simplytest.me
Screenshots:
It is not entirely clear why the last patch in #151 failed because the Drupal CI job output is miles long. This needs to be converted to an MR, with "careful reroll" as pointed out in the issue tags, to get things over to GitLab CI.
Looks like "tree-shake" is a specific algorithm for javascript frameworks to prune their DOM/Virtual DOM trees.
Therefore a more appropriate term here would be just "pruning".
While looking into this issue I also realized there is opportunity to take things a step further and reduce those redundant permissions.
I filed a sister ticket and follow-up ✨ Tree shake permissions matrix upon save Active .
jwilson3 → created an issue.
Improve readability.
jwilson3 → created an issue.
Closing this one since Drupal 11 automated fixes are the new thing, and Drupal 10 automated fixes are no longer going to be updated.
Plus this module is deprecated.
This module is obsolete after Drupal 10.2
Please see the big notice on the project page and the change record:
Completely agree with @codebymikey in #3. There is little benefit to using a wysiwyg formatter here, especially since CKEditor 5 is known to modify HTML it believes to be "incorrect" (even when it is not technically incorrect). CKEditor 5 won't check validity of Twig, only HTML validity and structure, so at best CKE is a partial solution to the equation anyway. The onus should be on a developer to ensure proper HTML structure (eg properly nested and closed tags, etc) just like everywhere else.
Updated issue summary with Proposed Solution.