When creating a new user, the help text for username field is "Spaces are allowed; punctuation is not allowed except for periods, hyphens, apostrophes, and underscores."

What are the steps required to reproduce the bug?

Create a new user with username smurf@example.com.

What behavior were you expecting?

User not created, error message about the @ symbol.

What happened instead?

User created, no error message.

I see in user_validate_name() a preg_matches that allows /[^\x{80}-\x{F7} a-z0-9@_.\'-]/i.

So either we change validation, or update the help text to what is actually allowed, which is @_. '-. So the text would read: "Spaces are allowed; punctuation is not allowed except for periods, hyphens, apostrophes, underscores, and the at sign (@)."

There doesn't seem to be a nice english word for @. Although I do like 'strudel' as proposed by http://foldoc.org/strudel.

Problem/Motivation

As per reviews by @webchick and discussion between @alexpott, @xjm and @effulgentsia, it may be a problem that configuration forms work totally opposite in terms of overridden values compared to how they worked in Drupal 7 and before. In Drupal 7 if you had a settings.php configuration override for example, that got used to build the configuration form and whatever you changed, the change did not stick. That was a WTF, but at least it was some sort of feedback on the value not being possible to change. In Drupal 8 however, overrides are not used to build forms and you can actually change settings and they would actually be saved and then displayed again on the form as if they were persisted. They are actually persisted but overrides may still apply on them, so the operation may be moot.

Proposed resolution

Following #2392319: Config objects (but not config entities) should by default be immutable each configuration form knows about the configuration keys edited and centralizes an accessor ($this->config()) to access them. Thanks to this, we can track if there were any configuration details loaded that may have overrides applied (by loading the editable version as well and comparing the data). That way, we can detect if there are overridden values at least under the same conditions as the admin form was displayed (eg. static global overrides). Using that information, we can display a message on top of the form if there is overridden configuration and editing is pointless.

Remaining tasks

Implement. Add tests. Review. Commit.

User interface changes

Configuration forms may display a message on the top if there are overridden values.

API changes

None.

Steps to reproduce

• Create a page with the page manager plugin
• Activate 'ckeditor' plugin and create a text_format mode to use ckeditor
• Add a block with a form containing a text_format element
• Form appear in popup
• Click the 'image' button in the CKEditor toolbar
• Select image and enter alt text
• Click OK

Expected behaviour
Image appears in CKEditor

Actual behaviour
JS Error in console: Uncaught TypeError: Cannot read property 'getParent' of null at plugin.js?t=p5y410:122

Workaround

• Create a page with the page manager plugin
• Activate 'ckeditor' plugin and create a text_format mode to use ckeditor
• Add a block with a form containing a text_format element
• Save the block
• Ctrl-click (or equivalent) on the 'edit' button on the block to open the form in a new window rather than a popup
• Click the 'image' button in the CKEditor toolbar
• Select image and enter alt text
• Click OK

If the image is added via a form NOT in a popup it works as expected. Based on the JS error I think that the 'image upload' popup replaces the 'block form' popup when the image button in CKeditor is checked, which means that the form itself is removed from the DOM and the plugin cannot find it.

Using Chromium 64 on Ubuntu 17.10, PHP 7.1

Drupal 8.5

Active contrib modules:

• automated_cron
• block
• breakpoint
• ckeditor
• color
• comment
• config
• contact
• contextual
• block_content
• menu_link_content
• dblog
• field
• field_ui
• filter
• help
• history
• dynamic_page_cache
• page_cache
• layout_discovery
• media
• menu_ui
• node
• path
• quickedit
• rdf
• search
• shortcut
• system
• taxonomy
• editor
• toolbar
• tour
• update
• user
• views
• views_ui
• admin_toolbar
• adminimal_admin_toolbar
• ctools
• ctools_block
• global_renewable_hub_explore_markets
• twig_field_value
• devel
• twig_kint
• inline_entity_form
• datetime
• dynamic_entity_reference
• file
• image
• link
• options
• text
• page_manager
• page_manager_ui
• entity_browser
• entity_browser_entity_form
• media_entity_browser
• entityreference_view_mode
• formblock
• menus_attribute
• token
• twig_tweak
• panels
• panels_ipe
• webform
• webform_bootstrap
• webform_node
• webform_ui

Problem/Motivation

It is impossible to load additional JS libraries in an Ajax response and then call that code through Ajax commands, because Drupal.ajax does not guarantee that the JS library will already have loaded.

See #23 and #31 for details.

Proposed resolution

TBD.

Remaining tasks

TBD.

User interface changes

None.

API changes

TBD

Related Issues

TBD

Original report by [username]

Hi,

Thanks for your module, it works perfect for me.

But I found there one small bug there: if all my .js files are mapped to the external CDN, ajax redirects doesn't execute. After some tests I found that CDN rewrites all js urls, even for ajax. So I attached a small patch that solved this problem for me.

Best regards,
Spleshka.

Problem/Motivation

Every time we change a translatable string in a Drupal release, we break translations of that string for all languages, until someone comes along and re-translated the string (if that ever even happens at all).

As a result, we are cautious about changing strings. In Drupal 8, it is only done in minor releases, i.e. every 6 months (see https://www.drupal.org/core/d8-allowed-changes#evaluate), whereas Drupal 7 core is relatively liberal about doing it for admin-facing strings but very conservative about doing it for end-user-facing strings (see https://www.drupal.org/node/1527558).

But if you think about it, in most cases it is ridiculous to break a site's existing translations just because we want to make a small improvement to the text. Here are a couple examples:

1. Fixing a typo

   Suppose the original string looked like this:

   t('Hello, how are youu?')

   Oops, there's a typo - so once that is discovered we obviously want to fix it.

   In this case, there's no reason to assume that the translators introduced a typo in their own language when translating the string from English! So breaking translations makes absolutely no sense at all.

2. Fixing a small bug or adding some minor clarification

   A real life example can be found at #2923151: Usernames allow @ symbol. There, a minor issue was identified with the user registration form's help text being slightly incorrect (it fails to tell people that the @ sign is allowed in usernames).

   In this case, the mistake would exist in other languages also, so we do want translators to re-translate the string eventually. However, before that happens, do we really want to show end users who don't speak any English the English version of the string? Of course not... it would be preferable for them to see something in their own language (even if it's slightly imperfect) than to see something in a language they don't understand at all.

Proposed resolution

Let's consider introducing a simple fallback system where a developer can pass in alternate strings to use for translation in case the main/preferred string doesn't have a translation available.

Conceptually, the easiest way to think of this is to allow t() to optionally accept an array of strings as its first parameter (instead of a single string).

So in that case, with the first example above, when we fix the typo, instead of just replacing the old string, we would change it to this:

t(array('Hello, how are you?', 'Hello, how are youu?'))

and the system would try to find a translation for the first string if available, but fall back on the second string's translation if not.

The second example above would be similar.

API changes

This is an API addition, not an API change.

However, it would be an API change for code like https://www.drupal.org/project/potx which needs to parse files and look for translatable strings in them. That module would need to be updated so that it recognizes code with this new pattern.

Problem/Motivation

Currently postponed on #2920672: OverviewTerms page has invalid table HTML when the user does not have access to some terms

Followup for issues:

1. #1848686: Add a dedicated permission to access the term overview page (without 'administer taxonomy' permission)
2. #2920672: OverviewTerms page has invalid table HTML when the user does not have access to some terms

The vocabulary overview page and the term overview page always show the Weight and Operations column. Preferably these columns are only visible when applicable.

Proposed resolution

1. Display the 'Weight' column including tabledrag when the current user can update all listed entities and the list contains more than a single item.
2. Display the 'Operations' column when at least one entity has an operation for the current user.

The patch file must include add test coverage to test the above changes. For reference view the test implementation of /core/modules/taxonomy/tests/src/Functional/VocabularyPermissionsTest.php

Remaining tasks

1. Write a patch
2. Review
3. Commit

User interface changes

The 'Weight' and 'Operations' columns display only when applicable on the Vocabulary overview page and Term overview page.

API changes

None.

Data model changes

None.

I have "basic_auth" authentication working for a custom resource post request and now want to add "cookie" authentication. I checked both options on the "Settings for resource" page. But when I try to do the cookie authentication I get

echo '{"foo": "bar"}' | curl -d @- http://localhost/api/RESOURCE?_format=hal_json --header "Content-Type:application/json" --header "X-CSRF-Token:1234" -v
HTTP/1.1 401 Unauthorized
{"message":"No authentication credentials provided."}

If I disable basic_auth and just leave cookie auth do the same request I get

echo '{"foo": "bar"}' | curl -d @- http://localhost/api/RESOURCE?_format=hal_json --header "Content-Type:application/json" --header "X-CSRF-Token:1234" -v
HTTP/1.1 403 Forbidden
{"message":"The \u0027restful post RESOURCE_rest_resource\u0027 permission is required."}

Not sure why I'm getting a different error message but what do I need to do to get cookie auth working? If I go to the People -> Permissions page and enable "Access POST" on my resource for Anonymous users then the curl call works. But that seems to completely bypass any authentication so I don't want that. Here's the call after enabling "Access POST" for anon users:

echo '{"foo": "bar"}' | curl -d @- http://localhost/api/RESOURCE?_format=hal_json --header "Content-Type:application/json" -v
HTTP/1.1 201 Created

Problem/Motivation

Berdir at #2720233-82: Use arguments resolver in RequestHandler to have consistent parameter ordering:

What he means is this line:

$method = strtolower($request->getMethod());

The problem is you can define whatever you want in your routes.. the concept that http method == php methed on the RestResource plugin is hardcoded and basically impossible to change without duplicating the whole method there.

Instead, it would like this:

$method ? $route_match->getRouteObject()->getOption('_rest_method') ?: strtolower($request->getMethod());

Then I could just say _rest_method = 'list' in my routes() method and wouldn't need my current ugly hacks.

Wim Leers at #2720233-82: Use arguments resolver in RequestHandler to have consistent parameter ordering:

Ah, I see! That's indeed one of the more questionable design decisions about Resource(Interface|Base) + RequestHandler.

I do find _rest_method = 'list' confusing too though. The REST module basically has spent no time/thought on how to deal with collections. AFAICT it deferred that entirely to Views. Which is often undesirable or overkill of course. I think the way you implemented it (http://cgit.drupalcode.org/monitoring/tree/src/Plugin/rest/resource/Moni... + http://cgit.drupalcode.org/monitoring/tree/src/Plugin/rest/resource/Moni...), with a single get() responsible for both individual and collection GET requests with an optional parameter makes total sense. Shall we discuss that further in a follow-up, to officially support that pattern? So that you don't need those routes() overrides anymore?

Then we could at least start having basic collection GET support. If you're +1, either create a follow-up or comment here and I'll create that follow-up.

Berdir at #2720233-83: Use arguments resolver in RequestHandler to have consistent parameter ordering:

Opening an issue certainly makes sense, but I'm not sure that it should be like I did with monitoring. For one thing, configuration is currently tied to methods, what if a resource doesn't support lists or only supports lists, or supports both but you only want to enable one of the two things? But we can discuss that in a dedicated issue. I already mentioned #2100637: REST views: add special handling for collections above, not sure if that *is* that issue but it's certainly related?

Proposed resolution

TBD

Remaining tasks

Discuss.

User interface changes

None.

API changes

API addition: details TBD

Data model changes

None.

Problem/Motivation

Everyone is having problems with modules being exported where they don't want it to be. The canonical example is the devel module.

Proposed resolution

Add a key to a module's info.yml file to allow them to opt out of config deployments.

Remaining tasks

User interface changes

None

API changes

TBD

Data model changes

None

Problem/Motivation

After doing some updates on our homepage we used the UI to delete a node we don't require anymore.

When we go to /admin/content we get the following PHP error:

[16-oct-2017] TypeError: Argument 1 passed to Drupal\views\Plugin\views\field\EntityOperations::getEntityTranslation() must implement interface Drupal\Core\Entity\EntityInterface, null given, called in [path.to.my.site]/core/modules/views/src/Plugin/views/field/EntityOperations.php on line 111 in Drupal\views\Plugin\views\field\EntityOperations->getEntityTranslation() (line 69 of [path.to.my.site]/core/modules/views/src/Entity/Render/EntityTranslationRenderTrait.php)

So it looks like Drupal8 tries to render information about the deleted node.

Proposed resolution

Ignore missing node when rendering the view.

This only stops the error message on page load, it doesn't fix the bug when deleting a node (the incomplete deleting of the node references?)

Thank you.
Susi

Postponed on #2935951: Copy migrate source plugin from migrate_drupal_d8 into migrate_drupal

Problem/Motivation

In #30 of the parent issue phenaproxima suggested a plan for handling entity references, links, menu_items, user_ratings.

The issue is for working on the entity_reference fields.

Proposed resolution

The issue proposed solution is:

Let's create more migrations to deal with this. They would have to run after the node migrations (d6_node:*, d7_node:*, and their ilk), which we can accomplish using the existing migration dependency system. They could easily loop through all entity reference fields, and then simply use the migration_lookup plugin to adjust the value.

Remaining tasks

Write the test and patch
Test it some more
Commit it!

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Problem/Motivation

Even after we get the last couple i18n issues resolved, there are still many unknowns and areas for i18n could get improved. Rather than rushing and stating all i18n migrations are ready because we just need to get things out the door, let’s take off the pressure. Give us a little more time to do things properly. Having a separate marking module let’s us mark i18n stable when it is really more stable.

Proposed resolution

• Add a new migrate_drupal_i18n module
• In all i18n source plugins, add to the existing checkRequirements function a call to \Drupal::service(‘module_handler’)->moduleExists(‘migrate_drupal_i18n’).
• If the module doesn’t exist (i.e. it isn’t installed) then it fails requirements and will not be available for migrations.
• Then mark migrate_drupal_i18n as experimental. And mark migrate_drupal as stable.
• Profit

Remaining tasks

• Roll a patch.
• Discuss if this can land as Experimental into 8.5. That way we could mark migrate drupal and the UI as stable sooner.

User interface changes

API changes

Data model changes

This issue is spun off from #2908282: Throw exception for source plugins without a source_module property.

Problem/Motivation

There are several implicitily required properties to destination, source and process plugins. Rather than waiting for someone to WSOD when they miss one of these implicit requirements, we should throw a loud exception.

The MigrateDestination annotation defines a destination_module property which needs to identify the system which will contain the processed, migrated data. In Migrate Drupal's case, this property is used to identify the D8 module which will "own" the migrated data.

When providing a strong API, it's important to tell consumers when they are doing something wrong. For Migrate Drupal's purposes (our main use case), this property is required in order to inform users whether their D6/D7 data will be migrated into Drupal 8. Therefore, this blocks the completion of the core migration path to Drupal 8, and is Migrate-critical.

Proposed resolution

• Port the destination-specific code from #2908282-53: Throw exception for source plugins without a source_module property into this issue
• Iterate on it until it's ready to commit. Consider inputs from:
  • #2908282-64: Throw exception for source plugins without a source_module property,
  • #2908282-65: Throw exception for source plugins without a source_module property&
  • #2908282-66: Throw exception for source plugins without a source_module property
  • Commit it.

  Remaining tasks

  That thing I just said.

  User interface changes

  None.

  API changes

  The destination_module property will be required on all Migrate destination plugins. So this constitutes a BC break.

  Data model changes

  None.

The fullscreen version of the ajax-progress loader is inserted after the body.

Drupal.Ajax.prototype.setProgressIndicatorFullscreen = function () {
    this.progress.element = $('<div class="ajax-progress ajax-progress-fullscreen">&nbsp;</div>');
    $('body').after(this.progress.element);
};

You should not insert html elements after the body, it is not valid HTML and will fail W3C. Try testing this, which is what Drupal generates.

<!DOCTYPE html>
<html>
<head>
<title>TEST</title>
</head>
<body></body>
<div></div>
</html>

$('body').after() should be replaced with $('body').append()

I'm working on an upgrade path for our projects from media_entity to media in core.

After running drush updb i have a duplicated image field on the media entity image.

Before update:

After update:

I think we don't have a really special configuration but i can provide additional informations if needed.

When I execute the following command, errors appear and the updates do not occur :

www.s1biose.com@vps000000:~/public_html$ composer update drupal/core --with-dependencies

Cannot create cache directory /home/www.s1biose.com/.composer/cache/repo/https---packages.drupal.org-8/, or directory is not writable. Proceeding without cache
Cannot create cache directory /home/www.s1biose.com/.composer/cache/repo/https---packagist.org/, or directory is not writable. Proceeding without cache
Cannot create cache directory /home/www.s1biose.com/.composer/cache/files/, or directory is not writable. Proceeding without cache
Gathering patches for root package.
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Conclusion: don't install symfony/console v3.2.13
    - Conclusion: don't install symfony/console v3.2.12
    - Conclusion: don't install symfony/console v3.2.11
    - Conclusion: don't install symfony/console v3.2.10
    - Conclusion: don't install symfony/console v3.2.9
    - Conclusion: don't install symfony/console v3.2.8
    - drupal/core 8.4.0 requires symfony/console ~3.2.8 -> satisfiable by symfony/console[3.2.x-dev, v3.2.10, v3.2.11, v3.2.12, v3.2.13, v3.2.8, v3.2.9].
    - drupal/core 8.4.0-beta1 requires symfony/console ~3.2.8 -> satisfiable by symfony/console[3.2.x-dev, v3.2.10, v3.2.11, v3.2.12, v3.2.13, v3.2.8, v3.2.9].
    - drupal/core 8.4.0-rc1 requires symfony/console ~3.2.8 -> satisfiable by symfony/console[3.2.x-dev, v3.2.10, v3.2.11, v3.2.12, v3.2.13, v3.2.8, v3.2.9].
    - drupal/core 8.4.0-rc2 requires symfony/console ~3.2.8 -> satisfiable by symfony/console[3.2.x-dev, v3.2.10, v3.2.11, v3.2.12, v3.2.13, v3.2.8, v3.2.9].
    - drupal/core 8.4.x-dev requires symfony/console ~3.2.8 -> satisfiable by symfony/console[3.2.x-dev, v3.2.10, v3.2.11, v3.2.12, v3.2.13, v3.2.8, v3.2.9].
    - drupal/core 8.5.x-dev requires symfony/console ~3.2.8 -> satisfiable by symfony/console[3.2.x-dev, v3.2.10, v3.2.11, v3.2.12, v3.2.13, v3.2.8, v3.2.9].
    - Conclusion: don't install symfony/console 3.2.x-dev
    - Installation request for drush/drush (locked at 8.1.13, required as ^8.1) -> satisfiable by drush/drush[8.1.13].
    - drupal/commerce 2.x-dev requires drupal/core ~8.4 -> satisfiable by drupal/core[8.4.0, 8.4.0-alpha1, 8.4.0-beta1, 8.4.0-rc1, 8.4.0-rc2, 8.4.x-dev, 8.5.x-dev].
    - drupal/commerce 2.x-dev requires drupal/core ~8.4 -> satisfiable by drupal/core[8.4.0, 8.4.0-alpha1, 8.4.0-beta1, 8.4.0-rc1, 8.4.0-rc2, 8.4.x-dev, 8.5.x-dev].
    - drupal/commerce 2.x-dev requires drupal/core ~8.4 -> satisfiable by drupal/core[8.4.0, 8.4.0-alpha1, 8.4.0-beta1, 8.4.0-rc1, 8.4.0-rc2, 8.4.x-dev, 8.5.x-dev].
    - Conclusion: don't install drupal/core 8.4.0-alpha1
    - Installation request for drupal/commerce 2.x-dev -> satisfiable by drupal/commerce[2.x-dev].

www.s1biose.com@vps000000:~/public_html$ nano composer.json

{
    "name": "drupal-composer/drupal-project",
    "description": "Project template for Drupal 8 projects with composer",
    "type": "project",
    "license": "GPL-2.0+",
    "authors": [
        {
            "name": "",
            "role": ""
        }
    ],
    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        }
    ],
    "require": {
        "composer/installers": "^1.2",
        "cweagans/composer-patches": "^1.6",
        "drupal-composer/drupal-scaffold": "^2.2",
        "drupal/admin_toolbar": "^1.19",
        "drupal/autologout": "1.x-dev",
        "drupal/back_to_top": "^1.0@beta",
        "drupal/bootstrap": "^3.3",
        "drupal/bootstrap_layouts": "5.x-dev",
        "drupal/captcha": "^1.0@beta",
        "drupal/colorbox": "^1.4",
        "drupal/commerce": "2.x-dev",
        "drupal/commerce_license": "2.x-dev",
        "drupal/commerce_paypal": "^1.0@beta",
        "drupal/commerce_payplug": "^1.2",
        "drupal/commerce_shipping": "^2.0@beta",
        "drupal/commerce_stock": "1.x-dev",
        "drupal/console": "~1.0",
        "drupal/copyright_block": "1.x-dev",
        "drupal/core": "~8.0",
        "drupal/diff": "^1.0@RC",
        "drupal/ds": "^3.0",
        "drupal/eu_cookie_compliance": "1.x-dev",
        "drupal/eva": "^1.2",
        "drupal/field_timer": "^1.0",
        "drupal/field_validation": "^1.0@alpha",
        "drupal/fivestar": "1.x-dev",
        "drupal/flag": "4.x-dev",
        "drupal/geocoder": "2.x-dev",
        "drupal/geofield": "1.x-dev",
        "drupal/geofield_map": "^1.4",
        "drupal/group": "1.x-dev",
        "drupal/honeypot": "^1.24",
        "drupal/invite": "1.x-dev",
        "drupal/leaflet": "1.x-dev",
        "drupal/leaflet_markercluster": "1.x-dev",
        "drupal/leaflet_more_maps": "^1.0@alpha",
        "drupal/masquerade": "^2.0@beta",
        "drupal/message": "1.x-dev",
        "drupal/message_digest": "^1.0@alpha",
        "drupal/message_private": "1.x-dev",
        "drupal/message_subscribe": "^1.0@beta",
        "drupal/message_thread": "^1.0@alpha",
        "drupal/metatag": "1.x-dev",
        "drupal/module_filter": "^3.0",
        "drupal/office_hours": "1.x-dev",
        "drupal/paragraphs": "1.x-dev",
        "drupal/pathauto": "^1.0",
        "drupal/piwik": "^1.1",
        "drupal/poll": "1.x-dev",
        "drupal/redirect": "^1.0@beta",
        "drupal/rules": "3.x-dev",
        "drupal/schema_metatag": "^1.0@RC",
        "drupal/search404": "^1.0@beta",
        "drupal/search_api": "1.x-dev",
        "drupal/simple_sitemap": "2.x-dev",
        "drupal/super_login": "1.x-dev",
        "drupal/swiftmailer": "^1.0@beta",
        "drupal/token": "1.x-dev",
        "drupal/typed_data": "1.x-dev",
        "drupal/views_bootstrap": "3.x-dev",
        "drupal/views_send": "^1.0",
        "drupal/yoast_seo": "2.x-dev",
        "drush/drush": "^8.1",
        "webflo/drupal-finder": "^0.3.0",
        "webmozart/path-util": "^2.3"
    },
    "require-dev": {
        "behat/mink": "~1.7",
        "behat/mink-goutte-driver": "~1.2",
        "jcalderonzumba/gastonjs": "~1.0.2",
        "jcalderonzumba/mink-phantomjs-driver": "~0.3.1",
        "mikey179/vfsstream": "~1.2",
        "phpunit/phpunit": ">=4.8.28 <5",
        "symfony/css-selector": "~2.8"
    },
    "conflict": {
        "drupal/drupal": "*"
    },
    "minimum-stability": "dev",
    "prefer-stable": true,
    "config": {
      "sort-packages": true
    },
    "autoload": {
        "classmap": [
            "scripts/composer/ScriptHandler.php"
        ]
    },
    "scripts": {
        "drupal-scaffold": "DrupalComposer\\DrupalScaffold\\Plugin::scaffold",
        "pre-install-cmd": [
            "DrupalProject\\composer\\ScriptHandler::checkComposerVersion"
        ],
        "pre-update-cmd": [
            "DrupalProject\\composer\\ScriptHandler::checkComposerVersion"
        ],
        "post-install-cmd": [
            "DrupalProject\\composer\\ScriptHandler::createRequiredFiles"
        ],
        "post-update-cmd": [
            "DrupalProject\\composer\\ScriptHandler::createRequiredFiles"
        ]
    },
    "extra": {
        "installer-paths": {
            "web/core": ["type:drupal-core"],
            "web/libraries/{$name}": ["type:drupal-library"],
            "web/modules/contrib/{$name}": ["type:drupal-module"],
            "web/profiles/contrib/{$name}": ["type:drupal-profile"],
            "web/themes/contrib/{$name}": ["type:drupal-theme"],
            "drush/contrib/{$name}": ["type:drupal-drush"]
        },
       "patches": {
            "drupal/core": {
                "Number widget validation can break AJAX actions": "https://www.drupal.org/files/issues/2614250-40.patch",
                "Fetch User ID from route context views contextual filter for any entity": "https://www.drupal.org/files/issues/fetch_user_id_from_route_for_all-2904908-2.patch",
                "If no body field [node summary] [node body] etc tokens are not replaced": "https://www.drupal.org/files/issues/drupal-tokens_are_not_replaced-1671420-12-D8.patch"
            },
            "drupal/commerce": {
                "Add store name to shopping cart when multiple stores enabled": "https://www.drupal.org/files/issues/add-store-name-when-multiple-stores-2870053-6.patch",
                "Views refuse to display the product type label": "https://www.drupal.org/files/issues/allow_product_type_labels_in_views-2900472-4.patch",
                "With a view catalog only the first product variations works": "https://www.drupal.org/files/issues/2897698-24.patch"
            },
            "drupal/rules": {
                "PHP Fatal error when adding an action and address is installed": "https://www.drupal.org/files/issues/2694685-52.rules-fix_type_definition_error.patch"
            },
            "drupal/flag": {
                "Add relationship to flagged entities when Flagging is base table": "https://www.drupal.org/files/issues/2723703_31.patch",
                "Unflag not allowed text does not work": "https://www.drupal.org/files/issues/2886308-Unflag-not-allowed-text-20.patch",
                "Views link field doesn't use flag.html.twig": "https://www.drupal.org/files/issues/2888268-8-views-link-doesnt-use-twig.patch"
            },
            "drupal/leaflet": {
                "LeafletMarker could not recognize geofield": "https://www.drupal.org/files/issues/leaflet-recognize_geofield-2839538.patch",
                "Leaflet not always working with AJAX": "https://www.drupal.org/files/issues/leaflet-2858091-3-alternative.patch",
                "Fix config schema": "https://www.drupal.org/files/issues/leaflet-config_schema-2883700-3.patch",
                "Error in leaflet_process_geofield() when twig debug is active": "https://www.drupal.org/files/issues/leaflet-error-when-debug-active-2783843-5.patch",
                "Rendered entity tooltip only works for nodes": "https://www.drupal.org/files/issues/rendered_entity_tooltip-2890641-2.patch"
            },
            "drupal/geofield": {
                "Re-implement the Views proximity filter/field for Drupal 8": "https://www.drupal.org/files/issues/geofield_views_proximity_filter-2654360-63.patch"
            },
            "drupal/geocoder": {
                "Incorrect config schema for geocoder.settings": "https://www.drupal.org/files/issues/2824802-geocoder-schema-fix-2.patch",
                "Don't add third party settings when geocoder method is none": "https://www.drupal.org/files/issues/geocoder-omit_third_party_settings-2884928-2-D8.patch",
                "Convert module to use short array syntax (new coding standard)": "https://www.drupal.org/files/issues/short_array_syntax-2881694-2.patch",
                "Remove admin variables when uninstall": "https://www.drupal.org/files/issues/remove_admin_variables-2833058-2.patch"
            },
            "drupal/views_bootstrap": {
                "Missing responsive utilities for grid with horizontal alignment": "https://www.drupal.org/files/issues/6e5acf0.patch",
                "Regression Raw field value displayed in accordion panel title": "https://www.drupal.org/files/issues/raw_field_value-2870642-2.patch"
            },
            "drupal/search404": {
                "Custom search to custom url": "https://www.drupal.org/files/issues/2844729-custom-search-to-custom-url_0.patch",
                "Allow spaces as seperators for custom search path": "https://www.drupal.org/files/issues/2896547-allow-spaces-as-separator-2.patch"
            }
        }
    }
}

