Drupal 11 compatibility fixes for webform

There should be an issue focussed on updating webform_bootstrap.

Maybe webform_bootstrap can be split off to its own contrib module. It would be nice to have a lean webform core so anything with optional external dependencies can manage them independently.

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.

I think webform_bootstrap5 should be a new contrib project, not part of the webform project.

If webform_bootstrap5 ends up being a separate contrib module, it might be best to take the "5" off the end of the name/machine name so that it's not only associated with bootstrap 5.

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.

Sounds good. Thank you.

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.

Unrelated to this issue, but will the webform_bootstrap5 contrib module only be compatible with Bootstrap 5 themes? If not, it seems like webform_bootstrap would make more sense.

The idea is that webform_bootstrap5 will work with bootstrap5 module.

Hi we have the MR applied locally and on Pantheon. Locally it works fine, but on Pantheon, we get this error when clearing the caches or whatnot (and can't run drush updb for the same reason):

 [error]  ArgumentCountError: Too few arguments to function Drupal\Core\Cache\MemoryBackend::__construct(), 0 passed and exactly 1 expected in Drupal\Core\Cache\MemoryBackend->__construct() (line 36 of /code/web/core/lib/Drupal/Core/Cache/MemoryBackend.php) #0 [internal function]: Drupal\Core\Cache\MemoryBackend->__construct()
#1 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(1119): ReflectionClass->newInstanceArgs(Array)
#2 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(577): Symfony\Component\DependencyInjection\ContainerBuilder->createService(Object(Symfony\Component\DependencyInjection\Definition), Array, false, 'cache.pantheon')
#3 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(1237): Symfony\Component\DependencyInjection\ContainerBuilder->doGet('cache.pantheon', 1, Array, false)
#4 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(1189): Symfony\Component\DependencyInjection\ContainerBuilder->doResolveServices(Object(Symfony\Component\DependencyInjection\Reference), Array, false)
#5 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(1649): Symfony\Component\DependencyInjection\ContainerBuilder->doResolveServices(Array, Array)
#6 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(1145): Symfony\Component\DependencyInjection\ContainerBuilder->callMethod(Object(Drupal\Core\Cache\CacheTagsInvalidator), Array, Array)
#7 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(577): Symfony\Component\DependencyInjection\ContainerBuilder->createService(Object(Symfony\Component\DependencyInjection\Definition), Array, true, 'cache_tags.inva...')
#8 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(1237): Symfony\Component\DependencyInjection\ContainerBuilder->doGet('cache_tags.inva...', 1, Array, true)
#9 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(1189): Symfony\Component\DependencyInjection\ContainerBuilder->doResolveServices(Object(Symfony\Component\DependencyInjection\Reference), Array, true)
#10 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(1089): Symfony\Component\DependencyInjection\ContainerBuilder->doResolveServices(Array, Array, true)
#11 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(577): Symfony\Component\DependencyInjection\ContainerBuilder->createService(Object(Symfony\Component\DependencyInjection\Definition), Array, true, 'router.route_pr...')
#12 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(1237): Symfony\Component\DependencyInjection\ContainerBuilder->doGet('router.route_pr...', 1, Array, true)
#13 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(1189): Symfony\Component\DependencyInjection\ContainerBuilder->doResolveServices(Object(Symfony\Component\DependencyInjection\Reference), Array, true)
#14 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(1089): Symfony\Component\DependencyInjection\ContainerBuilder->doResolveServices(Array, Array, true)
#15 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(1239): Symfony\Component\DependencyInjection\ContainerBuilder->createService(Object(Symfony\Component\DependencyInjection\Definition), Array, true)
#16 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(1189): Symfony\Component\DependencyInjection\ContainerBuilder->doResolveServices(Object(Symfony\Component\DependencyInjection\Definition), Array, true)
#17 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(1089): Symfony\Component\DependencyInjection\ContainerBuilder->doResolveServices(Array, Array, true)
#18 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(577): Symfony\Component\DependencyInjection\ContainerBuilder->createService(Object(Symfony\Component\DependencyInjection\Definition), Array, true, 'url_generator')
#19 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(522): Symfony\Component\DependencyInjection\ContainerBuilder->doGet('url_generator', 1)
#20 /code/web/core/lib/Drupal.php(577): Symfony\Component\DependencyInjection\ContainerBuilder->get('url_generator')
#21 /code/web/core/lib/Drupal/Core/Url.php(832): Drupal::urlGenerator()
#22 /code/web/core/lib/Drupal/Core/Url.php(765): Drupal\Core\Url->urlGenerator()
#23 /code/web/modules/custom/temp/webform/src/WebformHelpManager.php(1612): Drupal\Core\Url->toString()
#24 /code/web/modules/custom/temp/webform/src/WebformHelpManager.php(146): Drupal\webform\WebformHelpManager->initHelp()
#25 [internal function]: Drupal\webform\WebformHelpManager->__construct(Object(Drupal\Core\Session\AccountProxy), Object(Drupal\Core\Config\ConfigFactory), Object(Drupal\Core\Extension\ModuleHandler), Object(Drupal\Core\State\State), Object(Drupal\Core\Path\PathMatcher), Object(Drupal\webform\WebformAddonsManager), Object(Drupal\webform\WebformLibrariesManager), Object(Drupal\webform\Plugin\WebformElementManager))
#26 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(1119): ReflectionClass->newInstanceArgs(Array)
#27 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(577): Symfony\Component\DependencyInjection\ContainerBuilder->createService(Object(Symfony\Component\DependencyInjection\Definition), Array, true, 'webform.help_ma...')
#28 /code/vendor/symfony/dependency-injection/ContainerBuilder.php(522): Symfony\Component\DependencyInjection\ContainerBuilder->doGet('webform.help_ma...', 1)
#29 /code/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(289): Symfony\Component\DependencyInjection\ContainerBuilder->get('webform.help_ma...')
#30 /code/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(253): Drush\Runtime\LegacyServiceInstantiator->resolveFromContainer(Object(Drupal\Core\DependencyInjection\ContainerBuilder), 'webform.help_ma...')
#31 [internal function]: Drush\Runtime\LegacyServiceInstantiator->resolveArgument('@webform.help_m...')
#32 /code/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(223): array_map(Array, Array)
#33 /code/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(193): Drush\Runtime\LegacyServiceInstantiator->resolveArguments(Array)
#34 /code/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(167): Drush\Runtime\LegacyServiceInstantiator->instantiateObject('\\Drupal\\webform...', Array)
#35 /code/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(117): Drush\Runtime\LegacyServiceInstantiator->create('\\Drupal\\webform...', Array, Array)
#36 /code/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(54): Drush\Runtime\LegacyServiceInstantiator->instantiateServices(Array)
#37 /code/vendor/drush/drush/src/Boot/DrupalBoot8.php(242): Drush\Runtime\LegacyServiceInstantiator->loadServiceFiles(Array)
#38 /code/vendor/drush/drush/src/Boot/DrupalBoot8.php(218): Drush\Boot\DrupalBoot8->addDrupalModuleDrushCommands(Object(Drush\Boot\BootstrapManager))
#39 /code/vendor/drush/drush/src/Boot/BootstrapManager.php(211): Drush\Boot\DrupalBoot8->bootstrapDrupalFull(Object(Drush\Boot\BootstrapManager), Object(Consolidation\AnnotatedCommand\AnnotationData))
#40 /code/vendor/drush/drush/src/Boot/BootstrapManager.php(352): Drush\Boot\BootstrapManager->doBootstrap(5, 5, Object(Consolidation\AnnotatedCommand\AnnotationData))
#41 /code/vendor/drush/drush/src/Boot/BootstrapManager.php(304): Drush\Boot\BootstrapManager->bootstrapToPhaseIndex(5, Object(Consolidation\AnnotatedCommand\AnnotationData))
#42 /code/vendor/drush/drush/src/Boot/BootstrapHook.php(36): Drush\Boot\BootstrapManager->bootstrapToPhase('full', Object(Consolidation\AnnotatedCommand\AnnotationData))
#43 /code/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php(44): Drush\Boot\BootstrapHook->initialize(Object(Symfony\Component\Console\Input\ArgvInput), Object(Consolidation\AnnotatedCommand\AnnotationData))
#44 /code/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php(36): Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->doInitializeHook(Object(Drush\Boot\BootstrapHook), Object(Symfony\Component\Console\Input\ArgvInput), Object(Consolidation\AnnotatedCommand\AnnotationData))
#45 /code/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php(29): Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->callInitializeHook(Object(Drush\Boot\BootstrapHook), Object(Symfony\Component\Console\Input\ArgvInput), Object(Consolidation\AnnotatedCommand\AnnotationData))
#46 /code/vendor/consolidation/annotated-command/src/CommandProcessor.php(145): Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->initialize(Object(Symfony\Component\Console\Input\ArgvInput), Object(Consolidation\AnnotatedCommand\AnnotationData))
#47 /code/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(376): Consolidation\AnnotatedCommand\CommandProcessor->initializeHook(Object(Symfony\Component\Console\Input\ArgvInput), Array, Object(Consolidation\AnnotatedCommand\AnnotationData))
#48 /code/vendor/symfony/console/Command/Command.php(245): Consolidation\AnnotatedCommand\AnnotatedCommand->initialize(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#49 /code/vendor/symfony/console/Application.php(1047): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#50 /code/vendor/symfony/console/Application.php(316): Symfony\Component\Console\Application->doRunCommand(Object(Consolidation\AnnotatedCommand\AnnotatedCommand), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#51 /code/vendor/symfony/console/Application.php(167): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#52 /code/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#53 /code/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
#54 /code/vendor/drush/drush/drush.php(139): Drush\Runtime\Runtime->run(Array)
#55 /code/vendor/drush/drush/drush(4): require('/code/vendor/dr...')
#56 /code/vendor/bin/drush(119): include('/code/vendor/dr...')
#57 {main}. 
ArgumentCountError: Too few arguments to function Drupal\Core\Cache\MemoryBackend::__construct(), 0 passed and exactly 1 expected in Drupal\Core\Cache\MemoryBackend->__construct() (line 36 of /code/web/core/lib/Drupal/Core/Cache/MemoryBackend.php).

Our plan doesn't include a cache server, so Pantheon seems to think the issue is stemming from Webform, which the error output supports. Not sure if this is related to the patch, Webform in general, PHP 8.3, or what exactly.

A good debugging step would be to try to reproduce the issue on Drupal 10 and PHP 8.3.

I give merge with https://www.drupal.org/node/3435903 with:

curl -skL https://git.drupalcode.org/project/webform/-/merge_requests/429.patch | git am --keep-cr

And apply this MR for D11 now with:

...
    "repositories": {
        "drupal": {
            "canonical": false,
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        },
        "drupal/webform": {
            "canonical": false,
            "type": "vcs",
            "url": "https://git.drupalcode.org/issue/webform-3465838.git"
        },
    },
...
    "require": {
        "drupal/webform": "dev-3465838-drupal-11-compatibility",
    }
...

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.

Let me rebase now that tests are passing on the referenced issue

Ah Liam beat me to it.

Looks like one failure:

1) Drupal\Tests\webform\Functional\Element\WebformElementAddressTest::testAddress
Behat\Mink\Exception\ExpectationException: The string "address:
  country_code: US
  langcode: en
  given_name: John
  family_name: Smith
  organization: 'Google Inc.'
  address_line1: '1098 Alta Ave'
  address_line2: ''
  locality: 'Mountain View'
  administrative_area: CA
  postal_code: '94043'
  additional_name: null
  sorting_code: null
  dependent_locality: null
