Just curious on any movement here - also using this on a few projects and D11 OOB compatibility would be nice.
I can confirm these two simple changes appear to be all that's necessary to be Drupal 11 compatible.
Hi Alexandru,
It's not critical or anything, but we do have a few sites where users can see each other's profiles with an embedded contact form and this could be useful there as well. This is configured on different sites for either anonymous or authenticated use.
Yup, I think this did it. I still think this would be a helpful feature for anyone looking to only enable sticky at a larger breakpoint, but it is rather simple to implement if you have access to the backend.
.toc-js-container.sticky {
position: inherit;
@media (min-width: 31.25rem) {
.toc-js-container.sticky {
position: sticky;
}
}}Hi Lacey, I think this/your module was the last one I came across so I just gave the other seniority in my mind. I've made similar "combine efforts" posts before in both module issue queues, but am not sure if that's best or to just make it in the "newer" one. I don't really have a preference.
If it turns out a key difference would be that Dark Mode uses a subtheme approach and this one (Dark Switch) uses a alternative approach, then that would be a very key, helpful difference to note on the module overview page.
It would be great if the other maintainer @johnalbin could chime in with his thoughts and recommendation for either a unified direction or distinct, separate use-case breakdown to help users.
Okay, so if I'm understanding correctly now - the variable is still just for a single value that corresponds to whatever the user needs. The issue I'm attempting to highlight here is that when the same theme has conditional elements like the top bar in Olivero, the same theme will need different offsets.
When using the default Olivero frontend theme:
- Anonymous users don't see a top bar, so 0 works well.
- Authenticated users that see the new top bar navigation need an extra 64 px top value in order for the toc to display naturally.
I currently use some hack CSS that adds an extra 4 rem (64px) when the top-bar is present:
@media (min-width: 75rem) {
.top-bar__context:not(:empty),.top-bar__actions:not(:empty)) ~ .dialog-off-canvas-main-canvas .toc-js-container.sticky {
top: 4rem !important;
}
}
But I think it would be useful to have a UI option to account for this.
Just throwing this out there as well - it would be nice if there were a UI config option to swap the "authored by" and "author name" text.
In Japanese, for example, it's very common to have
アマンダ 執筆 or アマンダによる (Amanda written by) where the name comes before the "writing/authored by" text.
@mably, I just came across this issue on some new sites as well and perhaps I just don't understand where to configure this - I didn't initially see any place for variable top settings in the UI.
Thanks again! Looking forward to updating on the sites I have the hack fixes for and ripping those out =).
@mably tested and seems to work great! Awesome, and thanks for adapting my hodgepodge to get it in so quickly!
Following up if this is helpful - console and error log give me the following (screenshots).
Hi Sujan - yes, the issue still persists showing 0:00 for all songs in the playlist after updating the module and clearing caches.
I ran into this issue on Drupal 11.2.3 with Search API 1.38. The Views “Add view” wizard breaks because search_api_data is registered as feed-capable but has no title in its plugin definition. The wizard calls Views::fetchPluginNames('row', 'feed', …) and assumes every feed-capable row plugin has a title.
Suggested Fix:
Adding
title = @Translation("Search API row"),
display_types = {"normal"}to the @ViewsRow annotation in SearchApiRow.php stops the warnings and keeps the plugin out of the feed enumeration entirely.
Testing locally:
- Wizard no longer throws PHP warnings.
- Search API views work as before.
Can confirm manually applying #21 resolves the issue on our test site.
Confirming the latest patch appears to fix the issue upon testing creation of new accounts without email values.
Posted a related deprecation patch for core flysystem's ImageStyleCopier.php file in the 3.0 D11-compatibility issue 📌 Automated Drupal 11 compatibility fixes for flysystem Needs review - I think that's the correct place.
In trying to work on D11 compatibility for the flysystem_s3 submodule 📌 Automated Drupal 11 compatibility fixes for flysystem_s3 Needs review as well, it appears Symfony’s EventSubscriberInterface::getSubscribedEvents() is defined to return an array, and core’s Flysystem integration must match or you’ll get deprecation warnings.
This patch simply adds : array to getSubscribedEvents() in core/modules/flysystem/src/ImageStyleCopier.php to address the deprecation.
@benstallings
I think @eli-t's comment means it should be:
--- a/src/AwsCacheAdapter.php
+++ b/src/AwsCacheAdapter.php
@@ -38,7 +38,7 @@ class AwsCacheAdapter implements CacheInterface {
public function get(string $key): mixed {
if ($item = $this->cache->get($this->prefix . $key)) {
return $item->data;
}
- return false;
+ return NULL;
}
public function set(string $key, mixed $value): void {
Swapping false for null should resolve that, ensuring AwsCacheAdapter::get() returns null (instead of false) when an item is not found. This should make the “assert null on a cache‐miss” pass again.
--- a/src/AwsCacheAdapter.php
+++ b/src/AwsCacheAdapter.php
@@ -38,7 +38,7 @@ class AwsCacheAdapter implements CacheInterface {
public function get(string $key): mixed {
if ($item = $this->cache->get($this->prefix . $key)) {
return $item->data;
}
- return false;
+ return null;
}
public function set(string $key, mixed $value): void {
Here's a pass at a patch for the 2 deprecation issues I see in flysystem_s3, for AwsCacheAdapter.php and S3Adapter.php - the remaining deprecation for the ImageStyleCopier.php file in the core flysystem module.
Following up on this. I'm looking to try and use flysystem for S3 in a new D11 project and avoiding drupal-lenient unless absolutely necessary =).
I'm not sure about removing "user pictures" entirely, as I have quite a few sites where user (or avatar) pictures are included for both their authored content, profile pages, comments, etc.
But the current implementations are done using a new media entity image field for users, so this would need some major rework to be modern anyway.
This would be great to improve the default media options via extensible contextual links to:
- View
- Edit
- Translate
- Download →
- Delete
I'm adding the Download one as a common use case by our users, but an extensible widget would allow a method to add additional options per use case.
The theme is Drupal core's new Olivero, so perhaps to make it OOB compatible the extra styles should be applied within the module?
@jmauricio my team will be working on a PoC for integrating media folders with our current project, and I'll follow up here. Might be a week or two.
Thinking through this a bit more I think there would be two main parts.
1. Media Folders could detect the folder nesting in the S3 bucket and then add the correct nested taxonomy to the media entity.
2. If a user changed the taxonomy term (folder location) for a media entity, Drupal would inform S3 to move the file accordingly.
3. Would some kind of "change pending" or "completed" notification be needed - possibly as a "processing" circling arrows, followed by a green check mark icon, or similar feedback to the Drupal user to let them know the change was completed successfully?
I'm not sure. Here's a better specific use case scenario.
- A user takes a picture of themselves on a mountain. The image has geolocation data by default.
- The user uploads the picture to a private or cloud storage that strips metadata.
- The user then uploads the photo from their storage to their Drupal site. This image has no geolocation data.
- The user then decides they want to create a map for the pictures that relies on the geolocation data, so they re-upload the originals directly from their camera.
- The duplicates module detects the images are the same.
In this case would it in fact detect them as the same, or would the missing metadata make them unique to the module?
I've tested this on two migrated 11 sites, inspecting for loose rules on the elements and enabling each option individually and then together, always clearing cache. I did have a block on child images, but removing it didn't fix the issue.
I tested on both Olivero and Claro, and the issue is present for both of the core themes.
Confirmed changes in fork branch to the two core user files resolves the issue on a new Drupal 11.6 install with multiple languages.
w01f → created an issue.
This says committed for 11.1.x, but I have several sites that were updated to the most recent 11.1.6 and they still show that error. I've checked and there are no valid cases of duplicate emails.
Confirming #32 still works in Drupal 11.1.6.
I think we have a similar basic question.
We have an education resource site where many of the uploaded images do have descriptive titles or a location field on the media item for where the picture was taken.
Is there a way we can reference those other media fields in the prompt so the AI can incorporate existing title details and picture location information into the generated alt text?
Ahh, I misread. Just tested on D11 site and looks great to me!
@gxleano, I just updated to the latest dev on a test site and I'm not seeing the new "Avatar image field" option. It's on a content type with a user entity reference field. Is there some other step I'm missing?
Also confirming #10 🐛 Transparent SGV Watermark = background white Needs work fixes transparent bg issue for SVGs on new Drupal 11 build.
Only if you and Jurgen think something along the lines of:
"This module is the recommended replacement in Drupal 11 for sites previously using the EU Cookie Compliance and General Data Protection Regulation (GDPR) modules."
Otherwise, I agree and think it can be closed.
I just added a "text external link" to the Links & Resources menu dropdown in the main navigation for https://www.nonprofitdrupal.org.
There you can see the awkward spacing between the last and second-to-last words.
@dom, was this ported to the new 4.0 version? I just upgraded and I'm not getting results to show, though something else may have broken as well.
Ahh, I definitely think those details should be included as an example use case or pro to using this option on the module homepage.
Sounds great to me! Thanks Jurgen