When one sets the layout of an Umami recipe page with Layout Builder to use more columns there is no vertical space between the content of columns when the page is displayed.

Problem/Motivation

At the moment the schema definition for the list of styles in ckeditor doesn't support translation.

# Plugin \Drupal\ckeditor\Plugin\ckeditor\plugin\StylesCombo
ckeditor.plugin.stylescombo:
  type: mapping
  label: 'Styles dropdown'
  mapping:
    styles:
      type: string
      label: 'List of styles'
      translatable: true

Proposed resolution

As this string contains labels we should enable translation.

settings:
  plugins:
    stylescombo:
      styles: "table.mytableclass|Label to translate for my table class"

Problem/Motivation

Drupal versions (8.6.4) prior to changes in issue #2946402: Content moderation incorrectly always assumes a language is being added when the default language of an entity is being changed being committed at this commit, content moderation created duplicate content_moderation_state_field_revision table records when changing a content item's language. These duplicate table records then cause an error after updating to 8.6.4 or later that included the above changes.

Steps To Reproduce

Steps taken from comment #19, see it for more details.

1. Start with Drupal 8.6.2
2. Create content and save as published with French language
3. Edit and change language to English, save and publish
4. Update to 8.6.7 or later and process updates
5. Edit same node and attempt to save
6. Observe the reported error, "A translation already exists for the specified language (en)."

Proposed resolution

As recommended in comment #22 and #29, use a hook_post_update_NAME() to delete dud translation data.

Remaining tasks

1. Write hook_post_update_NAME() to delete dud translation
2. Tests, fixtures?

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

TBD

Originally Reported

Attempting to save a page in English (default language).

When I click to save it I get the following error:
The website encountered an unexpected error. Please try again later.Drupal\Core\Entity\EntityStorageException: A translation already exists for the specified language (en). in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 783 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Drupal\Core\Entity\Plugin\DataType\EntityAdapter->onChange('langcode') (Line: 77)
Drupal\Core\TypedData\Plugin\DataType\ItemList->setValue(Array, 1) (Line: 107)
Drupal\Core\Field\FieldItemList->setValue(Array) (Line: 1089)
Drupal\Core\Entity\ContentEntityBase->__set('langcode', 'en') (Line: 188)
Drupal\content_moderation\EntityOperations->updateOrCreateFromEntity(Object) (Line: 149)
Drupal\content_moderation\EntityOperations->entityUpdate(Object) (Line: 100)
content_moderation_entity_update(Object)
call_user_func_array('content_moderation_entity_update', Array) (Line: 403)
Drupal\Core\Extension\ModuleHandler->invokeAll('entity_update', Array) (Line: 206)
Drupal\Core\Entity\EntityStorageBase->invokeHook('update', Object) (Line: 756)
Drupal\Core\Entity\ContentEntityStorageBase->invokeHook('update', Object) (Line: 507)
Drupal\Core\Entity\EntityStorageBase->doPostSave(Object, 1) (Line: 641)
Drupal\Core\Entity\ContentEntityStorageBase->doPostSave(Object, 1) (Line: 432)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 774)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object) (Line: 390)
Drupal\Core\Entity\Entity->save() (Line: 281)
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: 589)
Drupal\Core\Form\FormBuilder->processForm('node_landing_page_edit_form', Array, Object) (Line: 318)
Drupal\Core\Form\FormBuilder->buildForm('node_landing_page_edit_form', Object) (Line: 93)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
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}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
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: 38)
Drupal\webprofiler\StackMiddleware\WebprofilerMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 669)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

I expect it to save the node.

Currently, when using the date range module in core, and using a value from the range as the filter in a view, the result is a very slow query, that relies on a significant amount of computing per row within the database. An example is shown below. On a very small site, when doing a performance review, the view that relied on this comparison tested as the slowest page on the site.

Problem/Motivation

Since TestSiteInstallCommand supports install profile and langcode parameters, it would be a good idea to make them customizable in the drupalInstall command as well.

Proposed resolution

Add instappProfile and langode to drupalInstall.js.

Remaining tasks

Provide a patch.

User interface changes

Nothing.

API changes

New params in drupalInstall command.

Release notes snippet

@todo

module.exports = {
  '@tags': ['core'],
  before(browser) {
    browser.drupalInstall({
      setupFile: 'core/tests/Drupal/TestSite/TestSiteInstallTestScript.php',
      installProfile: 'standard',
      langcode: 'de',
    });
  },
  after(browser) {
    browser.drupalUninstall();
  },
  'Test page': browser => {
    browser
      .drupalRelativeURL('/test-page')
      .waitForElementVisible('body', 1000)
      .assert.containsText('body', 'Test page text')
      .drupalLogAndEnd({ onlyOnError: false });
  },
};

The global view result counter passes itself wrapped in double curly braces when rendered, rather than as an integer value. This patch fixes that by adding a render function in Drupal\views\Plugin\views\field\Counter.php.

So, for example, a drupalist can put a global view counter and a global custom text field in a view, and then to add filters to counter in the text replacement field.

Fields:
Global: View result counter
Global: Custom text

In the custom text field:
{% if counter is even %}
... do something ...
{% endif %}

This was before not possible, as the string "{{ counter }}" was passed to the "even" filter, rather than the value of counter itself.

Problem/Motivation

Custom blocks are now publishable, but the Custom block library page (/admin/structure/block/block-content) doesn't not reflect this change. Since the custom blocks as publish-able, make the UI close to node admin page (/admin/content):

This work was started In #2834546: UI for publishing/unpublishing block_content blocks, but it was decided to split the changes to block_content view and related into a follow up issue, because this requires an upgrade path.#2834546: UI for publishing/unpublishing block_content blocks should be committed before this issue gets in.

Proposed resolution

Introduce below changes:
1. Bulk operation form
2. Add published column
3. Add publish status filter

and write the upgrade path in this issue.

Remaining tasks

- Implementation - Done
- Manual testing - Done
- More reviews
- Commit!

User interface changes

Adds a bulk publish / unpublish actions and a new "published" column to the Custom block library page /admin/structure/block/block-content

API changes

None

Data model changes

None

The Migration Lookup plugin relies on deprecated method MigrateIdMapInterface::lookupDestinationId(), which passes control over to MigrateIdMapInterface::lookupDestinationIds(), then filters out all but the first value returned.

This causes multiple-valued migration lookups to always match only one item.

The attached patch uses lookupDestinationsIds() directly and corrects this behavior.

Current behavior

Ran into some unexpected behavior when trying to use filters with multiple values:

filter[ids][condition][path]=id&filter[ids][condition][value][]=UUID1&filter[ids][condition][value][]=UUID2&page[offset]=0&page[limit]=50

If you use these filter parameters JSON:API returns a 500 response telling you that the query failed.

Talked with @gabesullice and seems like making the default operator IN when multiple values are provided makes the most sense:

I think that if we detect multiple values we should assume `IN`

Expected behavior

JSON:API should assume the `IN` operator when provided multiple filter values.

At the very least, that should be a 400 error, not a 500 for sure

Please also consider those that participated in #2714089: Views Filter by an entity reference view not working as expected when assigning issue credit. Done, see #84.

Problem/Motivation

When an entity relation field displays options via a view the view fields are not used, instead it is the entity label. This is a regression from Drupal 7.x.

Proposed resolution

Update \Drupal\views\Plugin\EntityReferenceSelection\ViewsSelection::getReferenceableEntities() to return the Views result rather than just the entity label.

Remaining tasks

None.

Feedback from @alexpott in #159 has been resolved, see #242 for an explanation of how and where.

User interface changes

None.

API changes

In order continue injecting dependencies, \Drupal\views\Plugin\EntityReferenceSelection\ViewsSelection::__construct() will add a $renderer parameter. However, as per the BC changes documentation, this is allowed in minor version releases.

Data model changes

None.

Original report:

I'd like to prepend the content type to the referenceable item titles in the field autocomplete. An entity reference view rewrites the title field as [type]: [title], and is selected as the "view used to select the entities".

This does not appear to work - the view is used to assemble the list (tested by adding a view filter), but the autocomplete continues to display the item titles only.

This is a regression from entityreference 7.x-1.x

Problem/Motivation

PHPUnit has a faster release cadence than Drupal and drops support for PHP versions quicker than we do. See https://phpunit.de/supported-versions.html. This leads to issues like:

• #3039275: phpunit-mock-objects is marked as "abandoned" when composer.lock is rebuilt
• #2927806: Use PHPUnit 6 for testing when PHP version >= 7.2
• #2937469: Automatic upgrade to PHPUnit 6 is dangerous

We're also always playing catch up and have to do issues like #2950132: [PP-2] Support PHPUnit 7 in Drupal 8.

Proposed resolution

Symfony does not include phpunit in its composer.json. Instead it uses a custom PHPUnit runner called simple-phpunit that selects the correct PHPUnit version for the PHP version you are running on. It exists to:

Provides a modified version of PHPUnit that does not embed symfony/yaml nor prophecy to prevent any conflicts with these dependencies.

https://symfony.com/doc/current/components/phpunit_bridge.html

Remaining tasks

• Implement.
• I think we should consider moving to simple-phpunit in Drupal 8 and deprecating PHPUnit via composer.json somehow and then removing that in Drupal 9
• A big unresolved question is if we do this what happens to the testing user interface? It would need to detect that simple-phpunit has been run to get the dependencies or something like that. See #3028663: Split up simpletest into simpletest and testing_ui to enable easier decisions for Drupal 9 for more about the testing UI

User interface changes

TBD

API changes

TDB

Data model changes

None

Release notes snippet

@todo

I got more clarity on this after my original post, so I'm adding the TL/DR version here:

Steps to recreate:

1. Drupal site using jsonapi and jsonapi_extras
2. Node type with an entityreference field
3. In jsonapi_extras config, change the "name" of the entityreference field
4. Create a node, referencing an entity through this field
5. Delete the referenced entity
6. Try a jsonapi query that would grab the node, along with the referenced entity
7. See the AssertionError mentioned below

Proposed solution:

When a referenced entity is missing/null, getRelatableResourceTypesByField is being called with $field->getName(), which is always the resource's internal name. So in the attached patch I'm explicitly converting that to the resource's public name.

Original post follows:

---

I don't know whether this is a bug with this module, or a bug with my site, or simply a support request. Apologies for my ignorance here, but you gotta start somewhere right? Either way I could use some help here:

First here are my versions:

• jsonapi: in core, Drupal 8.7.3
• jsonapi_extras: 3.8.0

I am requesting data with this URL: /api/agency_components?fields[agency_component]=title,agency,submission_address,submission_fax,website,foia_officers,public_liaisons,service_centers&fields[agency]=name&fields[foia_officers]=name,title,email,phone&fields[public_liaisons]=name,title,email,phone&fields[service_centers]=name,title,email,phone&include=agency,foia_officers,public_liaisons,service_centers&page[limit]=50

I am getting this error:
AssertionError: assert(is_string($resource_type) || $resource_type instanceof ResourceType) in assert() (line 81 of core/modules/jsonapi/src/JsonApiResource/ResourceIdentifier.php).

From some xdebugging it seems like this is resulting from an empty array being returned by getRelatableResourceTypesByField. The getRelatableResourceTypes method returns an array of field names that have been customized by this module. For example, instead of "field_service_centers" it has "service_centers". But $field_name, at this point in the code, is 'field_service_centers'. This means that isset($relatable_resource_types[$field_name]) is always false when it runs on a field that has had its name customized by this module.

Hope that makes sense. Please let me know if you think this is due to a quirk or misconfiguration in my site, and I will try to recreate with a blank slate Drupal site. Thank you!

This is follow-up to #1695658: Support optgroups for taxonomy selection list. It has just landed in D7 Views module. Would be nice to have same feature in core since Views module is a part of Drupal 8.

At the forefront, I understand that:

1. This is a deficiency with many CMS systems -- Drupal is not unique
2. The requested feature if implemented simplistically would break syndication feeds. (I've seen Dave Winer spit gears when people embed markup in newsfeed titles; apparently RSS geeks can get very perturbed about this.)

What I'm looking for is a way to insert markup in an entity's title field and actually have it displayed on the page. I understand that it's possible to hack your themes to make this happen via non-HTML markup code, but this should be a core feature.

Justification:

Invariably, when producing a site that has any kind of "marketing" purpose, it's important to present page title information that's formatted at the character level, or which includes character entities. For example, I'm currently working on a site to promote a new book. Some pages will have the book's title as the title of the page; other pages will have ordinary titles; other pages will incorporate the book title.

Here's the thing: Book titles must be rendered in italics. No way to do that using Drupal, unless you hack the theme to use non-HTML markup, or unless you suppress display of the Title field and use a header container at the top of the text. Which is tedious, to say the least, and places significant maintenance burdens. (This is another case where Drupal's content management interface is user-hostile to non-technical users.)

Book titles are one example. Here are a few other common sorts of page title presentations on "marketing" sites that you can't do in Drupal:

• Embedded entitites or typographically-sensitive presentation (e.g., proper right/left quote characters, em dashes, etc.:“Wheetabix®—They're Super-Fantastic!”
• Special formatting, as with branding treatments:"More Information About LudoTRAC"

BTW, while the examples are fictionalized, both of these are scenarios I encounter on every site that I implement. As noted, there are themable workarounds, but it really shouldn't be necessary to do it that way. For one thing, relying on the theme to do that lifting is user-hostile, as noted -- it reinforces the (very) common perception that Drupal is "only for geeks", and not suited for sites where less-technical users might have to maintain content. For another, if you have to embed pseudo-BBCode markup (or the ilk), you'll be sending out garbage in your newsfeeds. Not good.

HTML tags will need to be removed when rendering the entity title in a tag or in an RSS field, but HTML entities (special characters) should remain.

Problem/Motivation

Followup to #2779647: Add a workflow component, ui module, and implement it in content moderation.

In #2779647-48: Add a workflow component, ui module, and implement it in content moderation bojanz:

Why store the workflow ID inside the bundle info, and bless it as the "one true workflow"? Why not simply have a state_item field type that holds the state, and references the workflow? It would be convenient, and more natural when allowing multiple workflows.
This also makes sense when formatting the state, we currently store only the state ID, but will need to show the state label in various places. There's also a use case for a formatter that renders transition buttons (Jira-style), which would benefit from a field type.

This issue is proposing adding a new FieldType plugin which could be added to any entity which would reference a workflow and store the current state the content is at. The plugin would have formatters and widgets to allow users that can edit the content to transition the state. With pluggable workflow types, this could be used for things beyond moderation.

Right now content_moderation doesn't use a field type. In #2725533-67: Add experimental content_moderation module, concerns were raised that storing the state of content in a field would have ramifications for installing and uninstalling content_moderation as an experimental module. Thus a computed field is used instead, with a seperate entity type for storage. Other issues were raised about the usability of creating a field on an entity vs checking a box on a workflow edit screen.

• If a field type is introduce, would content_moderation have to use it?
• Could it be useful by itself or is there something else which could make use of it in core?
• Does it belong in contrib instead?

Proposed resolution

Unknown.

Remaining tasks

Define and narrow the scope of this issue until it's clear what needs to be done.

User interface changes

Unknown.

API changes

Unknown.

Data model changes

Unknown.

Pages are not showing up (WSOD) with the following error:

The website encountered an unexpected error. Please try again later. 

InvalidArgumentException: Cannot redirect to an empty URL. in Symfony\Component\HttpFoundation\RedirectResponse->setTargetUrl() (line 86 of vendor/symfony/http-foundation/RedirectResponse.php).

I also noticed that the LOGO and HOME in the main menu do not redirect to the front page but instead they redirect to the current page.

I am posting this as a site builder looking increasingly at Angular and React routing due to UI limitations for ajax delivery in drupal core and I think that Drupal probably has most of the elements to create a great front end routing experience for site-builders.

Feature suggestion: Make core menu items loadable to an html element with ajax. Drupal page delivery is fast, but its still whole page load by default and often unnecessary.

Feature could include

• System configuration option to page load *or* ajaxify all menu links and define a global html target.
• Menu config to override system scope.
• Menu item config to override menu scope.

Thanks

Problem/Motivation

To have an expose filter with one choice doesn't make sense for admin views. To improve the usability experience allow expose filter(s) to be hidden when there is only one choice. See #2898344-24: Add filters to the comments administration pages for a usecase.

Proposed resolution

Add a new checkbox to the expose form settings to hide single option select/checkbox.

Remaining tasks

Everything.

User interface changes

Expose form will have a new option to hide single option field.

API changes

None.

Data model changes

None.

Problem/Motivation

Output of composer outdated -D on PHP 5.5

egulias/email-validator      2.1.7   2.1.8   A library for validating emails against several RFCs
pear/archive_tar             1.4.6   1.4.7   Tar file management class with compression support (gzip, bzip2, lzma2)
symfony/class-loader         v3.4.26 v3.4.28 Symfony ClassLoader Component
symfony/console              v3.4.26 v3.4.28 Symfony Console Component
symfony/dependency-injection v3.4.26 v3.4.28 Symfony DependencyInjection Component
symfony/event-dispatcher     v3.4.26 v3.4.28 Symfony EventDispatcher Component
symfony/http-foundation      v3.4.27 v3.4.28 Symfony HttpFoundation Component
symfony/http-kernel          v3.4.26 v3.4.28 Symfony HttpKernel Component
symfony/process              v3.4.26 v3.4.28 Symfony Process Component
symfony/routing              v3.4.26 v3.4.28 Symfony Routing Component
symfony/serializer           v3.4.26 v3.4.28 Symfony Serializer Component
symfony/translation          v3.4.26 v3.4.28 Symfony Translation Component
symfony/validator            v3.4.26 v3.4.28 Symfony Validator Component
symfony/yaml                 v3.4.26 v3.4.28 Symfony Yaml Component
twig/twig                    v1.38.4 v1.42.2 Twig, the flexible, fast, and secure template language for PHP

Proposed resolution

Run composer update:

composer update pear/archive_tar twig/twig

Remaining tasks

Create a patch.
Review.
Commit.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Our PHP dependencies have been updated. This includes
pear/archive_tar to 1.4.7
twig/twig to v1.39.0

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