We'll need to make sure the release notes are clear that anyone using certain Webform sub-modules will need to add webform_deprecated to Composer before upgrading.
The best thing might just to be cast to string; see merge request. The problem with empt() is that 0 is empty.
That sound reasonable.
Thanks!
What are the steps to reproduce this?
As it currently is, there is no way to install the libraries from Project Browser; it would be CDN-only.
liam morland → created an issue.
Yes, that makes sense. I don't think we should require any external library unless Webform cannot operate without it.
There is no need for ::backwardsCompatibleCall() if the minimum is set to Drupal 10.3.
A release node should be made for 2.0.x.
Is there a reason 2.0.x is not marked as a recommended branch?
Tests are not passing again.
Clarify that the transaction will commit when $transaction goes out-of-scope
I have updated the issue fork with the current development code. Please put your patch into that and make a merge request.
The change in the merge request does remove the error messages and provide fallback text. I'm not sure if this is a good solution or not. The string would need to be translated.
liam morland → created an issue.
I'm referring to the line 68 issue.
Some of the spelling failures are spelling errors that should be fixed. Some can be ignored in .gitlab-ci.yml by setting _CSPELL_WORDS.
It could be merged anytime. There are a few simple issues outstanding that should be fixed.
liam morland → created an issue.
That one is about creating a mirror. This one is about preventing it from falling-back to a CDN.
Some users will not be using the slider, so they don't need the library to be installed but they also want to prevent the CDN from being used inadvertently and also don't want to see a warning about it on the status page.
liam morland → created an issue.
liam morland → created an issue.
webform_migrate 2.0.x is compatible with Drupal 10.
There should be a release node created for 2.0.x. I think that would prevent the bot from creating additional automated patch issues.
Even if the test pages are gone, I would much rather not have any JS library available on the server unless I am using it.
Please make a merge request so that tests will run.
I think select2_library would be good, pretty clear. Does Drupal have a pattern for this?
Thanks for the patch.
Those CSS selectors work to center the radio buttons, but they will change other tables too. It is probably needed to add .diff-responsive-table to the selectors.
The merge request should be updated.
Perhaps we should separate them out for Webform 6.4.x.
I'm concerned about adding all those libraries to the Webform Composer file. This would mean that all Webform users would suddenly get libraries installed that they are not using. Could you have the Drupal CMS Composer file require the libraries? Once the Webform sub-modules are moved into being top-level modules in their own projects, then the libraries would get installed from each of those.
I am suggesting that some modules that are currently sub-modules of the Webform project should be moved into their own projects. If you choose to install the module, its Composer file will bring in the corresponding library.
I think this makes it more urgent that Webform sub-modules that depend on external libraries be moved into separate projects. That way, the library would only get installed if the site wants to use it. The sites I work on only use a very few external libraries that we have specifically chosen to add to our Composer files.
I don't understand what is happening. You have a Webform in several languages. You add a component. This component now appears on the form in all languages. You make a submission. Is it the case that when you view the submission, the new component is only appears on the English results page, but not on the other language results?
Sure. That separated approach could be put into the merge request. When the MR is merged, squashing the commits into one will have the same result.
Makes sense.
If this restriction can be done in Composer, that would be great, but I'm not sure it can be.
I suggest adding to the top of "Upgrading from 3.x" in bold something like "Footnotes 4.x works with CKEditor 5, but not any older versions of CKEditor. For CKEditor 4, use Footnotes 3.1.x."
You could leave 3.1.x branch marked as supported and include on the project page that it will only receive security fixes. The fixes would probably be the same as 4.x anyway.
liam morland → created an issue.
The master branch is already gone, though there are some offer likely-obsolete branches which should probably be removed.
Test are now passing.
I rebased the merge request on 11.x. The patch is the current state of the merge request.
Who does the usability sign-off?
Does this need an upgrade hook or would it be OK to write it so that if allow_self_reference is not set, is is treated as true to preserve existing behaviour?
liam morland → created an issue.
I have created 📌 Document webform_bootstrap deprecation Active .
liam morland → created an issue.
Tests are failing again.
Should this be considered a blocker for 6.3.x?
Does this really need to use ::backwardsCompatibleCall()? Within days, Drupal 10.3 will be the oldest supported.
I suggest tagging 2.0.1 with just the fixes for this issue. That would allow people using 2.0.0 to run the same code but without the errors about creation of dynamic property.
Have you tried that the module works on Drupal 11?
Functional tests are now running and passing on Drupal 10.
liam morland → changed the visibility of the branch 3.2.x to hidden.
liam morland → created an issue.
It turns out that dependencies make this impractical.
Is this needed now that
📌
Remove use of deprecated "spaceless" filter in core templates
Active
has been committed? spaceless no longer appears in Drupal core.
Will be fixed in 🐛 Too few arguments to function Drupal\Core\Form\ConfigFormBase::__construct(), 1 passed in /var/www/html/web/modules/contrib/psa_oecd_publishing/src/Form/OecdPublishingSettingsForm.php on line 60 and exactly 2 expected Needs review . Leaving open for more patches.
State that PHP 8.4 support will not arraive
This change is triggering a phpstan error: "Cannot unset offset 'tablefield' on array." in src/Plugin/Field/FieldType/TablefieldItem.php.
$values['tablefield'] is already unset in the previous line, so unsetting $values['tablefield']['rebuild'] does nothing. This suggests to me that something is wrong with the change. At least, this line should be removed: unset($values['tablefield']['rebuild']);
Sure. Please make a 3.0.x development snapshot release first. Then, if you like, I'll make a beta.
Should this be cherry-picked onto branch 3.0.x?
Should this be cherry-picked onto branch 3.0.x?
I have added PHP 8.4 and Drupal 10.4 and 11.1 to the PHP support page → .
The advantage to making a separate project for each module is that is allows the users of that module to work on maintaining it together or not, if there is not enough community interest.
It could be helpful to move to their own projects most Webform modules that exist only to make an external library work with Webform. This allows Webform it self to not need to worry about maintaining a dependency on a library that only a subset use.
I have seen this on sites that did not have any outstanding update hooks. It was fixed by a cache clear. This is probably a bug that ought to be fixed.
I don't know how we ended-up in this situation. It is clear from the code that this would happen anytime that allowed_types is not an array. People could end up like this by setting it to null or to a string.
I think this issue should only correct the dependencies. The other issue an take care of removing.
Is it the case that admin_toolbar_links_access_filter module is no longer needed as-of Drupal 11.0? Or can it be removed earlier?
The merge request should be closed.
Please make a 8.x-1.6 release with this fix.
I don't know anymore. I'm not using Drupal 7 anymore. It's a simple fix, though.
Is #18 a reliable check? That is, is it the case that if disabling the module and exporting config results in no changes, then it is safe to leave the module disabled?
Merged. Leaving open for more automated patches.