🇺🇸United States @jrockowitz

I completely understand that we must skip fixing the dependency injections.

If you are saying in a later commit, we can automatically fix the t() calls since all that is required is the trait and then a search and replace, this is good enough to be committed.

A https://schema.org/TextObject defines a text document (not a string of text), and https://schema.org/Text is a data type.

I don't think mapping a Paragraph to either TextObject or Text makes sense. It might make sense to map a paragraph to a https://schema.org/Thing, or personally I like https://schema.org/WebContent.

Your request makes sense. Let me think about the implications before we make the change.

Below are hooks that could have $schema_type and $schema_property defined. Another approach is to add a $context that would allows $schema_mapping, $schema_type, and $schema_property.

hook_schemadotorg_jsonld_schema_type_field_alter(array &$data, \Drupal\Core\Field\FieldItemListInterface $items, \Drupal\Core\Render\BubbleableMetadata $bubbleable_metadata);

hook_schemadotorg_jsonld_schema_property_alter(mixed &$value, \Drupal\Core\Field\FieldItemInterface $item, \Drupal\Core\Render\BubbleableMetadata $bubbleable_metadata);

hook_schemadotorg_jsonld_schema_properties_alter(array &$values, \Drupal\Core\Field\FieldItemListInterface $items, \Drupal\Core\Render\BubbleableMetadata $bubbleable_metadata);

This looks very promising. If you are able to get an MR that has all the tests passing and phpcs is okay(ish). We should make the commit.

Things like dependency injection can be fixed later (or never).

jrockowitz → created an issue.

Let's see what the issues are before we manually fix them. I am assuming you are using Drupal Rector.

I think we need an MR to 6.3.x that sees what tests are failing. Depending on the number of tests failing we could commit this to 6.3.x or wait until 6.4.x.

Can we close this issue now that we have determined custom code was causing the caching issue?

@see #3278729: TypeError: Unsupported operand types: string * float for twig →
@see https://www.drupal.org/docs/contributed-modules/twig-tools/conversion-fi... →

jrockowitz → created an issue.

I accidentally committed this MR to 1.x. Fortunately, the tests were passing, so I am going to close this ticket.

There should be a test that checks that altered JSON-LD that does not have cache context is not updated via cache clear. This would confirm that the solution here works as expected.

Either you have to experiment to find the right syntax for the token. The token examples included entity references.

→

If you are using Bootstrap5, you will need to use https://www.drupal.org/project/webform_bootstrap5 → .

The most recent beta release of Webform 6.3.x now checks that you are using the Bootstrap 8.x-3.x version

I pinged @phenaproxima, but it is worth noting here that Webform 6.3.x now has a beta release → . I have to thank
@acbramley and @liam morland

Done! @liam morland do you have time to tag a beta release?

I am good with the being merged. @liam morland Does this work for you?

At a quick glance, none of the RTBC issues should be merged.

Thank you for fixing the broken tests. I am tempted to merge this and tag a beta release for Drupal CMS's sake. Webform is the only alpha release module being included in Drupal CMS.

@liam morland Are you okay with us merging and tagging a beta?

Can you hard clearing of your cache?

By restarting redis/memcache or manually clearing the cache tables in the database.

@see 📌 Ensure the variation cache is cleared for JSON-LD. Active

jrockowitz → created an issue.

I merged the MR. If you see any more regressions, please update this ticket or open a new ticket.

I am not sure we should be including the .gitlab-ci.yml if there are no tests which need to be triggered.

You definitely need to clear the entire cache.

I was able to reproduce the issue/regression, and it is a one-line fix.

I noticed that the Schema.org Blueprint Additional Mapping module validated the https://schema.org/recipeIngredient property, and https://schema.org/TextObject is an expected value. The Schema.org Blueprint Additional Mapping module removes unexpected types.

In other words, the generated Schema.org JSON-LD (see below) using https://schema.org/TextObject is not valid via https://validator.schema.org/ (see below)

{
    "@context": "https://schema.org",
    "@type": "Recipe",
    "@url": "https://schemadotorg.ddev.site/recipes/some-recipe",
    "inLanguage": "en",
    "name": "Some recipe",
    "copyrightHolder": "Schema.org Blueprints Demo",
    "copyrightYear": 2024,
    "dateCreated": "2024-12-27 12:18:51 -05:00",
    "dateModified": "2024-12-27 12:19:13 -05:00",
    "isFamilyFriendly": true,
    "recipeIngredient": [
        {
            "@type": "TextObject",
            "inLanguage": "en",
            "name": [
                "Value 1",
                "Value 2",
                "Value 3"
            ],
            "position": 1
        },
        {
            "@type": "TextObject",
            "inLanguage": "en",
            "name": [
                "Value 4",
                "Value 4",
                "Value 6"
            ],
            "position": 2
        }
    ]
}

→

I created a POC MR to allows the date part title display to be customized.

jrockowitz → changed the visibility of the branch 3495192-date-list-part-title-display to hidden.

The select labels could be removed with a custom hook. Someone would have to write and share the code snippet.

I am almost sure that the recommendation via #12 is correct, and you will need to adjust the "Schema.org type entity references display" settings (/admin/config/schemadotorg/settings/jsonld)

It takes a lot of time for someone to reproduce your specific example.

You might need a developer to debug your issue or write a hook to alter the JSON-LD to meet your requirements.

The module is still in alpha releases which means APIs and output can change,.

I don't have the time to start rewriting tests. Any help is appreciated.

A submission can be locked and unlocked via the notes tab.

/admin/structure/webform/manage/{webform}/submission/{sid}/notes

I am okay with someone creating and maintaining a dedicated webform_bootstrap project.

jrockowitz → created an issue.

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!

Deprecate Webform Shortcuts

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.

Adding notes about Bootstrap

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.

@see 📌 Allow custom data-options to added to elements JavaScript options Active

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