Problem/Motivation

In order for media to be the default method of attaching media to content, we'll need to deprecate the old image/file fields and allow Drupal 6/7/8 sites using them to migrate to media fields.

Postponed on #2835825: Add d8 media migration.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Issue:

From the doc:

function hook_local_tasks_alter(&$local_tasks) {

  // Remove a specified local task plugin.
  unset($local_tasks['example_plugin_id']);
}

The string "example_plugin_id" doesn't follow the convention of "module_name.task" and isn't a real plugin id.
This makes it confusing as to which plugin ids are the keys, given how overloaded the word "plugin" is.

More significantly, this documentation gives absolutely no clues on how to add a new local task.

Suggested resolutions:

• Replace "example_plugin_id" with a real example: call unset on a core module local task using a real world scenario, like "user.pass"
• Update comment to say what this will do, e.g. "// Unset the user.pass task to hide the 'password' tab from the login page"
• Add an example of adding a local task

Problem

RSS view with fields instead of content rendering in RSS view mode results in wrong URLs from path field (with pathauto enabled).

Instead of correct URL with http://mysite.domain/content/my-node-title we got http://mysite.domain/my-node-title.

Reproduced on multiple sites with current d.o D8 pathauto module.

1. Edit 'Frontpage' view
2. Select 'Feed' display
3. Switch display mode from content to fields
4. Add title, path, author, created field
5. Configure fields in display mode settings. Link & GUID with permaLink = Path field
6. Check URLs in preview output

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

When opening a view in a modal dialog, the title says '[object Object]' as this title is set as an array.

Problem/Motivation

For themers it is really important to distinguish the different block types.

Proposed resolution

Add a css class to blocks, which indicates which type is used.
For example: If you have a block type "Banner" then a css class "block--type-banner". I don't know the drupal css guidelines, so the classname is just a proposal.

Remaining tasks

[ ] Implement this

User interface changes

None

API changes

None

Data model changes

None

Should be a small fix with no breaking changes.

Problem/Motivation

Currently there is no way to pass #attributes to the drupal_add_js function. This is not a feature that is widely used, however, there are unique cases where the <script> tag generated needs to have available an id="" or other unique attributes to that tag.

Proposed resolution

By initializing the #attributes key of the $js_element array we can easily pass specific #attribute elements in our drupal_add_js calls, and sense theme('html_tag', array('element' => $js_element)); handles #attributes passed to it, all additional support is inherited. Here is an example of the new attribute code working in the case 'external' type of drupal_add_js is invoked. The patch of course accounts for all cases of 'type':

case 'external':
  $js_element = $element;

  // Attach custom attributes to the element.
  $js_element['#attributes'] = !empty($item['attributes']) ? $item['attributes'] : array();

  // Preprocessing for external JavaScript files is ignored.
  if ($item['defer']) {
    $js_element['#attributes']['defer'] = 'defer';
  }

  $js_element['#attributes']['src'] = $item['data'];
  $processed[$index++] = theme('html_tag', array('element' => $js_element));
  break;

Attached to this feature request is the patch containing this new fix.

After updating the Drupal 8.7.1, I'm seeing a significant increase in page responses related to 1 views block on a page. The view is a list of commerce products that just load the title. However, it looks like every entity is being loaded, rendered, and then the title is pulled out.

Blackfire profile (see timeline):
https://blackfire.io/profiles/6003723c-795b-4ce1-893c-1efb28e154b3/graph

It also seems like the view is not getting cached (or using it) as every refresh produces the same result.

Views execution times:

Query build time 8.33 ms
Query execute time 7.63 ms
View render time 2719.56 ms

Views execution times in Drupal 8.6.7 (older environment with same view config)
Query build time 4.53 ms
Query execute time 10.71 ms
View render time 66.23 ms

Problem/Motivation

Panelizer (at least in D7) allowed you to override a view mode for an entity and add relationships to pull in fields from additional entities (an obvious example being a User view which pulls in data from a profile attached to the user). Panelizer appears to be winding down now so much of what it did is in core, but this relationship aspect is not currently supported by core and is not easily possible in contrib either without swapping out large parts of core.