address_advanced:
  country_code: US
  langcode: en
  address_line1: '1098 Alta Ave'
  address_line2: ''
  locality: 'Mountain View'
  administrative_area: CA
  postal_code: '94043'
  given_name: null
  additional_name: null
  family_name: null
  organization: null
  sorting_code: null
  dependent_locality: null
address_none: null
address_multiple:
  - country_code: US
    langcode: en
    given_name: John
    family_name: Smith
    organization: 'Google Inc.'
    address_line1: '1098 Alta Ave'
    address_line2: ''
    locality: 'Mountain View'
    administrative_area: CA
    postal_code: '94043'" was not found anywhere in the HTML response of the current page.

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

There are also a bunch of deprecations that won't get removed until 12.0.0 I imagine those can be left alone too.

For example:

Ignore         234  Call to deprecated method renderPlain() of class            
                    Drupal\Core\Render\Renderer. Deprecated in drupal:10.3.0 and
                    is removed from drupal:12.0.0. Use                          
                    Drupal\Core\Render\RendererInterface::renderInIsolation()   
                    instead. 

If you agree with ignoring future removals for this update I think the only issues are these:

Fix now        207  Call to deprecated function file_validate(). Deprecated in  
                    drupal:10.2.0 and is removed from drupal:11.0.0. Use the    
                    'file.validator' service instead.    

and these:

Check manually 32   #access_callback callback '#access_callback' at key '0' is  
                    not callable.                                               
--------------------------------------------------------------------------------
Check manually 36   The "#lazy_builder" expects a callable array with arguments.
--------------------------------------------------------------------------------
Check manually 37   The "#post_render" render array value expects an array of   
                    callbacks.                                                  
--------------------------------------------------------------------------------
Check manually 38   The "#pre_render" render array value expects an array of    
                    callbacks.                                                  
--------------------------------------------------------------------------------
Check manually 45   The "#date_date_callbacks" render array value expects an    
                    array of callbacks.                                         
--------------------------------------------------------------------------------
Check manually 46   The "#date_time_callbacks" render array value expects an    
                    array of callbacks.   

FILE: web/modules/custom/webform/css/webform.theme.claro.css
STATUS         LINE                           MESSAGE                           
--------------------------------------------------------------------------------
Check manually 0    The #drupal-off-canvas selector is deprecated in            
                    drupal:9.5.0 and is removed from drupal:10.0.0. See         
                    https://www.drupal.org/node/3305664.   

The only other messages are core_version_requirement related and some deprecated sub modules: This extension is deprecated. Don't use it.

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.

Great!
In that case I think the job is the best source there are a LOT of changes so I won't copy them here.

https://git.drupalcode.org/project/webform/-/jobs/2729810

Fixed merge conflict and allowed tests to get past composer issues with the ckeditor module.

I think we need to spin out another issue to remove ckeditor support and require ckeditor5 though.

Many of the upgrade_status messages are just plain wrong, are they not running on HEAD??

Search for renderPlain in the codebase, it's only ever using our own WebformThemeManager::renderPlain which uses renderInIsolation

All the errors about extending deprecated classes are also wrong...

Finally got composer (next major) passing - sorry for the noise. Group module has major issues and doesn't seem needed by any tests (from my sleuthing). The issue is it depends on https://www.drupal.org/project/flexible_permissions which depends on https://www.drupal.org/project/variationcache neither of which are D11 compatible and are marked obselete.

This should be ready to go!

I've created #3474042: Speed up tests too because waiting 30 minutes for this was a tad painful.

Looks great to me. Should we create followups to fix the linting warnings?

@mstrelan has a lead on speeding up tests.

Do the rest of the upgrade status issues need to be resolved or are those the ones you mentioned are wrong?

Edited to add: @mstrelan's change cut 25 minutes off the test run time.

Ok I looked through the changes and they all look pretty straightforward.

I vote RTBC, but I'm leaving it open to answer the question about the upgrade status results.

Do the rest of the upgrade status issues need to be resolved or are those the ones you mentioned are wrong?

They all look wrong to me, I went through half a dozen and they were all incorrect. I have asked in the gitlab channel if anyone knows why.

I think if there were legit deprecations, they'd be caught and fail tests.

Looks like we've still got some failures anyway...

Created follow-up #3474074: Fix cspell errors

Thanks for your work.

This merge request introduces some phpcs issues. That test used to pass.

Deprecated file_validate() needs to be replaced. There may be other similar changes needed.

Instead of a big commit with all the fixes, I would prefer separate commits for each change. For example, a commit that only replaces file_validate(). I wouldn't mind follow-up issues for individual fixes like that.

@hswong3i why did you force push over all of my changes? Please don't do that.

@acbramley when there is a force-push, it will create a tag pointing to the earlier version, so the work is not lost.

It would probably be best to start by fixing each issue raised by upgrade_status. Once that is passing (except for the core_version_requirements), then work any remaining issues.

@liam morland right but it's a bit disruptive to lose all progress on a branch and have to force push again.

As explained above, the upgrade_status run seems bugged and is reporting many issues that aren't correct.

I'm first focussing on getting tests to pass as they should catch most of the real issues.

@linhnm thanks for your commit. Please use separate commits for each change. For example, replacing file_validate() should be its own commit.

Please use dependency injection for any new code. I know there is a lot of use of \Drupal:: currently; let's not add any more.

Please use dependency injection for any new code. I know there is a lot of use of \Drupal:: currently; let's not add any more.

That's in procedural code, can't use DI there.

Bit confused why you'd split up different file validator fixes, they are all consistent. There is no use of file_validate() in the project. I missed the file_validate() removal in that commit, sorry. But still think it's valid to update validators and that function in a single commit.

The file tests are failing on next major due to
The "webform_file_validate_extensions" plugin does not exist.

This validator is added in WebformManagedFileBase. I don't know the background as to why this exists, it only seems to be used to support comma delimited extensions (in webform_preprocess_file_upload_help)

Hmm I removed the custom validators but it looks like they are needed for this "per form" file size limit... not really sure how to manage that without a decent amount of rework.

'webform_file_validate_extensions' and 'webform_file_validate_name_length' are not actual file upload validators, but keys that were put in there to pass variables to hook_help().

'webform_file_validate_extensions' was never set as far as I could see, so I removed it.

Hi, it could be interesting to add a branch-alias configuration to the composer.json file to facilitate testing of Webform related modules on Drupal 11 :

    "extra": {
        ...
        "branch-alias": {
            "dev-3465838-drupal-11-compatibility": "6.3.x-dev"
        }
    }

Tested locally, seems to work fine as it allowed me to install some modules depending on the 6.3 branch.

But I guess it would require to remove the 6.3.x branch on the issue's fork...

EDIT:

A simpler solution is to use inline aliases:

require: {
    ...
    "drupal/webform": "dev-3465838-drupal-11-compatibility as 6.3.x-dev",

So the new composer require command could be something like:

composer require "drupal/webform:dev-3465838-drupal-11-compatibility as 6.3.x-dev"

I am not sure why an alpha release could not be made on the 6.3.x branch, since alpha releases would not be recommended for use anyways, but it would make it easier to test dependent contrib modules on drupal 11.
I think it would help contrib to commit this work and continue with fixes on that branch instead of waiting for a big pull request.

I would welcome small merge requests to make specific needed changes. For example, removing use of deprecated code. Remember, 6.3.x depends on Drupal 10.3.

After applying the merge request, if anyone encounters cache-related issues on Pantheon, please ensure to update the "pantheon-systems/drupal-integrations" package to the latest version. This should help resolve any caching problems.

Reference: https://github.com/pantheon-systems/drupal-integrations/issues/28

Going to start splitting some of these changes into separate issues to make this more manageable.

Modernizr deprecation has moved into #3478398: Remove modernizr dependency and code
Twig spaceless deprecation has moved into #3478399: [Drupal 12.x] Twig spaceless filter is deprecated

Moved optional params issue into #3478407: Fix Optional parameter X declared before required parameter Y

Few more:

#3478412: Enable concurrent phpunit
#3478414: Remove/replace deprecated #drupal-off-canvas selector
#3478415: Fix test module package versions

@acbramley #16

Going to start splitting some of these changes into separate issues to make this more manageable.

Thank you for doing this. It will make is possible for us to quickly review and merge changes, while isolating the remaining challenges.

I've reset the branch behind some of the commits that were moved out, and then merged 6.3.x in. Much less changes now!

The filter format failure is going to need some thinking

3) Drupal\Tests\webform\Functional\Access\WebformAccessFilterFormatTest::testFilterFormatAccess
Behat\Mink\Exception\ExpectationException: The string "webform_default" appears in the HTML response of this page, but it should not.

In https://git.drupalcode.org/project/webform/-/merge_requests/254/diffs, webform_filter_format_load was added which doesn't seem to get invoked on D11. All this is doing is hiding the default webform filter format on the filter format overview. I'll do a bit more debugging but we may need an alternative solution (e.g override the list builder or something more robust).

EDIT: Never mind, it does get invoked, but on D11 disabled formats are displayed #2502637: Disabled text formats can't be seen in the GUI

Getting to the tail end very end of these failures.

WebformClientSideValidationJavaScriptTest is still failing locally with a javascript error. When reproducing this in the browser the error is:

Can't set value before init

Debugging into this it's coming from Drupal.behaviors.states so I'm assuming something has changed in that API that either webform or clientside_validation needs to fix.

2) Drupal\Tests\webform_ui\FunctionalJavascript\WebformUiElementJavaScriptTest::testElement
TypeError: c.isArray is not a function

This is a random fail and is coming from select2 CDN javascript... I'll see if there's a way we can stop this interfering in completely unrelated tests.

EDIT: Maybe it's not random. This is because we're on jQuery 4 now, and isArray is deprecated in jQuery 4. https://github.com/select2/select2/issues/6298

Select2 is used for various webform_ui elements such as wrapper css classes, user permissions, etc.

FYI I've cherry-picked the commits from https://www.drupal.org/project/webform/issues/3477942 to move things proactively.

cc: @acbramley

Noticing one failure for next major phpunit pipeline: https://git.drupalcode.org/issue/webform-3465838/-/jobs/2973891
Need to handle upgrade_status pipeline: https://git.drupalcode.org/issue/webform-3465838/-/jobs/2973888

cc: @jrockowitz @acbramley

Hi @jrockowitz,
The next major pipeline is having only one failure which also weird ~~ same sub-module test I've run on my local machine
Please check the screenshot below

There might be chance our next major pipeline is failing due issue reported in https://www.drupal.org/project/drupal/issues/3479446

With all the changes on MR!501 can we consider atleast merge this MR to the develop so that rest of the open issues or related can move smoothly as there's lots of back and forth things going with all the related issues (Interdependent someway or other)

cc: @acbramley

Yay!! Test pipelines are green now!!!!

Wow!!! I reviewed all the changes and everything looks great. Awesome work. You rock!!!

I would like to give other people a chance to review but from my review this is RTBC.

I think we can merge AS-IS this and deprecate the Webform Bootstrap module in a new ticket.

@jrockowitz Only thing is remaining is to update the CR with the deprecation reason of this sub-module: https://www.drupal.org/docs/8/modules/webform/webform-frequently-asked-q...
With that we can merge MR!501.

I can't vouch for all the functionality, but I was able to install and enable the MR!501 in Drupal 11.

@lkmorlan @jrockowitz can we please move this issue ahead?

All the tests are passing. I merged the MR. Thanks.

Tests were passing in the merge request but are not passing now. I have opened #3481554: Make tests pass.

Thanks so much for getting this across the line.

Will a 6.3.x alpha or something be release shortly? Or should we be testing that on the dev 6.3.x dev branch?

I generally let major patches set for two weeks on the dev branch before making a release. Please test the dev branch for now.

We should probably consider #3479443: Remove legacy ckeditor from codebase. to be a release blocker. That is likely all that is needed for #3481554: Make tests pass.

https://www.drupal.org/project/webform/I am confused by this long issue. How do I get webform to work on Drupal 11?

 # composer require "drupal/webform:dev-3465838-drupal-11-compatibility as 6.3.x-dev" -W
./composer.json has been updated
Running composer update drupal/webform --with-all-dependencies
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires drupal/webform dev-3465838-drupal-11-compatibility as 6.3.x-dev, it is satisfiable by drupal/webform[dev-3465838-drupal-11-compatibility] from vcs repo (git https://git.drupalcode.org/issue/webform-3465838.git) but drupal/webform[dev-4.x, dev-5.x, dev-6.x, dev-6.0.x, dev-6.1.x, dev-6.2.x, dev-6.3.x, 4.x-dev (alias of dev-4.x), 5.0.0-beta1, ..., 5.x-dev (alias of dev-5.x), 6.0.0-alpha1, ..., 6.x-dev (alias of dev-6.x)] from composer repo (https://packages.drupal.org/8) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.
  Problem 2
    - drupal/webform_views is locked to version 5.4.0 and an update of this package was not requested.
    - drupal/webform_views 5.4.0 requires drupal/webform ^6.0 -> found drupal/webform[dev-6.x, dev-6.0.x, dev-6.1.x, dev-6.2.x, dev-6.3.x, 6.0.0-alpha1, ..., 6.x-dev (alias of dev-6.x)] but it conflicts with your root composer.json require (dev-3465838-drupal-11-compatibility as 6.3.x-dev).

and

# composer require drupal/webform:dev-3465838-drupal-11-compatibility
./composer.json has been updated
Running composer update drupal/webform
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires drupal/webform dev-3465838-drupal-11-compatibility, it is satisfiable by drupal/webform[dev-3465838-drupal-11-compatibility] from vcs repo (git https://git.drupalcode.org/issue/webform-3465838.git) but drupal/webform[dev-4.x, dev-5.x, dev-6.x, dev-6.0.x, dev-6.1.x, dev-6.2.x, dev-6.3.x, 4.x-dev (alias of dev-4.x), 5.0.0-beta1, ..., 5.x-dev (alias of dev-5.x), 6.0.0-alpha1, ..., 6.x-dev (alias of dev-6.x)] from composer repo (https://packages.drupal.org/8) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.
  Problem 2
    - drupal/webform_views is locked to version 5.4.0 and an update of this package was not requested.
    - drupal/webform_views 5.4.0 requires drupal/webform ^6.0 -> found drupal/webform[dev-6.x, dev-6.0.x, dev-6.1.x, dev-6.2.x, dev-6.3.x, 6.0.0-alpha1, ..., 6.x-dev (alias of dev-6.x)] but it conflicts with your root composer.json require (dev-3465838-drupal-11-compatibility).

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

Please issue a real release ASAP.

Strongly agree important to just get a release - even if marking it as alpha or beta - is important.
That said, @tjtj use this https://www.drupal.org/project/webform/releases/6.3.x-dev for now rather than the custom branch. It should work, but chance that the dependences on webform_views won't allow it. If it doesn't allow it you could try 'as 6.3.0' or similar.

Thanks. Why not put a link to this? Views claims they will do their update

It would be best to get tests passing again first; see #3481554: Make tests pass.

I would also like to have resolution to #3479443: Remove legacy ckeditor from codebase..

6.3.0-alpha1 released.

It would still be nice to get #3479443: Remove legacy ckeditor from codebase. resolved before beta.

where is the link to 6.3 alpha?

It's on the main page: https://www.drupal.org/project/webform

I have created #3492971: Document webform_bootstrap deprecation.

I have released Webform 6.3.0-alpha3.

Any Pantheon hosting users on this thread? I'm still getting the error mentioned in #19 Edit: Simply forgot to edit pantheon-systems/drupal-integrations in my composer.json. Nothing to see here, carry on.