Here is some usability feedback on the Workspaces UI from the product management team. This needs to be sussed out into what is commit-blocking vs. stable release blocking vs. "should/could have", but for now here's a braindump:

Issue for building the full Workspace UI, based on the top settings tray: #2949991: Add workspace UI in top dialog

• Module doesn't have a link to its configuration page.
• Updates/deploys results are not communicated (e.g. a message that says "27 articles updated, see full log").
• (potential bug) Created a node, published checkbox was checked, but after submitting, suddenly was no longer published (???).
• (potential bug) Publishing a node on Live also published it on Stage, which was unexpected; expected to have to click "update" in stage to see the changes.
• Switching between workspaces doesn't feel seamless (see #2784921-45: Add Workspaces experimental module): both the interaction itself and the labeling/positioning. e.g. missing colours from last design iteration.
• Workspaces configuration page, should belong under Configuration.
• "Update" might be confused for "Save" when it means "Pull from upstream" (maybe "Refresh"?).
• Link to "Manage workspaces" from workspace switcher seems to overly promote to content authors a "one-time" configuration, as a site builder.
• "Default upstream" might need some explanation on the workspaces config page.
• The workspace switcher is a) on the right, and b) isn't clearly a switcher.
• Switching between workspaces requires bouncing eyes all the way back to the left, easy to miss.
• Workspaces are not revisionable entities? I desperately want an undo here. :D

  Tracked in #2968861: Add a way to revert (undo) a workspace

Additional review by @yoroy in #6:

• The approach using the toolbar is an alpha level quality UI. The existing pattern to use for switching workspaces is probably Settings tray. A beta level UI will have moved away from using toolbar.
• Please do limit the scope to enforcing only 1 single parent workspace.
• The screen for pushing/refreshing needs work, at minimum showing number of changes between the different workspaces.
• On the workspaces listing (table) the default option in the drop button for inactive workspaces should be "activate".
• The default option for active workspaces should be "deploy"
• We want to visually label indicate the active workspace, needs exploration
• We discussed showing the hierarchy of parent vs child workspaces by possible using the same "indented" display that can be used for nesting menu items under parents. As long as there is only 1 parent this may not be necessary. Maybe we can show the parent separate from the others? Needs to be reconsidered when exploring doing some or all of this inside Settings tray
• UI for conflict resolution is not in scope of this initial patch but conflicts do have to be at least made explicit (not an alpha blocker imo)

Problem/Motivation

When reverting to a previous revision of an item of content, the new revision created matches the moderation state of the revision being reverted.

While this keeps the integrity of the workflow in tact, since content can only be recreated in a state that was valid at some previous point in time, it may not always be what users expect and it limits the utility of reverting in general, since certain revisions can only be recreated and immediately published or can only be recreated and reverted back to a draft.

Proposed resolution

A few proposals have been made to address this issue:

@catch in #17 (paraphrasing):

• Only allow reverts to default revisions
• Alter the access for the revert action to also require some kind of content_moderation permission
• Leave it as is, but probably with some messaging

@jhedstrom in #18:

• Could we simply add the moderation select list to the revert confirmation form?

@Sam152 in #30:

• Building on adding a moderation select list to the revert screen, but introducing additional permissions for reverting to each state.

Remaining tasks

Agree and implement an approach.

User interface changes

API changes

Data model changes

Steps to reproduce

1. Create moderation states and transition.

states order should be

1. Draft
2. Published
3. Publish to external application 1
4. Publish to external application 2

2. Now assign this moderation states to content type

3. Create a node of the content type which has the above moderation states assigned

4. Save the content with Publishedstate

5. Save the content with Publish to external application 1

6. Check the revision tab. the current revision will not consider step 5, it is set to step 4.
and also check the status of the latest revision in MySQL table, the node is set to unpublished.

Problem/Motivation

Let's have a multilingual site & node with more than 1 language (i.e. node is translatable): EN & DE.
Also enable Workflows module to have draft & published states.

