Problem/Motivation

In #2068063: Change "Save and keep un-/published" buttons to a "Published" checkbox and an included "Save" button we replaced the drop button with a "published" checkbox, however if a user doesn't have permission to publish content (or even view the checkbox) they don't know if clicking save will publish the content or not.

Proposed resolution

If the user doesn't have permission to change the publishing status, make them aware of what will happen when they click save.

Remaining tasks

User interface changes

API changes

Data model changes

This issue is spun off from #2831936-129: Add "File" MediaSource plugin, specifically this point of review:

The media creation form is a hodge-podge of information. The revision information is above / more important than the file itself. I also did not expect the path alias to be this prominent on the form. Do we have an issue to review the media creation UI?

We do now. Let's get UX review on the media creation form, and make as many fixes as possible.

Problem/Motivation

On the storage level revisions are not created just for a single translation of an entity, but for all translations. Because in the UI the field values are only edited for a single language, however, we calculate which translations are actually affected by this new revision, which means which translations actually have field values which differ from the previous revision.

We use this value in two places in core:

1. In the node revision overview revisions whose translations in the current language are not affected are hidden, so as not to confuse the user by showing them multiple revisions that are visibly indistinguishable
2. For entities that moderated with the Content Moderation module, the Latest version tab is only shown,
   if the translation in the current language of the latest version is actually affected

The problem is that when re-saving the same revision (i.e. when unchecking the Create new revision checkbox), the information which translations are affected by this revision is not being recalculated. Therefore this information may be invalid leading to misinformation wherever this information is accessed including the two places in core depicted above.

This capability was introduced in #2453153: Node revisions cannot be reverted per translation but the impacts of re-saving an existing revision were not discussed throughout the entirety of that issue.

Proposed resolution

When saving an entity and not creating a new revision, compare the field values of each translation to those of the previous translation and (re-)calculate which translations are affected by this revision.

Problem/Motivation

Create an entity and save it. Now call setNewRevision(TRUE) on the entity and before saving call setNewRevision(FALSE). The first call to setNewRevision removes the revision_id so trying to stop the creation of a new revision is not possible by calling setNewRevision a second time. Saving the entity now results in a new revision.

Proposed resolution

Make the function setNewRevision remember the changes it made and revert them if called again with TRUE.

Remaining tasks

review.

User interface changes

none

API changes

none

Data model changes

none

The kittens you are looking for cannot be found from here.

Problem/Motivation

The migrate_upgrade UI is now providing a confirmation page, showing the administrator performing the upgrade what modules are being upgraded from their legacy sites (and what modules are not). There is not currently an automated way to get this information - the closest thing is the source_provider annotation on the source plugin, but this doesn't help us with configuration-only migrations. My suggestion is adding a module key to the source plugin config for the Drupal migrations.

Proposed resolution

1. Modify the migrate_drupal_ui confirmation form to query source and destination plugins for their providers, instead of using a hard-coded list of module/provider relationships.
2. Add explicit provider information to all source/destination plugins lacking them.

Remaining tasks

None.

User interface changes

Contrib and custom modules will now be able to document their provider relationships, making the confirmation page more accurate.

API changes

None.

Data model changes

None.

Manual Testing

This issue is only present in the UI as drush doesn't utilize this provider array/config.

To test the manual update:

1. Create a D6 database from a standard install and back it up
2. Create a D7 Database from standard install and back it up
3. Create D8 install off standard, install migrate_drupal_ui
4. Visit /upgrade and test the upgrade path.
5. Ensure there are no regressions in the module destinations provided for d6 and d7 migrations

Problem/Motivation

Discovered by Berdir at #2789315-52: Create EntityPublishedInterface and use for Node and Comment and subsequent comments.

Where/when was this bug introduced?

