Contrib.social

Disable fields in form displays by default

Open on Drupal.org →
Created on 10 November 2022, over 2 years ago
Updated 17 May 2023, almost 2 years ago

Historically when the scheduler publish_on or unpublish_on fields are not wanted in an entity edit form they are removed (unset) in the entity hook_form_alter(). But now, due to the plugin functionality, a wider variety of forms can display the entities and this method of removing the fields is becoming onerous. A new way of doing this would be to have the fields added/removed in the form display depending on whether scheduling is enabled.

I have run the db update and got this message. What do I need to do now?

In almost all cases - nothing! The scheduler field(s) will appear in the form displays for entity type bundles that are enabled for scheduling, and will be disabled in form displays for bundles that are not enabled. If you change the scheduler publish or unpublish setting then the field will be automatically enabled or disabled to match.

The only scenario where you need to do anything manual now, as a one-off, is if you had previously manually disabled a scheduler field even though the entity bundle is enabled for scheduling. This is an unusual thing to do, as there are other ways to hide the field(s), for example by implementing one of the scheduler 'hide' hooks, e.g. hook_scheduler_hide_publish_date() or hook_scheduler_{type}_hide_publish_date(). If you want to hide a scheduler fields but cannot implement one of these functions, then you can manually disable the field, either by dragging it to the 'disabled' section of the display, or by changing the region dropdown to 'disabled'.

What does all this information mean?

It simply shows you which entity bundles now have the scheduler fields enabled. For completeness it also lists which entity bundles do not have the fields shown. If you have any problems, please open a support request issue.

My site built with a custom install script no longer shows the Scheduler fields

If you have a drush script to make/reset a test site, or perform configuration, you may have previous enabled Scheduler for an entity type/bundle by using, for example drush config-set media.type.document third_party_settings.scheduler.publish_enable 1. This would have been enough to have scheduled publishing working for media documents on your site. But now, you will need to run the extra step to make the required form fields visible (to mimic what is done in the admin UI). The function can be execute via drush, and this will align all scheduler form fields to match the enabled/disabled setting on the entity bundle:
drush php-eval "\Drupal::service('scheduler.manager')->resetFormDisplayFields();"

Tasks / Plan

  1. When Scheduler is installed set all the fields to be disabled in each form display [done]
  2. When a module with a plugin is enabled, set the fields to disabled by default in all form display modes [done]
  3. When scheduling for an entity is enabled or disabled via admin/structure/{entity_type} adjust the display fields [done]
  4. Add the concept of supported display modes in the Scheduler plugin, and implement entityFormDisplayModes() in SchedulerPluginBase [done]
  5. When a subsidiary module is installled after Scheduler that adds a new form display which is supported by Scheduler, replicate the current settings of the default display [follow-up later]
  6. Add a hook_update() function to adjust the existing form fields to match the enable/disable scheduler settings [done]
  7. Add more complete test coverage for the new functionality [follow-up later]

The existing hook_form_alter processing to remove fields will remain. The new processing is for extra safety and consistency, and to prevent more issues with fields appearing on forms when they should not be shown.

📌 Task
Status

Fixed

Version

2.0

Component

Plugin

Created by

🇬🇧United Kingdom jonathan1055

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment almost 2 years ago →
    🇨🇦Canada m4olivei Grimsby, ON

    Hey there. Arrived here from update hook output. I appretiate the effort here to explain whats going on.

    I ran into, what I think is an unintended consequence of the update hook here, (scheduler_update_8208). On the site I'm working on, we're updating scheduler and scheduler_content_moderation_integration to the latest D10 compatible release, which is 2.0.0-rc8 and 2.0.0-beta1 respectively. Both are being updated from 8.x-1.3. We have ... a lot of content types (236 .. I know .. wasn't me ... 😬). We also have 14 form display entities defined for nodes. At the end of the update hook, we end up with 236 * 14 = 3304 new config entities, eg. core.entity_form_display.node.<bundle>.<form_display>.yml, which before the update hook we didn't have.

    Perusing and stepping through the code, I think there is something off with the logic that attempts to remove the scheduler fields when a bundle is not enabled for scheduler (https://git.drupalcode.org/project/scheduler/-/blob/2.0.0-rc8/src/Schedu...):

    // If this bundle is not enabled for scheduled (un)publishing or the
// form display mode is not supported then remove the field.
if (!$bundle->getThirdPartySetting('scheduler', $setting, FALSE) || !in_array($display_mode, $supported_display_modes)) {
  $form_display->removeComponent($field)->save();
  if ($display_mode == $display_repository::DEFAULT_DISPLAY_MODE) {
    $fields_hidden[$field]["{$bundle->getEntityType()->getCollectionLabel()}"][] = $bundle->label();
  }
}

    Specifically, this code does not consider that the $form_display object here may be new, and therefore, may be able to be skipped. However, the line $form_display->removeComponent($field)->save(); will remove a component it doesn't have (b/c it's new) and then save it, which actually creates it for the first time. I don't think this is intentional. I think any $form_display that is new should be skipped.

    In our (albeit edge) case, it produces a boat load of form_display entities that we don't want or need. So many, that some CI jobs are blowing up with memory errors (pre-prod, nothing is on fire 😛).

    Working on firming up the above theory and potentially filing an issue / patch. Any insight would be helpful, I'm not terribly familiar with this module.

  • Comment almost 2 years ago →
    🇨🇦Canada m4olivei Grimsby, ON

    Opened 🐛 Many unwanted entity_form_display entities created when updating to 2.0.0-rc8 Fixed to follow up with the above. Will need a similar issue for scheduler_content_moderation_integration since it runs a similar update hook that is problematic as well.

  • Comment almost 2 years ago →
    🇨🇦Canada m4olivei Grimsby, ON
  • Comment almost 2 years ago →
    🇬🇧United Kingdom jonathan1055

    Hi m4olivei,
    Thanks for reporting this and for taking the time to explain your scenario.
    Will continue the discussion on the new issue.
    Jonathan

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024