The Publish and Unpublish state fields render outside of the scheduling options fieldset when certain conditions are met

I'm encountering the same issue. In addition to the two fields moving to the bottom of the page, in my case the whole sidebar moves to the bottom of the page. It depends on the version of Gin theme I'm using though: on an older version, just the theming of the sidebar changes, on the latest version the whole sidebar moves to the bottom of the page. This doesn't happen when using Claro though, so it might be related to Gin, but at the same time I feel like the two issues are connected in some way.

@Rick Bergmann can you check if the changes in #3270462: Set a default value in the publish / unpublish state dropdowns → fix your issue?

@DieterHolvoet Thanks for the recommendation, I tried to install that MR as a patch but it fails to apply on version 2.0.0-beta2. I can add a comment in that issue with the errors if that's helpful?

@DieterHolvoet I tried a different patch which does apply (the one from comment 25). Now the Publish / Unpublish state select fields are not displaying at all now. I guess they are meant to be hidden and their value should be the current workflow state, is that the case. If it is, then yes it looks like that patch fixes the issue.

@DieterHolvoet after some more testing, I see the `Publish state` dropdown appears once I have selected a schedule date, however the issue still remains when validation fails, the Publish state select field still re-renders outside of the Scheduling options section.

Okay, in that case that issue might not be related. Meanwhile, I also figured out that my issue is related to the Gin theme 🐛 Certain form validation errors make the sidebar move to the bottom of the page and the form operations disappear Active , so I'm afraid I can't help you here.

Fixes will need to be against 3.0.x

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.

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.