Proposed resolution

Make it possible for contrib to provide additional context for the layout builder. There are probably a few ways to do this, but the two obvious options to me seem to be one of:

1. An event that can be subscribed to: Pro - OO with subscribers able to inject services and possibly better 'applies' logic
2. A hook that modules can implement: Pro - quick and easy to implement!

The places I have identified which would need to invoke whatever process are:

1. \Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay::buildMultiple after adding the layout_builder.entity context: Implementers would need to provide real (potentially empty) context.
2. \Drupal\layout_builder\Plugin\SectionStorage\DefaultsSectionStorage::getContexts: Implementors would need to provide sample context.
3. \Drupal\layout_builder\Plugin\SectionStorage\OverridesSectionStorage::getContexts: Implementors would need to provide real or sample context.

Remaining tasks

• Decide what mechanism we want to use (events, hooks or other).
• Trigger implementations in the identified locations.
• Make sure there aren't other places that also need to trigger implementations.
• Test coverage!

User interface changes

None - it would be down to contrib to implement any UI to configure relationships, or to provide them programatically.

API changes

Addition of a mechanism to add additional context.

Data model changes

None - it would be down to contrib to deal with any additional storage requirements.

If the BookNavigationBlock does not have the configuration option "all pages" (UI option "Show block on all pages"), it only displays the subpages of the current book in the navigation block.

On line 143 there is this code:

          $data = $this->bookManager->bookTreeAllData($node->book['bid'], $node->book);
          $book_menus[$book_id] = $this->bookManager->bookTreeOutput($data);

which outputs the items in the book using ->bookTreeOutput()

but for some reason, on line 177, it only outputs the subpages:

 $tree = $this->bookManager->bookTreeAllData($node->book['bid'], $node->book);
  
        // There should only be one element at the top level.
        $data = array_shift($tree);
        $below = $this->bookManager->bookTreeOutput($data['below']);
        if (!empty($below)) {
          return $below;
        }

I guess some developers would only want the some pages, so I'm not sure if this is a bug, or should be an option.

PHP Fatal error: Class 'TYPO3\\PharStreamWrapper\\Resolver\\PharInvocationCollection' not found in [webroot]/misc/typo3/phar-stream-wrapper/src/Manager.php on line 98

Changes in includes/file.phar.inc don't seem to be working for PHP 5.3.3

We are stuck at this PHP version for a bit longer, so would be good to understand how to resolve so we can upgrade to 7.67

Hello. I don't know if this the right place to create this issue, but I solved it by modifying this specific file (EntityViewBuilder.php).

Problem

When using EntityViewBuilder to display an entity reference field, the output does not respect the current language.

How to reproduce

1. Create a new Drupal 8 installation
2. Add a user entity reference field to content type basic page
3. Add a second language. Enable translation for User and Basic Page
4. Enable tranlation for the entity reference field created in step 2
5. In Basic Page manage display, select rendered entity for the entity reference field
6. Add a text field to User, e.g. field_surname
7. Translate user 1
8. Create a basic page with a reference to user 1 and translate this page
9. Visit the basic page. The rendered user will be in the correct language.
10. Now install Fieldblock. You will also need to install this patch. I choose this example because Fieldblock uses EntityViewBuilder.
    • Fieldblock.php line 342 calls FieldItemList::view()
    • FieldItemList.php line 255 calls EntityViewBuilder::viewField()
11. Go to Manage Blocks and add a Fieldblock for the field of step 2. Once again, choose rendered entity display mode.
12. Again, visit the translated basic page. The rendered user in the block will be in the original language, untranslated.

Suggested resolution

I don't know if this is a general correct solution. In my case, I solved the issue by modifying EntityViewBuilder::viewField() (line 397 of EntityViewBuilder.php) from this:

  public function viewField(FieldItemListInterface $items, $display_options = []) {
    $entity = $items->getEntity();
    $field_name = $items->getFieldDefinition()->getName();
    $display = $this->getSingleFieldDisplay($entity, $field_name, $display_options);

    $output = [];
    $build = $display->build($entity);
    if (isset($build[$field_name])) {
      $output = $build[$field_name];
    }

    return $output;
  }

