Make form group optional

Created on 24 January 2023, over 1 year ago
Updated 17 August 2023, 11 months ago

Problem/Motivation

The option to make content private is moved into a vertical tab group.

Let's make this optional, so we can choose to display it next to the published field.

✨ Feature request
Status

Needs work

Version

2.0

Component

Code

Created by

🇺🇸United States mortona2k Seattle

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

Sign in to follow issues

Comments & Activities

  • Issue created by @mortona2k
  • @mortona2k opened merge request.
  • Status changed to Needs review over 1 year ago
  • 🇺🇸United States mortona2k Seattle

    I added a field setting, and check it before moving the field into the form group.

    I found this issue, which seems somewhat related: https://www.drupal.org/project/drupal/issues/2190333 📌 Make #group FAPI / render feature work on all form/render #types out of the box Needs work .

  • 🇮🇳India Jaspreet-Kaur

    Reviewed MR! 1 on Drupal 9.5.x and it worked for me. Thanks!

  • Status changed to RTBC 11 months ago
  • 🇨🇦Canada joseph.olstad

    RTBC based on comment #4

  • 🇬🇧United Kingdom AdamPS

    This module is marked on the project page as "Maintenance fixes only: considered feature-complete by its maintainers." This means that in most cases I would not accept patches for new features. The main advantage of this module over the more popular node_access is that it's simple and has minimal code.

    In this case there seems to be an easy solution for those who don't want the form group: write a hook_form_node_form_alter() containing a single line of code to unset the group. So I propose this is "Won't fix" - any comments?

    Other general points: adding a setting would need a schema change and an update hook to fix existing widgets. New features would anyway need a test. Before setting RTBC, there should be a green test pass.

  • 🇨🇦Canada joseph.olstad

    @AdamPS, I like the above patch because it's optional behavior, adding it in changes nothing provided the default matches the existing behavior.

    With that said, I haven't tested the patch myself but I think it's a great addition and would certainly make sense even with a simple solution as we currently have.

    I'd say, tag a release, and then after the tagged release put this into the dev branch to give people time to provide some feedback so that by the time we tag the next release it'll be well vetted.

  • 🇨🇦Canada joseph.olstad

    @AdamPS, I don't think a schema change is necessary for a default to value that when is not set keeps the current behavior. I'd have to test out the patch a bit more to say but that's why I'm suggesting the dev branch after a tagged release, would make it easier to get widespread feedback and improvements having it in the dev branch after tagging the current build without this change.

  • Status changed to Needs work 11 months ago
  • 🇬🇧United Kingdom AdamPS

    OK, I'm open to doing it.

    It would definitely need a test for the new feature, and I'm pretty sure this would then cause an error that would need a schema change to fix. The update hook is needed to set the value for existing sites.

Production build 0.69.0 2024