Port Workbench Moderation to Drupal 8

Standardized the issue title.

Yay! Beta 1 released! Any plans from the maintainers? Happy to help out with the porting effort.

Would this be based on the 7.x-1.x or the 7.x-2.x?

Good question, I think the both branches have quite some different approaches. And as far as I know 2.x has more dependencies.
But I like 2.x thus I'm working on that - no unfortunately not on the D8 port, but the D7 version atm.

I'm interested in working on the 7.x-1.x branch port. The 2.x I guess would require a stable release on 7.x first.

It would be good to go through the current backlog of RTBC issues and make a new release on 7.x-1.x before starting the D8 port. There are some important issues waiting to be committed.

Looking at the quite distinctive difference in complexity as well as added dependencies between 1.x and 2.x I think there is good arguments for both approaches to be ported.

My proposal for the Drupal 8 is:

1.x -> Workbench Moderation Lite

Basically as simple as 1.x is today except with the addition of multiple workflows.

2.x -> Workbench Moderation

All bells and whistles
With support for upgrading from Lite to full.

Alternatively both could be bundled in the same module and have a feature to convert a Lite workflow to an advance.

*cough* Drafty *cough*

Continuing to use the double-node_save architecture is a critical architecture mistake in the module, results in content being published when it shouldn't be, and could even be a security issue.

Posted by das-peter over in #1307256: Timestamp bug when saving a new draft:

@hass As I'm not the initial developer of 2.x and also just have limited knowledge about the other related modules I can hardly deliver qualified answers. But here's what I know :)
State Machine / State Flow is the tool at hand for handling the revisioning and the different states on entity level.
The submodule workbench_workflows of Workbench Moderation integrates with State Flow to be able to create configurable workflows.
So Workbench Moderation is basically "degraded" to a tool for configuring the Moderation Workflow, provide some UI and act as glue to Workbench.

I think the idea is to have the really complex handling of revisions in a central location API as State Machine tries to provide.
Btw. "recently" Drafty was created by catch which also aims to be a bulletproof revision / publish / draft handling tool.
We really should try to focus on one module that does all the hardcore revisioning / drafting / publishing stuff. But I personally have not enough of a bird-view to be able to tell or even guess what's the one module in the future.

I'm idling in IRC if you'd like to have a more direct conversation :)

fwiw state_flow has the same/similar issues in terms of revision integrity that other workflow modules do, see for example state_flow_entity_exit() in the 3.x branch.

In theory, core now has some concept of allowing drafts, which might make this port more of a UI to that API.

See #1776796: Provide a better UX for creating, editing & managing draft revisions. and #218755: Support revisions in different states.

Over the summer Crell and I worked on a plan for D8: https://docs.google.com/document/d/1ATciywmNVepNYCLXlBZMbAWfI49Uncvvwz7_... Implementation started here before stalling as we shifted back to client work: https://github.com/palantirnet/workbench_moderation

I no longer work at Palantir.net and won't have any significant dedicated time for Workbench Moderation going forward. However I am going to the content authoring summit this Friday at BADCamp and will have that time to discuss/work this plan.

There appears to be a significant amount of work going on for the Workflow port in #2351299: Port Workflow module to Drupal 8.

Yes, but we could have that in any module; it doesn't need to be this one.

If it's the first to market, folks begin adding the missing features, and there's an upgrade path, then I don't see why this would be a problem.

However, I like the idea of a general API module like Drafty in D8 that any possible implementations can use. I don't think this is being done for Workflow.

Workbench Moderation contains two primary features:

1. Workflow states (Also covered by Workflow module)
2. Forward revisions (Also covered by Drafty)

If Workbench Moderation becomes a bridge module tying these two feature sets together from other modules I think that's fine. That may be easier said than done as the plan Crell and I developed put a lot of additional complexity in the storage of workflow states (making them separately revisionable from their parent entities) that is meant to ease the forward revision part.

the plan Crell and I developed put a lot of additional complexity in the storage of workflow states (making them separately revisionable from their parent entities) that is meant to ease the forward revision part.

I wonder if that last part is handled by Multiversion.

https://www.drupal.org/project/commerce_migrate_ubercart

https://www.drupal.org/project/cck

