I Just Want to Edit a Node!

 

These are my notes from a talk at DrupalCon Denver given by Robin Barre @RobinBarre and Steve Persch @stevector.

At Palantir, we've developed a suite of modules called Workbench for Drupal 7. It aims to ease some of the pain points for content authors. Authors can see an overview of content they created and other active content on the site at the moment. Depending on your needs, you can customize the workbench page to suit your needs. We also have Workbench Moderation, which helps you move content between workflow states. We've been living in the Drupal 7 contrib world, and as we worked on Workbench we found some areas for improvement.

Workbench Moderation addresses two main questions: workflows, as well as forward revisions. Forward revisions have to do with a currently-published version of a node, but you still want to work on that node and publish that new version later.

Many modules do a mix of workflow and forward revisioning.

  • Entity Revision Scheduler
  • Maestro
  • Revisioning
  • State Machine
  • Workbench Moderation
  • Workflow

Each of these modules have to struggle with how core does node saving. In our case, we want the revision to go through all the save hooks, except we don't want it to change what is currently displayed.

Drupal 7

Drupal 7 does something like this:

  1. node_save($node)
  2. Write to {node}
  3. Write to {node_revision}
  4. Wait, was that the "published" vid?
  5. No? Call node_save($published) in hook_exit or shutdown.

In this case, you get two node_save calls, even if you're saving an unpublished revision. Any event that is revisionable can cause us to jump through these hoops again.

Drupal 8

In Drupal 8, we're hoping to simplify this. When node_save is called, save the revision first along with any revisionable data. At that point, ask if the revision is supposed to be public, and if so, write to the node table. This may impact some of our hooks.

As far as the UI, we can replace "Preview" with "Save Draft." Quicksketch suggested that ctools object cache can fulfill a similar objective.

What happens to the code? I imagine we would clean up node_save and add or change some of the hooks. For example, maybe we could have a hook for the step of writing to the node table? For example, perhaps path or pathauto doesn't want to operate on a node revision until it is going to be published.

Workflow could stay in contrib, but it could be in core. Complications include the definition of workflows, and how workflows work across entity types. Is state an entity, and how do we handle related fields?

We're doing a workflow sprint on Friday where you can check out the work that has been underway to Workbench Moderation.

Q: I have a question about the delete button. I've had issues with people deleting things they didn't mean to delete.
A: Us too! Since we've been modifying the node edit form to make it seem like they're editing a revision, clients will press the button thinking it's deleting the revision but they delete the whole node. It's a problem!

Q: Doesn't your button suggestion hard-code the concept of "published," which doesn't apply to every project? (asked by @crell)
A: I see this as a replacement for the 'Published' checkbox.

Q: Would this be easier if we switched from CRUD to CRAP, where we remove the update command and move to add revision and promote revision?
A: I think that works with the idea of prioritizing saving of the revision. It fits the CRAP model.

Q: I wish the delete button just posted a new revision that says "This node has been deleted!"
A: Yeah, and I think this is a permission issue, where maybe the admin can delete the node, but a lower-level user only has the ability to save an empty draft. A state beyond publish, perhaps called "archived," that's still around but isn't available for the public to view.

Q: You have "Save as Draft". I think "Preview" is important as a button label.
A: I'd be find with keeping the text as "Preview" but from my understanding of the problem, it would be better if the "Preview" button actually saved a new version of the node.

Q: Should fields be revisionable entities?
A: Good question. I think with Field Collections you can wrap your field in a collection and get the idea of the field being revisionable (there is a patch to make them like that.)

Q: What about autosave?
A: I've thought about it. I don't have a great answer beyond what's already available in contrib. There are autosave and content locking modules. Whether they're the best solution, I really can't say.

Did you enjoy this post? Please spread the word.