If you would like to write an update hook, please create a follow-up issue.
This appear to be outdated. If not, please re-open and provide details.
Webform 6.3.x requires Drupal 10.3, so we might as well update everything since none of the changes require a version newer than 10.3. Some of them have already been fixed in 6.3.x.
The next thing to do is to keep fixing the issues identified by the update_status test. The goal should be to get a clean report on upgrade_status (except for the errors about core_version_requirement).
liam morland → created an issue.
Right now, the UI is confusing. It does the exact opposite of the plain-language meaning of the UI text. Fixing that should be the priority.
This can be done without an update hook or any changes to the config schema. Just have the UI display what will actually happen using radio buttons for "Show on all pages" and "Hide on all pages" whenever the list of pages is empty.
It would make sense to have an update hook that would convert "Hide on all pages" to having the block be disabled. Getting that implemented is more complicated. It should not hold up getting the confusing UI fixed. A change like that should be in a follow-up ticket.
Thanks for the patch. Please make a merge request.
Thanks for the patch. Please make a merge request and indent with spaces. Can you add a test that would have caught this?
@dydave The merge request only adds a test. It does not appear to do anything that would fix the error with ::invalidateAll().
What you are talking about sounds like a reasonable use case. It would be good to support it.
If the issue fork is old, you will have to push the dev branches so that it has the latest. Then you can rebase the feature branch onto the latest 5.2.x and force-push it.
Actually, this is not a change for Drupal 11. The change happened in Drupal 10.2. It looks like the setting didn't work so they just removed it. The setting can probably just be removed from the Views. The change was in commit f890b7f.
Candidate for 6.0.x.
Hi, Kevin, please rebase on 5.2.x. I don't think there is currently a way to do this. Thanks for the merge request.
Other ones have NULL as the default. The cast is needed anyway because of the error I mentioned in #16.
There is another call in modules/custom/wxt_ext/wxt_ext_media/src/Element/Upload.php.
This merge request sets up coding standards testing.
This is raised as an issue by upgrade_status. I believe this applies to any entity query not just those created with \Drupal::entityQuery('node').
This change doesn't have to wait until Drupal 11. It can happen anytime that the minimum is Drupal 10.2
liam morland → created an issue.
This works for new entities. However, the "Also on update" checkbox does not work because hook_entity_field_values_init() only runs on entity creation. For updates a different hook is needed, perhaps hook_entity_prepare_form().
liam morland → created an issue.
liam morland → created an issue.
liam morland → created an issue.
Rebased
Please make a merge request.
Can you provide steps to reproduce this?
There is a failure in WebformElementMediaFileTest. The failure is that it fails to find a specific string in the HTML. It could be something simple like the elements being in rendered in a different order. If this test was switched to XPath, differences like that would not matter and the test would pass.
It would be helpful if there was a way to see the failed output.
If the version is not in webform.info.yml, that suggests that you have a Git repo instead of a release. When I install from Composer, I see the version. The repo was probably installed manually or there is something that needs to be changed in your Composer setup. I doubt there is a Webform issue here. Please re-open if you need more help.
The next step is to get tests passing again on Drupal 10. Then we can see what the Drupal 11 failures are and get tests passing there.
liam morland → created an issue.
liam morland → created an issue.
What did you do to trigger this? Are you upgrading? From what to what version?
This related issue implements alternative 1 in comment #17.
I made a merge request with the patch in #13 plus adding the ability to use ::setLinks() when the links are not empty. Before making tests, I perhaps a maintainer could approve the direction of this.
liam morland → made their first commit to this issue’s fork.
If the value is NULL, the automatic message will result in this error:
Argument #2 ($message) must be of type string, Drupal\Component\Render\FormattableMarkup
liam morland → made their first commit to this issue’s fork.
Note that this does not happen on Postgres; it works as expected.
If the bug exists in both places, both will need to be fixed and the fixes will not be the same.
The patch in #7 without the test config changes.
This might be fixed by ✨ Compatibility with embedded forms - inline entity form, profile Needs review .
Patch with current state of merge request.
liam morland → made their first commit to this issue’s fork.
Drupal 7 and Drupal 8+ are totally different code bases. Please open a new issue instead of moving issues between them.
Yes, I have "Use the administration theme when editing or creating content" enabled.
liam morland → created an issue.
Did you check where the other values get set? It seems odd that some get set and some do not. Perhaps there is other code that could be fixed or that could be removed due to this change.
Please rebase onto 6.3.x.
All the view displays are embeds. Is the default actually used anywhere? The permissions should probably be administer webform submission. Tests will need to be updated.
Are you sure you don't have something else that is changing the theme on your site? I just checked a simple site and the view and test where both in the front-end theme. Build, etc. are in the admin theme.
liam morland → created an issue.
liam morland → created an issue.
Please make the changes on the merge request. This allows tests to be run.
Sure, better documentation is welcome.
A good debugging step would be to try to reproduce the issue on Drupal 10 and PHP 8.3.
liam morland → made their first commit to this issue’s fork.
OK, what about the latest 6.2.x? They are not very different.
I agree with @mandclu. inline_entity_form 3.x should only support versions of Drupal that are supported when it reaches full release and perhaps only the latest version of Drupal. It should be set to ^10.2 || ^11 or perhaps ^10.3 || ^11. People using old Drupal or PHP can use old inline_entity_form too.
It looks like $next_button_custom is not getting set. That needs to be fixed. This also needs tests.
The idea is that webform_bootstrap5 will work with bootstrap5 module.
The change in this issue has caused 🐛 Webform asset javascript (webform/javascript/webform_id/custom.js) is showing not found Active .
Thanks for taking care of that. I don't think we'll be creating any new branches now. What can happen now is marking webform_bootstrap as deprecated.
If you take the latest 6.3.x and revert commit 2fc9b78, does that fix it?
It should probably use a batch to delete the submissions and then delete the form when the submissions are all gone.
You can use git bisect to figure out which commit was the change that caused this problem.
Sounds good. Thank you.
How would the transition work if there are two modules called webform_bootstrap, one within webform and the other separate?
I was thinking that webform_bootstrap5 would match bootstrap5 module. I don't use Bootstrap myself, so it doesn't matter to me.
A change like this will be needed for compatibility with embed 2.0.x.
I think webform_bootstrap5 should be a new contrib project, not part of the webform project.
Webform 6.3.x is to be compatible with Drupal 11 and PHP 8.3. It will not require PHP 8.3; it's minimum will be Drupal 10.3 and PHP 8.1.x. The current focus is getting tests to pass in 📌 Fix test failures Active .
I suggest making a release node for the 2.0.x branch. That would allow setting the version of this issue to 2.0.x. Tests are passing. 8.x-1.x could be maintained for only Drupal 10, so no need for any D11 compatibility patches.
The immediate problem is solved by using entity 8.x-1.9. entity_embed should be made so it is also compatible with entity 2.0.x.
@bsnodgrass it looks like this is patching entity instead of entity_embed. It is probably a better solution to stay with embed 8.x-1.7.
Perhaps there should be a new contrib module called webform_bootstrap5 to handle integration with bootstrap5 module. Then webform_bootstrap can be deprecated and will not be made compatible with Drupal 11.