I am getting beta4, and I am on Drupal 10.4.
What version of Drupal are you on, because the Drupal dependency for the CER module change between beta3 (^9.5 || ^10) to beta4 (^10.3 || ^11)
https://www.drupal.org/project/cer/releases/5.0.0-beta3 →
https://www.drupal.org/project/cer/releases/5.0.0-beta4 →
I thought "drupal/cer": "^5.0", allowed beta releases to be installed.
This module is still in alpha, and it is possible/likely that some. config did not get updated or exported as expected.
One workaround is to back up and restore the schemadotorg.mapping.*.yml files, with a reinstall.
I'm sure it is one of the many, many schema modules.
At the same time, you can start disabling modules and see if it cause the issue.
With no error message or log, I won't be able to debug this issue.
Amongst other things, it re-thinks some Drupal UIs, specifically form actions, that are moved to the top right corner.
I am seeing this impact other contrib modules including custom_field.module, but we should look into if there is way to fix the problem via Gin or a contrib modules
I am very confused by your example, you are nesting a flexbox inside a container, creating an unexpected layout. If you remove the container, the flexbox layout starts being more predictable. Also, uou are also mixing inline labels with the default vertical label.
I think you either have to write a little CSS to get the layout your desire or simplify your layout.
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.