This approach is very much a Drupal reality, and a new release is a great time to consolidate efforts.

*cough* Metatag 1.0 only took 3 2/3 years :p *cough*

BTW we're aiming to have the Metatag-D8 release out along side the 8.0.0 release.

The migration path is only as good as the people who have contributed to it.

I never go into a major version upgrade without expecting to help improve migration paths for the contrib modules involved. The maintainers don't have access to dozens of sites using their modules to be able to get this work 100% solid by themselves.

I'm not claiming its all rainbows and unicorns, but there are no technical issues blocking a workbench -> workflow migration. If I were facing that migration myself today I would just look at what is configured and reconfigure my d8 site for workflow from the UI. Not all problems need to be solved in code.

Just to throw that in: Workbench Moderation 7.x-2.x uses State Machine 7.x-3.x which actually uses Drafty.
So this very important architectural change is covered in the latest versions.

Two things I didn't see mentioned much in the doc:

1. Tracking workflow across sets of entities

2. Preview (especially with sets of entities)

Asking because those are the two main things that CPS is concerned with. It also handles the 'multi-version' case - although it won't try to resolve conflicts if you have two branches of an entity, just lets you know you could be getting into trouble.

There's no active CPS port to 8.x, but as with Drafty (and entity_status), I think it would be good to maximise the amount of shareable code between these modules.

@hass the big problem with all previous major upgrades of Drupal core and contrib modules was hook_update_N() - which was a nightmare to test.

With migrations, whether the schema is the same between 6/7 and 8 or completely different, you have to write the migrations either way, and once written they'll be more robust and testable. Whether that gets done is a different matter, but something being rewritten or not doesn't necessarily make the migration path any harder - it could even be easier in some cases (i.e. moving from custom storage to config entities).

Cross-posting from #2579433-6: [workbench_moderation] Workbench Moderation:

Some community members including @Crell and @dixon_ are looking into plans for this module in D8.

The general idea is to standardize on a single architecture for managing revisions, another for managing workflow states/transitions, and then let a variety of modules flourish (Workbench Moderation, CPS, etc.) that provide customized UIs on top for particular use cases.

It's tentatively looking like Multiversion module will be the thing providing revisioning support for all entities. Hopefully its functionality progressively gets moved more and more into core in 8.1.x+.

Evaluations for workflow/state transitions piece are going on currently. One option might be Workflow module, which is being actively worked on for D8 already, and has been the staple module for this since the Drupal 4.x days.

If you are interested in this problem space, folks are generally discussing this and other topics in #drupal8-ports on IRC.

And if all of that sounds complicated (it did to me and others I spoke to), I've been prodding at a light weight solution that adds some ui on top of core's existing forward revision support (built in for d8). I have been working with an alternate title, but ideally it could use the workbench moderation namespace, but as an 8.x.1.x branch, with the more involved approach being a 2.x. Thoughts?

@larowlan:

If it was going to be an alternative lighter-weight solution I would think it would be better as a new module instead of have two alternative approaches in different major versions of the same module since I would generally consider a 2.x version would be a replacement for a 1.x version instead of an alternative.

Agree with @rooby

Ok, will go with a new module - thanks for considering.
Will keep folks posted here.

my lightweight thing is here https://www.drupal.org/sandbox/larowlan/2624238

see the project page for the stuff still to do, most notably some UI alters from #2429153: On node revision overview, use 'Set current' if revisions are newer than current version

Thanks larowlan! I'll check it out this week.

Note: this module is now the 8.x-1.x branch of workbench_moderation

s/not/now

Hm, didn't notice this thread...

larwolan's sandbox is now the 8.x-1.x branch of Workbench Moderation.

Others are working on a "git branch the whole site" very-advanced use case, which will be built largely off of the Multiversion module.

If it's later determined that a mid-level option (akin to what Workbench 2.x was attempting to do) is appropriate, it will be built using the Multiversion tool chain in a separate module namespace independent of Workbench Moderation. At this time, I expect Workbench Moderation to always remain the "common 80%, save-as-draft-on-steroids" use case.

Leaving this open for now, although it's sort of a duplicate with #2579433: [workbench_moderation] Workbench Moderation

Shall we close this issue?

Given there's now an alpha release, follow-ups should be handled as separate issues.