🇨🇦Canada @joelseguin

I've tested the patch and it works without issues.

** For reference, patch seems to be the same as the duplicate issue (now closed) where a few have also tested:
https://www.drupal.org/project/opigno_lms/issues/3483078 🐛 it is not possible to create an activity Needs work

Thanks @kanchamk! I can confirm that the patch works nicely. I Just tested on my dev site and the activities page now loads as expected.

** For reference, here is what I used for patching using Composer Patches (was originally trying to patch against opigno_lms):

"drupal/opigno_learning_path": {
"it is not possible to create an activity": " https://www.drupal.org/files/issues/2024-11-05/it-is-not-possible-to-cre... → "
}

I can confirm this issue. It is not possible to update or add new activities following an upgrade from Opigno LMS 3.1.0.

The other sections within the course (Description, Modules) seem to load fine.

Here is a screenshot showing a javascript error when navigating to the Activities page.

I've tested with a fresh D10 install and the 2.x branch and it is definitely loading the jQuery library (from /core/assets/vendor/jquery/jquery.min.js).

To reproduce:

• Disable CSS and JS aggregation from the Drupal UI
• Add an actual Google Analytics (G-xxxxxxxx) tag ID
• You will notice the jquery.min.js file being loaded in the front-end of the site

I would be happy to test a patch if someone has a chance to work on one.

@MarkConroy

I've applied the patch to my test site and it works great!

I've tested against a few different scenarios and it is working as I would expect. I even tried adding a content type that my test user does not have edit/delete permissions and it could only be seen in the content list (view only).

The one thing I did notice was that if this patch gets merged it would be an important change in how the module works with permissions.

• For existing sites that have not assigned specific content type permissions to roles, then those roles would lose access to modify/delete altogether. I've tested this out and it is the case.
• It should probably be mentioned that after updating the module, site builders should go back and verify the content type permissions since content access will likely be different following the update.
• For new users of the module, it might also be helpful to provide a reminder on the Content Access By Path taxonomy term form display. For example: Make sure to provide the necessary permissions to content types as well.

joelseguin → created an issue.

I'd like to offer up an solution that seems to have worked nicely for my use case without the need for a patch. Perhaps this will work for others.

No issues with content translation with Webform when using the following language and detection configuration:

• Interface text language detection: Session enabled
• Contenu language detection: Session enabled

Previously I did not have an option enabled for "Interface text language selection" and only had "Content language" enabled for "Content language detection". Now, with both having "Session" enabled, everything works as expected and cleaner URLs (?language=en vs using ?language_content_entity=en and does not get added to the default site language).

1) Thanks! I can confirm that the latest patch from #26 (3175374-23.patch) works against Webform version 6.2.

I came across this issue after a bit of searching as I couldn't quite figure out why my webforms' translations were not getting applied. There is definitely a need for translation based on content as I would've had to take a different approach for translating our site. My use case is that only certain content types from our native French website are offered in English. The rest of the site, we simply offer Google translation.

2) As per @gbotis, I've noticed the same issue with the patch where specifically the subject, the body and the confirmation message cannot be translated. Happy to test out any future patches.

The "save config" event definitely works nicely with any webform access configuration that has changed - thanks!

However, it seems that the actual users that are added to a Webform Access Group are not saved as config and are not accessible for that reason. Here is an example of a Webform Access Group config. Note that user ids are not stored within config (which completely makes sense):

uuid: ba4ca60a-c97a-48c9-875e-8f05cee3efa7
langcode: en
status: true
dependencies: { }
id: south_region
label: 'South Region'
description: ''
type: regions
permissions:
- create
- configuration
emails: { }

Any thoughts as to how we could access the IDs of users that have been updated? Ultimately, the idea would be to be able to programmatically (via ECA) add/update user IDs based on logic.

No problem, will test that out and report back.

I can't seem to be able to apply the patch via composer to test.

I have come across this issue as well. If I indicate that an event is full day the event spans across two days in the calendar. I've attempted to change various settings in my smart date field in the view and none seem to have addressed the issue. Happy to offer testing as needed on this.

I've reproduced this in the Views preview as seen in this screenshot:

Made tweaks in regards to clarity of the text and images specifically around the use if filters to limit the result set.

@benjifisher - thanks for the patch! I had assumed this functionality was already part of Paragraphs until I noticed it wasn't. I think it's very helpful for site builders as it improves the authoring experience especially when making use of many Paragraphs. It also serves as a reminder to actually set permissions for any new Paragraph that is created.

I tested the patch against the latest stable 1.x version and it worked without issues.

I'm seeing this issue as well on a new D10 build. Happy to test out any future patches.

Following a bit of testing I was able to pinpoint the issue.

It seems as though when using the Viewsreference field → module to display a calendar with ajax, the results do not load as expected when navigating via the months links.

This can be tested by installing the Viewsreference field, creating a calendar view and enabling ajax. From there, add a Viewsreference field to a content type of choice. Enter content and select the calendar view created. Navigate the calendar (which should contain several recurring events) via the month links.

At the moment, I've circumvented the problem by using a Block field → instead of a Viewsreference field.

I've come across this issue while using Feeds with Opigno LMS. It seems as though Opigno makes use of the "Override cron queue processing" options and I'm assuming config relates to the issue (as I have no problems with several other sites using Feeds and Ultimate Cron).

I can confirm that patch #2 still works on 2.0.0-alpha6. Perhaps it is worth considering integrating this patch in the next release?

@frankdesign the latest patch (from MR 6) is working nicely for me. No errors in the logs. Both background image and responsive background image formatters work as expected with background images appearing on the frontend of the site.

Sorry about that, I hadn't fully tested on a completely fresh Drupal (10) install. After doing a test on a fresh install AJAX does work as expected. There is likely a module causing an issue on the fairly simple site I'm working on. I'll report back with my findings once I get a chance to do more testing.

I can confirm that on Drupal 9.5.10 the patch worked perfectly for me. I added several users to a training and was getting a WSOD when visiting the catalog page. Patch applied, no errors in the even log and users can now access the page as expected.

joelseguin → created an issue.

Thanks @Jeya sundhar - I can confirm that the patch worked perfectly after testing against the same site making use of the "Responsive background image" formatter.

By default it seems as though Smart Date fields are configured to display "All values in the same row" which prevents the calendar view working with recurring dates as one might expect. A mention of this has been added to the documentation.

I've tested with a Drupal 10 install. The new "dynamic" option works great! I believe it's definitely a feature that is worthwhile to incorporate in the module as it is a common scenario. I plan on using it moving foward as it will save from having to select a specific book and help automate that process.

I've tested out the "book_menu_default" option in the patch and I'm getting the following error when saving the option as well as on a book page:
Warning: Undefined array key "#book_title" in template_preprocess_book_all_books_block() (line 374 of core/modules/book/book.module).

joelseguin → created an issue.

Thanks for your thoughts on the suggestions - it all makes sense to me. Agree with #2 and not requiring the ability to save. A note in the documentation in regards to Webform submissions would certainly be sufficient.

The updated MR works nicely now and I can set and get webform submission field values without issues (no errors in logs).

I'm attaching a screenshot with some thoughts to perhaps improve UX a bit in the future.

Explanation of the screenshot:

1. At first I was thinking that since I'm listening for a webform event on "Update Content Entity" that I could access webform submission data via "Entity: Set Field Value", but that's not quite the case (since we need eca_webform for this). Wondering if there shouldn't be a notice to users about this (especially if the Webform module is enabled) since it's not immediately obvious?

2. Also, when using the "Webform Submission: Set Data" action, I'm wondering if it's possible to allow the same options as found under the "Entity: Set Field Value" for consistency? This could be useful for those expecting the same functionality to be available.

I've attempted to apply the patch to both the 1.2-dev and 1.14 branches with no success.

No issues applying the plain diff (.diff) file though. Once applied webform access tokens work instantly again. Thanks!

After further testing, it seems as though there is an issue affecting Webform access tokens when ECA is enabled. See the issue I have submitted regarding this here: https://www.drupal.org/project/eca/issues/3378283 🐛 Webform access tokens do not get replaced when ECA is enabled Fixed

That said, while testing I did notice that it is important to create a webform node and assign it a webform access group for the webform access tokens to work. This may potentially solve the the issue originally noted.

joelseguin → created an issue.

I can confirm this issue on version 6.1.5.

I've experienced it on 3 separate D9 sites so far. The issue seems to be with the following configuration:
Confirmation > Confirmation type > Message (reloads the current page/form and displays the confirmation message at the top of the page)

The form is submitted, but when the page reloads there is simply no confirmation message displayed. There are no errors noted in the log nor in the browser's console.

My workaround is to use any of the other options under Confirmation > Confirmation type - all of which seem to be working as expected.

** I have not yet had a chance to test on a fresh D9 install with no other modules installed. I'll see about doing that tomorrow.

I can confirm the same issue with Webform 6.2.0-beta6.

I use the webform access group tokens extensively and none of them are getting translated to email addresses in my email handlers. Happy to offer some testing on this issue as needed.

joelseguin → created an issue.

Thanks @kenorb - I can confirm that the patch works great. I was attempting to add a date token [current-date:html_year] and was wondering why it wasn't getting applied.

This module seems to handle tokens for both contextual filters and field filters.

Thanks @adrianliegmann - I've run into the same issue and applied the latest merge request (#25) and all seems to work perfectly fine now.

joelseguin → created an issue.

I can confirm that #4 works with Permissions By Term version 3.1.22 with Drupal 10.0.9.

Addition explaining that it is possible to simplify the update of modules that are only compatible with D10 using the composer.json file.

I can confirm the issue. Tested with a fresh copy of a known working database (without the issue). Updated from 1.7 to 1.8 and have the mismatch being reported in the status report.

I just tested with 2.x-dev and it looks like the same problem exists.

joelseguin → created an issue.

joelseguin → created an issue.

Did some quick research and tested out the latest patch.

Patch #3 doesn't work since DOMPDF likely does not support the ::marker pseudo element. ::marker is not part of the CSS 2.1 spec (https://www.w3.org/TR/CSS2/) which DOMPDF mostly adheres to as per https://github.com/dompdf/dompdf.

Patch 2 removes the use ::marker altogether which is likely the only way to avoid the error.

I've applied the patch and it worked as expected for a "destination" parameter.

In my use case I'm looking for a custom parameter to be respected (for example: key=1234). This is to integrate with the Disable Login module → . I'm wondering if we should allow all params to be passed instead of just allowing "destination"? This would allow for other scenarios (such as mine) to work as expected.

I've applied both patches from #40 to Media Bulk Upload 3.0 (with Dropzone JS module 2.7, Dropzone library version 5.9 and latest D9).

I'm definitely seeing additional options in the module's config. However, when I attempt to bulk upload svg files I'm never prompted to enter alt text. I do see a title field appearing without issues.