Should we merge this and tag a new alpha release?
The patch from #3251823: #states does not affect empty or filled when using mouse driven input actions like input type number → does not address this issue.
The search event would need to be tracked
https://stackoverflow.com/questions/2977023/how-do-you-detect-the-cleari...
I recommend not using a search input with conditional logic or try to come up with a work-around.
I think #17 might be the best approach I've heard suggested to how the Drupal community could handle external dependencies.
I would urge us to come up with a naming convention for the external libraries.
The Full Calendar module is using https://www.drupal.org/project/fullcalendar_io →
My thought/suggestion is we suffix all the mirrored libraries with *_library because there are being installed in the /libraries directory.
Done!
I think this is a related issue. #3251823: #states does not affect empty or filled when using mouse driven input actions like input type number →
Please try the patch and see if it fixes the problem.
The attached webform replicates the issue which is coming for Drupal core's search API.
Should we also deprecate the webform_shortcuts module?
The https://github.com/jeresig/jquery.hotkeys has not been updated in 10 years
To help move us along, I updated the UPDATE_LIBRARIES.md and exported libraries
@see https://git.drupalcode.org/project/webform/-/blob/6.3.x/docs/UPDATE-LIBR...
@see https://git.drupalcode.org/sandbox/jrockowitz-2941983/-/tree/6.3.x
Below are all the libraries
- algolia.places
- choices
- codemirror
- jquery.chosen
- jquery.geocomplete
- jquery.hotkeys
- jquery.icheck
- jquery.image-picker
- jquery.inputmask
- jquery.intl-tel-input
- jquery.rateit
- jquery.select2
- jquery.textcounter
- jquery.timepicker
- jquery.toggles
- popperjs
- progress-tracker
- signature_pad
- svg-pan-zoom
- tabby
- tippyjs
How would we use composer.json to ensure that the project with *_Js is placed in the correct directory?
It is also worth noting that the progress-tracke only contains CSS, so I suggested using an *_library project extension. Using *_js is also okay.
Lastly, we also need to account for 📌 Deprecate the use of drgullin/icheck Active
This is a regression triggered via Drupal core.
Notice that although the title option is set to "Invisible", same does not apply to the "Date part" options selected
@see 🐛 Date list labels are not visible above select field creating bad UX Fixed
That could work, it should be a recipe rather than yet another module, though.
I am not used to thinking in terms of recipes but that it is perfect.
We could also create a webform_libraries project with a composer.js file that requires all the external libraries. The Webform Libraries project could be used via Project Browser.
If the Drupal community agrees that external libraries should be mirrored as projects (w/ *_js suffix ) on Drupal.org, I will be 100% committed to adopting this solution for the Webform module.
The attached patch to Drupal core gets Mercury Editor loading with workspaces.
Below shows how navigation and workspaces look within mercury editor.
jrockowitz → created an issue.
Drupal CMS, we should create and require the *_js external library projects.
We can also rework the webform module to recommend these external library projects.
At a later point, we can decide to require these external library projects via the webform module's composer.json.
Does this seem like a reasonable way forward?
jrockowitz → created an issue.
I am starting to think that supporting implicit *.schemadotorg.inc files is a bad idea. Especially if the includes are not loaded via database update.
Maybe a module will need explicitly include their *.schemadotorg.inc files.
I ran into this exact issue when dealing with an optional dependency. The suggested solution makes sense to me.
jrockowitz → created an issue.
You are one step of ahead of me.
This looks good to me. Did it pass config inspection?
BTW the groups in mercury_editor.menu.settings.yml could be changes from a string of YAML to sequence/mapping so that it is translatable.
jrockowitz → created an issue.
*_js is perfect because it is the shortest and easiest-to-understand suffix.
Adding the dependencies to Drupal CMS' composer.json does work, too. I just wonder why other users of webform shouldn't benefit from this improvement as well. The fact that a dozen JS libraries get downloaded and stored in the libraries folder, doesn't sound too bad. At least compared to the gain factor in convenience.
The added benefit is that the site gets notified of a new version or security issue. The one downside is files in /libraries are publically available, and there have been test *.html pages in J /libraries with XSS issues.
For example, you need could change
mobile_presets:
type: sequence
label: 'Mobile preview present dimmensions'
sequence:
type: object
label: 'Preview preset'
- to -
mobile_presets:
type: sequence
label: 'Mobile preview present dimensions'
sequence:
type: mapping
label: 'Mobile preview present dimension'
mapping:
name:
type: text
label: Name
width:
type: integer
label: Width
height:
type: integer
label: Height
I tested my suggestion in #5 and using the a path repository won't work as expected.
I don't think we need to require the new webform external library projects in webform/composer.json but Drupal CMS could require them.
The webform external library projects would be another (recommended) way to install external libraries.
We are going to run into namespacing issues unless we add a prefix or suffix. For example, there is already a https://www.drupal.org/project/select2 → and https://www.drupal.org/project/codemirror → project.
We could suffix the namespace, below are some example.
https://www.drupal.org/project/select2_library →
https://www.drupal.org/project/select2_lib →
https://www.drupal.org/project/select2_ext →
jrockowitz → created an issue.
This problem and solution for external libraries makes sense to me.
What will be the namespace for these JavaScript projects?
Key in mind there is https://git.drupalcode.org/project/webform/-/blob/6.3.x/composer.librari...
Could we move this file to something webform_libraries/composer.json and include it via a path?
The below example is entirely untested.
{
"repositories": [
{
"type": "path",
"url": "webform_libraries/composer.json"
}
],
"require": {
"webform_libraries": "*"
}
}
I think we should try again. I am pretty sure the patch caused some expected issues.
I am leaning toward the delete the directory, commit, recreate directory, and commit approach to be safe.
Changing the submission display is something you would have to do using a custom template or custom module.
The submission display is meant to show data without the form's layout or design.
I was skeptical about being able to fix this but then I realized that the aria-label for the tooltip was only including the help title and not the help text.
The attached MR should fix the problem but we'll need to tweak a few broken tests.
jrockowitz → made their first commit to this issue’s fork.
I think can we assume no one is creating new sites with Bootstrap 3.x, and we should remove the Bootstrap check in hook_requirements. This will allow us to move the webform_bootstrap.module to https://www.drupal.org/project/webform_deprecated → .
I am realizing that Bootstrap 3.x is still supported. We can keep the code deprecated in the core webform module but tweak the webform_bootstrap.module to only work with Bootstrap 3.x.
The select other element is wrapped in a fieldset. You need to adjust the margin/padding in your custom theme.
jrockowitz → created an issue.
Looks good. Thanks for the review.
I am finding the scope of this MR daunting. I am unsure how we can test these changes and ensure nothing is broken.
With the D11 upgrade, we broke the MRs into smaller tickets.
The fix is a simple CSS tweak, so I am going to commit it AS-IS.
jrockowitz → created an issue.
We should close this ticket as long as you have a workaround and no one else is reporting this issue.
The two aliases are created to ensure that the webform language has an alias, and there is a fallback for other languages.
@see https://git.drupalcode.org/project/webform/-/blob/6.3.x/src/Entity/Webfo...
Attached is patch for testing based on the MR.
jrockowitz → changed the visibility of the branch 3493572-switch-to-dashboard to active.
jrockowitz → changed the visibility of the branch 3493572-switch-to-dashboard to hidden.
jrockowitz → created an issue.
If "Include files as attachments" is not checked, it means that something is not configured as expected.
@see https://git.drupalcode.org/project/webform/-/blob/6.3.x/src/Plugin/Webfo...
@see https://git.drupalcode.org/project/webform/-/blob/6.3.x/src/Plugin/Webfo...
Either the email handler or the webform attachments is not setup.
You could try to
- Confirm that smtp is enabled.
- Make sure an attachment field is added to the form
- Experiment with adding a file upload to see if attachments are enabled.
- Upgrade to 6.3.x
jrockowitz → created an issue.
jrockowitz → created an issue.
I am inclined to merge, close this ticket, and create a new ticket to track the status of Drupal 11 dependencies.
Attached and below are the Drupal 11 test failures related to dependencies that do not support Drupal 11.
There were 8 failures:
1) Drupal\Tests\schemadotorg_cer\Functional\SchemaDotOrgCorrespondingReferenceFormAlterTest::testFormAlter
Unable to install modules: module 'schemadotorg_cer'. Its dependency module 'cer' is incompatible with this version of Drupal core.
/builds/project/schemadotorg/web/core/lib/Drupal/Core/Test/FunctionalTestSetupTrait.php:505
/builds/project/schemadotorg/web/core/tests/Drupal/Tests/BrowserTestBase.php:554
/builds/project/schemadotorg/web/core/tests/Drupal/Tests/BrowserTestBase.php:363
/builds/project/schemadotorg/tests/src/Functional/SchemaDotOrgBrowserTestBase.php:44
2) Drupal\Tests\schemadotorg_cer\Functional\SchemaDotOrgCorrespondingReferenceSettingsFormTest::testSettingsForm
Unable to install modules: module 'schemadotorg_cer'. Its dependency module 'cer' is incompatible with this version of Drupal core.
/builds/project/schemadotorg/web/core/lib/Drupal/Core/Test/FunctionalTestSetupTrait.php:505
/builds/project/schemadotorg/web/core/tests/Drupal/Tests/BrowserTestBase.php:554
/builds/project/schemadotorg/web/core/tests/Drupal/Tests/BrowserTestBase.php:363
/builds/project/schemadotorg/tests/src/Functional/SchemaDotOrgBrowserTestBase.php:44
/builds/project/schemadotorg/modules/schemadotorg_cer/tests/src/Functional/SchemaDotOrgCorrespondingReferenceSettingsFormTest.php:27
3) Drupal\Tests\node\Functional\SchemaDotOrgContentModelDocumentationHelpTest::testHelpLink
Unable to install modules: module 'schemadotorg_content_model_documentation'. Its dependency module 'content_model_documentation' is incompatible with this version of Drupal core.
/builds/project/schemadotorg/web/core/lib/Drupal/Core/Test/FunctionalTestSetupTrait.php:505
/builds/project/schemadotorg/web/core/tests/Drupal/Tests/BrowserTestBase.php:554
/builds/project/schemadotorg/web/core/tests/Drupal/Tests/BrowserTestBase.php:363
/builds/project/schemadotorg/tests/src/Functional/SchemaDotOrgBrowserTestBase.php:44
4) Drupal\Tests\node\Functional\SchemaDotOrgContentModelDocumentationMarkupTest::testHelpLink
Unable to install modules: module 'schemadotorg_content_model_documentation'. Its dependency module 'content_model_documentation' is incompatible with this version of Drupal core.
/builds/project/schemadotorg/web/core/lib/Drupal/Core/Test/FunctionalTestSetupTrait.php:505
/builds/project/schemadotorg/web/core/tests/Drupal/Tests/BrowserTestBase.php:554
/builds/project/schemadotorg/web/core/tests/Drupal/Tests/BrowserTestBase.php:363
/builds/project/schemadotorg/tests/src/Functional/SchemaDotOrgBrowserTestBase.php:44
/builds/project/schemadotorg/modules/schemadotorg_content_model_documentation/tests/src/Functional/SchemaDotOrgContentModelDocumentationMarkupTest.php:42
5) Drupal\Tests\schemadotorg_content_model_documentation\Functional\SchemaDotOrgContentModelDocumentationSettingsFormTest::testSettingsForm
Unable to install modules: module 'schemadotorg_content_model_documentation'. Its dependency module 'content_model_documentation' is incompatible with this version of Drupal core.
/builds/project/schemadotorg/web/core/lib/Drupal/Core/Test/FunctionalTestSetupTrait.php:505
/builds/project/schemadotorg/web/core/tests/Drupal/Tests/BrowserTestBase.php:554
/builds/project/schemadotorg/web/core/tests/Drupal/Tests/BrowserTestBase.php:363
/builds/project/schemadotorg/tests/src/Functional/SchemaDotOrgBrowserTestBase.php:44
/builds/project/schemadotorg/modules/schemadotorg_content_model_documentation/tests/src/Functional/SchemaDotOrgContentModelDocumentationSettingsFormTest.php:35
6) Drupal\Tests\schemadotorg_diagram\Functional\SchemaDotOrgDiagramBlockTest::testOrganizationDiagram
Unable to install modules: module 'schemadotorg_cer'. Its dependency module 'cer' is incompatible with this version of Drupal core.
/builds/project/schemadotorg/web/core/lib/Drupal/Core/Test/FunctionalTestSetupTrait.php:505
/builds/project/schemadotorg/web/core/tests/Drupal/Tests/BrowserTestBase.php:554
/builds/project/schemadotorg/web/core/tests/Drupal/Tests/BrowserTestBase.php:363
/builds/project/schemadotorg/tests/src/Functional/SchemaDotOrgBrowserTestBase.php:44
7) Drupal\Tests\schemadotorg_entity_reference_override\Functional\SchemaDotOrgEntityReferenceOverrideSettingsFormTest::testSettingsForm
Unable to install modules: module 'schemadotorg_entity_reference_override'. Its dependency module 'entity_reference_override' is incompatible with this version of Drupal core.
/builds/project/schemadotorg/web/core/lib/Drupal/Core/Test/FunctionalTestSetupTrait.php:505
/builds/project/schemadotorg/web/core/tests/Drupal/Tests/BrowserTestBase.php:554
/builds/project/schemadotorg/web/core/tests/Drupal/Tests/BrowserTestBase.php:363
/builds/project/schemadotorg/tests/src/Functional/SchemaDotOrgBrowserTestBase.php:44
/builds/project/schemadotorg/modules/schemadotorg_entity_reference_override/tests/src/Functional/SchemaDotOrgEntityReferenceOverrideSettingsFormTest.php:36
8) Drupal\Tests\schemadotorg_entity_reference_override\Functional\SchemaDotOrgEntityReferenceOverrideTest::testEntityReferenceOverride
Unable to install modules: module 'schemadotorg_entity_reference_override'. Its dependency module 'entity_reference_override' is incompatible with this version of Drupal core.
/builds/project/schemadotorg/web/core/lib/Drupal/Core/Test/FunctionalTestSetupTrait.php:505
/builds/project/schemadotorg/web/core/tests/Drupal/Tests/BrowserTestBase.php:554
/builds/project/schemadotorg/web/core/tests/Drupal/Tests/BrowserTestBase.php:363
/builds/project/schemadotorg/tests/src/Functional/SchemaDotOrgBrowserTestBase.php:44@see 📌 Drupal 11 support Active
Is " Include files as attachments" disabled or enabled?
jrockowitz → created an issue.
The change via JSON-LD is most likely due to the addition of "Schema.org type entity references display" settings in /admin/config/schemadotorg/settings/jsonld.
@see 📌 Track and prevent displayed entity reference recursions in JSON-LD Active
jrockowitz → made their first commit to this issue’s fork.
We could also move this code to the webform_deprecated project.
jrockowitz → created an issue.
Adding GIF demo
Marking 'Major' since this is a significant problem when JS aggregation is enabled.
I am able to reproduce this issue which is coming from mercury_editor_library_info_alter() which adds 'mercury_editor/dialog.drupal' as a dependency to 'drupal.dialog'.
I tested the MR, and it fixes the reported issue.
Your best work-around may be to set the default date using JavaScript.
You can set additional attributes in the source
name:
'#type': name
'#title': Name
'#title__autocomplete': 'This is an autocomplete attribute'
It is not feasible to support every attribute via the UI.
You can also create your own custom elements in code the supported any attribute
A button element is not supported by the core Webform.
Support for buttons must be created via custom code or a dedicated contribs module.
For D11 support, we are going to have to use the Lenient Composer Plugin → .
We might also need to create a dedicated composer.libraries.11x.json file to module upgrade patches.
To address the code example from #3
The Drupal.webform.intlTelInput.options should not be defined in a Drupal behavior but globally
One of the reasons Drupal behaviors are public is you can completely override and replace Drupal.behaviors.webformTelephoneInternational, which feels like the right solution for your project.
Below is an untested POC.
(function ($, Drupal) {
const defaultAttach = Drupal.behaviors.webformTelephoneInternational.attach;
Drupal.behaviors.webformTelephoneInternational.attach = function myCustomAttachCode(context) {
Drupal.webform.intlTelInput.options.autoPlaceholder = "off";
defaultAttach(context)
}
})(jQuery, Drupal);
I think the challenge of customizing a webform element's JS options keeps coming up, and maybe we need to come up with a broader solution that allows a data-options attribute to be supported. ✨ Allow disabling of specific dates in jqueryui date picker. Active
Let's leave this open because I think #5 needs to happen for most webform element libraries.
Moving this to Critical because it will block the beta and stable release of Webform 6.3.x
I am better understand the importance of the ticket via ✨ Add Config Action to enable captcha form elements Active .
We are going to have to step back and think about what config actions are required for webforms.
For example, we probably need a way to add any element to a webform and we can expose \Drupal\webform\Entity\Webform::setElementProperties as a config action method.
Attached is POC (untested) patch that might be a simpler approach for a Drupal CMS MVP.
Because config actions are required via Drupal CMS, I am going to mark this a Critical.
Marking this RTBC and assuming all the tests will pass.
Let's try updating the latest release of choices, which is 11.0.2.
Below are my steps to test
- Check that composer libraries work as expected
- Check that
drush webform:libraries:downloadworks as expected - Check that CDN works as expected
drush webform:libraries:remove - Confirm Choices is loading via CDN
- Check that the Choices library is enabled ()
- Check that the Choices select menu works as expected (/form/test-element-select)