#2631774: Impossible to update Comment entity with REST (HTTP PATCH): bundle field not allowed to be updated, but EntityNormalizer::denormalize() requires it introduced this bug. But before describing what bug it introduced, let's explain what that issue was trying to achieve: it wanted to make it possible to PATCH comment entities at all. For the entity denormalizer to succeed, it needs to know the bundle. So, requests must include the comment type. After denormalizing the entity, one must denormalize the fields in the entity. Before denormalizing a field, field access is checked. But modifying an entity's bundle is not allowed. End result: sending the bundle was necessary in step 1, but forbidden in step 2. Hence PATCHing comment entities was impossible.

To solve this, #2631774 needed to disable field access checking for at least the bundle field: as long as it was being sent unchanged, it should be allowed. But Field API does not have a facility for detecting changes made to fields, so some logic had to be added at the REST level to manually check certain fields. But which fields?

To not hardcode this, we tried to find what aspect determined which fields are safe to send, but should match the current value. There already was one case of this: the langcode entity key field. bundle is another key. Therefore it seemed safe to make the jump to assuming that all entity keys are in fact safe to treat this way. After all, their name indicates that they are "keying the entity", i.e. together determine a unique entity. This impression is supported by the fact that:

1. name — "keys" have a very specific meaning in this software context
2. the langcode key was already being special-cased in a similar way
3. we'd want similar special-casing for e.g. the UUID field too, which is another entity key
4. the same reasoning/assumptions were used by \Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema::getSharedTableFieldSchema() which ensures entity keys are NOT NULL, hence seemingly confirming this is the right way to use it — being fixed in #2841291: Fix NOT NULL handling in the entity storage and 'primary key' changes when updating the storage definition of an identifier field now
5. … big long-time contributors like @dawehner and @larowlan RTBC'd this, so they also didn't notice…

So this solution was committed.

How did we discover this solution was incorrect?

This worked well for a while: #2631774 was committed on May 31, 2016. It shipped with Drupal 8.2. Nobody complained for a long time.

Then the Workflow Initiative happened, and #2789315: Create EntityPublishedInterface and use for Node and Comment happened for that initiative, in November 2016. That was adding status to the entity keys. Which is an entity key that does not uniquely identify an entity. It can be modified. This then caused test failures, which I was called in to comment on: #2789315-53: Create EntityPublishedInterface and use for Node and Comment. Turns out "entity keys" only exist for "fast access" purposes, or at least that's what they exist for today!

So "entity keys" are misleadingly named — created an issue for that: #2885411: "Entity keys" aren't actually keys — rename to avoid misinterpretation.

Proposed resolution

Attempt 1: insecure

@amateescu first posted a patch in #6 that simply ignores any values that are sent that match the current value. But @Berdir pointed out in #8 that this leads to an information disclosure vulnerability. So this solution was ditched.

Attempt 2: broken

So @amateescu reworked the patch to always check field access. But in doing so, he re-introduced the bug that we originally fixed: it was once again impossible to send an entity's bundle because field access disallowed it, but it was required for denormalization: exactly the same problem that #2631774: Impossible to update Comment entity with REST (HTTP PATCH): bundle field not allowed to be updated, but EntityNormalizer::denormalize() requires it solved!

Attempt 3: poor performance

Then @Wim Leers and @amateescu had a try: @Berdir recommended to rely on \Drupal\Core\TypedData\DataDefinitionInterface::isReadOnly() instead. We tried to do that in #2826101: Add a ReadOnly constraint validation and use it automatically for read-only entity fields. But then @Berdir pointed out in #24 and #29 that using a validation constraint is the wrong tool for the job. Not to mention that #2826101 quickly got stuck on computed fields' semantics being ambiguously defined: #2392845: Clarify the notion of "computed field".

Attempt 4: stuck

@Wim Leers tried to take @Berdir's #29 to heart and bring all information together in a new proposal: #31. It involved 3 things:

1. Providing correct field access control behavior for read-only fields by modifying the default field access logic: forbid them
2. Updating the comment entity access control handler's field access logic, to allow in case the pre- and post-update values match
3. Remove all specialty logic in EntityResource::patch()

However, the second point turned out be impossible due to the fact that Field API does not pass pre- and post-update values to field access checking logic.

Attempt 5: unclear

