File upload (on a Basic page) has suddenly stopped working for me. This has worked hundreds of times previously, including a couple hours ago, and just now stopped working. I changed nothing in between.

When I click on the file upload ("Choose Files") button, it allows me to select a file, and I get a progress indication cursor. But when the progress indicator quits (after a little while, as it should), I don't get Description dialog box, and there's no indication the file got uploaded. Checking the server-side file system also indicates the file didn't get uploaded.

Of course, I could always upload the file by other means (e.g., scp), but that wouldn't give the on-page reference, as is convenient.

The function template_preprocess_file_link() in core/modules/file/file.module starts out like this:

function template_preprocess_file_link(&$variables) {
  $file = $variables['file'];
  $options = [];

  $file_entity = ($file instanceof File) ? $file : File::load($file->fid);
  // @todo Wrap in file_url_transform_relative(). This is currently
  // impossible. As a work-around, we currently add the 'url.site' cache context
  // to ensure different file URLs are generated for different sites in a
  // multisite setup, including HTTP and HTTPS versions of the same site.
  // Fix in https://www.drupal.org/node/2646744.
  $url = $file_entity->createFileUrl(FALSE);
  $variables['#cache']['contexts'][] = 'url.site';

  $mime_type = $file->getMimeType();
  // Set options as per anchor format described at
  // http://microformats.org/wiki/file-format-examples
  $options['attributes']['type'] = $mime_type . '; length=' . $file->getSize();

Note how it tries to be backward-compatible with the passing of a stdClass object in $variables['file'] by calling File::load() to load a File object. However, these lines will cause an exception:

  $mime_type = $file->getMimeType();
  $options['attributes']['type'] = $mime_type . '; length=' . $file->getSize();

because they are using $file, not $file_entity.

These lines should either be fixed to use $file_entity, or support for passing a stdClass object should be completely removed.

Problem/Motivation

follow up #3041659: Remove the layout tab from translations because Layout Builder does not support translations yet

Part of #3044386: [META] Make Layout Builder layouts translatable

Right now you are not able to translate layouts at all.

The most common use case is probably translating the block labels and inline blocks but having the actual layouts not change from language to language. For different layout per language: see #3040487: Allow Independent Layout Override Translations

Proposed resolution

1. Provide access to the Layout table on translations
2. On Translations the Layout builder would only allow translating labels and inline blocks
3. Translated settings for block would be stored a new field that would be translatable(the current Layout field would still be untranslatable)
4. Most blocks could only have labels as translated settings
5. Inline blocks could additionally have a block revision ID stored.

Remaining tasks

• Get#3013197: Cloning an implementation of SectionListInterface does not deep clone the Section or SectionComponent objectscommitted.
• Write more tests for Inline blocks. <-- We are here.

User interface changes

API changes

Data model changes

Problem/Motivation

Currently all the field blocks in layout builder are being rendered in ---custom view modes. Having field templates for user defined view modes is not possible at the moment, and hence not able to get the required markup for the page when using layout builder.

This is due to usage of \Drupal\Core\Entity\EntityDisplayBase::CUSTOM_MODE in \Drupal\layout_builder\Plugin\Block\FieldBlock::getFormatter()

Proposed resolution

Force the field blocks to render with the view mode template suggestion that is used at the Layout Builder level

Remaining tasks

Decide if Layout Builder should provide an additional suggestion or just expose the info

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Problem/Motivation

When uploading a new file using the Media Library module, the "Add File" action fails to upload the file and silently throws a console error. This error occurs every time with every media type for our site.

Steps to reproduce:

1. Choose a node that contains a media field for editing using the "Add media" button.
2. In the resulting "Add or select media" lightbox, click the "Choose File" button in the "Add File" section.
3. Choose a file of the appropriate media type.
4. At this point, a progress spinner is shown then disappears. Nothing further occurs and the file is not added to the library.
5. Check the console log to see the Ajax error:
   

   An AJAX HTTP error occurred.
   
   HTTP Result Code: 200
   
   Debugging information follows.
   
   Path: /media-library?media_library_opener_id=field%3Afield_documents_media_&media_library_allowed_types%5Bbasic_image%5D=basic_image&media_library_allowed_types%5Bdocuments%5D=documents&media_library_allowed_types%5Bicon%5D=icon&media_library_allowed_types%5Blocation_photos%5D=location_photos&media_library_allowed_types%5Bremote_video%5D=remote_video&media_library_selected_type=basic_image&media_library_remaining=1&hash=wFpjTCU6C4We9HKZWN4uK4B2cxaXeEhPCddqHR-vBKQ&media_library_content=1&_wrapper_format=drupal_ajax&ajax_form=1
   
   StatusText: parsererror
   
   ResponseText: Notice: Undefined index: #parents in /app/web/core/modules/media_library/src/Form/AddFormBase.php on line 250
   
   [...]

OS: nginx/1.14.2
Database: 5.5.5-10.1.38-MariaDB
PHP 7.2.15
Drupal 8.7.0

Proposed resolution

Adding a null check to AddFormBase.php:buildEntityFormElement():250 allowed me to successfully upload files (patch file to follow in comments).

-    $parents = $form['#parents'];
+    if (array_key_exists("#parents", $form)) {
+      $parents = $form['#parents'];
+    }
+    else {
+      $parents = [];
+    }

Hi,

I have figured a way to access views views row fields inside views-view-unformatted.html.twig

{% for row in rows %}

  {{ row.content['#view'].style_plugin.render_tokens[ loop.index0 ]['{{ YOUR_FIELD_NAME }}'] }}

{% endfor %}

I need to know what do you think of this method, is it cool or bad.

The reason why I avoid using views-view-fields.html.twig is that I use lots of views with many displays, and I don't wan't to use lots of template overrides.

Hi, When I try to update Drupal 8.7.0 db br drush updb I get the following error.

>  [notice] Update started: taxonomy_post_update_make_taxonomy_term_revisionable
>  [error]  Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'name' cannot be null: INSERT INTO {tmp_d305d9taxonomy_term_field_data} (tid, revision_id, vid, langcode, name, description__value, description__format, weight, changed, default_langcode, status, revision_translation_affected) 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, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11); Array
> (
>     [:db_insert_placeholder_0] => 1
>     [:db_insert_placeholder_1] => 1
>     [:db_insert_placeholder_2] => tags
>     [:db_insert_placeholder_3] => tr
>     [:db_insert_placeholder_4] =>
>     [:db_insert_placeholder_5] =>
>     [:db_insert_placeholder_6] =>
>     [:db_insert_placeholder_7] =>
>     [:db_insert_placeholder_8] =>
>     [:db_insert_placeholder_9] =>
>     [:db_insert_placeholder_10] =>
>     [:db_insert_placeholder_11] => 1
> )
>  in Drupal\Core\Database\Connection->handleQueryException() (line 689 of /var/www/drupal8/web/core/lib/Drupal/Core/Database/Connection.php).
>  [error]  The entity update process failed while processing the entity type taxonomy_term, ID: 1.
>  [error]  Update failed: taxonomy_post_update_make_taxonomy_term_revisionable
 [error]  Update aborted by: taxonomy_post_update_make_taxonomy_term_revisionable
 [error]  Finished performing updates.

Problem/Motivation

To reproduce:

1. Using 8.7.x
2. Enable Layout Builder and Allow overrides on Basic page
3. Install Media and Media library module
4. Add a Media reference (Image bundle) and use Media library form widget to the Basic block type
5. Create a new node
6. Try add a custom block and upload a media

, when pressing Add block, two blocks are added.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

With a reasonable site, the number of revisions for an entity can build up quite easily.

Proposed resolution

Provide a bulk action for admins to clear out extraneous revisions.

Remaining tasks

Code and UX reviews

User interface changes

New action

API changes

Data model changes

Release notes snippet

A new action is available on the admin/content view allowing content-admins to remove old revisions in bulk.

Original report

An action to delete all old revisions of a node in Drupal 8 would be very helpful on the administer content overview for example. Furthermore log entires should document that deletion.

Hi,

When I trying to update Drupal core to 8.7.0 using composer I am getting the following error.

$ composer require drupal/core:8.7.0 --update-with-dependencies

Your requirements could not be resolved to an installable set of packages.

Problem 1
- Can only install one of: egulias/email-validator[2.0.x-dev, 1.2.14].
- Can only install one of: egulias/email-validator[2.0.x-dev, 1.2.14].
- Can only install one of: egulias/email-validator[2.0.x-dev, 1.2.14].
- drupal/core 8.7.0 requires egulias/email-validator ^2.0 -> satisfiable by egulias/email-validator[2.0.x-dev].
- Installation request for drupal/core 8.7.0 -> satisfiable by drupal/core[8.7.0].
- Installation request for egulias/email-validator (locked at 1.2.14, required as ^1.2) -> satisfiable by egulias/email-validator[1.2.14].

When I try to update the egulias/email-validator[ package separately it shows:
$ composer require egulias/email-validator:2.0.1 --update-with-dependencies

Your requirements could not be resolved to an installable set of packages.

Problem 1
- Installation request for egulias/email-validator 2.0.1 -> satisfiable by egulias/email-validator[2.0.1].
- Can only install one of: egulias/email-validator[2.0.1, 1.2.x-dev].
- Installation request for egulias/email-validator ^1.2 -> satisfiable by egulias/email-validator[1.2.x-dev].

Drupal 8.6.15 reqquires email-validator with ^1.2 version and 8.7.0 requires ^2.0 email-validator.

Any solution? help please.

Problem/Motivation

To reproduce:

1. Using 8.7.x
2. Enable Layout Builder and Allow overrides on Basic page
3. Install Media and Media library module
4. Add a Media reference (Image bundle) and use Media library form widget to the Basic block type
5. Create a new node
6. Try to add/edit a custom block and upload a media
7. Media Library widget does not work (should open Media Library popup)

Works as expected when editing custom block independently from LB.
Also, the same setup worked in 8.6.x :( regression?
Also, does not work with IEF widget.

Proposed resolution

Fix Ajax subform handling inside block config form.

http://jsonapi.org/format/#crud

Problem/Motivation

While working on #2931785: The path for JSON API to core, I think we overlooked one very important thing wrt spec compliance. The fact that the JSON API module for Drupal incorporates two spec extensions:

1. Fancy filters: https://gist.github.com/e0ipso/efcc4e96ca2aed58e32948e4f70c2460
2. Partial success: https://gist.github.com/e0ipso/732712c3e573a6af1d83b25b9f0269c8

… yet we support Accept: application/vnd.api+json and Content-Type: application/vnd.api+json. Which signifies we're implementing the base spec. Additionally, we're not even mentioning in jsonapi.api.php that this module implements more than just the base spec!

http://jsonapi.org/format/#content-negotiation says:

Content Negotiation

Client Responsibilities

Clients MUST send all JSON API data in request documents with the header
Content-Type: application/vnd.api+json without any media type parameters.

Clients that include the JSON API media type in their Accept header MUST
specify the media type there at least once without any media type parameters.

Clients MUST ignore any parameters for the application/vnd.api+json
media type received in the Content-Type header of response documents.

Server Responsibilities

Servers MUST send all JSON API data in response documents with the header
Content-Type: application/vnd.api+json without any media type parameters.

Servers MUST respond with a 415 Unsupported Media Type status code if
a request specifies the header Content-Type: application/vnd.api+json
with any media type parameters.

Servers MUST respond with a 406 Not Acceptable status code if a
request’s Accept header contains the JSON API media type and all instances
of that media type are modified with media type parameters.

Note: The content negotiation requirements exist to allow future versions
of this specification to use media type parameters for extension negotiation
and versioning.

… and sadly, JSON API's extension system was reverted. http://jsonapi.org/extensions/ currently says An extension system is currently under development […]… on May 21, 2015.

In https://github.com/json-api/json-api/issues/614, Roy Fielding (of REST fame) is quoted to have written that media type negotiation like vnd.api+json is meaningless. He clarified his statement at https://github.com/json-api/json-api/issues/614#issuecomment-101741478. That issue spawned https://github.com/json-api/json-api/pull/650, which tried to improve things, but it was considered "too late before the imminent 1.0 release". Then, ironically, it is https://github.com/json-api/json-api/pull/660, which is mentioned nor linked in neither of the two issues above (614 an 650), and it simply removed the concept of/support for extensibility altogether. This was May 21, 2015.

It was worked on a bit in November 2015, in https://github.com/json-api/json-api/issues/915. Again in December 2015, in https://github.com/json-api/json-api/pull/957. And then again in https://github.com/json-api/json-api/pull/1195, in July 2017. And finally, https://github.com/json-api/json-api/issues/1207 in August 2017.

https://github.com/json-api/json-api/issues/1207 is the latest and greatest, confirmed by spec author dgeb at https://github.com/orbitjs/orbit/issues/479#issuecomment-358654119 on Jan 18, 2018. but it still hasn't actually gone anywhere — there's still nothing spec implementers can actually do …

Finally, note that http://jsonapi.org/format/#content-negotiation (quoted in full above) says the server must send an error response if any media type parameters are specified!

Proposed resolution

1. Update jsonapi.api.php to state that the JSON API module implements the base spec + 2 extensions
2. Figure out how to communicate in our HTTP responses that it's the base spec + 2 extensions … even though the JSON API spec literally forbids it, and there's a whole string of GitHub issues: 614, 650, 660, 915, 957, 1207.

Remaining tasks

Discuss!

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Hi, folks look like I having problems since #3038308: Avoid translations DELETE data loss and unintended changes with PATCH and test all methods against entity route parameter translation upcasting.

I can't PATCH my custom content entity since I updated module 2.3.0 => 2.4.0.

I have a custom content entity type, which is not translatable. The site is installed on different from the English language.

For example I send this request:

{
   "data":{
      "attributes":{
         "due_date":"2019-03-02"
      },
      "id":"d38dc101-4c91-4522-a0c6-56e86a660802",
      "type":"scrm-issue--scrm-issue"
   }
}

And got this response:

{
   "jsonapi":{
      "version":"1.0",
      "meta":{
         "links":{
            "self":{
               "href":"http:\/\/jsonapi.org\/format\/1.0\/"
            }
         }
      }
   },
   "errors":[
      {
         "title":"Method Not Allowed",
         "status":"405",
         "detail":"The requested translation of the resource object does not exist, instead modify one of the translations that do exist: und.",
         "links":{
            "via":{
               "href":"http:\/\/scrm.localhost\/jsonapi\/scrm_issue\/scrm_issue\/d38dc101-4c91-4522-a0c6-56e86a660802"
            },
            "info":{
               "href":"http:\/\/www.w3.org\/Protocols\/rfc2616\/rfc2616-sec10.html#sec10.4.6"
            }
         },
         "source":{
            "file":"\/var\/www\/html\/web\/modules\/contrib\/jsonapi\/src\/ParamConverter\/EntityUuidConverter.php",
            "line":78
         },
         "meta":{
            "exception":"Symfony\\Component\\HttpKernel\\Exception\\MethodNotAllowedHttpException: The requested translation of the resource object does not exist, instead modify one of the translations that do exist: und. in \/var\/www\/html\/web\/modules\/contrib\/jsonapi\/src\/ParamConverter\/EntityUuidConverter.php:78\nStack trace:\n#0 \/var\/www\/html\/web\/core\/lib\/Drupal\/Core\/ParamConverter\/ParamConverterManager.php(100): Drupal\\jsonapi\\ParamConverter\\EntityUuidConverter-\u003Econvert(\u0027d38dc101-4c91-4...\u0027, Array, \u0027entity\u0027, Array)\n#1 \/var\/www\/html\/web\/core\/lib\/Drupal\/Core\/Routing\/Enhancer\/ParamConversionEnhancer.php(45): Drupal\\Core\\ParamConverter\\ParamConverterManager-\u003Econvert(Array)\n#2 \/var\/www\/html\/web\/core\/lib\/Drupal\/Core\/Routing\/Router.php(260): Drupal\\Core\\Routing\\Enhancer\\ParamConversionEnhancer-\u003Eenhance(Array, Object(Symfony\\Component\\HttpFoundation\\Request))\n#3 \/var\/www\/html\/web\/core\/lib\/Drupal\/Core\/Routing\/Router.php(131): Drupal\\Core\\Routing\\Router-\u003EapplyRouteEnhancers(Array, Object(Symfony\\Component\\HttpFoundation\\Request))\n#4 \/var\/www\/html\/web\/core\/lib\/Drupal\/Core\/Routing\/AccessAwareRouter.php(92): Drupal\\Core\\Routing\\Router-\u003EmatchRequest(Object(Symfony\\Component\\HttpFoundation\\Request))\n#5 \/var\/www\/html\/vendor\/symfony\/http-kernel\/EventListener\/RouterListener.php(115): Drupal\\Core\\Routing\\AccessAwareRouter-\u003EmatchRequest(Object(Symfony\\Component\\HttpFoundation\\Request))\n#6 [internal function]: Symfony\\Component\\HttpKernel\\EventListener\\RouterListener-\u003EonKernelRequest(Object(Symfony\\Component\\HttpKernel\\Event\\GetResponseEvent), \u0027kernel.request\u0027, Object(Drupal\\Component\\EventDispatcher\\ContainerAwareEventDispatcher))\n#7 \/var\/www\/html\/web\/core\/lib\/Drupal\/Component\/EventDispatcher\/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\\Component\\HttpKernel\\Event\\GetResponseEvent), \u0027kernel.request\u0027, Object(Drupal\\Component\\EventDispatcher\\ContainerAwareEventDispatcher))\n#8 \/var\/www\/html\/vendor\/symfony\/http-kernel\/HttpKernel.php(127): Drupal\\Component\\EventDispatcher\\ContainerAwareEventDispatcher-\u003Edispatch(\u0027kernel.request\u0027, Object(Symfony\\Component\\HttpKernel\\Event\\GetResponseEvent))\n#9 \/var\/www\/html\/vendor\/symfony\/http-kernel\/HttpKernel.php(68): Symfony\\Component\\HttpKernel\\HttpKernel-\u003EhandleRaw(Object(Symfony\\Component\\HttpFoundation\\Request), 1)\n#10 \/var\/www\/html\/web\/core\/lib\/Drupal\/Core\/StackMiddleware\/Session.php(57): Symfony\\Component\\HttpKernel\\HttpKernel-\u003Ehandle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#11 \/var\/www\/html\/web\/core\/lib\/Drupal\/Core\/StackMiddleware\/KernelPreHandle.php(47): Drupal\\Core\\StackMiddleware\\Session-\u003Ehandle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#12 \/var\/www\/html\/web\/core\/modules\/page_cache\/src\/StackMiddleware\/PageCache.php(99): Drupal\\Core\\StackMiddleware\\KernelPreHandle-\u003Ehandle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#13 \/var\/www\/html\/web\/core\/modules\/page_cache\/src\/StackMiddleware\/PageCache.php(78): Drupal\\page_cache\\StackMiddleware\\PageCache-\u003Epass(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#14 \/var\/www\/html\/web\/modules\/contrib\/jsonapi\/src\/StackMiddleware\/FormatSetter.php(45): Drupal\\page_cache\\StackMiddleware\\PageCache-\u003Ehandle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#15 \/var\/www\/html\/web\/core\/lib\/Drupal\/Core\/StackMiddleware\/ReverseProxyMiddleware.php(47): Drupal\\jsonapi\\StackMiddleware\\FormatSetter-\u003Ehandle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#16 \/var\/www\/html\/web\/core\/lib\/Drupal\/Core\/StackMiddleware\/NegotiationMiddleware.php(52): Drupal\\Core\\StackMiddleware\\ReverseProxyMiddleware-\u003Ehandle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#17 \/var\/www\/html\/vendor\/stack\/builder\/src\/Stack\/StackedHttpKernel.php(23): Drupal\\Core\\StackMiddleware\\NegotiationMiddleware-\u003Ehandle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#18 \/var\/www\/html\/web\/core\/lib\/Drupal\/Core\/DrupalKernel.php(693): Stack\\StackedHttpKernel-\u003Ehandle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#19 \/var\/www\/html\/web\/index.php(19): Drupal\\Core\\DrupalKernel-\u003Ehandle(Object(Symfony\\Component\\HttpFoundation\\Request))\n#20 {main}",
            "trace":[
               {
                  "file":"\/var\/www\/html\/web\/core\/lib\/Drupal\/Core\/ParamConverter\/ParamConverterManager.php",
                  "line":100,
                  "function":"convert",
                  "class":"Drupal\\jsonapi\\ParamConverter\\EntityUuidConverter",
                  "type":"-\u003E",
                  "args":[
                     "d38dc101-4c91-4522-a0c6-56e86a660802",
                     {
                        "type":"entity:scrm_issue",
                        "converter":"paramconverter.jsonapi.entity_uuid"
                     },
                     "entity",
                     {
                        "_controller":"jsonapi.entity_resource:patchIndividual",
                        "resource_type":"scrm_issue--scrm_issue",
                        "_is_jsonapi":true,
                        "entity":"d38dc101-4c91-4522-a0c6-56e86a660802",
                        "_route":"jsonapi.scrm_issue--scrm_issue.individual.patch",
                        "_route_object":{

                        },
                        "_raw_variables":{

                        }
                     }
                  ]
               },
               {
                  "file":"\/var\/www\/html\/web\/core\/lib\/Drupal\/Core\/Routing\/Enhancer\/ParamConversionEnhancer.php",
                  "line":45,
                  "function":"convert",
                  "class":"Drupal\\Core\\ParamConverter\\ParamConverterManager",
                  "type":"-\u003E",
                  "args":[
                     {
                        "_controller":"jsonapi.entity_resource:patchIndividual",
                        "resource_type":"scrm_issue--scrm_issue",
                        "_is_jsonapi":true,
                        "entity":"d38dc101-4c91-4522-a0c6-56e86a660802",
                        "_route":"jsonapi.scrm_issue--scrm_issue.individual.patch",
                        "_route_object":{

                        },
                        "_raw_variables":{

                        }
                     }
                  ]
               },
…

Sorry for this big response code, but I want to provide full information.

All entities created via JSON:API or Drupal UI get und(?) langcode in JSON:API, but in fact, the default langcode for site is ru.

And I don't understand how to patch it correctly for now. Trying to add prefix /und/ and /ru/ to the URL of JSON:API, and they throw 404 error.

Problem/Motivation

I'm creating a proof-of-concept for richer hypermedia using JSON:API in the jsonapi_hypermedia module. I'm unable to create rich target attributes for those hypermedia links because of an assertion in the Link constructor:

    assert(Inspector::assertAll(function ($target_attribute_value) {
      return is_string($target_attribute_value)
        || is_array($target_attribute_value)
        && Inspector::assertAllStrings($target_attribute_value);
    }, array_values($target_attributes)));

Proposed resolution

Remove Inspector::assertAllStrings($target_attribute_value).

Remaining tasks

Review
Commit

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

The "content_moderation_state" entity is a mechansim for tracking state information about content entities. It is exposed through a computed field on entities called moderation_state.

Previously a views relationship was required from entities to "content_moderation_state" in order to display and filter by state. Ideally users shouldn't need to understand how states are stored and should just be able to reason about the "moderation_state" field on their moderated entities directly. For this reason, lets provide first class filtering and displaying of the state by way of the computed field.

Blockers:

#2862041: Provide useful Views filters for Content Moderation State fields
#2852067: Add support for rendering computed fields to the "field" views field handler

Given the "content_moderation_state" entity is going to become @internal, we shouldn't allow people to add a relationship to it. There shouldn't be a reason to once the above blockers are resolved.

Proposed resolution

Remove the views relationship to this entity type.

Remaining tasks

User interface changes

API changes

Data model changes

Backport of #2820611: FileStorage generated .htaccess doesn't cover PHP 7

User can't change password from the forgot password or reset password screen.

User receives their one-time login email to change their password. Once clicked they are able to change their password. But when they are logging in again with their new password the system tells them that the password is wrong.

I am currently looking into running CKEditor in a modal dialog using the Drupal Modal API.

At this moment it is working OK, but there is a problem with the link and image modals which can be triggered from the CKEditor interface. Those also use the Modal API and when triggering one of these functions, the modal containing CKEditor is fully closed.

Is there any way to open de link/image modal without closing the CKEditor modal? It seems like it is possible to define the HTML element to which the modal should append when triggering. When overriding this setting ('appendTo' => '#foo'), even the link/image modals are appended to #foo (instead of the default '#drupal-modal').

Any ideas on how to get this to work?
Thanks for your support.

I get this error when i try to run the database update:

Failed: Drupal\Core\Entity\EntityStorageException: The entity update process    [error]
failed while processing the entity type menu_link_content, ID: 3. in
Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema->copyData() (line
216 of
D:\FILES\REPOS\detroitmi-test\docroot\core\lib\Drupal\Core\Entity\Sql\SqlFieldableEntityTypeListenerTrait.php).

Problem

Bartik sets a .field__label class only for .field--type-entity-reference and .field--name-field-tags. Instead it should inherit Classy's styling for those selectors as they are. (Currently on the field label of only these two fields, Bartik overrides the font-weight, lateral padding and font-size).

Steps to reproduce the problem

1. On a Standard install profile content type (e.g. Article), create an entity reference field.
2. Preserve the existing body field.
3. Under Manage display of a Content type, set both field labels to display the same way, either Above or Inline.
4. Create a node and add one word of content to each field.
5. View the node and note the field labels display different styling.

Expected behavior

All field label(s) use the same styling.

Proposed fix

Remove all calls to the .field__label class from the Bartik css, allowing Bartik to inherit Classy styling on each field label.