We have 2 published revisions for EN & DE languages.
Then we create new revision of node with EN language but do not publish. Database containt up-to-date value for e.g. field body.
After it we create new draft revision of DE node.
Database contains value for body field for EN node from previous published (default) revision.
Drafts with different languages of one node should not revert another draft to previous state.
It also affects JSON:API.
There are a lot of possible related issues I guess:
#2875861: Optimize updating data and revision data tables
#3023194: [PP-2] Add parallel revisioning support
#2795279: [PP-4] [META] Revisions support
#2833084: $entity->original doesn't adequately address intentions when saving a revision
#2833049: ContentEntityBase::hasTranslationChanges will compare a forward revision with the default one instead of the newest forward revision
#2477419: Codify mechanism to set a forward revision as the default revision
#2960887: Do not create field revisions when field data hasn't changed
#2769741: Node revisions page might not list a default revision for translations
#3056440: Cannot add new translation if the latest affected translation revision of the source language is older than the default revision
#3080995: EntityRepository::getActive does not return a translations most recent revision
#2815949: It is not possible to know if a revision was once the default
#2766957-176: Forward revisions + translation UI can result in forked draft revisions - potential root cause

How to reproduce

• 1. Add 2 languages to site (EN and any one).
• 2. Make "Article" node revisionable & translatable.
• 3. Create Moderation Workflow with: draft, review, published states.
• 4. Create Published revision of node with default language: body field text = "published default"
• 5. Create Draft revision of node with default language: body field text = "draft default"
• 6. Verify database table "node_revision__body", created node has body_value = "draft default" for default (en) language
• 7. Create Published revision of node with non-default language: body field text = "published translation"
• 8. Create Draft revision of node with non-default language: body field text = "draft default"
• 9. Verify database table "node_revision__body", created node has body_value = "published default for default (en) language

Visually database will look like:

Revision 9659 contains new EN content but reverts RU to previous published.
Revision 9660 contains new RU content but reverts EN to previous published.
Revision 9661 contains new EN content but reverts RU to previous published once again.

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

API changes

Data model changes

I am using Content moderation, Workflows, Language and Content translation core modules in Drupal 8.6.4. I have implemented workflow on Basic page with states like (Draft, Audit, Review, Pre Publish and Publish). Now I am creating a Test content in English as well as in Spanish language and pass all the workflow states and publish the content in both language. Now when i try to update the moderation state of both of these content to Draft one of them gets auto published, but inside the edit mode it shows current state as Draft only for both of the content which is correct. (Here, we are refering to content_moderation_state_revision table in DB)

Has anyone faced this issue before with multilingual?

Looking forward for the comments and possible solutions.

Thanks

Problem/Motivation

Steps to reproduce

1. Enable content_moderation and two languages
2. Allow articles to be added to menus.
3. Publish an article with a menu item.
4. Create a new draft revision of the node with an updated menu title.
5. After saving, note the draft node title immediately appears in the menu.

Critical per #2858434-5: Menu changes from node form leak into live site when creating draft revision:

a critical priority bug because it is a data integrity issue when information is menus change when you don't intend them to change.

Proposed resolution

Change the node/menu integration to somehow be revision-aware.

Remaining tasks

1. Write a patch
2. Review
3. Commit

User interface changes

None.

Problem/Motivation

Maybe this is because we are using a patch from #3020448: Invalid translations of the ContentModerationState entity created before #2946402 exist in some installations of content_moderation and have some inconsistent data, but it I imagine it might also be possible to reproduce when the langcode of the default translation changes.

Proposed resolution

As a quickfix, don't delete that that "translation". Not sure what else we could do.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

I translated two nodes, when I change the state to draft the revision is being created correctly, but when I tried to edit the other translation of the same node, I saw that the translation has the same moderation state even if I haven't edited this translation.

