Hello Caspar,
Could you please provide the exact steps to reproduce the issue? I want to ensure I'm not missing anything, as I haven't been able to replicate the problem on my end. Thanks!
Hello Zack,
I'm not sure if any fixes are required on the module's end. Increasing the xdebug.max_nesting_level in php.ini to a higher value can help to investigate further, but this is just a temporary workaround.
Your issue might be resolved by switching PHP versions, as this could have cleared the opcode cache (like OPCache), which may fix issues caused by stale or corrupted cached data.
Yes Jakob, I’ve been able to replicate the issue. While we hadn’t considered this specific case earlier, I’m still trying to understand the real-world scenario where a customer would want to serve the same media source for both embed and download within a single application. That said, we do have the flexibility to serve different media sources for each option if needed.
Hello @ibullock, Could you please outline the exact steps to reproduce the issue?
Hello @capysara, Could you please outline the exact steps to reproduce the issue?
Hello James,
I'm not entirely sure I fully understand your point. Before responding based on assumptions, I'd appreciate a bit more clarification. It would be helpful if you could update the ticket with more details about the URLs you're navigating, along with some relevant screenshots.
Hello @bhagyalakshmi,
Currently, there is no feature that allows image type conversion during asset attachment to the content. The assets displayed in the content are shown exactly as they were uploaded to the Acquia DAM (formerly Widen) system.
I'm trying to understand the scenario where you would want to upload different image type to Widen, and you plan to serve different versions of those images on Drupal applications. Also, if you make any modifications to the image in Widen, how would that updated version be automatically converted and synced with the Drupal application? Could you please describe your use case in more detail?
I faced the same issue, but applying the patch resolved it and unblocked me from creating content.
Hello Pavlos,
The deprecation message has been removed from the Media:Acquia DAM module page.
The migration path from Media:Acquia DAM → to Acquia DAM → is already underway. A beta version has already been released 2.1.0-beta1 → , and the stable version is expected to be available by this month with improved migration dashboard experience. Most of the issues and challenges that customers face with Media: Acquia DAM have already been resolved in the Acquia DAM module. Instead of maintaining two separate modules, our goal is to focus on a single module that offers a broader range of integration options for customers.
There is no specific timeline for Media: Acquia DAM customers to migrate; however, once the migration path is established, we recommend migrating as soon as possible. This will allow customers to take advantage of the enhancements and bug/security fixes available in the Acquia DAM module.
It is possibility that no additional fixes will be made for the issues related to Media: Acquia DAM that have already been resolved in the Acquia DAM module.
That's good to hear and will help me release it as soon as possible.
Sure @zoeblair, I will be releasing soon as validating some other changes too. In the meantime, you can run at https://www.drupal.org/project/user_redirect/releases/2.0.x-dev →
Hello @tostinni,
Could you please confirm if you are able to replicate the issue from https://www.drupal.org/project/user_redirect/releases/2.0.x-dev → as I am planning to have another release with Drupal 11 compatible.
Hello vbalsys, What I meant to say is that this module is not designed to log into the Drupal system and then redirect to an external site. However, I’d be happy to implement this feature if any customers are interested in it. Any code for this would also be appreciated.
Hello @ishan.gupta,
I'm trying to understand the scenario where you'd want to serve same asset from the same media source in two different media types for both the embed and download options.
Hello Ishan,
The expected behavior is that assets will be served from the Drupal file system when both media types, "Download & sync assets," are checked. To serve assets from an embedded URL, ensure that the "Download & sync assets" option is unchecked.
I applied the patch, but the issue still persists.
vipin.mittal18 → created an issue.
vipin.mittal18 → created an issue.
vipin.mittal18 → created an issue.
vipin.mittal18 → created an issue.
vipin.mittal18 → created an issue.
vipin.mittal18 → changed the visibility of the branch 1.0.x to hidden.
vipin.mittal18 → changed the visibility of the branch 1.1.x to hidden.
vipin.mittal18 → created an issue.
vipin.mittal18 → made their first commit to this issue’s fork.
vipin.mittal18 → created an issue.
At present, when a ZIP file is uploaded to the Widen Digital Asset Management (DAM) system, it does not appear in the Drupal application. This is because the compressed_archive format_type is not yet supported by the module.
Duplicate of https://www.drupal.org/project/sitestudio_gin/issues/3497539 📌 Add support of version 4 of gin Active
vipin.mittal18 → created an issue.
vipin.mittal18 → created an issue.
vipin.mittal18 → created an issue.
vipin.mittal18 → created an issue.
ankitv18 → credited vipin.mittal18 → .
Thanks @manojapare, we are actively implementing the necessary fixes, and you can expect a prompt resolution to this concern.
rajeshreeputra → credited vipin.mittal18 → .
ankitv18 → credited vipin.mittal18 → .
ankitv18 → credited vipin.mittal18 → .
ankitv18 → credited vipin.mittal18 → .
rajeshreeputra → credited vipin.mittal18 → .
Hello @bmahesh03121,
I'm not sure I fully understand what you're trying to raise a issue. Could you clarify below?
Export and the configurations.
No Authentication credentials are exported.
rajeshreeputra → credited vipin.mittal18 → .
rajeshreeputra → credited vipin.mittal18 → .
rajeshreeputra → credited vipin.mittal18 → .
📌 Automated Drupal 11 compatibility fixes for quickedit Needs work has all Drupal 11 compatibility fixes so not required duplicate efforts on this ticket.
ankitv18 → credited vipin.mittal18 → .
ankitv18 → credited vipin.mittal18 → .
deepakkm → credited vipin.mittal18 → .
@Rajeshreeputra, Kindly add more details in the description with the screenshot, if possible.
Hello Martin,
It would be greatly appreciated if you could find some time to release a Drupal 11 compatible version of simple_gmap so that the community can upgrade to the most recent version of Drupal. Thanks!
Hello @dave,
It would be greatly appreciated if you could find some time to release a Drupal 11 compatible version of embed so that the community can upgrade to the most recent version of Drupal. Thanks!
MR !24 is working fine on Drupal 11.
Duplicate of 📌 Add Gitlab CI Fixed
Hello @rajeshreeputra, Would you like to elaborate the issue a bit more?
vipin.mittal18 → changed the visibility of the branch 3485873-dependency-injection-anti-patterns to hidden.
vipin.mittal18 → created an issue. See original summary → .
gotcha. Thanks very much Damien for your prompt confirmation!
According to my perspective, it does not make sense to make Panelizer compatible with Drupal 11, since maintainers have already announced no further development and provided upgrade paths to Layout builder. Maintainers are also not supporting D11 compatibility in 4.x version 📌 Drupal 11 compatibility fixes for panelizer [v4] Active .
@damienmckenna, Could you please let us know if you intend to make D11 compatible and see any values?
Thanks @sdjili for your response!
Hello @hchonov,
I hope you’re doing well! I’m reaching out to ask about the release plans for this module with Drupal 11 compatibility. Any updates on the timeline would be greatly appreciated. Thanks!
Hello @martin107,
I hope you’re doing well! I’m reaching out to ask about the release plans for this module with Drupal 11 compatibility. Any updates on the timeline would be greatly appreciated. Thanks!
One can use composer require 'drupal/jwt:3.x-dev' to download the JWT D11 compatible version.
To avoid any breakable changes in dev version, one can use composer require 'drupal/jwt:3.x-dev#5fe746dc'
Drupal starter kit Place support latest drupal versions.
This module supports latest Drupal version.
D10 has been supported from version https://www.drupal.org/project/acquia_cms_tour/releases/2.1.4 →
D10 has been supported from version https://www.drupal.org/project/acquia_cms_tour/releases/1.3.5 →
Drupal 1o version has been supported from version https://www.drupal.org/project/acquia_cms_video/releases/1.5.1 →
D11 stable version has been released. Refer https://www.drupal.org/project/acquia_cms_video/releases/1.6.2 →
D11 stable version has been released. Refer https://www.drupal.org/project/acquia_cms_tour/releases/2.1.13 →
D11 stable version has been released. Refer https://www.drupal.org/project/acquia_cms_site_studio/releases/1.6.4 →
D11 stable version has been released. Refer https://www.drupal.org/project/acquia_cms_place/releases/1.6.4 →
D11 stable version has been released. Refer https://www.drupal.org/project/acquia_cms_page/releases/1.6.1 →
D11 compatible version has been released. Refer https://www.drupal.org/project/acquia_cms_component/releases/1.3.12 →
D11 stable version has been released. Refer https://www.drupal.org/project/acquia_cms_search/releases/1.6.2 →
Hello @sdjili,
There is no constraint which prevents this module from upgrading to the latest 2.x version of drupal/facets. Refer https://git.drupalcode.org/project/acquia_cms_search/-/blob/1.6.2/compos...
I have tried on the Drupal 10 and Drupal 11 versions to upgrade the Acquia CMS Search module and have been able to do so. Refer attached screenshots
Kindly refer the page to resolve the issue that you are experiencing.
vipin.mittal18 → made their first commit to this issue’s fork.
vipin.mittal18 → created an issue.
I am not able to replicate the issue. Kindly provide the steps to reproduce the issue.