Hi @scott_euser,
Can you please let me know the domain name of the site having the issue?
Drupal 11 compliant version (4.6.0) is now released.
We are currently working on Drupal 11 support and other bugfixes.
I think we will be able to release within the next couple of weeks.
On a second thought we could also rely on the `$form['publish_on']['#group']` (defined in scheduler.module) to retrieve the correct field_group key.
The scheduler group name defined in the scheduler module is variable, adding a numerical suffix to cope for situations where more than one entities exist in the form. Copying the corresponding code snippet from scheduler.module below:
// Create the group for the fields. The array key has to be distinct when more
// than one $entity appears in the form, for example in Media Library uploads.
// Keep the first key the same as before, without any suffix, as this is used
// in drupal.behaviors javascript and could be used by third-party modules.
static $group_number;
$group_number += 1;
$scheduler_field_group = ($group_number == 1) ? 'scheduler_settings' : "scheduler_settings_{$group_number}";
$form[$scheduler_field_group] = [
'#type' => 'details',
'#title' => t('Scheduling options'),
'#open' => $expand_details,
'#weight' => 35,
'#attributes' => ['class' => ['scheduler-form']],
'#optional' => FALSE,
];
// Attach the fields to group.
$form['publish_on']['#group'] = $form['unpublish_on']['#group'] = $scheduler_field_group;From the other hand scheduler_content_moderation_integration assumes that the scheduler group name remains the same (i.e. scheduler_settings). Thus when this changes the publish_state and upublish_stage fields are added in a group that doesn't exist.
The MR https://git.drupalcode.org/project/scheduler_content_moderation_integrat... follows the same approach as the scheduler module to fix this issue.
tper → made their first commit to this issue’s fork.
Hi @Sachbearbeiter,
Indeed we have tested and identified the issue. We are working to provide a proper fix.
Should the privacy policy change after a user gives consent, Cookie Control will invalidate prior records of consent and seek the user's preferences using the latest information available. Thus if a date in the future is configured in the statement updated date field, the widget will determine on every page load that the privacy statement is updated and launch the widget.
A possible fix for this in the drupal side will be to add a validator preventing saving if a statement updated date in the future is used.
Changing this to task to plan it accordingly.
I have tried reproducing this issue with no success.
Is this issue still valid? If yes can you please provide a url with the issue and/or steps to reproduce?
4.5.0 Version is compatible with drupal 10.
4.4.x Versions will not be updated for drupal 10.
4.5.x Versions are the ones that are already updated for drupal 10.