Steps to reproduce it:

1. Create two or more nodes
2. Install content_moderation and workflows
3. Install config_translation, content_translation and locale
4. Add either a custom or default language, in my case I added en-mx and es-mx.
5. Go to language content settings page and check all the content types
6. Go to workflow settings page and apply the default workflow to all the content types
7. Go to content and translate one of the nodes
8. Edit one of the translations, in my case I change the state to draft in the es-mx node.
9. Go to en-mx and you will see the draft state even if this translation was not edited.

In order to solve my issue I added a condition to find the correct revision by language, it's working on my end but I would like to know if someone is having the same issue.

any thoughts?

Problem:

Using nested paragraphs creates multiple drag handles for sub-paragraph field.

What it looks like:

Steps to reproduce:
1. Create a new paragraph type (sub paragraph) (can be empty without fields)
2. Create two other paragraphs (main paragraphs) (the other one can be empty without fields)
3. Add a Paragraph field to the other main paragraph and include to sub paragraph in the reference type.
4. Add a Paragraph field to basic page and include the two main paragraphs in the reference type
5. Add a basic page and add there the paragraph type which has the sub field. It shows the three drag handles for the sub paragraph

This seems to be an issue in the Claro tabledrag, which has overriden the core tabledrag, because this doesn't happen with Seven administration theme. It seems that the Claro tabledrag.js is adding some wrappers and other divs to the html so that we end up with 3 drag handles. The problem doesn't come up with any other place in admin UI, but the nested paragraphs use the "multiple drag".

The difference seems to be here:

The output for the Seven admin theme:

<td class="field-multiple-drag">
  <a href="#" class="tabledrag-handle" title="Drag to re-order">
    <div class="handle">&nbsp;</div>
  </a>
</td>

And the output for the Claro theme:

<td class="field-multiple-drag tabledrag-cell tabledrag-cell--only-drag">
  <div class="tabledrag-cell-content js-tabledrag-cell-content">
    <a href="#" class="tabledrag-handle js-tabledrag-handle" title="Drag to re-order"></a>
    <div class="tabledrag-cell-content__item">
      <div class="tabledrag-cell-content js-tabledrag-cell-content">
        <a href="#" class="tabledrag-handle js-tabledrag-handle" title="Drag to re-order"></a>
        <a href="#" class="tabledrag-handle js-tabledrag-handle menu-item__link" title="Drag to re-order"></a>
          <div class="tabledrag-cell-content__item"></div>
      </div>
    </div>
  </div>
</td>

It adds the handle three times.

Problem/Motivation

When creating a revision of a published node in a different language, the content type doesn't get set. I believe this affects the permissions too as anyone without the "Bypass content access control" cannot view that revision of the node in the Moderated Content view.

Steps to reproduce:
1. Install Content Moderation and Content Translation modules on a clean installation.
2. Add a language.
3. Edit the default Editorial workflow and apply the workflow to the Basic page content type.
4. Edit the Basic page content to enable revisions "Create new revision" and enable translation.
5. Create new basic page and set to be published.
6. Create a translation of the page in the other language and set to be draft.
7. Go to the Moderated content view (/admin/content/moderated) and notice the content type doesn't display for the draft. The whole draft won't show in the view for other users without the "Bypass content access control" permission.

I'd expect the content type to show and the users with the "View any unpublished content" to be able to view it.

Problem/Motivation

I'm having an odd issue where I am getting a 'default language cannot be changed' error when trying to save a translated node.
I've tracked it down to the attached content moderation entity, and in particular EntityOperations::updateOrCreateFromEntity()

  /**
   * Creates or updates the moderation state of an entity.
   *
   * @param \Drupal\Core\Entity\EntityInterface $entity
   *   The entity to update or create a moderation state for.
   */
  protected function updateOrCreateFromEntity(EntityInterface $entity) {
    /** @var \Drupal\Core\Entity\ContentEntityInterface $entity */
    $entity_revision_id = $entity->getRevisionId();
    $workflow = $this->moderationInfo->getWorkflowForEntity($entity);
    $content_moderation_state = ContentModerationStateEntity::loadFromModeratedEntity($entity);
    /** @var \Drupal\Core\Entity\ContentEntityStorageInterface $storage */
    $storage = $this->entityTypeManager->getStorage('content_moderation_state');

    if (!($content_moderation_state instanceof ContentModerationStateInterface)) {
      $content_moderation_state = $storage->create([
        'content_entity_type_id' => $entity->getEntityTypeId(),
        'content_entity_id' => $entity->id(),
        // Make sure that the moderation state entity has the same language code
        // as the moderated entity.
        'langcode' => $entity->language()->getId(),
      ]);
      $content_moderation_state->workflow->target_id = $workflow->id();
    }

    // Sync translations.
    if ($entity->getEntityType()->hasKey('langcode')) {
      $entity_langcode = $entity->language()->getId();
      if ($entity->isDefaultTranslation()) {
        $content_moderation_state->langcode = $entity_langcode;
      }
      else {
        if (!$content_moderation_state->hasTranslation($entity_langcode)) {
          $content_moderation_state->addTranslation($entity_langcode);
        }
        if ($content_moderation_state->language()->getId() !== $entity_langcode) {
          $content_moderation_state = $content_moderation_state->getTranslation($entity_langcode);
        }
      }
    }

    // If a new revision of the content has been created, add a new content
    // moderation state revision.
    if (!$content_moderation_state->isNew() && $content_moderation_state->content_entity_revision_id->value != $entity_revision_id) {
      $content_moderation_state = $storage->createRevision($content_moderation_state, $entity->isDefaultRevision());
    }

    // Create the ContentModerationState entity for the inserted entity.
    $moderation_state = $entity->moderation_state->value;
    /** @var \Drupal\Core\Entity\ContentEntityInterface $entity */
    if (!$moderation_state) {
      $moderation_state = $workflow->getTypePlugin()->getInitialState($entity)->id();
    }

    $content_moderation_state->set('content_entity_revision_id', $entity_revision_id);
    $content_moderation_state->set('moderation_state', $moderation_state);
    ContentModerationStateEntity::updateOrCreateFromEntity($content_moderation_state);
  }

If the moderation state can't be found we create it with the langcode of the entity that we are saving. If that isn't the default langcode of the entity, then next time we go to save the default language of the eniity it tries to change the langcode and the api won't let it.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

I have a multilingual site that uses content_moderation workflow and revisions. I came across an issue recently where If I create a node and leave it in review but then translate it, and publish the translation, I cannot delete the translation.

Steps to reproduce:

1. Create a site with three languages and enable content moderation
2. Create an article in the default language but do not publish it.
3. Create a translation of new article and publish it
4. Create a second translation of the article and publish it
5. Now try to delete the translations. They appear to delete but when you visit the translations page you will still see them marked as published. If you try to visit the translated pages you will get a 500 error as they entity has deleted the translation but the tables have not been updated. If you have created a single translation you will be able to delete the translation by clicking delete a second time. However if you have multiple publish translations on an unpublished node you will not be able to delete the translations

From what I can see, it all comes down to the entity after the translation is deleted is not being marked as a default_revision because it does not trigger any of the following in 'src/EntityOperations.php':

$update_default_revision = $entity->isNew()
      || $current_state->isDefaultRevisionState()
      || !$this->moderationInfo->isDefaultRevisionPublished($entity);

If I force $update_default_revision to be true the node deletes translations correctly. Is it correct to have a new default revision on every translation removal?

Expected Behavior

When I delete a translation I expect it to be removed from the list of available translations and to be redirected back to the default language translation which should be unpublished.

Actual Behavior

When I delete a translation I get redirected to a seemingly published version of unpublished default language article and translation still appears as published in translation list even though it has been removed from the entity.

Problem/Motivation

See #2833049-14: ContentEntityBase::hasTranslationChanges will compare a forward revision with the default one instead of the newest forward revision.

Right now, using the createRevision() API to prepare a new revision uses the untranslatable fields of the current default revision. This does not make a big difference currently when just using regular untranslatable fields as they are not visible on the edit form. They are however visible when looking at the saved translation draft.

Example:

Content type 'Article' has an untranslatable image field and a translatable body text field. There is an existing published version in EN and a translation in DE. Then, the user creates an EN draft with a new image and a different text. Then, he also edits the DE translation and creates a new draft, updating the text also accordingly (lets say it describes the untranslatable image). In Edit, the image is hidden, but when then saving that draft, it still shows the old image.

This becomes a bigger problem with e.g. paragraphs, but then you can for example add completely new paragraphs with new translatable fields, which are then impossible to translate until you publish the EN draft. This goes against user expectations/requirements.

Proposed resolution

Basically, the proposal is to change createRevision() and specifically use the draft versions of the untranslatable fields, However, what happens if you try to then publish the DE translation draft before the EN draft? I can imagine at least 3 variants:
1. We just publish the translatable fields. This would be the default behavior, but it's really problematic for paragraphs as you would then basically just drop translations you might have created for new paragraphs.
2. We disallow that with a validation constraint
3. We publish it including untranslatable fields. Don't quite see how that would work as it basically goes completely against the current behavior.

Maybe a combination, core would continue to do 1, but in paragraphs, we add our own validation that prevents publishing a DE draft if it is based on the EN draft with a different structure.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

I'm using content moderation in combination with the group.module, so I'm relying on node grants from that for edit access and normal editors do not have "view any unpublished entity".

As a result, /latest works fine for content that the user himself creates as he does have view own unpublished, but it doesn't work for entities that someone else created.

However, the editor can edit that entity and I'm also allowed to view it through /revisions. And on save, he's even redirect to /latest and then sees the access denied page.

Proposed resolution

Not sure what to do, For similar problems with translations, we're handling it through #2972308: Allow users to translate content they can edit, so the access check could look at edit permission, alternatively, we could add an entity type specific check through the handler, so that node can check its access revisions permissions?

Remaining tasks

User interface changes

API changes

Data model changes

In mymodule.routing.yml it is possible to define _method in route requirements to allow access using only specified request methods. It seems that route validation, however, does not preserve request method and defaults to GET requests, which will then fail the _method requirement always.

According to stack trace, the problem seems to lie in Drupal\Core\Routing\AccessAwareRouter::match, as the Request object is created from plain path without any other context.

mymodule.vote:
  path: '/foobar/vote'
  defaults:
    _controller: '\Drupal\mymodule\Controller\FoobarViewController::vote'
  requirements:
    _entity_access: 'foobar.view'
    _method: 'POST'

Symfony\Component\Routing\Exception\MethodNotAllowedException: in Symfony\Component\Routing\Matcher\UrlMatcher->match() (line 101 of core/vendor/symfony/routing/Matcher/UrlMatcher.php).

Drupal\Core\Routing\UrlMatcher->finalMatch(Object, Object)
Symfony\Cmf\Component\Routing\NestedMatcher\NestedMatcher->matchRequest(Object)
Symfony\Cmf\Component\Routing\DynamicRouter->matchRequest(Object)
Symfony\Cmf\Component\Routing\ChainRouter->doMatch('/kysy-kirjastonhoitajalta/vote', Object)
Symfony\Cmf\Component\Routing\ChainRouter->matchRequest(Object)
Drupal\Core\Routing\AccessAwareRouter->matchRequest(Object)
Drupal\Core\Routing\AccessAwareRouter->match('/kysy-kirjastonhoitajalta/vote')
Drupal\user\Plugin\LanguageNegotiation\LanguageNegotiationUserAdmin->isAdminPath(Object)
Drupal\user\Plugin\LanguageNegotiation\LanguageNegotiationUserAdmin->getLangcode(Object)
Drupal\language\LanguageNegotiator->negotiateLanguage('language_interface', 'language-user-admin')
Drupal\language\LanguageNegotiator->initializeType('language_interface')
Drupal\language\ConfigurableLanguageManager->getCurrentLanguage()
Drupal\language\EventSubscriber\LanguageRequestSubscriber->onKernelRequestLanguage(Object, 'kernel.request', Object)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.request', Object)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1)
Stack\StackedHttpKernel->handle(Object, 1, 1)
Drupal\Core\DrupalKernel->handle(Object)

Problem/Motivation

This is a side issue spun off from

https://www.drupal.org/node/2834982#comment-12074099

EntityForm::buildForm() has a overcomplicated and undeclared dependency on the renderer service.

Via a call to

 \Drupal::service('renderer')->addCacheableDependency($form, $this->entity);

the renderer service is being used incorrectly as a helperClass, as a pass through service, to access CacheableMetadata methods.

The same argument can be made for

RendererInterface::mergeBubbleableMetadata() it is just a helper class for BubbleableMetadata helper calls

Proposed resolution

1) Deprecate ( for removal in Drupal9 )

RendererInterface::mergeBubbleableMetadata()
RendererInterface::addCacheableDependency()

2) Create replacements RenderDependencies::addCacheableDependencyToRenderArray() and RenderDependencies::mergeBubbleableMetadata()

3) isolate tests, for Renderer tests. ( see RenderDependenciesTest )

4) Replace method calls in FieldPluginBase.php and EntityForm.php HtmlRenderer.php to calls of the new replacement methods.

Problem/Motivation

Upon (re)installing Drupal 9 or any 8.8.1+ version via the web browser, you’ll run into the The website encountered an unexpected error. Please try again later. error. The installer works correctly with Drush.

You might also see a variation of these errors in the log files:

NOTICE: PHP message: Uncaught PHP Exception InvalidArgumentException: "Class "\Drupal\system\Controller\Http4xxController" does not exist." at /var/www/html/web/core/lib/Drupal/Core/DependencyInjection/ClassResolver.php line 24"

Or

Uncaught PHP Exception InvalidArgumentException: "No check has been registered for access_check.permission" at /var/www/html/web/core/lib/Drupal/Core/Access/CheckProvider.php line 97

For completeness, this error was also reported at https://drupal.stackexchange.com/questions/289480/class-drupal-system-co...

How to reproduce?

1. Blank copy of Drupal with empty DB but with valid DB credentials in settings.php
2. Visit /index.php (this will redirect you to /core/install.php)
3. Install Drupal via the web browser
4. After you’re finished configuring the new site, you’ll get the The website encountered an unexpected error. Please try again later. error

The initial bug report also included those steps to reproduce with ddev:

1. mkdir d8recommended && cd d8recommended &&. ddev config --project-type=drupal8 --docroot=web --create-docroot
2. ddev start
3. ddev composer create drupal/recommended-project
4. ddev config --project-type=drupal8
5. Tail logs with "ddev logs -f"
6. Visit the *http* URL (for example, http://d8recommended.ddev.site) and do the web-based installation. You'll get these errors when you finish configuration on the final page.

Proposed resolution

• Find a way to prevent cache pollution when installing Drupal via the web browser.
• Ensure it meets the requirements to solving SA-CORE-2019-009 gracefully.

Remaining tasks

Discuss the best approach and provide a patch with tests.

User interface changes

The web installer works again as expected.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation
Progress throbber position and styling are incorrect while viewing in table display as compared with other displays.

Steps to replicate
Example:
1. Go to admin/structure/block and click on place block to check the throbber effect.
2. After that click on the place block button from place block modal popup form and check the throbber effect.

See the below screenshots