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

[Thoughts] Allow more comprehensive customization of edit screens, for better workflow/drafts handling #6687

Closed
wsydney76 opened this issue Aug 20, 2020 · 3 comments
Labels
enhancement improvements to existing features

Comments

@wsydney76
Copy link

Had the opportunity to wrap up and review all the stuff we have done around handling drafts and workflows. So this is not
a concrete FR, just didn't want these thoughts to get lost before i finally disappear into retirement (big thanks to @brandonkelly and the team for the great product and all the support on this occasion).

The main takeaway is that requirements are very different from project to project, from team to team, from section to section, even between different entries, different permissions, making it impossible for any CMS to deliver such experiences out of the box.

So beyond the crystal clear default behavior we will see in the next Craft releases (i'm sure ...), it's all about giving custom modules/plugins the opportunity to tailor different aspects of the editing screen.

For example the most accepted workflow in our projects is a very strict one, trying to avoid conflicts/inconsistencies between drafts/current or site-specific entries:

  • Do not allow a current entry to be edited and saved: disable fields, disable save buttons (main reason is to avoid
    inconsistent translations)
  • Do not allow to enter preview from a current entry: disable/hide preview button (do not create drafts by accident)
  • Do not allow to create a draft if one already exists: disable/hide 'create draft button' (avoid conflicting drafts)
  • Do not allow to publish a draft in certain scenarios (depending on custom status fields, or the entry should not be
    published on its own, but by a custom functionality publishing all drafts belonging to a 'Change Set' at once. )
  • Change button labels...
  • For translators: Disable all input fields that are not translatable (dreaming of also displaying the content to be translated)
  • Add a help modal explaining the available actions to the user
  • Add a custom permission for certain users to ignore all these rules, just in case...

In other projects this will not fit at all, but there seem to be common settings: allow/disallow actions, disable input fields, change texts, add hints)

All of this is currently done with hacky JavaSript/CSS/Event listeners by unscrupulous developers, always in danger to break in future releases.

What would have helped us the most, would be some kind of event based functionality, like EVENT_DEFINE_EDITOR_BEHAVIOR (ups, behavior is ambiguous), enabling a custom module to define the desired behavior:

  • Hide/disable actions
  • Add buttons pointing to custom controller actions
  • Change button texts
  • Add a notification area with help infos for the editor
  • Disable all/a list of field inputs
  • Disable editing via HUD (as this does not support draft handling)
  • to be continued

Add some JavaScript functions like .hideAction('save') or .setText('publish', 'your text here')

Suggesting an event instead of a static configuration, as the current state of an entry and the permissions of the current user
can lead to different settings.

PS.
May be a good idea to add some fancy UI though, as all of the above is probably out of scope for smaller projects.

@wsydney76 wsydney76 added the enhancement improvements to existing features label Aug 20, 2020
@Anubarak
Copy link
Contributor

Just my two cents: while you are totally right and have some good points, most of that can already be done without custom css hacking via PHP. There are certain events that allows you to do that (plus DI container for the win) its just not that obvious

@brandonkelly
Copy link
Member

brandonkelly commented Aug 26, 2020

Appreciate all the feedback! However there’s just too much here for us to be able to address in any one commit, so I’m going to close it. Feel free to keep the discussion going here or in the linked issues below, or post new issues focussed on a single feature request at a time.


Related requests: #829, #2029, #5661

Do not allow a current entry to be edited and saved: disable fields, disable save buttons (main reason is to avoid
inconsistent translations)

This is provided by the “Publish entries” and “Publish other authors’ entries” permissions. Unless you are saying you want authors to be allowed to publish – just only from a draft.

Do not allow to enter preview from a current entry: disable/hide preview button (do not create drafts by accident)

Alternatively, maybe #6681? (request to treat drafts created by Live Preview as ephemeral, until the “Save as a draft” button is explicitly clicked)

Do not allow to create a draft if one already exists: disable/hide 'create draft button' (avoid conflicting drafts)

I’m pretty sure there was a request at some point for Edit Entry pages to load the last-edited draft by default, but I can’t find it now. I wonder if that would help here? As well as the ability to merge nested Matrix changes so there’s less chance of drafts overwriting each other in the first place (#5503).

Do not allow to publish a draft in certain scenarios (depending on custom status fields, or the entry should not be
published on its own, but by a custom functionality publishing all drafts belonging to a 'Change Set' at once. )

This will be solved when we add advanced workflow and governance features (#829).

Change button labels...

Can you elaborate on that please?

For translators: Disable all input fields that are not translatable

See #947.

Add a help modal explaining the available actions to the user

The Guide plugin does a great job with this. Also see the new UI elements feature we’ve added to field layout designers in Craft 3.5, which can be used to show helpful instruction outside of field instructions.

@wsydney76
Copy link
Author

Unless you are saying you want authors to be allowed to publish – just only from a draft.

Yes. The reason is that just updating a current site having non translatable fields or matirx fields set to 'publish block to all sites...' will potentially create inconsistent content on other sites. Will add a FR for that.

Change button labels... Can you elaborate on that please?

That's basically #5661 (comment)

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

No branches or pull requests

3 participants