@tedbow tried to solve it by introducing DataDefinitionCreatableInterface, to allow values to be provided during entity creation even if the field is read-only.

Attempt 6: currently proposed solution!

However, as far as @Wim Leers can see, the solution can actually be much simpler if we solve it in the right place:

1. EntityResource::patch() must do its field-level access checking based on $entity->_restSubmittedFields: that is how the REST EntityResource plugin knows which fields were sent (which is itself a hack that is being fixed in #2456257: [PP-1] Normalizers must set $entity->_restSubmittedFields for entity POSTing/PATCHing to work)
2. all of these problems would go away if we had a Entity::getDirtyFields() API, because then we'd know to only check field access for fields that were actually changed

Therefore solving #2862574: Add ability to track an entity object's dirty fields would unblock both #2456257: [PP-1] Normalizers must set $entity->_restSubmittedFields for entity POSTing/PATCHing to work and this issue:

1. #2456257 would be able to remove ->_restSubmittedFields.
2. This issue would be able to remove all of the conditionals to skip field access checking.

This issue is therefore not hard-blocked on #2456257, but "mostly parallel-blocked". But this issue will also need to replace foreach ($entity->_restSubmittedFields as $field_name) { with foreach ($entity->getDirtyFields() as $field_name => $field) {. And that's the entire scope of #2456257. Therefore this issue actually is blocked on #2456257.

Remaining tasks

1. Land #2862574: Add ability to track an entity object's dirty fields.
2. Land #2456257: [PP-1] Normalizers must set $entity->_restSubmittedFields for entity POSTing/PATCHing to work.
3. Roll patch.
4. Review.
5. Commit.

User interface changes

None.

API changes

None.

Data model changes

None.

I found my Drupal8 website broken with no appearent reason, i.e., no code nor structure modifications since it was working last time.

I discovered that the error was initially raised after a Rest Post.

Location: http://drupal8.test/entity/node/

Page Body:
<html><head></head><body>The website encountered an unexpected error. Please try again later.</body></html>

Server Error number: 500.

Symfony\Component\HttpKernel\Exception\HttpException: Internal Server Error in Drupal\rest\Plugin\rest\resource\EntityResource->post() (line 200 of /var/www/elders.dev/core/modules/rest/src/Plugin/rest/resource/EntityResource.php).

After some testing I discovered the problem is from the query creating the entity,
Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '179-0-0-en' for key 'PRIMARY': INSERT INTO {node__field_device_id} (entity_id, revision_id, bundle, delta, langcode, field_device_id_value) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5); Array ( [:db_insert_placeholder_0] => 179 [:db_insert_placeholder_1] => 191 [:db_insert_placeholder_2] => accesso [:db_insert_placeholder_3] => 0 [:db_insert_placeholder_4] => en [:db_insert_placeholder_5] => ID TEST ) in Drupal\Core\Database\Connection->handleQueryException() (line 682 of /var/www/elders.dev/core/lib/Drupal/Core/Database/Connection.php).

and