Problem/Motivation

When flushing the cache on a site recently upgraded to Drupal 8.5, I am now getting a fatal uncaught error:

 Rebuilding cache(s), wait a moment please.
PHP Fatal error:  Uncaught Error: Call to undefined method Drupal\views\Plugin\views\style\DefaultStyle::getFormats() in /app/docroot/core/modules/rest/src/Plugin/views/display/RestExport.php:368
Stack trace:
#0 /app/docroot/core/modules/views/src/EventSubscriber/RouteSubscriber.php(120): Drupal\rest\Plugin\views\display\RestExport->collectRoutes(Object(Symfony\Component\Routing\RouteCollection))
#1 [internal function]: Drupal\views\EventSubscriber\RouteSubscriber->routes()
#2 /app/docroot/core/lib/Drupal/Core/Routing/RouteBuilder.php(146): call_user_func(Array)
#3 /app/docroot/core/lib/Drupal/Core/ProxyClass/Routing/RouteBuilder.php(83): Drupal\Core\Routing\RouteBuilder->rebuild()
#4 /app/docroot/core/includes/common.inc(1156): Drupal\Core\ProxyClass\Routing\RouteBuilder->rebuild()
#5 /app/vendor/drupal/console/src/Utils/DrupalApi.php(355): drupal_flush_all_caches()
#6 /app/vendor/drupal/console/src/Command/Cache/RebuildCommand.php(103): Drupal\Console\Utils\DrupalApi->drupal_rebuild(Object(Symfony\Component\ClassLoader\ApcCl in /app/docroot/core/modules/rest/src/Plugin/views/display/RestExport.php on line 368

