🇩🇪Germany @gogowitsch

Updated issue summary in #1.

gogowitsch → created an issue.

Personally, I would go with your solution 2, “an error could be triggered on form save”. It strikes a good balance for site owners to understand what the problem is.

About solution 2, I also like that GET requests are not affected by the small performance penalty of the additional permission check.

Cool, I am happy you got it working.

Sorry that I don’t have a helpful answer here.

As I cannot reproduce this issue locally, I will close this issue now.

The code posted by dhruveshdtripathi → looks correct. Without a way to debug the issue on my machine, I cannot help.

I will therefore now close this issue.

Thanks! I created a new release 1.21

I, too, can confirm that the patch in #3 fixed the problem.

Thanks for your report. I’ll review it later. Once it runs again with Drupal 11, I’ll create a new release.

@megaphonejon → : Thank you for your detailed report!

Feel free to answer just with the information you have. If the drush cex part seems too hard, just leave it out.

Interesting! Which operating system / distro is your Drupal instance running on? If it runs in a container: which distro is that?

Also helpful would be a zip file with all the YAML files that the command drush cex produces. Feel free to redact all private information. Leave out files you believe are not relevant to the email problem.

This is a good idea - thanks!

Yes, certainly. Co-maintainers, code and financial contributions are welcome. For the latter, see the project page.

To subscribe anonymous users, you can install the Webform phpList module. It supports phpList’s user attributes. The module needs Drupal 8 or newer, though.

In the simplest case, the webform has just one element: the email address.

We can tackle this in a separate issue. I have opened Issue #3474610: Feature: make confirmation message customizable ✨ Feature: make confirmation message customizable Needs work .

Meanwhile, here is a solution you can use:

1. Enable Core’s Interface Translation module
2. Go to /admin/config/regional/language/edit/en and check “Enable interface translation to English”
3. Go to /admin/config/regional/translate
4. Search for the message and change it.

gogowitsch → created an issue.

If you are using a custom theme, you can fix it by copying the template file locale-translation-update-info.html.twig from core to the templates directory of your theme.

Within the <li> tag, you can change the param of format_date, for example to this: format_date('short'). This will circumvent the error.

I have attached a patch file to make the necessary fix a little bit clearer. If you are using a theme managed by composer, then the "cweagans/composer-patches" plugin can prevent losing the manual change. Add these lines to your composer.json file, within the "extra" section:

        "patches": {
            "drupal/core": [{
                "description": "https://www.drupal.org/project/twig_intl/issues/3419285",
                "url": "locale-translation-update-info.html.twig.patch"
            }]
        },

Then, you can run composer require cweagans/composer-patches:~2.0 && composer patches-relock && composer patches-repatch.

I have added a release with this new feature.

gogowitsch → created an issue.

For Drupal 8 and newer, you can use the Webform phpList module → . It adds a handler for sending webform → submissions to a self-hosted phpList installation.

The Webform phpList module → adds a handler for sending webform → submissions to a self-hosted phpList installation.

Regarding #13: ...Interface as a type hint should always be preferred if an ...Interface type exists.

Regarding #11: the patch should apply independent of the Drupal Core version. I suspect you either were not in the right directory, or you had a different webform_views module version on your disk.

I have attached a patch. Now my database updates (drush updb) run through smoothly and the site works again.

I improved the code based on @jsacksick's feedback in Comment #7 ✨ Add a 'description' field to the schema for states and transitions RTBC .

The GitHub PR from #13 🐛 missing license URL RTBC has been merged, further confirming the MIT license.

@jsacksick Thanks, the code in #4 helped me, too. I ran it within drush php.

Since for me, only the core twig file locale-translation-update-info.html.twig caused the problem, I copied it to my custom theme and changed the date format call to format_date('short')

I am leaving this issue open so that the bot can add more comments and patches.

Gogowitsch → created an issue.

I have tested the feature: very useful for my situation.

I have read the diff (code changes): looks good to me.

Gogowitsch → made their first commit to this issue’s fork.

Gogowitsch → created an issue.

The last release is from Jan 2023. Dear @ChristianAdamski: Please create a new release.

Thanks in advance.

Gogowitsch → created an issue.

For my theme, it was feed-icon.html.twig. I actually copied the twig file from a core theme to my custom sub-theme before emptying it.

+1: Reviews and tested 👍

I have opened a PR here: https://github.com/briancherne/jquery-hoverIntent/pull/86

Gogowitsch → created an issue.

Thanks, @abhishek_gupta1! The code change looks fine.

However, a test fails: https://git.drupalcode.org/issue/commerce-3441980/-/jobs/1371800#L1422:

Drupal\Tests\commerce_product\FunctionalJavascript\ProductLayoutBuilderIntegrationTest::testConfiguringDefaultLayout
Behat\Mink\Exception\ElementHtmlException: Element exists on the page.

Gogowitsch → created an issue.

This is a reroll of #16 against 11.x-dev.

Let’s focus on the string before the colon. I would expect something like:

...
process:
  field_custom_status/value: field_custom_status_value
  field_custom_status/format: field_custom_status_format
...

However, the value behind the colon is most likely wrong, as I don’t know what keys your source produces.

In addition to the UnexpectedTypeException above, here are two more points:

1. I noticed my IDE, PhpStorm, to incorrectly highlight null as a schema validation error.
2. I expect configuration I export using drush cex to be valid. This is not the case with migrate_plus.migration.*.yml files.

Please review the attached patch, which solves both.

I used the inspiration from #12 to fix my site. In my case, dr updb (database migration using Drush) complained about a missing entity "crop". Here are my steps - in case you find them easier than #12:

• open Bash
• run dr cex -y
• cd to the export directory
• run grep <em>crop</em> core.entity_view_mode* (here "crop" is the missing entity the migration stumbled over.
• delete the config using dr config:delete <em>core.entity_view_mode.crop.token</em> (in my case, grep found core.entity_view_mode.crop.token.yml)
• run the migration again, e.g. using dr updb

Gogowitsch → created an issue.

I had a similar breadcrumb problem with the item Checkout repeating. My solution was to add this function into the site’s theme:

/**
 * Prepares variables for `breadcrumb.html.twig`.
 */
function theme_preprocess_breadcrumb(&$variables){
  if (count($variables['breadcrumb']) > 2) {
    if ($variables['breadcrumb'][1]['url'] == '/checkout') {
      // Avoid: Home » Checkout » Checkout
      unset($variables['breadcrumb'][1]);
    }
  }
}

Patch committed to branch 8.x-1.x.

Patch committed to branch 1.x.

For Drupal 8-11, these modules can show a counter (or a bar, if you have a target count):

• Webform Crowdacting Social Progress Bar - also has a plain text counter element (in addition to the bar).
• Webform Counter supplies a token.

Regarding 1) The 640x480 player size is the default on new Drupal installations. You can change the display of videos by going to this page: /admin/structure/media/manage/video/display

I encountered this exact problem, applied the patch by codebymikey: voilà, problem gone.

Before applying the patch, I hit error above on the typical white Drupal error page.

The code change looks fine.

I encountered this exact error when setting up my store. The explanation in #4 is correct.

Regarding czigor's patch: it only fixes the issue in 1 of the 3 locations where getCheckoutFlow() is called.

I have attached a much smaller fix. Maybe we can get this committed and released quicker this way. Given that the error happens to IT folks (not end users) I find it sufficient to show it in the /admin/reports/dblog.

The error means that you have no payment gateway or the gateway has no attached add-payment form. Go to the /admin/commerce/config/payment-gateways page to fix this.

I will release version 1.5 with this patch applied.

I added a patch.

Here is a stack trace from the debugger:

Drupal\Core\Form\FormErrorHandler->displayErrorMessages(Array, Object) (Line: 23)
Drupal\Core\Form\FormErrorHandler->handleFormErrors(Array, Object) (Line: 199)
Drupal\Core\Form\FormValidator->finalizeValidation(Array, Object, 'webform_submission_bulk_form') (Line: 119)
Drupal\Core\Form\FormValidator->validateForm('webform_submission_bulk_form', Array, Object) (Line: 593)
Drupal\Core\Form\FormBuilder->processForm('webform_submission_bulk_form', Array, Object) (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm('\Drupal\webform\Form\WebformSubmissionBulkForm', Object) (Line: 224)
Drupal\Core\Form\FormBuilder->getForm('\Drupal\webform\Form\WebformSubmissionBulkForm', Array, 1) (Line: 577)
Drupal\webform\WebformSubmissionListBuilder->buildEntityList() (Line: 462)
Drupal\webform\WebformSubmissionListBuilder->render() (Line: 23)
Drupal\Core\Entity\Controller\EntityListController->listing('webform_submission')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Gogowitsch → created an issue.

New patch ahead! I could not push to the fork in the MR, with Git telling me “You are not allowed to push code to this project.”

I have moved the empty function to the base class MigrateSandboxEntity and fixed the phpcs errors.

Thanks everyone!

I can confirm the “Reviewed & tested by the community” status: I have applied the patch from Comment #2 📌 Automated Drupal 10 compatibility fixes RTBC , and actively use the module for a complex migration from Drupal 8 to Drupal 10.

Gogowitsch → created an issue.

Gogowitsch → created an issue.

Gogowitsch → created an issue.

I suspect that the problem is in your particular Drupal installation or in your code. Online, there are many complaints about "noname" attachments that are not related at all to Drupal.

Try to have a look what the file contains. It might be an inline image or a mime part added by another module.

Fixed.

This code change looks good to me and works fine. Let’s get this merged, shall we?

Well, actually, here it is. Hopefully. The UI for Drupal issues is not the most intuitive.

Here is the patch.

Gogowitsch → created an issue.

I merged the commit 7d2ea8ebd512d464c243a368589db2519c3ef471 into the 8.x-1.x branch.

This module should now be compatible with Drupal 10.

I have released 1.19 → and my production server is green again.

I am deeply sorry for the time you have lost due to my poor quality assurance of the previous release! I have marked it as broken.

Thank you, @sleitner! I have added your patch to both the D7 and the D8 dev branch.

Tests run again. Sign of relieve! 🙂

This will be fixed in release 1.19.

Thanks for your work, @solideogloria and @sleitner! I’ll release a new version later today. I am currently testing.

I have released version 8.x-1.18 → to fix this issue.

Thanks everyone. I have merged your proposed changes, except for these points:

• I changed the names of the functions so they start with an underscore to show that they are internal, including the @internal annotation.
• I fixed the project name in `modules/email_attachment_demo/email_attachment_demo.info.yml`
• I re-added some of the `@param` annotations that were removed in this MR.

Gogowitsch → created an issue.

@mi-dave I have pushed a fix to the dev branch. If you have time to give feedback to code changes or a manual test, please share your results here.

If all is good or I don’t here from you in a while, I will publish a new release of the module.

Until the actual incompatibility with Drush 12 is fixed, I suggest we quickly release an intermediate version that just prevents civicrm_drush to be installed alongside Drush 12.

Please review the patch I have attached for composer.json. It is exactly the change from the following commit on the 8.x-2.x branch: https://git.drupalcode.org/issue/civicrm_drush-3380821/-/commit/508cf4b4...

I have reviewed and applied the patch from #3 and now use it in a Drupal 10.1.6 production site.

From my perspective, this patch should be included in a release as soon as possible.

I have tested this module with Drupal v10.0.0 and v10.1.6. The dependency openid_connect was at v1.4.0.

Please review the attached patch.

Thanks for the detailled description, mi-dave. I’ll work through your code and steps in the next days.

Add links, especially to API

Mention the check_markup function as the primary purpose of the filter module.

Thanks for fixing this. I ran across this as well.

I saw it in my monitoring using Icinga2 with the Nagios module.

Just confirming that I am still available to co-maintain this module. 😊

Meanwhile, we end-users can add the following lines to the form under Build » Source:

opt_in_status:
  '#type': value
  '#title': opt_in_status
  '#value': 'Double opt-in confirmation mail pending'

Also, I figured out that of the 2 handlers this module provides, only the DoubleOptInEmailWebformHandler is useful. The “Compatible“ handler doesn’t yet understand the [email-confirmer:confirmation-url] token as far as I can tell. In fact, it looks like the “Compatible“ handler is just an old copy of the one that is shipped with the vanilla webform module.

And in short, I got the module to work and am happy.

I am also interested in co-maintaining this module.

@Ahmad: we could review each other’s code changes to learn from each other and ensure higher quality.

Gogowitsch → created an issue.

Fixed in version 1.3 of the module. Thanks, Nathan!

Thanks, MegaphoneJon!

I have pushed the patch to the dev branch. It will be part of the next release, which is not yet scheduled.

Thanks. We cannot add the dependency, as this would break existing installations. We briefly had the dependency activated and I received a lot of feedback. However, we can make it a softer dependency. I'll look into this.