πŸ‡ΊπŸ‡ΈUnited States @kmonty

San Francisco, CA
Account created on 15 August 2007, almost 17 years ago
#

Recent comments

πŸ‡ΊπŸ‡ΈUnited States kmonty San Francisco, CA

kmonty β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States kmonty San Francisco, CA

@Rajeshreeputra Thanks for changing the status of `2.0.3`

I just wanted to nudge that hopefully Focal Point makes this a pattern for releases in the future :)

Thanks for maintaining a great module!

πŸ‡ΊπŸ‡ΈUnited States kmonty San Francisco, CA

No patch here, so this can't be RTBC

πŸ‡ΊπŸ‡ΈUnited States kmonty San Francisco, CA

I just wanted to +1 this.

Other projects will leave releases like `2.0.3` as supported (but not recommended) so it doesn't flood Admin UIs with a scary red banner asserting a module is unsupported.

This can inject stress into teams, especially from non-technical stakeholders who are security-focused.

πŸ‡ΊπŸ‡ΈUnited States kmonty San Francisco, CA

Great call, @anybody! I just looked at the 2.x branch and jQuery isn't used / required as a library. I'll leave it up to the maintainers to close this as outdated, but it strikes me as something that could be.

πŸ‡ΊπŸ‡ΈUnited States kmonty San Francisco, CA

I think it makes sense to remove the dependency. Core can require it, but the module itself doesn't need to. Eventually the goal is to remove the jQuery dependency from core (as I understand it), so it seems reasonable to get ahead of that.

πŸ‡ΊπŸ‡ΈUnited States kmonty San Francisco, CA

I found a bug with the latest patch with Webform Submissions. It causes a PHP error Recursive rendering attempt aborted for webform_submission1html. In progress: Array ( [webform_submission1html] => webform_submission1html ).

Reproduction steps:

1. Be on Core 10.2.4 and the latest stable release of Webform. Apply the patch as of the 15.03.2024 commits.
2. Setup a basic Webform, submit a form (will be submission ID #1)
3. Go to /admin/structure/webform/submissions/manage and go to View the submission you just put in.
4. Instead of seeing a list of fields that you filled in, you just see the "Submission information"
5. If you have dblog enabled, you can see the PHP error in the latest log messages

πŸ‡ΊπŸ‡ΈUnited States kmonty San Francisco, CA

Our QA team tested the patch file (not the MR) which removes the library and found no issues.

+1 for removing the library entirely, as IE 11 has been at end of support for near two years now.

+1 RTBC

πŸ‡ΊπŸ‡ΈUnited States kmonty San Francisco, CA

I think this should be higher than `normal`, as it's a security threat.

πŸ‡ΊπŸ‡ΈUnited States kmonty San Francisco, CA

kmonty β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States kmonty San Francisco, CA

I'd say this is `Needs Work`, as this is an `ugly, temporary solution`.

At the very least, it should remove the dependency on jQuery.

πŸ‡ΊπŸ‡ΈUnited States kmonty San Francisco, CA

Several people reporting issues. Moving back to Needs Work.

πŸ‡ΊπŸ‡ΈUnited States kmonty San Francisco, CA

The new patch is just for my suggested changes against the 8.x branch and not updating the existing patch. It also does not include eslint changes.

πŸ‡ΊπŸ‡ΈUnited States kmonty San Francisco, CA

Minor change, but the `once` dependency should be included in the wrapper function.

So:

(function (Drupal, drupalSettings) {
[...]
})(Drupal, drupalSettings);

becomes:

((Drupal, drupalSettings, once) => {
[...]
})(Drupal, drupalSettings, once);

Also, this should be run through eslint, as it doesn't match Drupal's Prettier rules (single quotes instead of double quotes, no unnamed funcs, incomplete code comments // If no error messages exist, the etc.)

πŸ‡ΊπŸ‡ΈUnited States kmonty San Francisco, CA

I won't go as far as modifying the child issues, but calling out we found a breaking regression that was implemented in beta7. πŸ› Regression > Patch for "webform entity reference formatters not supporting translations" in 6.2.0-beta7 breaks Webform embeds within untranslated entities Active

πŸ‡ΊπŸ‡ΈUnited States kmonty San Francisco, CA

Here is a small patch we wrote to add a setting to enable the display of the signature file.

There are probably more elegant ways to write this, such as:

  1. Doing a file_exists check.
  2. Changing the logic to be disable_signature instead of enable_signature. As this patch is written now, a database update hook would be required before merging this into the branch. That said, it was a quick way for our team to solve this.

Hoping this helps folks for now. We might pick this back up to improve the patch if the maintainers seem interested in merging at some point + offer up guidance as to what their preferred implementation is. Cheers!

πŸ‡ΊπŸ‡ΈUnited States kmonty San Francisco, CA

Our team is satisfied that this is sufficient to get us to be able to deploy the security release. I didn't look into if this needs tests or anything. Again, just prioritized getting today's security release out. Hope this helps folks!

Note: patch was written against `3.0.x-dev` but it applies cleanly to `3.1.0`

πŸ‡ΊπŸ‡ΈUnited States kmonty San Francisco, CA

I have a patch working on localdev. Going to have our QA team give it a test before posting here. Assigning to myself for now.

πŸ‡ΊπŸ‡ΈUnited States kmonty San Francisco, CA

I'm currently working on a patch based off the work done here: https://www.drupal.org/project/language_switcher_menu/issues/3348242 πŸ› SA-CORE-2023-003 Fixed

Production build 0.69.0 2024