Mark and Leisa designed their node edit form to include a "Save draft" and a "Publish" button. Their design has the Publish button more prominent (in part due to autosave happening in the background, which is to be implemented in another patch :). However, this patch just adds direct "Save draft" and "Publish" buttons. These have the distinct functionality of setting the published flag accordingly. Also, the Publish button updates the publishing date at the same time (something Drupal people often forget). Once the node is published, these buttons will not show up but the regular "Save" button will appear which works as before. If the node is unpublished via the checkbox later, the Save draft and Publish buttons will appear again and work as before (including the setting of the date).
This approach was inspired by the blogaid module, which has a similar implementation but with different button text. Now this maps pretty well with the D7UX work. Let's discuss this approach!
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | contentwireframe.jpg | 42.35 KB | gábor hojtsy |
| #1 | contentunpublished.jpg | 33.48 KB | gábor hojtsy |
| #1 | contentpublished.jpg | 27.24 KB | gábor hojtsy |
| save-as-draft.patch | 2.63 KB | gábor hojtsy |
Comments
Comment #1
gábor hojtsyAlso, we should discuss the permissions connections of saving as draft and publishing. Before this patch, "Save" worked as draft saving for users without the node admin permissions, if the default workflow option was unpublished, while it worked as a Publish button for users when the default workflow was to publish. With the patch, users are exposed to both options regardless. That should still be solved. Should we hide the Publish button if the default workflow is to save as draft, but the user has no node admin perms? Same for the draft button if the user has no admin privs and workflow is to publish by default?
Also, should we apply this button layout for certain node types only? Saving forum posts as drafts might not be a good idea.
Many users do not have any way to list their unpublished/draft nodes ATM, so what if they publish their node profile, forum post or advertisement as draft? How can they review and edit/publish those?
Also, other parts of Drupal use the terminology "unpublished". Should we rename all unpublished to "draft"? Unpublished is obviously more generic, since it applies to stuff which was unpublished due to abuse, inappropriate content, etc. Those are not "drafts" in a philosophical sense, right?
Attached are images on how this looks on the MBD mockups and with the patch.
Wireframe:
Buttons with patch on yet unpublished nodes:
Buttons with patch on currently published nodes:
Comment #2
dries commentedPersonally, I always wanted to have a Save as draft feature in Drupal, especially for use on buytaert.net, but also for the announcements that I write on drupal.org. I see it being useful on every Drupal site that I publish on and welcome this feature. In fact, we've been discussing a Save as draft for years now. Either way, combined with a "auto save as draft" feature, I think it would be stellar and very Google Docs or GMail alike. Added it to my favorites!
On Drupal blogs, like buytaert.net, that should make the Save as draft feature available to the blogger because they typically have administrative rights. On Drupal forums, it would mean that most people don't see the button which I think is desirable too. It seems to work and degrade well in all possible scenarios. We can do something more fancy in the future but for now the approach I outlined seems perfectly defensible.
As you know, the form API allows you to do access control at the form element level. This means you'll probably have to split the handler in two handlers; one for each of the buttons ... I wonder what that means for contributed modules that tap into the publishing workflow (e.g. would Mollom (have to) fire on both handlers?). I think this is a non-issue but I figured I'd bring it up.
+ $form_state['values']['status'] = 0;Instead of using integers we should start using constants/defines.Comment #3
gábor hojtsy1. Agreed that we can go with just putting this out for people, who have the permission to see unpublished posts.
2. I am positive on adding a third state. On Drupal.hu, we also have problems on distinguishing the "new and to be reviewed" content and the "unpublished for good reasons" content. Introducing this third status for nodes would extend the default workflow capabilities of Drupal. Also, this would affect all node permission modules, node listings, etc. Anyway, we can expect that on a major Drupal version upgrade :)
3. yup :)
4. Right.
Comment #5
damien tournoud commentedThis seems like a duplicate of #282122: D7UX: "Save draft" and "Publish" buttons on node forms.
Comment #6
gábor hojtsyIndeed, that patch has much of what is done here. Moving discussion there than.