🇩🇪Germany @gogowitsch

It is fixed in the version 1.25 release → .

Thanks for reporting this, @interlated! 🙂

That should be easy.

Fixed.

While I found a solution, it is not a visibility condition, but rather a full Twig field for the text that supports the {% if bla %}{% endif %} syntax.

More complex example:

{% set i = 0 %}
{%- for e in elements|keys -%}
  {%- set i = i + 1 -%}
  Field {{ i }}: {{ e }} = “{{ webform_token('[webform_submission:values:' ~ e ~ ']', webform_submission) }}”äö
{% endfor -%}

This might get tricky.

Wow, thanks for the request. I have an idea how to solve this.

gogowitsch → created an issue.

Fixed. We now allow multiline text.

Thanks, drupallena! I’ll check what I can do.

This is part of the release 1.1.0 → .

Will be part of version 1.1.0.

Fix is on the way.

This will be fixed in an upcoming release.

gogowitsch → created an issue.

Thanks again for reporting and your code change suggestions. I added dependency injection and a CI pipeline.

I'll release the fix in version 1.8.

The WARNING says "where possible":

If you’re really sure that you need to pass something other than a string literal to the t() function, use this comment before the problematic code line:

// @codingStandardsIgnoreLine Drupal.Semantics.FunctionT.StringLiteralsOnly

gogowitsch → created an issue.

Thanks for opening an issue. I’ll work on it within the next 2 weeks.

Nothing to do for now. Patch has been applied.

Is there already a tool to parse the watchdog id (wid)? Or any plan to build such a tool?

I changed the format so that the regex " wid=([0-9]+) " can be used to extract the wid.

Thanks for the MR, tunic! I’ll review it later later, before the end of March.

I ran into the exact same problem.

I can confirm that MR !20 worked. I simplified the code by replacing $this->entityTypeManager->getDefinition($entity_type->id()) with $entity_type.

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

gogowitsch → created an issue.

Okay, so here are the 3 ways an update from keycloak v1.8.0 => 2.2.1 works:

1. explicitly require openid_connect 3.0.0-alpha5 first, then update to alpha6
2. require drupal/externalauth:^2 and enable the module with drush en externalauth
3. Use the patch from #?.

Using the patch from #?? didn’t work on my install, because the module externalauth was not enabled. So clearing the Drupal cache with drush cr resulted in this error:

In CheckExceptionOnInvalidReferenceBehaviorPass.php line 119:
The service "openid_connect.openid_connect" has a dependency on a non-existent service "externalauth.authmap".

@joseph.olstad: Yes, applying the patch to alpha6 solves the error on rebuilding the cache. Thanks for the fast response.

gogowitsch → created an issue.

You’re right. I messed up when creating the git tag. Both version 1.22 and 1.23 are identical.

Rather, this issue is fixed in release 1.24 → of the Nagios module.

The core issue #3442009 📌 OOP hooks using event dispatcher Needs review that caused our bug was merged after 10.4.1and before 11.1.0-beta1.

This issue is fixed in release 1.23 → of the Nagios module.

The bug was introduced by core issue #3442009 📌 OOP hooks using event dispatcher Needs review . It can also be triggered by drush updb.

Thanks for the fix, megaphonejon → ! Commited and pushed. I’ll release a new version soon.

joachim namyslo → credited gogowitsch → .

The new type hints caused issue 3493815 🐛 TypeError in getCellRaw: string expected, Markup received Needs review .

This bug was introduced by issue #3478883: Parameter typing and return type hints

gogowitsch → created an issue.

The reason that states were wrong was the $form[$group]['#access'] = FALSE; line: it hides the module selection if no other modules add checks to nagios. I pushed a fix to the dev branch. If tests are green, I will create a release.

Thanks for your throrough description. I will review the suggested change within the next 48 hours.

Regarding Comment #5 🐛 Incorrect caching of nodes with access denied pages Needs review : no, unfortunately not without more logic. The access rules for viewing webforms can be defined both per user and per role.

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.