[META] Merge changes from 2.x and 3.x [#1587574]

I just pushed the 3.x branch that Robeano and I worked on for a client. It was started off of 1.x a few months ago so there are changes in 2.x not present in 3.x. We can use this issue to track the big pieces and resolve them in this issue or spin-offs.

I will be at Drupal Camp Twin Cities this weekend and will write up a more complete summary of the tasks to be done.

Big Changes in 3.x

The State records themselves are fieldable entities: #1412728: Make state change records themselves be entities with bundles
A start on "entity agnosticism." State Machine 1.x and 2.x put states on nodes. 3.x separates the node logic into a separate module. This should allow additional modules to be written to handle users, beans, or any other entity.
As part of the entity agnostic conversion, the history tables were renamed to use a state_flow prefix instead of a node_ prefix. We may need to discuss this and the column in these tables.
Changes to the tables meant changes to the Views handlers. I'll make an issue.
The juggling of what vid is in the node table was re-written largely to model ERS' handling of revisions.
Moving base-level configuration of Workflow from an array in the init function to an array passed into the init function. This allows the same class to file to handle more than more workflow. This also allows 3rd party modules to create these configuration arrays. I've written such a module that currently lives in the 2.x branch of Workbench Moderation and is powered by CTools so it gets easy exportability and access plugins to control what nodes can use a given state/event/workflow.
I'll add more tasks as they arise through the merge.
We now rely on Drafty to handle the revisioning of entities.
Enhanced entity_translation support: #2546728: Edition of a node revision with Entity Translation language switcher
To make use of this new functionality you've to apply a patch to entity translation: #1707156: Workbench Moderation integration

Comments

Comment #1

robeano commented 20 May 2012 at 16:29

As I work on merging changes between 2.x and 3.x in state_flow.module, I noticed that 2.x provides a hook that is not yet implemented in 3.x:

* @todo - provide a hook when juggling revisions
* In State Machine 7.x-2.x, a hook was provided via
* state_flow_promote_node_revision() allowing modules to run their own
* processes when a revision id is pushed to the entity base table.
* i.e.
* // Notify other modules about the vid change
* module_invoke_all('state_flow_change_vid', $current_vid, $new_rev);
* State flow Entity should provide this hook as well.

I think a thorough review of where hooks should be implemented is warranted.

At a minimum, we should provide a hook during the revision juggling in State Flow Entity and State Flow (Node).

Comment #2

robeano commented 20 May 2012 at 17:03

Another hook to review.

In modules/state_flow_entity/plugins/state_flow_entity.inc, a hook is implemented for use when an event is fired (StateFlowEntity::fire_event()). In 7.x-2.x, this hook is implemented as well but with different arguments. We need to review this and fix as needed.

In state_flow_entity.inc:

      // Allow state_flow to provide other hooks or event triggers.
      /**
       * @todo the original hook in 7.x-2.x looks like this:
       *    state_flow_invoke_event_handlers($this, $key, $uid, $log);
       * We should review to see if other code uses this hook and update as
       * needed.
       */

      state_flow_entity_invoke_event_handlers($this->object, $new_state, $this->get_history_entity());