Drupal\Core\Entity\EntityStorageException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '179-0-0-en' for key 'PRIMARY': INSERT INTO {node__field_device_id} (entity_id, revision_id, bundle, delta, langcode, field_device_id_value) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5); Array ( [:db_insert_placeholder_0] => 179 [:db_insert_placeholder_1] => 191 [:db_insert_placeholder_2] => accesso [:db_insert_placeholder_3] => 0 [:db_insert_placeholder_4] => en [:db_insert_placeholder_5] => ID TEST ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 777 of /var/www/elders.dev/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Now I can't create nodes that share those fields anymore, I get the white page:
The website encountered an unexpected error. Please try again later.

This issue doesn't seem to be striclty related to:

• Ambiguous Langcode
• Not NULL constraint failed

Problem/Motivation

All our render cache entries like page, entities, blocks, views and so on are by default cached forever.

That's great. Except when you have a lot of data + a lot of variations and a cache backend that doesn't support something like LRU like the default database backend. Then your cache table will grow and grow and it's suddenly not so great anymore :)

You could argue that sites with a lot of data should use redis/memcache and not the database but also medium-sized with not so many users could run into problems eventually, also in regards to copying the database around since only few people remember to ignore cache tables.

Proposed resolution

Either the render cache service or the database backend (per-bin) should support an upper limit for the max-age. E.g. a day or a week. It would probably be great to vary that slightly for every write, e.g. +/- 5% so not all cache entries expire at the same time.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Drupal 8 has separate field storage types Text (plain) and Text (formatted). There's also Text (plain, long) and Text (formatted, long). The important part here is that this selection is done on field storage level.

In Drupal 7, the text processing settings are defined on Field instance settings. In other words, the text processing settings can be plain text on one content type and filtered html on another.

In Drupal 6, the text processing settings are defined on global field settings which is equivalent of Drupal 8 field storage settings.

There are two issues on how text fields are migrated to Drupal 8.

• Drupal 7 text fields and long text fields are currently migrated to Drupal 8 as Text (formatted) / Text (formatted, long). This is problematic from two different aspects: a) single-line text fields are migrated as Text (formatted) which is rarely the desired behavior and b) migrating content of D7 plain text field to a Drupal 8 Text (formatted) field might have security implications if the content filtering settings are not correctly set.
• When analyzing the Drupal 7 issue mentioned above, it was identified that the Drupal 6 text formatting settings were not respected even though they can be mapped 1:1 to Drupal 8. This topic is handled as a separate child issue: #2849861: D6 text area formatting settings not respected when migrating to D8

Proposed resolution

For the Drupal 7 text fields, the proposed resolution is as follows:

* Common base for d7_field, d7_field_instance sources
* if the text or text_long field has only plain text instances, migrate to string or string_long field.
* If the text or text_long field has only filtered text instances, migrate to text or text_long field.
* if the text or text_long field has both plain text and filtered text instances, don't migrate and log a message indicating the required steps in order to fix this (fix the instances on the source site or use custom migration)
* If there are instances of both text-y and string-y types, string-y instances fall back to text with plain_text filter
* 'entity_exists' process plugin (to check for plain_text filter)
* 'log' process plugin (to log errors if the filter doesn't exist)

The proposed resolution for the Drupal 6 issue is covered in the child issue: #2849861: D6 text area formatting settings not respected when migrating to D8

Remaining tasks

• Agree if the proposed resolution is the way to go.


• Figure out how the D7 field instances can be fetched from the context of the field storage migration.


• Modify the field storage migration logic so that it takes the D7 instance filtering settings into account.
• Tests, lots of them.

User interface changes

None.

API changes

None, hopefully.

Data model changes

None, hopefully.

---clips---
When this issue was analyzed, all possible permutations of the Drupal 6 and Drupal 7 text fields were analyzed. The findings of this analysis is listed below for reference purposes.

Summary of the analysis: D7 - D8 migrations

Scenario ID: D7/1

D7 Field type: Text
D7 Widget type: Text field
D7 Global field settings: 255 or less
Current D8 field storage type: Text (formatted)

This scenario is currently being discussed in the comments of this issue. D7 text processing settings are on field instance settings, not in global field storage settings. It is not possible to determine the text processing from field instance settings so we need to choose if we want to migrate to Text (plain) or Text (formatted).

Single-line text fields are typically not used for formatted text (but of course it is possible that this would be the case). It is being proposed that we would change the migration of this scenario so that the target D8 field type would be Text (plain) instead of Text (formatted).

Scenario ID: D7/2

D7 Field type: Text
D7 Widget type: Text field
D7 Global field settings: 256 or more
Current D8 field storage type: Text (formatted)

This scenario has a bug: if the field length exceeds 255 characters, we have data loss because the current D8 target field type Text (formatted) is limited to 255 characters. Child issue has been created to change the target field type to Text (formatted, long). See #2849864: D7 text fields with long field length incorrectly migrated to D8.

This scenario is currently being discussed in the comments of this issue. The same comments as in the scenario D7/1 apply with the exception that the discussion is whether the D8 target field type should be Text (plain, long) or Text (formatted, long). Update: now that the field length is working as expected, this scenario is effectively same as D7/1. In other words, the question is between Text (plain) vs. Text (formatted).

Scenario ID: D7/3

D7 Field type: Long text
D7 Widget type: Text area (multiple rows)
D7 Global field settings: n/a
Current D8 field storage type: Text (formatted, long)

No issues found in the analysis. No changes proposed. This scenario is here for reference purposes only.

Scenario ID: D7/4

D7 Field type: Long text and summary
D7 Widget type: Text area with summary
D7 Global field settings: n/a
Current D8 field storage type: Text (formatted, long, with summary)

No issues found in the analysis. No changes proposed. This scenario is here for reference purposes only.

Summary of the analysis: D6 - D8 migrations

Scenario ID: D6/1

D6 Field type: text
D6 Widget type: Text field
D6 Global field settings: a) Text processing Plain text b) max length less than 256
Current D8 field storage type: Text (plain)