to this:

  public function viewField(FieldItemListInterface $items, $display_options = []) {
    $entity = $items->getEntity();
    if ($entity instanceof TranslatableInterface && $entity->isTranslatable()) {
      $entity = \Drupal::service('entity.repository')->getTranslationFromContext($entity);
    }
    $field_name = $items->getFieldDefinition()->getName();
    $display = $this->getSingleFieldDisplay($entity, $field_name, $display_options);

    $output = [];
    $build = $display->build($entity);
    if (isset($build[$field_name])) {
      $output = $build[$field_name];
    }

    return $output;
  }

I will also create a patch and post it here.
Any comments welcome, thanks in advance.

Problem/Motivation

Modules need a way to declare their migration status and give a short description on the Migrate Upgrade review page, /upgrade. The short description can have a link to a documentation page for example for known issues.

The Review form lists all modules on the source site in either a 'will be upgraded' or 'will not be upgraded' list. However, determining which section to add a module too is not robust. If the module has migrations, it will be displayed in the 'will be upgraded' list, even if it only has one migration and needs more than one to be complete. We need a mechanism that can explain this situation in the UI.

The mechanism needs to be flexible to accommodate the many scenarios possible. See #71 and #72 for details.

This work here is to only create and implement such a system, to make the first step, for what is a complicated problem. Changes may be made to the UI but are expected to be minimal. However, a UX review is planned. When that feedback is given it needs to be decided what can be done in this issue and what must be moved to followups.

Note: in #2914974: Migrate UI - handle sources that do not need an upgrade we defined a list of modules that do not need any migrations (e.g. Overlay, Help) or the contrib functionality has moved into core and there is not a D8 core module with the same name. These modules are listed in ReviewForm::$noUpgradePaths

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?

Proposed resolution

Allow Drupal 8 modules to declare their migration state in module_name/migrations/state/migrate_drupal.yml. This will allow the Review form (at /upgrade) to display accurate information. See Change Record for details and usage examples.

A deprecation notice is displayed when a module has at least one migration and does not have a migrate_drupal.yml file.
A brief description:
In 'finished' is a list of all source module/destination module pairs for migrations that are complete in the module. In 'not_finished' is a list of all the migrations this module intends to provide but either do not exist or are incomplete for any reason. Any migrations discovered in the module that do not have a corresponding entry in the migrate_drupal.yml file will be assumed 'not finished'.

The 'not_finished' is needed because more than one module can have migrations for a source module and at least one of the modules uses the 'finished' key. The 'not_finished' one will ensure that the source module is listed in the 'will not be upgraded' list. Say Module A and Module B provide migrations for Module C. Module A is finished and uses 'finished'. Then, if Module B has no migrations, it needs to use 'not_finished'.

Screen shots

The difference between the before and after is that on the after screenshots the modules in the Drupal 8 column will be listed in a single line separated by commas whereas in the before screenshots they are on separate lines. That's all.

The new Review page also has a new help text string to give some information or direction to the user on what to do about the modules in the 'will not be upgraded' section. The new help text is

The new site is missing modules corresponding to the old site's modules. Unless they are installed prior to the upgrade, configuration and/or content needed by them will not be available on your new site. Read the checklist to help decide what to do.", [':review' => 'https://www.drupal.org/docs/8/upgrade/upgrade-using-web-browser#pre-upgr...']),

See #87

Screens shots using the Drupal 6 Ubercart test database from Commerce Migrate.
Before
Module that will not be upgraded section

After
Modules that will not be upgraded section

Screens shots using the Drupal 6 test fixture.
Before
Modules that will be upgraded

After
Modules that will be upgraded
The checklist referred to is https://www.drupal.org/docs/8/upgrade/upgrade-using-web-browser#pre-upgr...

History

The first proposal which came from a migrate meeting was to add the migrate status of the module and a description string to be displayed on the Review Page to info.yml . This was tweaked a few times. See #7 and #8. See #10. Eventually, the description was removed as to difficult to maintain an html string in .info but the version key remained.

After framework manager review the status information moved from .info.yml to module.migrate.yml, the format stays the same. And later it moved to migrate_drupal.yml since this is only for drupal sources. See comment #124.

All the logic to determine whether a source module will be upgraded or not is now in a service (See suggestion in #137.9, migrate_drupal.migration_state.

Discussion of the logic are in #72 and #77

Remaining tasks

• Decide on the format of the new 'migrate' key and values in .info.yml. Suggested formats are in #11 and #15. Those have been abandoned in favor of 'migrations_finished' and 'migrations_not_finished'.
• Decide on the allowed values for status. Suggestions are in #7, #9. Currently proposed values are 'complete', 'incomplete' and 'n/a'. The UI impact with a screenshot is in #28.
• Decide if adding a key for source version is ok.As pointed out in #10, the status needs to be declared by source version.
• Review
• UX Review - See #106 - #11
• Update change record</li>
• Update handbook documentation
• Commit
• Possible followup: Allow modules to add text to the page via a hook.

Problem/Motivation

When normalizing collection requests we should be able to leverage the cached data from the normalization of the individual entities.

Proposed resolution

If an entity has been already normalized in the past, then re-use it during the normalization process.

Remaining tasks

1. Make sure that the normalized entity cache is varied depending on the sparse fieldsets. This is in addition to any existing cache contexts for the normalizer value.

Problem/Motivation

In \Drupal\Core\Controller\FormController there is a @todo

@todo Make this a trait in PHP 5.4.

Proposed resolution

Either do the @todo or remove the @todo as Drupal 8 has always required > PHP 5.4

Remaining tasks

User interface changes

None

API changes

@todo

Data model changes

None

Release notes snippet

Problem/Motivation

Discussing the layout builder at Drupaldelphia BoF.

When editing the layout for a view mode you get dummy content applied that may not be helpful to understand how the real content will look.

Proposed resolution

Add an autocomplete box that allows picking a node to user (temporarily?) as the content to be shown while editing the layout. Ideally change the content or refresh when a new node is picked - allowing the site builder to check how the layout will work with different examples of the content.

Remaining tasks

Decide how it should work, build it

User interface changes

added field to the layout form + new functionality

API changes

n/a

Problem/Motivation

\Drupal\system\SystemRequirements::phpVersionWithPdoDisallowMultipleStatements() is pointless now PHP5 is not supported.

Proposed resolution

Deprecate \Drupal\system\SystemRequirements as phpVersionWithPdoDisallowMultipleStatements is the only method in the class.

Remaining tasks

• Create a change record
• Add an @trigger_error to main in the class
• Convert \Drupal\Tests\system\Unit\SystemRequirementsTest to a legacy test

User interface changes

None

API changes

\Drupal\system\SystemRequirements is deprecated

Data model changes

None

Release notes snippet

N/a

Problem/Motivation

Once #3053363: Remove support for PHP 5 in Drupal 8.8 lands \Drupal\Component\Assertion\Handle::register() is kind of pointless.

Proposed resolution

• Create a change record
• Deprecate the entire class
• Replace calls to it with assert_options(ASSERT_EXCEPTION, TRUE);

The assert_options(ASSERT_WARNING, FALSE); is pointless. If you have assert_options(ASSERT_EXCEPTION, TRUE); on no warnings are produced by the following code:

assert_options(ASSERT_WARNING, TRUE);
assert_options(ASSERT_EXCEPTION, TRUE);
assert(TRUE == FALSE);

Remaining tasks

User interface changes

None

API changes

\Drupal\Component\Assertion\Handle is deprecated

Data model changes

None

Release notes snippet

Problem/Motivation

We want to create a roadmap for Drupal 8.8 release.
Starting by putting together a list of our ambitious goals and then prioritize it into:
Must have & Nice to have.

Whatever we cannot complete by the week of October 14, 2019, the scheduled Drupal 8.8.0 Feature Freeze (alpha1 release), we can move to Drupal 8.9 or Drupal 9.

This list will evolve and will be updated through comments and additional conversations.

Some of the items can be achieved by getting help from volunteers in other teams, like Documentation and Translation.

Kanban Board

Proposed resolution

(not sorted by importance)

Language Switcher improvement
Low hanging fruit
#3042417: Umami's language-switcher as a drop-down menu

Tour
Ambitious goal
Adding Tour content to many more pages (mostly a documentation effort).
Teaching people Drupal with hands-on experience, explaining backend/frontend choices we made to build Umami.
Low hanging fruit
Improve Tour experience, by loading it automatically after installation.
#3038406: How do we make sure people new to Drupal know about the Umami Tour?

404 page
Ambitious goal
Add a View search results of whatever was typed in the URL.
Low hanging fruit
Theme the page with a friendly message, also relevant to 403 pages.

Multilingual
Ambitious goal
Allow installing Umami in any language by switching from CSV import to localize.drupal.org translation import.

1. #3048283: Read content from Drupal 8 core's demo_umami
2. #3048295: Install Umami in any language (import content from https://localize.drupal.org)

Low hanging fruit
To add RTL functionality in Umami, add Hebrew / Arabic as a 3rd language (mostly content translation effort).

Media Library
Ambitious goal
Add (an external) video and audio to some of the pages / recipes / articles.
Low hanging fruit
#2954378: Use Media images in Umami demo Replace all exising image fields with media fields.

Theme Structure / Layout Builder
Ambitious goal
Update Umami's theme to a component-based design.
Low hanging fruit
Implement Layout Builder on every page, recipe & article.

Json:API
Ambitious goal
FE addition that suggests recipes according to groceries you have at home.
Low hanging fruit

Try Umami
Ambitious goal
#3047290: One button Umami drupal installation One button on Drupal.org that installs for you Umami demo on simplytest platform

Miscellaneous
Low hanging fruit
#3044366: Fix styling of Umami for layout builder
#2985551: Style and show content moderation form in Umami
#2940023: Improve accessibility of Umami's responsive main menu
#3051465: Revert "Taxonomies are only displayed in English"
#3034784: Displaying translation string counts and string errors is too much detail in the installer
#3041039: Search for content in current language/#3045362: Search for node content in current language

We should keep an eye on https://www.drupal.org/core/roadmap to see which modules could potentially become stable in the next Drupal release.
In the process of Drupal 8.7 development, Layout Builder and JSON:API modules became stable at the very end of the process.
We can prepare patches in advance for Media Library and other upcoming new functionality that might be ready in time for when Drupal 8.8 is going to be released.

Drupal 9 Wishlist

Fresh Images
Ambitious goal
Fresh new photos for Drupal 9

Multiple types of demo sites
Ambitious goal
Finding free and open content repository, that we can either copy to into our own CSV files or use their APIs directly.
Create a content model for each type of website and import the content into it.
Create one global theme that can work for all these types of websites.

Problem/Motivation

All work done so far only will affect the "main content" region of a site.

For full landing page functionality, more work is needed to control the sidebar, header, footer, etc.

Proposed resolution

Discuss!

Remaining tasks

User interface changes

API changes

Data model changes

Test current patch

Go to /page-layout/bartik to test it out.
Unless you add the "Tabs" block you won't see the buttons (lol)
So you can go to /page-layout/bartik/save if you want to save.

Problem/Motivation

On a site with ~20 content types, and quite a few modules, there may be a few hundred permissions at /admin/people/permissions. In this case, the web-page loads relatively quickly (network) but then flatlines the CPU at 100% for a long time (70 seconds on my 2.4GHz Macbook Pro, Google Chrome). Roughly same results in Safari and Firefox.

I will use Speed Tracer http://code.google.com/webtoolkit/speedtracer/ to investigate this a bit further, but initial results in attached screenshot.

Additionally, it's possible for the permissions page to exceed max_input_vars and silently drop part of the form submission.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes