🇺🇸United States @jrockowitz

The short answer is people have to upgrade to resolve this issue

I reverted the commit.

@BramDriesen My jaw dropped when I logged back in. I was about to re-roll the MR when I saw that you had already done it. Thank you!!!

We probably need to rebase this because of 📌 Convert to OOP Hooks Active

Your persistence has paid off. I am at DrupalCon is time to merge this. Thank you!!!

jrockowitz → made their first commit to this issue’s fork.

While it is a big patch, this is the same process used for core to convert, and we can spot check that the conversions are accurate. Since this is rector it's really just copying the hooks to a hook class an method.

Webform also has more tests than most modules so we can have more confidence than most modules would have that this won't introduce systemic issues.

I completely agree with you that this should not introduce systemic issues and merging it would nudge more contrib modules to use OOP hooks.

I think 🐛 Checkboxes/Radios with description display set to "before" renders description in #prefix Active might have addressed this issue.

I have to agree that this is a release blocker

jrockowitz → made their first commit to this issue’s fork.

Since we are changing the $form array, this should be only committed to 6.3.x

Here is the change record. With tests passing, I am fine with merging this.

There are security implications for allowing someone to specify the submission owner via query parameter.

ChatGPT suggested the below approach which is a valid solution

/**
 * Implements hook_webform_submission_presave().
 *
 * Allow setting the webform submission owner from a query string parameter.
 */
function MYMODULE_webform_submission_presave(WebformSubmissionInterface $webform_submission) {
  // Check if a query parameter 'submission_owner' exists.
  $owner_uid = \Drupal::request()->query->get('submission_owner');
  
  if ($owner_uid && is_numeric($owner_uid)) {
    // Ensure the user ID exists in the system.
    $user = \Drupal\user\Entity\User::load($owner_uid);

    if ($user) {
      // Set the submission's owner to the user ID from the query string.
      $webform_submission->setOwnerId($owner_uid);
    }
  }
}

Patch seems very safe.

jrockowitz → made their first commit to this issue’s fork.

I think we need to fork the webform bootstrap 3 module into a dedicated project and deprecate the code in the webform module.

In a form alter hook, you can change the $form['progress'] weight or alter the $form array.

ChatGPT suggested the below approach, which is completely valid and the simplest solution

/**
 * Implements hook_form_alter().
 */
function mymodule_form_alter(array &$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id) {
  // Check if the form ID matches the webform submission form.
  if ($form_id == 'webform_submission_form') {
    // Save the progress element into a temporary variable.
    $progress_element = $form['progress'];
    // Remove the progress element.
    unset($form['progress']);
    // Add the progress element to the end of the form.
    $form['progress'] = $progress_element;
  }
}

Please review the MR based on #17 which tries to keep the changes as simple as possible.

jrockowitz → made their first commit to this issue’s fork.

I am for any patch that simplifies the JS code and is safe to commit.

Core at some point reversed https://www.drupal.org/node/1570578 → and use strict is no longer included in core JS.

jrockowitz → made their first commit to this issue’s fork.

Let's update the URL field to support 2048 characters @see https://serpstat.com/blog/how-long-should-be-the-page-url-length-for-seo/

Let's update the URL field to support 2048 characters @see https://serpstat.com/blog/how-long-should-be-the-page-url-length-for-seo/

Let's update the URL field to support 2048 characters @see https://serpstat.com/blog/how-long-should-be-the-page-url-length-for-seo/

jrockowitz → made their first commit to this issue’s fork.

I think the current OOTB approach is the use something like IMCE → to upload a file to the public file directory and attach the file via the Attachment URL element.

→

If we were going to support attachments via file upload I would opt for Attachment File element, which could be maintained in a dedicated contributed module. Does this approach make sense?

Make sense that a mailer application needs the body to be a string.

Adding a new property to Name would require a new 6.4.x version of Webform to be created.

This improvement should be handled in a dedicated contrib module. You can also use https://www.drupal.org/project/webform_composite → to create this variation of a name input.

I tested the fix in Chrome and Firefox and it looks good.

MRs are welcome to help resolve this

Fixing in 6.2.x and 6.3.x

We have been using this patch on production and it seem sreasonable that we want to ensure the webform_image_select.element library loads after webform.filter.js

The tweak looks fine to me, and enough people have reviewed this

jrockowitz → made their first commit to this issue’s fork.

I validated that a group_relationship entity exists via https://git.drupalcode.org/project/group/-/blob/3.3.x/src/Entity/GroupRe... and it was added in 2022 (@see #3303321: Drop 2.0.x upgrade path and update machine names → )

The code being updated was added via 📌 Support group v2/v3 Fixed
I would be happy to merge this is someone can confirm that we should have looking for the group_relationship entity and NOT the group_relation entity

I think gradually fixing eslint and other JS issue in smaller MRs might be the only approach because there is no JavaScript test coverage in the module.

I am going to go with this MR is good enough. The only breaking change is the removal of the completely unused \Drupal\webform\Plugin\WebformElement\TextFormat::hasCompositeElement added in 2017.

jrockowitz → made their first commit to this issue’s fork.

I think the webform_default is no longer visible via the UI, and we might be able to close this ticket since we can't reproduce the issue and the suggestion from #6 is a valid fix.

I think the webform_default is no longer visible via the UI, and we might be able to close this ticket since we can't reproduce the issue and the suggestion from #6 is a valid fix.

jrockowitz → created an issue.

jrockowitz → created an issue.

jrockowitz → created an issue.

jrockowitz → made their first commit to this issue’s fork.

I was experimenting with this patch and a bunch of update hooks failed with the below error

LogicException: withRelatableResourceTypes() must be called before getting relatable resource types. in Drupal\jsonapi\ResourceType\ResourceTypeRelationship->getRelatableResourceTypes() (line 48 of /var/www/html/docroot/core/modules/jsonapi/src/ResourceType/ResourceTypeRelationship.php) #0 /var/www/html/docroot/core/modules/jsonapi/src/ResourceType/ResourceType.php(406): Drupal\jsonapi\ResourceType\ResourceTypeRelationship->getRelatableResourceTypes()

Sorry, I can't provide more details.

jrockowitz → created an issue.

jrockowitz → created an issue.

jrockowitz → created an issue.

jrockowitz → made their first commit to this issue’s fork.

jrockowitz → created an issue.

Yeh that patch is to core because Mercury Editor is extending HtmlEntityFormController and Workspaces does not support returning a RedirectResponse.

Here is quick fix for people wanting to revert back to the having the datelist title invisible.

/**
 * Implements hook_webform_element_alter())
 */
function MYMODULE_webform_element_alter(array &$element, \Drupal\Core\Form\FormStateInterface $form_state, array $context) {
  if (isset($element['#type']) && $element['#type'] === 'datelist') {
    $element['#after_build'][] = 'MYMODULE_webform_element_datelist_after_build';
  }
}

function MYMODULE_webform_element_datelist_after_build(array $element, FormStateInterface $form_state) {
  foreach (Element::children($element) as $child_key) {
    if (!isset($element[$child_key]['#title_display'])) {
      $element[$child_key]['#title_display'] = 'invisible';
    }
  }
  return $element;
}

I think all new functionality should be handled in dedicated contributed module like a webform_block_advanced.module which could extend or replace the webform block plugin.

We are posting a patch because we are not able to update the latest release.

nicxvan → credited jrockowitz → .

Passing the \Drupal\Core\Field\FieldItemInterface or \Drupal\Core\Field\FieldItemListInterface to the below hooks feels like the right thing to do, and we MUST pass the BubbleableMetadata, which allows JSON-LD to be cached.

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);

A maximum of 2 alterable arguments is supported. In case more arguments need to be passed and alterable, modules provide additional variables assigned by reference in the last $context argument:

@see https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Extension...

I experimented with adding $context, which contains the items, mapping, schema_type, and schema_property, and that started to feel ugly because users have started parsing through the $context. Moving $items to $context also breaks anyone's current implementation of these hooks.

The best compromise I can come up with is to provide a \Drupal\schemadotorg\Utility\SchemaDotOrgFieldHelper, which makes it easier to get the mapping, scheme type, and schema property.

Please review the attached proposed MR.

jrockowitz → created an issue.

jrockowitz → created an issue.

The MR addressed the immediate issue for me. We might want to use a human-readable format for the array, maybe YAML wrapped in PRE tags.

jrockowitz → created an issue.

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);