No issues found in the analysis. No changes proposed. This scenario is here for reference purposes only.

Scenario ID: D6/2

D6 Field type: text
D6 Widget type: Text field
D6 Global field settings: a) Text processing Plain b) max length greater than 255.
Current D8 field storage type: Text (plain, long)

No issues found in the analysis. No changes proposed. This scenario is here for reference purposes only.

Scenario ID: D6/3

D6 Field type: text
D6 Widget type: Text field
D6 Global field settings: a) Text processing Plain b) max length not defined
Current D8 field storage type: Text (plain, long)

No issues found in the analysis. No changes proposed. This scenario is here for reference purposes only.

Scenario ID: D6/4

D6 Field type: text
D6 Widget type: Text field
D6 Global field settings: a) Text processing Filtered text b) max length less than 256
Current D8 field storage type: Text (formatted)

No issues found in the analysis. No changes proposed. This scenario is here for reference purposes only.

Scenario ID: D6/5

D6 Field type: text
D6 Widget type: Text field
D6 Global field settings: a) Text processing Filtered text b) max length greater than 255
Current D8 field storage type: Text (formatted, long)

No issues found in the analysis. No changes proposed. This scenario is here for reference purposes only.

Scenario ID: D6/6

D6 Field type: text
D6 Widget type: Text field
D6 Global field settings: a) Text processing Filtered text b) max length not defined
Current D8 field storage type: Text (formatted, long)

No issues found in the analysis. No changes proposed. This scenario is here for reference purposes only.

Scenario ID: D6/7

D6 Field type: text
D6 Widget type: Text area (multiple rows)
D6 Global field settings: a) Text processing Plain b) max length: does not matter
Current D8 field storage type: Text (formatted, long)

The analysis revealed a bug in this scenario. D6 has text processing on global settings. If the text processing has been set to Plain Text in D6, that should be maintained in the migration. A child issue has been created to handle this issue. See #2849861: D6 text area formatting settings not respected when migrating to D8

Scenario ID: D6/8

D6 Field type: text
D6 Widget type: Text area (multiple rows)
D6 Global field settings: a) Text processing Filtered text b) max length: does not matter
Current D8 field storage type: Text (formatted, long)

No issues found in the analysis. No changes proposed. This scenario is here for reference purposes only.

Scenario ID: D6/9

D6 Field type: text
D6 Widget type: Select list
D6 Global field settings: Does not matter
Current D8 field storage type: List (text)

No issues found in the analysis. No changes proposed. This scenario is here for reference purposes only.

Scenario ID: D6/10

D6 Field type: text
D6 Widget type: Check boxes / radio buttons
D6 Global field settings: Does not matter
Current D8 field storage type: List (text)

No issues found in the analysis. No changes proposed. This scenario is here for reference purposes only.

Scenario ID: D6/11

D6 Field type: text
D6 Widget type: Single on/off checkbox
D6 Global field settings: Does not matter
Proposal for D8 migration: Boolean

No issues found in the analysis. No changes proposed. This scenario is here for reference purposes only.

Run eslint --fix on the codebase.

Before: 7088 issues
After: 1288 issues

While there are a lot of changes in the es6 files, it doesn't impact the compiled js files too much. Major since it "Cause a significant admin- or developer-facing bug with no workaround."

I get some test failures if the db driver is set to avoid transaction management. Not sure if these are purely related to test code, or if there are real bugs.

Problem/Motivation

Creating a checkbox field ( boolean ) in a content type and giving it a default value only works for new content,
thats also mentioned in the field default value description ( see attached image).
In our case : we have many content types , and we add a checkbox field to all of the content types when a specific "module" is enabled , so we create an instance of this field for each type. after creating the field , content types edit forms have a new field (checkbox) that is checked by default in our case , that works fine ,
but the problem is with the already existing nodes before enabling our module, those old nodes wont get the default value of the checkbox.
the checkbox in this case has no value.

Proposed resolution

Our proposed solution is in
function options_field_widget_form(&$form, &$form_state, $field, $instance, $langcode, $items, $delta, $element) {}
under = > /modules/field/modules/options/options.module

the #default_value should be changed from
'#default_value' => (isset($default_value[0]) && $default_value[0] == $on_value) ? 1 : 0,
to
'#default_value' => (isset($default_value[0]) && $default_value[0] != $on_value) ? 0 : 1,

Remaining tasks

(reviews needed, tests)

Quoting @effulgentsia in #2428703: Add a 'user.permissions' cache context (was: "Should cache contexts be able to associate a cache tag?"):

How about this to address #74: we embed the hierarchy in the context name / service ID only when that hierarchy is intrinsic to the meaning of the context, not merely an implementation choice.

[…]

In a followup, I think we can add a service tag to convey an implementation-driven parent relationship. For example:

  cache_context.pagers:
   ...
    tags:
      - { name: cache.context, parent: cache_context.url.query_args:page }
  cache_context.route:
    ...
    tags:
      - { name: cache.context, parent: cache_context.url }

And thereby allow CacheContexts::optimizeTokens() to optimize for implementations where pagers are solely determined by a single URL query argument and routing is done exclusively by URL.

Background
In D8 the default access settings are simple: there is a single 'administer users' permission that controls editing other users.

More complex schemes are possible using contrib modules to allow selective editing of other users under certain conditions. An example of such a module is Administer Users by Role. I am the maintainer of this module, trying to port it to D8.

Problem
contrib modules cannot grant field-level access to some fields on the user. For example, in a view of users, the "status" column will not be present except to a user with 'administer users' permission.

• The code in the contrib module can implement hook_ENTITY_TYPE_access() for entity type "user" which works to allow editing of the user.
• The code in the contrib module can implement hook_entity_field_access, but this doesn't work because the default code in UserAccessControlHandler has set AccessResult::forbidden().

The documentation here states

Note: Even a single module returning an AccessResultInterface object from hook_node_access() whose isForbidden() method equals TRUE will block access to the node. Therefore, implementers should take care to not deny access unless they really intend to. Unless a module wishes to actively forbid access it should return an AccessResultInterface object whose isAllowed() nor isForbidden() methods return TRUE, to allow other modules or the node_access table to control access.

Solution
UserAccessControlHandler should set AccessResult::neutral. This prevents access by default, but allows other modules to override.

The password field is an exception because it should be forbidden for any user to read it under any circumstances.

Patch coming.

Migrating a Drupal 6.x (6.38) without any translations fails when trying to migrate i18n variables with the following output:

Migration failed with source plugin exception: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'db_name.prefix_i18n_variable' doesn't exist:
SELECT v.*
FROM
{i18n_variable} v
WHERE name IN (:db_condition_placeholder_0); Array
(
    [:db_condition_placeholder_0] => site_offline_message
)

Activating and installing Locale module on the 6.x installation makes no difference. In fact I can't find any reference to i18n_variable at all in the 6.x core download.

Problem/Motivation

Content editors are unable to re-save existing, translatable draft content as draft again. After hitting "Save and Create New Draft", an EntityStorageException is thrown:

Drupal\Core\Entity\EntityStorageException: The state '' does not exist in workflow 'editorial' in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 770 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Drupal\content_moderation\EntityOperations->isDefaultRevisionPublished(Object, Object) (Line: 112)
Drupal\content_moderation\EntityOperations->entityPresave(Object) (Line: 81)
content_moderation_entity_presave(Object)
call_user_func_array('content_moderation_entity_presave', Array) (Line: 402)
Drupal\Core\Extension\ModuleHandler->invokeAll('entity_presave', Array) (Line: 169)
Drupal\Core\Entity\EntityStorageBase->invokeHook('presave', Object) (Line: 441)
Drupal\Core\Entity\ContentEntityStorageBase->invokeHook('presave', Object) (Line: 435)
Drupal\Core\Entity\EntityStorageBase->doPreSave(Object) (Line: 298)
Drupal\Core\Entity\ContentEntityStorageBase->doPreSave(Object) (Line: 389)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 761)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object) (Line: 364)
Drupal\Core\Entity\Entity->save() (Line: 286)
Drupal\node\NodeForm->save(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 585)
Drupal\Core\Form\FormBuilder->processForm('node_article_edit_form', Array, Object) (Line: 314)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 74)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array) (Line: 144)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 64)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 656)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Steps to reproduce

1. Install Drupal with the standard profile
2. Enable Content Moderation and Content Translation modules
3. Enable "Editorial workflow" for the Article content type.
4. Add a new Article. Save it as draft, and then edit it again and save the changes as draft.
   There won't be any errors and the changes will be saved
5. Add an additional language and enable translation for the Article node, and only for that type.
6. Add an another test article again, repeat 4th step (above).
   Exception will be thrown
7. Now repeat the 4th step with the Basic page content type as well
   Exception will be thrown

Drupal Core 8.3.x is also affected.

Drupal Core 8.2.x (without the Workflow module) throws Fatal error: Call to a member function isPublishedState() on null in [docroot]/core/modules/content_moderation/src/EntityOperations.php on line 263. I'll post that as a standalone issue immediately.

Problem/Motivation

The overall goal is to make more site edit/build functionality available directly on the frontend of your site (“turning Drupal outside in”). A current example of this is the "Edit" button (toggle) top right in the toolbar:

This button in itself has usability issues but new developments like #2724819: Create experimental module for place block on any page feature are adding their own seperate links to the toolbar. Which obviously does not scale well:

We need to find a way to scale this pattern so that besides content editing we can also expose interactions for "add new", "rearrange" and others. The general idea could be to have a global View/Edit/Build toggle for example which could show a sidebar with applicable tools.

Proposed resolution

Image links to attached video

Trigger an "edit mode" in which links are disabled but all blocks are tap/clickable. Taps/clicks trigger an off-canvas configuration tray which separates content and configuration tasks into two tabs (the above prototype shows the toggle and off-canvas tray integrated with the experimental "place block" module).

Remaining tasks

- List potential interactions to expose
- Rank them: what are the 80% use cases, which are more on the side of 20%?
- Define an initial scope
- What are existing contrib solutions in this space?
- Explore designs options
- Prototype, test, iterate
- Decide on the preferred design
- Write up a spec
- Write the patch (in a followup issue?)

User interface changes

See child issues.

Problem/Motivation

Steps to reproduce:
1. Enable content moderation module and enable default workflow for article content type (at admin/config/workflow/workflows/manage/editorial)
1. Create article with alias /hello
2. Create a new draft of that article with filling in /hello2 as the url alias
3. The article is immediately accessible at /hello2 and not at /hello

Proposed resolution

Probably #2336597: Convert path aliases to full featured entities.

Alternatively add validation to stop people changing that value unless it's the default revision as a stopgap?

Remaining tasks

User interface changes

API changes

Data model changes

$remove_role_plugin = new AddRoleUser($config, 'user_add_role_action', ['type' => 'user'], $this->userRoleEntityType);

$remove_role_plugin->execute($this->account);

I guess it was borrowed from RemoveRoleUserTest class.