Fatal error: Uncaught Error: Call to undefined method Drupal\views\Plugin\views\style\DefaultStyle::getFormats() in /app/docroot/core/modules/rest/src/Plugin/views/display/RestExport.php on line 368

Error: Call to undefined method Drupal\views\Plugin\views\style\DefaultStyle::getFormats() in /app/docroot/core/modules/rest/src/Plugin/views/display/RestExport.php on line 368

API changes

Upgrade to Drupal 8.5

There's a following code found at \Drupal\migrate\Plugin\migrate\destination\EntityContentBase::processStubRow():

    $bundle_key = $this->getKey('bundle');
    if ($bundle_key && empty($row->getDestinationProperty($bundle_key))) {
      if (empty($this->bundles)) {
        throw new MigrateException('Stubbing failed, no bundles available for entity type: ' . $this->storage->getEntityTypeId());
      }
      $row->setDestinationProperty($bundle_key, reset($this->bundles));
    }

    // Populate any required fields not already populated.
    $fields = $this->entityManager
      ->getFieldDefinitions($this->storage->getEntityTypeId(), $bundle_key);

The $bundle_key variable contains bundle property name (e.g. 'type' for a node) while getFieldDefinitions() expects bundle name.

The effects are following:

1) The $fields variable is not correctly populated.
2) Some entity types may throw an exception or error; in my particular case, \Drupal\commerce_order\Entity\OrderItem::bundleFieldDefinitions() was throwing an 'Error: Call to a member function getPurchasableEntityTypeId() on null' error since it failed to load a bundle.

I think we should pass '$row->getDestinationProperty($bundle_key)' (which is a bundle property value) rather than just '$bundle_key'.

Problem/Motivation

The REST export (\Drupal\rest\Plugin\views\display\RestExport) ViewsDisplay plugin allows paths to be configured for displays, but does not allow menu entries. While menu entries may not make sense for JSON serialization, there are use cases for other types.

For example, https://www.drupal.org/project/csv_serialization and https://www.drupal.org/project/xls_serialization allow users to create a View and have it create a CSV or XLS file. A user may want to make these available as a menu entry (eg, a menu of all of the XLS reports that can be generated from a site). Right now, you can add the path manually to a menu, but this means path changes need to be updated in multiple places and can cause quirks with permission changes made in views. You can also make a similar case for XML exports (I have had clients where we have done lots of manually trading XML back and forth).

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes