I'm running MySQL 5.7 under Ubuntu 16.04. The query for the affiliated content leads to an error:

Drupal\Core\Database\DatabaseExceptionWrapper: Exception in Affiliated content[affiliated_content]: SQLSTATE[HY000]: General error: 3065 Expression #1 of ORDER BY clause is not in SELECT list, references column 'gh.node_field_data.changed' which is not in SELECT list; this is incompatible with DISTINCT: SELECT DISTINCT node_field_data.langcode AS node_field_data_langcode, users_field_data_node_field_data.langcode AS users_field_data_node_field_data_langcode, node_field_data.nid AS nid, users_field_data_node_field_data.uid AS users_field_data_node_field_data_uid FROM {node_field_data} node_field_data INNER JOIN {users_field_data} users_field_data_node_field_data ON node_field_data.uid = users_field_data_node_field_data.uid LEFT JOIN {node__field_domain_access} node__field_domain_access ON node_field_data.nid = node__field_domain_access.entity_id AND (node__field_domain_access.deleted = :views_join_condition_0 AND node__field_domain_access.langcode = node_field_data.langcode) WHERE (( (node__field_domain_access.field_domain_access_target_id = :db_condition_placeholder_2) )) ORDER BY node_field_data.changed DESC LIMIT 50 OFFSET 0; Array ( [:db_condition_placeholder_2] => polybau [:views_join_condition_0] => 0 ) in Drupal\views\Plugin\views\query\Sql->execute() (Zeile 1488 in /web/core/modules/views/src/Plugin/views/query/Sql.php).

Enable images to be added to the body field via text formats.
goto the body field.
select an image
hist save.
You get a white screen and the error:

Error: Call to undefined method Drupal\\Core\\Image\\Image::setAttribute() in drupal-8.5.3/html/core/modules/filter/filter.module on line 843

#0 drupal-8.5.3/html/core/lib/Drupal/Core/Extension/ModuleHandler.php(539): filter_filter_secure_image_alter(Object(Drupal\\Core\\Image\\Image), NULL, NULL)\

I downloaded a brand new drupal-8.5.3 to test.
cd drupal-8.5.3/core/modules/image
grep -in setAttributes -d recurse *

There is no setAttributes.

In the api there is no reference to setAttributes
https://api.drupal.org/api/drupal/core%21modules%21image%21src%21Plugin%...

However I do see it defined for resonsive_image and media.

What happened?

Problem/Motivation

As per discussion in the weekly Layout Initiative meeting #2972783: [Weekly Meeting] 2018/05/15 we need to decide how Layout Builder should function with Content Moderation and Workspaces modules and detailing the complexities.

These decisions have an impact on how issues like #2937199: Track Layout override revisions on entities which support revisioning and #2957425: Explore the concept of Custom Block re-usability should be implemented.

Proposed resolution

n/a

Remaining tasks

Discuss and make decisions.

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Problem/Motivation

Two problems:

1) Unit test requires a database

Running TestSiteApplicationTest in isolation reveals that it errors out.

That's because it uses the SIMPLETEST_DB environmental variable, which is intended for use by KernelTestBase tests.

$ ./vendor/bin/phpunit -c core/ --testsuite unit --filter TestSiteApplicationTest
PHPUnit 6.5.8 by Sebastian Bergmann and contributors.

Testing 
EEESS.                                                              6 / 6 (100%)

Time: 17.01 seconds, Memory: 136.00MB

There were 3 errors:

1) Drupal\Tests\Scripts\TestSiteApplicationTest::testInstallWithNonExistingFile
InvalidArgumentException: Minimum requirement: driver://host/database

/Users/paulmitchum/projects/drupal8/core/lib/Drupal/Core/Database/Database.php:460
/Users/paulmitchum/projects/drupal8/core/tests/Drupal/Tests/Scripts/TestSiteApplicationTest.php:267
/Users/paulmitchum/projects/drupal8/core/tests/Drupal/Tests/Scripts/TestSiteApplicationTest.php:47

This can be mitigated by setting the SIMPLETEST_DB variable in phpunit.xml, but this ruins the isolation between unit and kernel tests.

2) This test is never run by run-tests.sh

Since it lives in core/tests/Scripts, the test is not discovered when run-tests.sh runs tests.

You can see evidence of this in this recent HEAD test. See the actual tests that were run which does not include TestSiteApplicationTest: https://dispatcher.drupalci.org/job/php7_mysql5.5/5506/artifact/jenkins-...

Versus the test list generated for that same build which lists TestSiteApplicationTest: https://dispatcher.drupalci.org/job/php7_mysql5.5/5506/artifact/jenkins-...

Here's an issue about fixing that discrepancy: #2878269: Modify TestDiscovery so the testbot runs all the tests

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

This is a child issue of #2949363: [meta] Impossible to make trigger_error in some files without test fails

In that issue we discovered that we can't perform test discovery on files which @trigger_error() for deprecation.

These include abstract classes, such as base classes and traits.

The problem: Reflection loads the file, which triggers the deprecation error whether the class is used or not in any test.

In #2296635: Evaluate performance impact of limiting test discovery to *Test.php filename suffix we considered excluding all files from scan except for *test.php files. This presents BC problems because it could lead to false positives for the unaware.

Proposed resolution

Modify TestDiscovery to exclude reflection on files which end in TestBase.php or Trait.php.

Remaining tasks

User interface changes

API changes

Data model changes

In #2319103-5: SearchAPI tasks system does not scale, I wanted to add a local action for a route that is only accessible under special conditions. I added an access check class implementing \Drupal\Core\Routing\Access\AccessInterface and from its access() method return AccessResult objects with a cache max-age of 0 (as the conditions can change at any time – maybe I'll add a cache tag later instead).

However, this doesn't work as expected, since it seems the render cache still caches the "Local actions" block, without taking the cache data from the individual local actions into account. It seems to me that the information from those is just never looked at to compute the cache data for the complete block's render array.

I admit I know little about all of this, so it's possible I'm just doing something wrong – but, if so, I just cannot find it.
My knowledge also isn't sufficient to guess at what the proper fix could be here (if this is indeed a bug). I expect it will be somewhere in the local actions system, so I set "menu system" as the component.

Please tell me if I can provide any more information!

(Also, I tried this in the latest 8.2.x dev version, but I expect the bug's present in 8.1.x as well – don't know what to set as the version, then.)

Hey folks. Any idea on where to start looking to debug the following? I'm getting this on one of my sites after the 8.5.0 upgrade. I tried disabling all my contrib modules, yet this error still persists.

[Thu Mar 08 09:41:03.880667 2018] [:error] [pid 22584] [client 69.162.124.237:24151] Uncaught PHP Exception Drupal\\Core\\Database\\DatabaseExceptionWrapper: "SQLSTATE[42S22]: Column not found: 1054 Unknown column 'revision.revision_default' in 'field list': SELECT revision.revision_id AS revision_id, revision.langcode AS langcode, revision.revision_user AS revision_user, revision.revision_created AS revision_created, revision.revision_log AS revision_log, revision.revision_default AS revision_default, base.id AS id, base.type AS type, base.uuid AS uuid, CASE base.revision_id WHEN revision.revision_id THEN 1 ELSE 0 END AS isDefaultRevision\nFROM \n{block_content} base\nINNER JOIN {block_content_revision} revision ON revision.revision_id = base.revision_id; Array\n(\n)\n" at /var/www/drupal8/www.MYSITE.com/public_html/core/lib/Drupal/Core/Database/Connection.php line 686, referer: http://www.MYSITE.com/

Problem/Motivation

On a site using the Workflows and Content Moderation modules, I created a table using Views, and enabled click-to-sort for the "Moderation state". When I click on the column header, I get a WSOD with the error message

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

Drupal\Core\Entity\Sql\SqlContentEntityStorageException: Column information not available for the 'moderation_state' field. in Drupal\Core\Entity\Sql\DefaultTableMapping->getFieldColumnName() (line 215 of core/lib/Drupal/Core/Entity/Sql/DefaultTableMapping.php).

Drupal\views\Plugin\views\field\EntityField->clickSort('asc') (Line: 139)

The site I am using is Drupal 8.5.0. I have not yet tried to reproduce the problem on a plain Drupal install, but it seems like a bug in Drupal core.

Proposed resolution

TBD

Remaining tasks

User interface changes

None

API changes

TBD

Data model changes

TBD

Please credit `svenryen, nattie, joseph.olstad, mforbes, bwaindwain` from #2908543: Tabledrag is broken when you've scrolled down on the page in chrome 61

Problem/Motivation

After two recent commits, the drag and drop behavior is bugged in IE11: when dragging the bottom item, the page is scrolled to the top of the page.

Behavior before (7.50):

Current behavior (7.53):

The related commits are:
- #1261002: Draggable tables do not work on touch screen devices
- #2821441: Newer Chrome versions and IE11/Edge cannot drag and drop anymore on desktop after 7.51 update when jQuery is updated to 1.7-1.11.0

Proposed resolution

Return the drag and drop behavior in IE11 to the state of Drupal <7.51

Remaining tasks

1. Write a patch
2. Review
3. Commit

User interface changes

The drag and drop behavior in IE11 is unchanged compared to Drupal <7.51

API changes

None

Data model changes

Problem/Motivation

The UI for filters and bulk operations on listings (content, files, comments, users and more) are inconsistent and not very pretty.

Content:

Comments:

Users:

Proposed resolution

1. View with filters + actions

By default, the only view with both filters and actions is People page:
- People (/admin/people): #2023683: Improve the layout and usability of the admin/people exposed filters and actions

Proposed design:

2. View with filters.

The rest of the views that have several filters in a fieldset. The proposed design follows the style guide (https://groups.drupal.org/node/283223#Fieldset).
- @TODO: Decide label for the field set to suit both filters and sort options.
List of places in core where it can be found:
- Content (/admin/content) #2521808: Visually encapsulate the content listing filter to distinguish it from the 'add content' action link
- Files (/admin/content/files)
- Custom block library (/admin/structure/block/block-content)

In case there are several lines of filters, they should be nicely placed in several lines: #2711337: Too many exposed filters and operators create weird view.

3. Single text filters (filtering in-page).

This one is a single filter used to filter elements in the current page. A new design have been created with a bigger input and a magnifying glass to make it clear what is its purpose. List of places in core where it can be found:
- Views (/admin/structure/views)
- Extend (/admin/modules)
- Uninstall (/admin/modules/uninstall)

4. Single filters with button (paged list).

A single filter appearing used to filter elements in several pages. In this case the single filter should be envolved in a fieldset and a button will be placed inline, following the current design in the styleguide (https://groups.drupal.org/node/283223#Fieldset).

List of places in core where it can be found:
- URL aliases (/admin/config/search/path)

5. Only actions.

The design to use should be the same used for People view page.
List of places in core where it can be found:
- Comments (/admin/content/comment)
- Unapproved comments (/admin/content/comment/approval)

1. Explore visual design options
2. Decide on a direction
3. You are here: Implement:
   • #2023683: Improve the layout and usability of the admin/people exposed filters and actions
   • #2521808: Visually encapsulate the content listing filter to distinguish it from the 'add content' action link
   • #2711337: Too many exposed filters and operators create weird view
   • @TODO: Create issue for single filter in-page (Filters 3)
   • @TODO: Create issue to fix styles in URL aliases (Filters 4)
   • @TODO: Find related issues or create a new one for styling system actions in comments (not views) (Filters 5)

User interface changes

Pretty & consistent UI pattern and design for filters and bulk operations on listing pages.

API changes

?

Data model changes

?

drupal-7.56\includes\database\select.inc has function

  public function orderBy($field, $direction = 'ASC') {
    // Only allow ASC and DESC, default to ASC.
    $direction = strtoupper($direction) == 'DESC' ? 'DESC' : 'ASC';
    $this->order[$field] = $direction;
    return $this;
}

so it means, that I can't sort data -> ASC NULLS FIRST OR DESC NULLS LAST, etc.

should be changed to something like this:

 public function orderBy($field, $direction = 'ASC') {
    // Only allow ASC and DESC, default to ASC.
    
    $direction = strtoupper($direction);
    if ($direction !="ASC NULLS FIRST"){
    $direction == 'DESC' ? 'DESC' : 'ASC';
    }
    // 
    $this->order[$field] = $direction;
    return $this;
  }

MySQL exports nulls first, but PostgreSQL export nulls last, so there is big problem if db are switched and there is no way to fix this problem, because there is only ASC and DESC values allowed.

Problem/Motivation

The current Media administration experience is not very visual, and does not look like what most people expect from a CMS.

Proposed resolution

We should update the view at /admin/content/media to look more modern - displaying a grid of media cards that show a preview of the media and metadata (attributes/fields) that make sense for each media item.

To give more flexibility to site builders and themers, each media item in the library is rendered in a new view mode called "Media Library", which is customizable like any other view mode.

This updated view will also be the basis for a new Field Widget, to allow visual selection of Media while editing/creating content. This widget will be added in another issue, but part of why this is being added in a new experimental module is to have a place for us to iterate on the widget and other code related to the Media Library experience.

Remaining tasks

Review the current patch. Discuss UX feedback.

Note for committers - on commit, please ensure that "jan.stoeckler, webflo, seanB, chr.fritsch, DyanneNova, yoroy, dennis-cohn, rfmarcelino, andrewmacpherson, benjifisher" is added to the issue credits. This is ported over from #2834729: [META] Create an MVP for adding and re-using Media.

User interface changes

The view at /admin/content/media looks different, but is functionally the same.

API changes

None.

Data model changes

None.

Problem/Motivation

When you create a Custom Block entity, a Block Plugin definition is derived and is available anywhere Block Plugin definitions are listed. This makes a lot of sense when Custom Blocks are meant to be re-used, for example you may want a "Logo" Custom Block on many pages in different regions.

However, when using something like Panels or Layout Builder, Custom Blocks are often only meant to be used once. If you're building out hundreds of pages you could end up with thousands of Custom Blocks that clutter user interfaces and lead to performance issues.

Proposed resolution

Add a new base field to Custom Blocks that determines is they are re-usable. If a Custom Block is not re-usable, it should not have a derived Block Plugin definition and should not be visible in normal Views listings. For integration with Layout Builder, we should create a new Block Plugin that stores Custom Block revision IDs, possibly also implementing an inline form for editing these Custom Blocks.

This issue actually include several concepts that should probably be split out into separate issues.
To determine if end goal is achievable and advisable with this approach lets keep this as a big patch containing the sub tasks until it looks like it is good idea. We won't want to commit small supporting parts if we are going abandon this approach for something like #2948064: Layout Builder should support inline creation of Custom Blocks using entity serialization(currently that issue seems not doable)

Eventually we may want to have separate issues for

1. Allow some Content Blocks to be non-reusable(probably in Block Content module eventually)
2. Implement generic entity usage tracking to support non-reusable blocks
3. Allow inline creation of non-reusable blocks in the Layout Builder (maybe all that would remain for this issue)

Remaining tasks

Write a patch to explore the feasibility of this approach.

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Problem/Motivation

#597236: Add entity caching to core added the entity cache to core, but unfortunately it did not consinder enabling it when loading an entity by revision id.
There are contrib modules such as Entity Reference Revisions, which allow for referecing an entity by its revision id. The referenced entity is then loaded with ContentEntityStorageBase::loadRevision.
A developer might build a system where she is using ContentEntityStorageBase::loadRevision to load a default entity revision and by doing so she will not profit from the new entity cache.
ContentEntityStorageBase::loadRevision is neither using the static entity cache nor the persistent entity cache, which has as a consequence that the function is inconsistent with ContentEntityStorageBase::load, as if you retrive an entity multiple times in a single request with the latter one it will always return an reference to the same entity object, but if you retrive it multiple times with the former one you will always get a new entity object.

The attached test demonstrates all the problems.

Proposed resolution

1. Move loadRevision and deleteRevision away from EntityStorageInterface and put them into ContentEntityStorageInterface.
2. Add two new functions to RevisionableInterface - getOriginalRevisionId and resetOriginalRevisionId, the latter one will only set the original revision id to the current one.
3. Enable static entity caching for ContentEntityStorageBase::loadRevision for all revisions.
4. Enable persistent entity caching for ContentEntityStorageBase::loadRevision only for default revisions.
5. ContentEntityStorageBase::doPostSave should remove the static cache entry for the previous revision id (ContnetEntityBase::getOriginalRevisionId), if the entity got a new revision id after it has been saved.
6. ContentEntityStorageBase::doPostSave should call the resetOriginalRevisionId function on the entity, to ensure getOriginalRevisionId will return the new revision id the entity received, if the revision id has changed.
7. Ensure ContentEntityStorageBase::load and ContentEntityStorageBase::loadRevision return an reference to the same entity object, if retrieving the default entity revision.

Remaining tasks

Write a patch for the proposed resolution.

User interface changes

none

API changes

Two new functions in ContentEntityInterface - getOriginalRevisionId and resetOriginalRevisionId.

Data model changes

none

There are two cases where the "Restrict images to this site" doesn't work properly:
1) If you copy/paste an image directly into CKEditor, it brilliantly converts it into base64 and the code is saved to the database, like so: <img alt="" src="data:image/png;base64, lots and lots of characters />
2) If your image is explicitly referenced using the full URL (I have got lots like this on my site as a result of using IMCE), like so: <img alt="" src="http://mysite.com/my-image-file.jpg" />
In both these cases, although the image is actually on my site it only gets displayed if I switch off the "Restrict images to this site" filter

Problem/Motivation

Currently, Drupal.AjaxCommands.prototype.insert() always wraps the returned HTML in a div. There are multiple conditions where even the more limited DIV wrapping creates problems (see comments #41-#48).

See the consequences of this in massive duplication related issues, and on screens in #331, and on your sites.

Proposed resolution

The solutions avoids wrapping returned content in all cases where it's possible without breaking existing sites. We will still wrap the inserted markup when trying to insert multiple root elements with a ajax effect. This will be removed from Drupal 9.0.0. For more details: #284. However, the div is now added in a theme function which provides an option for developers to opt out from this.

We can't parse SVGElement without wrapper since innerHTML is only available on HTMLElement. See #316 - #321 about it.

As a result, we decided to first insert the markup into an empty div, and then use .contents() to get the elements (see #336):

// Parse response.data into an element collection.
const $newContent = $('<div></div>').html(response.data).contents();

// ...

// Add the new content to the page.
$wrapper[method]($newContent);

See latest patch

Remaining tasks

• 🎉™️

Follow-up #736066-366: ajax.js insert command sometimes wraps content in a div, potentially producing invalid HTML and other bugs:

@lauriii

We should document that these are deprecated and will be removed in Drupal 9.0.0. We should also open a follow-up for triggering a deprecation warning here.

Postponed until:

• #736066: ajax.js insert command sometimes wraps content in a div, potentially producing invalid HTML and other bugs
• #2962344: [policy, no patch] Document how to handle deprecations in JavaScript

Problem/Motivation

I have observed an InvalidQueryException being caused by what I believe is probing for vulnerability to SA-CORE-2018-002. This occurs when UserPasswordForm::validateForm()is invoked but the 'name' value is not set.

Steps to Reproduce

curl --request POST \
  --url 'http://localhost/user/password?name[#post_render][0]=passthru&name[#markup]=redacted_value&name%5B%23markup%5D=redacted_value&name[%23post_render][0]=passthru' \
  --header 'Cache-Control: no-cache' \
  --header 'Postman-Token: 0a134fcc-949d-49a1-9b26-59ea73adc794' \
  --header 'content-type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW' \
  --form form_id=user_pass

Drupal\Core\Database\InvalidQueryException: Query condition 'users_field_data.mail IN ()' cannot be empty. in Drupal\Core\Database\Query\Condition->condition() (line 103 of core/lib/Drupal/Core/Database/Query/Condition.php).

Proposed resolution

Would it be appropriate to be more defensive and not assume that $form_state->getValue('name') returns a result in UserPasswordForm::validateForm()?

I'd just upgrade my site from 8.4.5 to release 8.5.0 (php7.1) and get now the following exception with one of my views.
This view worked fine before with 8.4.5.

The website encountered an unexpected error. Please try again later.
TypeError: Argument 1 passed to Drupal\views\Plugin\views\field\EntityOperations::getEntityTranslation() must implement interface Drupal\Core\Entity\EntityInterface, null given, called in /srv/devel/deploy/.../releases/20180216111106/core/modules/views/src/Plugin/views/field/EntityOperations.php on line 111 in Drupal\views\Plugin\views\field\EntityOperations->getEntityTranslation() (line 69 of core/modules/views/src/Entity/Render/EntityTranslationRenderTrait.php).

Drupal\views\Plugin\views\field\EntityOperations->getEntityTranslation(NULL, Object) (Line: 111)
Drupal\views\Plugin\views\field\EntityOperations->render(Object) (Line: 1146)
Drupal\views\Plugin\views\field\FieldPluginBase->advancedRender(Object) (Line: 226)
template_preprocess_views_view_field(Array, 'views_view_field', Array) (Line: 287)
Drupal\Core\Theme\ThemeManager->render('views_view_field', Array) (Line: 437)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 1738)
Drupal\views\Plugin\views\field\FieldPluginBase->theme(Object) (Line: 761)
Drupal\views\Plugin\views\style\StylePluginBase->elementPreRenderRow(Array)
call_user_func(Array, Array) (Line: 378)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 709)
Drupal\views\Plugin\views\style\StylePluginBase->renderFields(Array) (Line: 576)
Drupal\views\Plugin\views\style\StylePluginBase->renderGrouping(Array, Array, 1) (Line: 468)
Drupal\views\Plugin\views\style\StylePluginBase->render(Array) (Line: 2112)
Drupal\views\Plugin\views\display\DisplayPluginBase->render() (Line: 131)
Drupal\webprofiler\Views\TraceableViewExecutable->render() (Line: 183)
Drupal\views\Plugin\views\display\Page->execute() (Line: 1627)
Drupal\views\ViewExecutable->executeDisplay('page_1', Array) (Line: 77)
Drupal\views\Element\View::preRenderViewElement(Array)
call_user_func(Array, Array) (Line: 378)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 226)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 227)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object) (Line: 76)
Drupal\webprofiler\EventDispatcher\TraceableEventDispatcher->dispatch('kernel.view', Object) (Line: 156)
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: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 657)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Problem/Motivation

This is a follow-up to #2500521: Upgrade path for Statistics 7.x and 6.x where we identified that StatisticsViewsResult was (sometimes) returning strings when it should only ever return integers.

Proposed resolution

Cast the inputs to integer in the constructor.

Remaining tasks

Write patch.
Review patch.
etc.
Removes @todo from Drupal\Tests\statistics\Kernel\Migrate\d6\MigrateNodeCounterTest and Drupal\Tests\statistics\Kernel\Migrate\d7\MigrateNodeCounterTest (assuming #2500521: Upgrade path for Statistics 7.x and 6.x lands first).

User interface changes

API changes

Data model changes