Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node default values ignored if 'Show option...' disabled #3800

Open
ghost opened this issue May 20, 2019 · 3 comments
Open

Node default values ignored if 'Show option...' disabled #3800

ghost opened this issue May 20, 2019 · 3 comments

Comments

@ghost
Copy link

ghost commented May 20, 2019

Description of the bug
If you set a content type's "Show option to promote content" setting to disabled (meaning that option isn't shown on the node forms) but you set the "Promote content by default" setting to enabled, when you create a node it's not promoted.

The reasons I believe it should be promoted in this case are:

  1. The first setting is called 'Show option to promote content', nothing about enabling/disabling the next setting
  2. The 'Promote content by default' setting is always shown, regardless of the first setting (as a result of [UX] Remove the #states behavior from "Sticky", "Promote" and "Revision" options for content types. #1536)

The same is true for the Sticky and Revision settings. This is basically a follow-up issue to #1536.

Steps To Reproduce
To reproduce the behavior:

  1. Edit a content type and untick 'Show option to promote content' but tick 'Promote content by default'
  2. Create a piece of content of that type
  3. Check the frontpage (if set to 'node') or the database to see the value of 'promote'

Actual behavior
Content is not promoted.

Expected behavior
Content is promoted.


PR: backdrop/backdrop#2693

@stpaultim
Copy link
Member

stpaultim commented Feb 21, 2021

I was not able to test this, because the sandbox needs refreshing. I did confirm the problem on a fresh site and agree that the current state is not ideal. It could be made better in either of the following ways.

promote-content

  1. "Promote by Default" option is ONLY visible/possible if the "Show option to promote" option is checked.

  2. If the "Promote by Default" option is checked and the "Show option to promote" is not checked, then the content should always be promoted (If I understand correctly, this PR does this option).

At first I thought that option 2 would be redundant with the recent content block if everything was automatically promoted. But, then I realized that this is not the case, because different content types can have different settings.

It is completely plausible that a user might decided to allow the editor to choose to which post is promoted, but decide that all notifications should automatically be promoted (disabling the Show option to promote option).

Given that option 2 is a legitimate use case and that we apparently have a PR that implements that option, I would endorse option 2 (in agreement with @BWPanda ).

I will test once the PR sandbox is updated.

@stpaultim
Copy link
Member

One possible concern.

If implemented, does this mean that some content on existing sites that was not visible in the "Promoted Content" block will suddenly become visible in that block?

@ghost
Copy link
Author

ghost commented Feb 21, 2021

PR has been rebased, so Tugboat sandbox should be working now.

If implemented, does this mean that some content on existing sites that was not visible in the "Promoted Content" block will suddenly become visible in that block?

I'm not sure. The PR affects only the node forms as they're being prepared for editing. And the code in question is only being run if $node->promote is not yet set. So this may only affect new nodes... But I'm not 100% sure.

Also note that while we're talking a lot about the 'promote' setting, this issue and PR are addressing all settings that have a 'Show option...' setting (e.g. 'promote', 'sticky' & 'revision').

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant