Saving a draft unpublishes the content for pre-exsiting content

Seemingly related - the above clues led me to solve my own issue:

* I had a heap of content imported via 'migrate'.
* workbench_moderation had been set up on the content types before the import.
* after the import, all was 'published' and worked fine.
* yet any type of trivial change made through the /content/admin page (eg, promote to front page, or rebuild alias) would mysteriously UNPUBLISH content unintentionally!

--- the migrated content had been saved, and was published, and worked.
But it had no 'moderation' state.

So when re-saving (by any means),
Previously 'stable' content had its moderation state checked. And got SET to 'nope'

The 'migration' import must have bypassed the hook_node_save() or whatever. workbench_moderation missed the arrival of the new injections, then freaked out when it was introduced to them.

So - The retro-active flagging from rooby in #3 helped a LOT! THANKS!

It could be that the module could/should have a sanity-check that can be used to ensure all entities can be set to a valid state - to repair stuff as content and imports may come from any state.

same issue ++

I'm running into this when using the scheduled updates module. If I setup the first version of a node to be a draft that should be scheduled with the latestRevisionUpdate running from that module, when the update runs the moderation state flips from draft to NULL and the node stays unpublished. It also appears to come up if I have multiple future revisions. It looks like the update runs correctly, except that during the entityPresave from workbench moderation the $state_before value fails to get detected correctly and instead of failing over to the default value it fails over to NULL

// There's currently a bug in core where $entity->original always points
// to the default revision, for now work around this by loading the latest
// revision.
$latest_revision = $this->moderationInfo->getLatestRevision($entity->getEntityTypeId(), $entity->id());
$state_before = !empty($latest_revision) ? $latest_revision->moderation_state->target_id : NULL;

It seems that if it can't get a moderation_state off the entity the right answer it to load the default for that entity type.

Experiencing the same problem, how are people using this with it being in such a broken state? Even content I created after WBM has been enabled I'm experiencing the same problem, which shouldn't be happening. Any helps here? I tried updating the database as per #3, but still having the same problem.

The workaround provided in #3 works for me. Below is the equivalent in the form of an update hook. As with #3, it presumes certain default states for published/unpublished, and you may need to adjust for your site's configuration

Perhaps the module maintainers could follow a similar, abstracted approach in their workbench_moderation.install file?

<?php
/**
 * Fix moderation state values for nodes created before enabling Workbench.
 */
function mymodule_update_8001(&$sandbox) {
  $query = \Drupal::database()->update('node_field_data');
  $query->fields(['moderation_state' => 'published']);
  $query->isNull('moderation_state');
  $query->condition('status', '1');
  $query->execute();

  $query = \Drupal::database()->update('node_field_data');
  $query->fields(['moderation_state' => 'draft']);
  $query->isNull('moderation_state');
  $query->condition('status', '0');
  $query->execute();

  $query = \Drupal::database()->update('node_field_revision');
  $query->fields(['moderation_state' => 'published']);
  $query->isNull('moderation_state');
  $query->condition('status', '1');
  $query->execute();

  $query = \Drupal::database()->update('node_field_revision');
  $query->fields(['moderation_state' => 'draft']);
  $query->isNull('moderation_state');
  $query->condition('status', '0');
  $query->execute();
}

?>

the database queries fixed this issue for me, thanks.

Maybe I'm not doing things correctly if the solution is working for others here. I'm fairly new to Drupal and certainly new to the Workbench suite. Is there a good primer on using this in D8 somewhere?

@lightguardjp, given that you say "Even content I created after WBM has been enabled I'm experiencing the same problem, which shouldn't be happening" -- a behavior that is not described by anyone else -- I might conclude that either (a) you found another bug or (b) maybe something in your configuration is incorrect.

If you are testing with User 1, thereby bypassing permissions limitations, then I would suggest reviewing that your given content types have Workbench moderation enabled as you intend (e.g., https://www.evernote.com/l/AlXzJ7uKRGBCtorODI_AW0YegrW2pytd1AY) and secondarily reviewing /admin/config/workflow .

The problem was that I installed this module on a site that already had content, not a fresh install, and all of the previously published content was treated as if it was an unpublished new draft by workbench_moderation.

I'd go to a piece of published content and my options were not reflecting the options specified in the workflow for a published piece of content. So it was very confusing for users, who would go to a piece of content they had published prior to the this modules installation, then click "create new draft" and it would unpublish their content and create a new revision. It should have left the content published and created a new revision that was only visible to users with proper permissions.

Thankfully, the workaround in #3 worked for me.

Turns out my issue was being caused by https://www.drupal.org/node/2842471. After I got that taken care of #3 worked for me as well.

same issue in drupal 7 workbench moderation-version 7.x-3.0.There is no such table node_field_revision and node_field_data to update.Can anyone please clarify.?

@rooby ,yes ,its not a suitable table.

Same issue for me in Drupal 7. The workbench_moderation_node_history table has 0 for the "published" and "is_current" columns, except for the most recent version of the node which has 1 in both columns. Seems to me the published column should not change from 1 to 0.

This may be unrelated but I was having an issue similar for workbench moderation 7.x-3.0 and I made a change to Drupal Core. Here's the link #2824725: Node Unpublished when more recent revision state changed

In my case (which might help others) there is a configuration setting that can cause this also:

Problem:
When a Draft of a Published node is created the current Published version gets set to unpublished.

Resolution:
Verify the settings of the new "Default revision" State option that was added to the "States" config for each of your States /admin/structure/workbench-moderation/states. In my case the "Draft" State was checked as "Default revision" which I guess would overwrite the published default State when a new Draft was created. Unchecked that box solved it the issue. Review all your other States to ensure this setting is correct.

I couldn't find any documentation about the "Default revision" check box but my understanding is that when this is checked content that enters into this revision state will automatically become the current revision (so it would overwrite the previous current revision). You'll probably want this checked only on States you expect to replace the current one (like Published, Archived, Unpublished, etc). States like "Draft" and "Needs Review" for example you'll want to make sure this setting is NOT checked.