🇺🇸United States @pcate

@pcate: If you apply the patch from MR!57, does it fix the issue on your site?

@tr, I've tested MR #57 and can confirm it does fix the error.

I'm able to recreate the error from #29 with a CLOSED webform, but unable to replicate by changing the access setting for the Webform.

After some more testing, the settings which triggers the error for me were:

1. In the "Submissions" tab, enable the "Confidential submissions" option.
   • Note: If you have the "General" > "Disable saving of submissions" option enabled, you won't see this option.
2. Set the Access > "Create submissions" permissions to be both anonymous and authenticated users.
3. Visit the form while logged in as a basic authenticated user who doesn't have any permissions to bypass access restrictions.

I updated the input description text.

After updating to version 2.2.1 I've started getting webform error messages related to this change.

The error is:

TypeError: array_key_exists(): Argument #2 ($array) must be of type array, null given in array_key_exists() (line 151 of modules/contrib/honeypot/src/HoneypotService.php).
Drupal\honeypot\HoneypotService->addFormProtection() (Line: 234)
honeypot_webform_submission_form_alter() (Line: 552)
Drupal\Core\Extension\ModuleHandler->alter() (Line: 78)
Drupal\webform\WebformThirdPartySettingsManager->alter() (Line: 678)
Drupal\webform\WebformSubmissionForm->buildForm()
call_user_func_array() (Line: 536)
Drupal\Core\Form\FormBuilder->retrieveForm() (Line: 284)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 48)
Drupal\Core\Entity\EntityFormBuilder->getForm() (Line: 1250)
Drupal\webform\Entity\Webform->getSubmissionForm() (Line: 112)
Drupal\webform\Element\Webform::preRenderWebformElement()
call_user_func_array() (Line: 113)

It appears that are circumstances where the $form['elements'] is not set on webforms. It seems in my clients case to be related to access controls where the form may not be rendered if the user is logged in.

I think we need to check if the $form['elements'] is also set in the if statement on line 151 of HoneypotService.php

I created a MR with @emptyvoid patch. I also replaced the $section_component->get('configuration') call with $section_component->getConfiguration() to fix the deprecation warning.

Added test to MR #16

The code in #4 or https://www.drupal.org/project/group/issues/3494298 🐛 The "group_content_type" entity type does not exist error after upgrade from v2 to v3 Active seems to fix the uninstall page issue and replaces the group_content_type references in the group_relationship.field_storage_definitions key_value table entry, but I'm still seeing group_content_type references in the the group_relationship_type.entity_type entry @ljwilson shows in #2..

I create a MR with the required Drupal 11 changes.

It would be nice to get an official published release of the module as well.

pcate → created an issue.

I applied MR #5 and after running the upgrade status module scan is showed the module as Drupal 11 compatible.

The rector patch applied cleanly and after running the upgrade status module scan on the module, it showed the module as Drupal 11 compatible.

I applied patch #4 and ran the upgrade status module scan on the module. The following errors were found affecting Drupal 11 compatibility.

2 errors found.

modules/contrib/layout_builder_block_sanitizer/src/LayoutBuilderBlockSanitizerMa
nager.php:
| 115  | Call to deprecated method get() of class
Drupal\layout_builder\SectionComponent. Deprecated in
drupal:10.2.0 and is removed from drupal:11.0.0. Additional
properties should be gotten via ::getThirdPartySetting().
 |
| 136  | Call to deprecated method get() of class
Drupal\layout_builder\SectionComponent. Deprecated in
drupal:10.2.0 and is removed from drupal:11.0.0. Additional
properties should be gotten via ::getThirdPartySetting().

The MR applies cleanly and after running the upgrade status module scan the module shows are being Drupal 11 compatible.

Setting to RTBC. The MR applied cleanly and running the upgrade status module scan on the module shows it Drupal 11 compatible.

@danflanagan8 can we get a new release with this change?

Fixed broken images in issue summary. For some reason the did not save previously.

I added before/after screenshots to the issue summary and created a draft CR.

Neither the patches or the MR are applying for me with Group v3.3.x and the 3.x branch of gcontent_moderation module.

Patch #14 worked for me with the latest 9.1.2 version of the module.

Looks like the issues in #9 and #10 are related to using multiple patches. I tested just the #2 patch again with the latest 9.1.2 module version and it appears to be working correctly.

I added the #2 patch to the existing MR in case it is more helpful.

@sagarmohite0031 I apologize, the field input actually is under the row class input. It used to be at the bottom of the modal form, but I forgot it was moved.

