-
Notifications
You must be signed in to change notification settings - Fork 640
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
Comments
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 |
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
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.
Alternatively, maybe #6681? (request to treat drafts created by Live Preview as ephemeral, until the “Save as a draft” button is explicitly clicked)
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).
This will be solved when we add advanced workflow and governance features (#829).
Can you elaborate on that please?
See #947.
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. |
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.
That's basically #5661 (comment) |
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:
inconsistent translations)
published on its own, but by a custom functionality publishing all drafts belonging to a 'Change Set' at once. )
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:
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.
The text was updated successfully, but these errors were encountered: