Problem/Motivation

Layout Builder currently allows instances of Block Plugins to be added to Sections, but does not allow creation of new content.

Today, if you wanted to add a Basic Custom Block, you would need to create it in a new tab, then place the derived Block Plugin in a Section. Once that Custom Block is placed, changes to its fields are not reflected in the parent entity's revision history or configuration. This leads to incompatibilities with modules like Content Moderation, as users expect everything they see when viewing a Draft to be tied to the latest revision.

Proposed resolution

We should improve this experience by allowing Custom Blocks to be created and placed inline. For an MVP, a new Block Plugin should be created that embeds Custom Block entity forms inside the normal configuration form. This will allow Custom Block field values to be tracked in that configuration, which will have the added benefit of Content Moderation support.

Remaining tasks

Write a patch.

User interface changes

The Layout Builder's interface will have an added "Create Content" section to creating Custom Blocks inline. The mockups already include this.

API changes

Undecided.

Data model changes

Undecided.

Problem/Motivation

I have a problem with field info cache on a huge portal solution with many fields (280-300 to be precise). Reducing field count is out of the question, as it's a legacy system that is very hard to change, so let's improve D7 core to accommodate some worst cases.

The cause is that there are many fields, and all field info items are stored in a single cache key. Mem-cache server does not work with huge cache items. Even though memcache module 1.5+ is splitting the item for storage, this is a workaround to make Drupal work. The core issue is that the cache item is HUGE, and we end-up with the following issue on a system with a 1GB connection:

cache_get is taking 0.1-0.5 seconds (note that this varies, as it is bottleneck-ing the memcache server instance, where the item is situated.

Proposed resolution

The FieldInfo::getFields (https://api.drupal.org/api/drupal/modules%21field%21field.info.class.inc...)
Is isolated and the cache management is used only there, so if we change caching logic to 2 layers:
Layer 1: List of cache keys for field IDs, so we get this with cache_get.
Layer 2: Cache item per field info instance and we access this with cache_get_multiple, based on the list from 1.

In theory this should improve scallability of the solution, as field information will be spread within the memcache cluster, instead of residing in a single machine in it. I will be starting on implementation of this idea and posting any updates.

This can also be just an alternative cache management utility within field module, so the solution can switch between modes, based on variable configuration, or dynamic (some more ideas):
1. X amount of fields are 1 cache item .
2. More than X -> cache item per field (proposed)
3. Mixed approach, where 10 (configurable constant) fields are stored per cache item, so we will not end-up with 300 TCP connections, but 30 x 10 fields each or 10 x 30 fields each, based on the config.

We can profile and decide on an approach.

Note.
I have not checked how this affects D8, and I have no way of easily testing it and this is why this is reported against D7.

Remaining tasks

Patch, profiling, RTBC, commit.

User interface changes

NONE

API changes

NONE / VERY small, the change is internal to field module and how it handles it's cache layer. Correct me if I am wrong :).

Data model changes

NONE, cache data does not count as data model, AFAIK.

This patch adds a new recipe to the default content created on the Umami profile.

Hi Folks, I've made updates to a few "controller" files within /modules/custom. However, when running Drupal's flush cache or Drush's cache rebuild in, the changes aren't reflected on the site. Twig, CSS, and JS files in the theme clear without a problem. I've also tried clearing the server's opcache. I've worked in D6 and D7, not sure if D8 has anything I'm unaware of keeping the php file cache from clearing?

Thanks for any help.

Problem/Motivation

Generally, past minor versions are not supported and do not receive security coverage. However, we decided it would be a good idea to backport SA-CORE-2018-001 to 8.3.x for an 8.3.8 release given current usage statistics for 8.3.x vs. 8.4.x or. 8.5.x.

Proposed resolution

Attached includes backports of the issues from 8.4.5 as well as a temporary update module fix to allow that release to indicate it's secure even though 8.4.5 and 8.5.0-rc1 exist. Future security releases will work normally since the list is hardcoded.

Remaining tasks

Test run just to make sure everything's working OK.
Then, commit with the SA-CORE-2018-001 commit message, and tag an 8.3.8

User interface changes

API changes

Data model changes

The Layout Builder uses core's off-canvas "tray" when adding/editing blocks to a layout. It opens the tray on the right side of the page, but it's not very wide, and as a result it doesn't accommodate larger block forms very well. This is most evident when adding block that has a textarea field w/ CKEditor:

This problem surfaced in #2948064: Layout Builder should support inline creation of Custom Blocks.

An interesting issue to follow that may help resolve this is #2916781: Allow off-canvas dialog to be rendered elsewhere on the page.

This is really a follow on from #1178580: PHP notices with [node:summary], [node:body], or [comment:body] if there is no body field or language mismatch. Like that issue, it applies to [node:summary], [node:body]. If you use [node:body] on a node that has no body field, that issue fixed the errors but the solution was to leave the token unreplaced.

It seems to make far more sense to me to replace the token with an empty string rather that leave it unchanged. For example, if you try to use [node:summary] in http://drupal.org/project/metatag/ for the meta description for nodes, then for nodes (or comments) with no body I would expect the token to give me back an empty string rather than "[node:summary]".

Am happy to be corrected, but I can see no situation where you would not want an empty string. Attached is a patch that implements this.

As a more obscure case, this situation also arises if the body field does exist but has been changed from the default to a multivalue field that is empty for the node in question.

Follow-up to #2161337: Add a Date Range field type with support for end date

Problem/Motivation

datetime_field_views_data() performs some nice improvements for the Views integration for datetime fields, but has not yet been updated to cover daterange fields, so daterange fields only receive the integration provided by the views_field_default_views_data() fallback. This means that for example, the year-only, month-only, etc. formats aren't available as arguments for daterange fields like they are for datetime fields.

Proposed resolution

The proposed resolution is to allow datetime views plugin to be used for datetime_range fields too. Together with this we have to make sure: extending/reusing the current datetime implementation becomes an easy task for developers, any existing views making use of datetime_range fields is correctly updated, default views shipped with contrib modules using old plugins are automatically migrated on save, etc.
In order to achieve that the solution should include the following tasks:

• Extending the datetime fields Views integration in order to allow any datetime-based fields to make use of it. #4
• Letting daterange fields use the same Views integration capabilities that datetime fields have, using the work from previous point. #4
• Providing an upgrade path for views having old datetime_range fields string/standard views plugins to new plugins types. #24 ~ #139
• Updating contrib modules provided views having old datetime_range fields string/standard to new plugins types. #133 ~ #142

Remaining tasks

• map current 'string' view plugin values/operators to new 'datetime' plugin on the update path using regular_expression operator
• take care of contrib views too. Move all the existing update logic to hook_view_presave and just do $view->save() in the update hook when appropriate as described in #133
• update path test for #127 and #129 changes
• Convert Webtestbase based testing to Browsertestbase
• Deciding if we need a stronger message alerting the user to manually review the views being converted (and/or may be a Change record?). Change Record added.
• Update the issue summary:
  • User interface changes: the IS should mention this issue is neither adding nor removing UI elements, instead we are moving from string/standard views plugins UI to datetime ones. A screenshot with "before - after" should help.
  • API changes: "Extending the datetime fields Views integration in order to allow any datetime-based fields to make use of it" solution task introduce a new API helper for datetime-based fields who want to integrate datetime views plugins easily.
  • Data model: we are not changing any data model. However existing and contrib modules shipped views may be altered. Developers and site builders should be aware of that.

• UI/API/Data Model changes above need a place in the CR - together with a good clean up - as flagged by #192.7
• Upgrade test path is still using old simpletest. We should move it to use Drupal\FunctionalTests\Update\UpdatePathTestBase

User interface changes

This issue doesn't introduce new UI elements, but it converts Views filter and sort plugins from string/standard formats to datetime based ones. The change is automatic, site-builders and developers don't need to do any action.
See the example below of how the UI will change for a Views filter plugin against a datetime_range field:
Before:

After:

API changes

datetime_type_field_views_data_helper - new API helper to integrate datetime views plugins easily for any datetime-based fields. Modules defying datetime-based fields can now benefit of datetime Views plugins easily.

Example usage in core/modules/datetime_range/datetime_range.views.inc:

/**
 * Implements hook_field_views_data().
 */
function datetime_range_field_views_data(FieldStorageConfigInterface $field_storage) {
  \Drupal::moduleHandler()->loadInclude('datetime', 'inc', 'datetime.views');

  // Get datetime field data for value and end_value.
  $data = datetime_type_field_views_data_helper($field_storage, [], 'value');
  $data = datetime_type_field_views_data_helper($field_storage, $data, 'end_value');

  return $data;
}

Data model changes

There are no Data model changes. However existing and contrib modules' shipped Views - using datetime_range fields/plugins - may be altered. See update message about the ids of changed views like (view id is datetime_test):

The update will map existing datetime_range views string plugins operators/values according with this list:

• = maps to =, value is unchanged
• != maps to !=, value is unchanged
• not maps to !=, value is unchanged
• starts maps to regular_expression, value is prefixed with '^'
• ends maps to regular_expression, value is suffixed with '$'
• any other operator (contains, word, allwords, not_starts, not_ends, shorterthan, longerthan, regular_expression) maps to regular_expression, value is unchanged if not empty otherwise *. is used

Example, filter Starts with with 'value' will be converted into Regualr expression with '^value';

Problem/Motivation

In most cases, no security updates are provided for old minor versions of core, so any security release is created only on the latest minor version. However, there are a few scenarios where security releases might be issued for two branches:

1. The next minor branch of Drupal 8 is in its release candidate phase. Core release candidates receive security coverage, so we would want to mark both (e.g.) 8.2.0-rc2 and 8.1.10 as security releases as part of the same security advisory in SA-CCORE-2016-004. Sites on 8.1.10 already have the fixes for the issues disclosed in the advisory, and they should not upgrade to 8.2.0-rc1 (as it is not yet stable and may include disruptive changes). The two releases are equivalent in terms of their security status.
2. We have a one-month window following each minor release in which we do not disclose any security issues with the old minor release,
   to give users time to update and adjust for any disruptions in the minor release. However, sometimes it is necessary to issue advisories within this window, so we provide a release for the old, unsupported minor as well as the new minor to ensure all users can update safely without breaking other things on their sites. This was the case with SA-CORE-2017-002, for which we released both Drupal 8.2.8 and Drupal 8.3.1.
3. In the future, we may adopt a shorter minor release cycle but provide security fix backports for the old minor, so it might be more common to have equivalent security releases on two branches. This is being discussed in #2945200: [policy, no patch] Four month minor release cycles.

Example of what the OP experienced when updating to 8.1.10, when 8.2.0-rc2 was also marked as a security release:

With the error message on admin pages:

There is a security update available for your version of Drupal. To ensure the security of your server, you should update immediately! See the available updates page for more information and to install your missing updates.

Proposed resolution

• Normally, when a security advisory is issued for one minor branch, all previous releases (including previous security releases on earlier branches) should be marked insecure.
• In cases where releases are issued for two minor branches in the same advisory, the old minor branch should not be marked insecure and the user should not be told a security update is required.
• However, say 2017-002 had released 8.3.2 instead of 8.3.1. In that scenario, 8.2.8 would have been secure, 8.3.1 would have been insecure, and 8.3.2 would have been secure

Problem/Motivation

Other modules need a way to declare their migration status and thus control which list (available upgrade path or missing upgrade path) they will appear in on the Migrate Upgrade review page, /upgrade.

The form lists all modules on the source site in either a 'missing an upgrade path' or 'available upgrade path' list. If the module has migrations it will be displayed in the 'available upgrade path' list, even if it only has one migration and needs more than one to be complete. If it as no migrations it will be displayed in the 'missing an upgrade path list', even it does not need an upgrade path. This will lead to misleading data for the user.

In a migrate meeting, using a hook or an event was discussed. A possible solution, using hook_form_alter, was implemented in #2914974: Migrate UI - handle sources that do not need an upgrade and removed after a review #176. That review asked some questions, listed below, which should be resolved here.

1. The CR is titled Provide a Method to Intentionally Mark Modules, Themes and Profiles as not Upgradable but we're not really providing a method.
2. Did we give consideration to a dedicated API? E.g. we could put entries in .info.yml or we could put .migrate.info.yml files in modules.
3. How likely is it that contrib modules will need to make this change?

Note: As of this writing, there is the two categories of 'missing' and 'available'. Another category, 'incomplete' is being added, #2928147: Migrate UI - add 'incomplete' migration status

Proposed resolution

In a migrate meeting option #2 was decided as the best option, reasons included that it is easy to add and there is no need to write code. See #7 and #8.
Add a version key to identify the source version. While working on this it became clear that the status needs to be declared by source version. See #10

Remaining tasks

Decide on the format of the new 'migrate' key and values in .info.yml
Decide on the allowed values for status. Suggestions are in #7, #9
Decide if adding a key for source version is ok.
Review
Add documentation
Commit

Problem/Motivation

In contrib (and even in core itself), there is a lot of boilerplate repeated when a migrate deriver wants to add fields to an source migrate deriver. Let's make the code for discovering and adding fields generic and make a re-usable trait.

Paragraphs and Commerce would use this. Node, user and taxonomy term in core could also.

Proposed resolution

Take a look at node source deriver, make a trait and then implement it for node, user and taxonomy.

Remaining tasks

1. Code it
2. Run existing tests
3. Commit it

User interface changes

API changes

Data model changes

Problem/Motivation

So far we can find several components using both syntax: font-weight: normal and font-weight: 400, or font-weight: bold and font-weight: 700 in the Umami theme.
font-weight: normal is the same asfont-weight: 400 and it's not a matter of browser compatibility since all accept both syntax.

Proposed resolution

Decide if we should use font-weight: normal/font-weight: 400 and font-weight: bold/font-weight: 700and implement it.

Remaining tasks

• Decide which syntax we should use.
• Review the current code to be sure we use the chosen syntax everywhere.

You can browse Drupal 8 paths like /some/path with /index.php/some/path. In Drupal 7 /index.php/some/path would be a 404.

Problem/Motivation

The settings tray currently uses the dialog system and is always rendered on the right side of the page. Some modules may have a need for the tray to appear at the top, bottom, or left of the page.

Proposed resolution

Add a class or other attribute to a link which tells settings tray to render in a different location than the default right side of the page.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Views currently doesn't provide a relationship from the revision table back to the base table by default.
There are though workarounds in both block_content and node module for that.

Proposed resolution

Let's add it.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

CKEditor's default styles and resets are being overridden by off-canvas' CSS. As a result, CKEditor is basically un-usable when rendered inside of the off-canvas dialog.

How it looks now:

You can see this locally by following these steps:

1. Apply the provided "layout-builder-debug.patch" patch
2. Install the Standard profile
3. Enable the "Layout Builder Debug" (layout_builder_debug) module
4. Visit /admin/structure/types/manage/article/display-layout/default
5. Click "Add Block"
6. Select "Debug Form Styling" from the block listing
7. See that CKEditor looks funky

Proposed resolution

I started working on this and I'm not really sure what to do - we need a way to exclude CKEditor from off-canvas styling, but this is really hard without modifying all of off-canvas' CSS.

Currently the selector "#drupal-off-canvas" is a part of almost every selector in off-canvas' CSS, and that makes overriding any off-canvas style really tough. I think a good long-term solution to prevent problems like this is to stop selecting off-canvas elements with an ID, and instead use a class like .off-canvas-reset. This would allow more specific class selectors to override off-canvas without the use of !important or ID/element names.

Remaining tasks

Discuss the problem, determine what solution we should use.

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Problem/Motivation

Right now using the core menu block subtrees aren't show unless they are in the active trail. This isn't ideal for things like primary navigation which require subtrees to be shown regardless of which item the user is viewing.

Proposed resolution

Add an option to the core system menu block to make this behavior configurable.

Remaining tasks

None

User interface changes

Adds a checkbox within the "Menu Levels" fieldset on the block configuration interface.

API changes

None

Data model changes

None

Warning: count(): Parameter must be an array or an object that implements Countable a theme_table() (línia 1998 de /var/local/html/dadesobertes/includes/theme.inc).

Problem/Motivation

In #2804155: If the next minor version of core has a security release, status still says "Security update required!" even if the site is on an equivalent, secure release already, we discovered badly-outdated sites offer up all the security updates.

Proposed resolution

Possible solutions:

1. Only show the most recent security release.
2. Only show the most recent security release for each minor.
3. Still show all the releases, but within a single line under the latest release, something like:
   

   Security update required! 8.4.5
   Previous security releases: 8.3.8, 8.3.7, 8.3.4, 8.3.1, 8.2.8, 8.2.7, 8.2.3

   (if the site is on 8.1.10.)

4. Other?

Remaining tasks

User interface changes

API changes

Data model changes

In D8, is it still possible to override a Views template in a module? If so, how? In D7, I used hook_views_api() to register a 'template path' so that Views could discover appropriately named templates, but this function appears to be gone in D8.
With a file named views-view-table--my-view--my-display.html.twig in a subdirectory of my module, how do I register it with Views?