Please provide an example webform which can be used to replicate this issue.
The MR looks good. I appreciate the specificity of the fix. Someone needs to do some manual review.
I don't want to implement this feature because it would require too much work to support it.
For example, the webform views module would most likely need to be updated and tokens will probably need to fixed.
Please reopen this ticket or create a new one if you can provide steps to replicate the issue.
Please reopen this ticket or create a new one if you can provide steps to replicate the issue.
Please reopen this ticket or create a new one if you can provide steps to replicate the issue.
Please reopen this ticket or create a new one if you can provide steps to replicate the issue.
Please reopen this ticket or create a new one if you can provide steps to replicate the issue.
I am closing this issue but I did see something similar with. Custom code that added a callback using $this inside a service or OOP hook.
The below code will cause the $this (i.e, a service) to serialized.
$form['actions']['save']['#submit'][] = [$this, 'formSubmit'];
The code had to be changed to
$form['actions']['save']['#submit'][] = [static::class, 'formSubmit'];
I first have to ask, do we try to fix this. The themes (in core) include a fix.
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/themes/claro/...
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/themes/oliver...
We need to be very careful with our solution because the fieldgroup css is most likely going to be removed.
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...
Tests are passing, and I'm confident that element access controls have sufficient test coverage.
Hmm I am almost would rather add the missing CSS to something like webform.form.css.
The webform add-ons service was removed. I think running update.php will resolve this issue.
The "Schema.org Blueprints JSON-LD Preview" provides the tab
I think this feature can be part of the schemadotorg_jsonld_preview.module.
We should add the 'Schema.org' tab to all supported content entity types.
- media
- taxonomy
- user
- block
- etc...
The routes and tasks would have become dynamically generated.
We do something similar to the devel.module.
- \Drupal\devel\Routing\RouteSubscriber
- \Drupal\devel\Plugin\Derivative\DevelLocalTask
You can modify or create your own CSV file and define it via Schema.org data file/URL. (/admin/config/schemadotorg/settings/general)
@see ✨ Bioschemas or other schemas support Needs review
It make sense to make sure the $element['#webform'] is not empty via
I updated the MR to use the below code.
// Make sure that the '#webform' property is defined before proceeding.
if (empty($element['#webform'])) {
return $element;
}
If all tests pass, this should be RTBC.
jrockowitz → made their first commit to this issue’s fork.
Wow, forgot about this ticket and the patch, and just ran into the same issue via 🐛 PHP 8.1 TypeError: Drupal\webform\WebformRequest::getUrl() Closed: cannot reproduce and my conclusion is the the main entity (node) should always be stored as the source entity. Yet the problem is that tokens are current accessing the paragraph and node.
Yes, this is a challenging issue to resolve because when a webform is placed within a paragraph, the webform submission's source entity is the paragraph, but the webform node's source entity is the node.
The current MR might be best compromise
I was able to determine that source entity for the webform and submission are out-of-sync. I can't find the root cause.
The current MR is might resolve the issue but the root cause needs to be tracked down.
Here are the steps to reproduce this issues.
- Create a node with paragraph containing a webform
- Submit the webform
- Edit the node and delete the paragraph, click Save.
- Edit the node and re-add the same paragraph pointing to the same webform click save.
- Confirm you get the
TypeError: Drupal\webform\WebformRequest::getUrl(): Argument #1 ($webform_entity)error
Yeh, I was also looking into this and couldn't reproduce the bug.
Yep, the update hook is missing. I commited the fix the 1.0.x-dev.
I got caught in my own update process. The key is to run the database updates via drush updb, which clears the service container, allowing hooks to call services.
The email confirm element's title is displayed via the email input and not the wrapper.
@see https://git.drupalcode.org/project/webform/-/blob/6.3.x/src/Element/Webf...
I should note, this works the opposite of how the "Address" component works. For the Address component,
This is because the address element's title is not used in the sub-elements.
The workaround if you need a fieldset visible around the email confirm element is to place the element inside a fieldset and use a simple container.
email_container:
'#type': fieldset
'#title': 'Enter your email'
email:
'#type': webform_email_confirm
'#title': Email
Please reopen if you can provide an example webform similar to #11 that can reproduce this issue.
Please reopen when you can provide the setup and steps required to reproduce this issue.
Please reopen when you can provide the setup and steps required to reproduce this issue.
Please reopen when you can provide the setup and steps required to reproduce this issue.
This needs an MR and should target 6.3.x
I have merged the simple solution. Please reopen this ticket if there are any other problems.
I tried to write a test to recreate this issue and I am seeing no way to duplicate the problem. When a webform or webform submission is deleted their associated log messages are deleted.
@see \Drupal\webform_submission_log\Hook\WebformSubmissionLogHooks
We need to be able to replicate this issue to properly fix it with a test.
jrockowitz → made their first commit to this issue’s fork.
Currently, you have to write custom code to map your custom additional properties.
The schemadotorg_custom_field module currently only supports name/value pairs for additionalProperties. We could potentially enhance this code.