I manually tested the MR again with both 10.4 and 11.1 and everything still appears to be working, including see the field input.

@sagarmohite0031 the new CSS class form field should be at the bottom of the table style options form modal. Your screenshot does not show this.

See @dalemoore screenshot in #26 as an example.

The test failure was with a unrelated core module. Merging in latest 11.x changes included a fix. Tests are now passing.

After apply the MR to Drupal 11 site install, be sure to run database updates (drush updb) and clear caches. After applying MR and updates, when you export configuration you should see the schema changes for any views that use a table style.

After applying the latest MR to the 3.x dev branch and runing the Upgrade Status module it shows the following issue:

File name: modules/contrib/gcontent_moderation/tests/modules/gcontent_moderation_test/src/GroupStateTransitionValidation.php

Line: 96

Error: Call to deprecated method loadRevision() of interface Drupal\Core\Entity\EntityStorageInterface. Deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Use Drupal\Core\Entity\RevisionableStorageInterface::loadRevision instead.

Rector patch applied cleanly and after running Upgrade Status module → it shows are Drupal 11 compatible.

Rector patch applied cleanly and after running Upgrade Status module → it shows are Drupal 11 compatible.

Patch #4 ( https://www.drupal.org/files/issues/2024-10-31/new_relic_rpm-3433555-4_0... → ) applied cleanly and after running Upgrade Status module → it shows are Drupal 11 compatible.

Rector MR #3 applied cleanly and after running Upgrade Status module → it shows are Drupal 11 compatible.

Rector patch applied cleanly and after running Upgrade Status module → it shows are Drupal 11 compatible.

Rector patch applied cleanly and after running Upgrade Status module → it shows are Drupal 11 compatible.

Rector patch applied cleanly and after running Upgrade Status module → it shows are Drupal 11 compatible.

So with addition of upgrade path will need a test for the that hook.

I've added a db schema upgrade test.

pcate → created an issue.

+1 RTBC

I ran into this error when syncing between different environments after adding the module. Patch fixed issue.

@kristiaanvandeneynde I just ran a test upgrade from v2 to v3 with this MR and it resolved the error.

Any language.content_settings.group_content.* config files were also not updated. Some of those include the ones with hashed ID's so I'm not sure if updating the language config files needs to be part of the update hook to prevent config dependency errors.

Doing a test upgrade from v2.3.1 to v3.3.2 I ran into this same error.

+1 RTBC. Patch resolves error on /admin/config/services/jsonapi page.

The failing test may be caused by the Twig version, the composer job log shows twig/twig (v3.14.1) which has a timeout problem, and woud cause the problem of not finding expected elements on the form. The previous pipeline on this MR had (v3.14.0) which does not have the problem.

Yeah, looks like that was the problem. I re-ran the composer build stage and that installed twig/twig (v3.14.2). Tests seem to be passing now.

@smustgrave I went ahead and tried running all the module tests locally with the latest 3.x dev branch. The LayoutBuilderTest functional test always failed for me, and all the other tests passed, with and without this issue's MR changes added. The new FormDisplayWeightTest test always passed for me with the MR changed applied.

Below is the error from the failing LayoutBuilderTest test. I get the same error when I ran just the LayoutBuilderTest test by itself.

Testing /var/www/html/docroot/modules/contrib/scheduler_content_moderation_integration
....................E...............................              52 / 52 (100%)

Time: 06:39.901, Memory: 8.00 MB

There was 1 error:

1) Drupal\Tests\scheduler_content_moderation_integration\Functional\LayoutBuilderTest::testLayoutBuilder
Behat\Mink\Exception\ExpectationException: Current response status code is 500, but 200 expected.

/var/www/html/vendor/behat/mink/src/WebAssert.php:888
/var/www/html/vendor/behat/mink/src/WebAssert.php:145
/var/www/html/docroot/modules/contrib/scheduler_content_moderation_integration/tests/src/Functional/LayoutBuilderTest.php:44
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:729

ERRORS!
Tests: 52, Assertions: 1356, Errors: 1.

I did also got the following deprecation notice when running the tests:

Remaining self deprecation notices (1)

  1x: system_time_zones() is deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. This function is no longer used in Drupal core. Use \Drupal\Core\Datetime\TimeZoneFormHelper::getOptionsList(), \Drupal\Core\Datetime\TimeZoneFormHelper::getOptionsListByRegion() or \DateTimeZone::listIdentifiers() instead. See https://www.drupal.org/node/3023528
    1x in LayoutBuilderTest::testLayoutBuilder from Drupal\Tests\scheduler_content_moderation_integration\Functional

Would a test fail because of the deprecation notice?

I ran all the modules tests about a half-dozen times with the same results.

I ran into a similar issue adding this option would help fix.

We have a content type that has publish immediately on save if the date is in the past, with the change the created date option disabled. Because the changed date is set to the scheduled published date, but the created date isn't changed, the changed date is actually before the created date.

For instance:
Scheduled for publish on 10/20/24.
Run scheduled on 10/22/24.
Changed date is 10/20/24 (timestamp equivalent)
Created date is 10/22/24 (timestamp equivalent)

Per #13 → I added a functional test to confirm the field weight reset fix.

Branch seems to have failing tests but don't appear to be related.

I've also ran into this issue when trying to upgrade from v2.3 to v3.3. I can also confirm that upgrading from v2.2.2 to v3.3 does not run into this error.

Using existing views update hooks as examples I tried adding an update hook for the table CSS class schema change. I also added the update hook task to the list of remaining tasks.

Is there any documentation on how to write config update hooks for views? My understanding is that it is different than regular update hooks?

When I ran into this I manually added back the variationcache module via composer so the module could then be uninstalled.

I just ran into this error when loading a view block on Drupal 10.3.5. Layout Builder is not used on the site, the block was added via the regular block layout page. The big pipe placeholder element is rendered on the page but the error prevents it being replaced with the actual content.

The MR resolved the error and loaded the block fine.

I want to keep the twig function as close to the PHP one it uses as possible. Comment #3 has an easy way to work with nullable values.

@darren.fisher I just released 2.1.0

@jcsparks, the fix hasn't made it into a new release of the scheduler module yet. You'll either need to install the dev version of this module (which has the fix) or use the MR in this issue. Whether you're using Drupal core 10.3 or 10.2.7 shouldn't matter.

Ran into this issue after upgrading to 2.0.4 on a site. The MR/patch fixed the issue.

What was the scenario that you had which led to the fields not being in the form?

For me it was showing on content types that only showed the published or unpublished form elements, but not both. So for instance on content types configured to only allow publishing but not unpublishing, or vise-versa.

Setting to "Needs Review". I added a functionality test to confirm functionality is working, and I also tested manually.

It does appear the table style config schema needs to css class option added. The test I added was failing without it. Updated issue summary to reflect this.

I've made an initial conversion of @dieuwe #10 patch to a merge request.

@smustgrave I've updated the issue summary to follow the standard template.

This issue I think is the same as https://www.drupal.org/project/paragraphs_limits/issues/3200895 🐛 Undefined index: handler_settings in Drupal\paragraphs_limits\Plugin\EntityReferenceSelection\ParagraphsLimitsSelection->buildConfigurationForm() Fixed . Unfortunately the fix in that issue never made it in the alpha5 release. Do you see the error which the latest dev version?

How is that related to Gin?

So I guess that was an assumption on my part since I'm using the Gin admin theme and Gin has twig template overrides for some date related elements such as datetime-wrapper.html.twig, as well as other form customizations.

I just tested adding a custom attribute to the data input as well. In that case it is added to the date input and .form-datetime-wrapper parent div, but not the .form-items-inline parent div.

<div class="field--type-datetime field--name-field-test-upload-date field--widget-datetime-default js-form-wrapper form-wrapper" data-drupal-selector="edit-field-test-upload-date-wrapper" id="edit-field-test-upload-date-wrapper">
   <div data-test-id="DATA-TEST-ID" data-drupal-selector="edit-field-test-upload-date-0-value" class="form-item form-datetime-wrapper">
      <h4 class="form-item__label">Test Upload Date</h4>
      <div id="edit-field-test-upload-date-0-value" data-drupal-field-elements="date" class="form-items-inline">
         <div class="js-form-item form-item js-form-type-date form-type--date js-form-item-field-test-upload-date-0-value-date form-item--field-test-upload-date-0-value-date form-item--no-label">
     
            <label for="edit-field-test-upload-date-0-value-date" class="form-item__label visually-hidden">Date</label>

               <input data-test-id="DATA-TEST-ID" data-drupal-selector="edit-field-test-upload-date-0-value-date" type="date" placeholder="YYYY-MM-DD" data-help="Enter the date using the format YYYY-MM-DD (e.g., 2024-06-10)." id="edit-field-test-upload-date-0-value-date" name="field_test_upload_date[0][value][date]" value="" size="12" class="form-date form-element form-element--type-date form-element--api-date">
          </div>
        </div>
    </div>
</div>

PCate → created an issue.

The #8 patch resolves the issue. The change in use statement appears to be all that is needed.

If @jonathan1055 in #7 is correct when the change was made in the parent scheduler module, I think this patch effectively now makes the module require version 2.0.2 of the scheduler module.

Is that considered a BC? Should the composer.json be updated to set that as the minimum scheduler module version?

I'm happy to convert the patch to a MR with changes.

I've experienced that after the update, to fix it, what I did, is to enable each content type into the container configuration to get it working again.
IMO, this should work in the opposite mode, by default all content types should print the gtm tag, and only use the config to exclude the ones we want to not use gtm.

Thank you @Diego Sabolo!!! We were banging our heads trying to get this to work and this was the solution. I completely agree that the default should be to add to all content types and any checked content types should then be excluded.

@jurgenhaas the patch applied cleanly and resolved the issue.

PCate → created an issue.

I guess, most of the "tokens" are read-only and a few (e.g. "row") might be modifiable, right?

@jurgenhaas, I would expect the "pre/save" events would have modifiable tokens, but the "post/delete" ones would not?

@jurgenhaas below is the list of relevent tokens/events.

PCate → created an issue.

Add nullable possibility for base64Encode.

The base64_encode filter is a thin wrapper around the base64_encode php function: https://www.php.net/manual/en/function.base64-encode.php

Starting with PHP 8.1 passing null to non-nullable functions like base64_encode is deprecated.

You can use the string filter provided by the module to avoid this issue:

{{ null|string|base64_encode }}

Fixed the property name in the MR. Setting back to needs review. Also, this started showing when I updated to PHP 8.2.

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

@msn5158 thanks for providing the additional debug information.

Can you try:
{% set dict2 = '{"44":"test"}'|json_decode(true) %} {# for twig_tools module #}

The json_decode filter is just a wrapper around the PHP json-decode function. By default the function returns a JSON object as a PHP std object. By passing in the true option it will instead return it as an associative array.

This is documented in the module's doc page: https://www.drupal.org/docs/contributed-modules/twig-tools/conversion-fi... →

Do wonder what others thoughts are on
$('.ui-dialog-off-canvas') to $('.ui-dialog-off-canvas')[0]
To me that reads worse but will defer to the community, there are a number of issues in review like that.

An alternative would be using the .first method: $('.ui-dialog-off-canvas').first() or using array destructuring: const [dialog] = $('.ui-dialog-off-canvas')

Can you post what the var dump of testbamboo.field_jsondata.value is?
Are any watchdog errors being thrown? They may have more information.

@msn5158 I'll need more information to debug further.

{% set testbamboo = bamboo_load_entity('node', 1) %}
{% set jsonbamboo = testbamboo.field_jsondata.value | json_decode %}

{{ jsonbamboo.key }}

• What field type is field_jsondata?
• Can you post what the var dump of testbamboo.field_jsondata.value is? You may not be accessing a string value.
• Are any watchdog errors being thrown? They may have more information.

@jurgenhaas happy to help if I can. Would something like the following be helpful?

Name: migrate.pre_import
Description: Fired when beginning a migration import operation.
Tokens:
migration: The migration entity being run.

Name: migrate.idmap_message
Description: Fired when saving a message to the ID map.
Tokens:
migration: The migration entity being run.
source_id_values: The source ID values.
message: The message to be logged.
level: The severity level of the message.

If this is the information you are looking for, I should be able to provide a list of these.

Hovering over labels displays the pointer cursor, while clicking focuses on text boxes or checks boxes.

It is common for form labels to be styled to display a pointer cursor when hovering over them to give a visual indicator that the labels are interactive. Form labels with a for attribute should be interactive.

However, the pointer cursor should be limited to specific label elements, rather than being displayed universally across the site

What is the criteria for whether a label should use the pointer cursor? Is this documented somewhere?

Right now Claro is showing the pointer cursor for elements with the .form-item__label class and a for attribute. Are you seeing this class and attribute being added to non-label form elements?

I'm seeing the same CSS for form labels is in the core Olivero theme as well.

do not display a cursor pointer when a checkbox toggle is not present, aligning with Drupal coding standards

@djsagar, can you provide a link to the Drupal coding standards where this is stated?

Is this a duplicate of: https://www.drupal.org/project/drupal/issues/3413079 🐛 Cannot read properties of null (reading 'nodeType') on node.page.body RTBC ?

I made a MR of patch #2 for convenience.

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

@kristiaanvandeneynde the patch worked great! I was able to upgrade to 10.2 and install the site from configuration.