Problem/Motivation

While working on #2757007: Convert all book web tests to BrowserTestBase, I discovered that, in a JavascriptTestBase test, it's impossible to swap 2 rows by dragging the lower over upper row. The reverse works: you can swap them by dragging the upper over the lower row.

This behaviour doesn't occur when testing manually

In order to unblock #2757007: Convert all book web tests to BrowserTestBase, I opened this dedicated issue for investigation but it can be also a starting point for a full draggable table test.

It's possible that this behaviour is caused by:

1. a bug in our tabledrag.js implementation

OR

2. an upstream cause in \Behat\Mink\Element\NodeElement::dragTo()

I will let our JavaScript team to find the cause. I'm only providing here this starting test.

Proposed resolution

1. Find the cause of this bug and fix if it's a Drupal bug or report upstream.
2. Expand the test to cover all draggable table aspects like indenting, other actions test, etc.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

Related to #2313075: Allow users to upload webp files in image fields

Since webp is becoming popular, it would be nice if contrib could change the supportedTypes of GDToolkit without needing the extend the class, or even better add support for WebP out of the box.

PS: PHP 5.5 has build in support for WebP and since PHP 5.4 will be abandoned somewhere in 2015, it might be easier to just add support for it.

Proposed resolution

@todo

Remaining tasks

User interface changes

@todo

API changes

@todo

Data model changes

@todo

Release notes snippet

@todo

Add the `config` key to the media library module info, so the settings page link appears in the description at admin/modules

Problem/Motivation

\Drupal\system\Entity\Action::setPlugin() is not actually part of any interface, despite that its docblock uses {@inheritdoc}.

  /**
   * {@inheritdoc}
   */
  public function setPlugin($plugin_id) {
    $this->plugin = $plugin_id;
    $this->getPluginCollection()->addInstanceId($plugin_id);
  }

Proposed resolution

Add this method to ActionConfigEntityInterface

API changes

Because there is a 1-1 relationship between \Drupal\system\Entity\Action and \Drupal\system\ActionConfigEntityInterface this is permissible in 8.x due to the Interfaces within non-experimental, non-test modules not tagged with either @api or @internal section of https://www.drupal.org/core/d8-bc-policy.

However, we should add a change notice.

Problem/Motivation

When adding packages doesn't sort them in composer.json.

Proposed resolution

Add sort-packages:true in root composer.json and core/composer.json

Remaining tasks

Add a patch.

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Problem/Motivation

We are skipping the deprecation. This is part of BC layer and it is hiding a bug in the \Drupal\rest\RequestHandler::createArgumentResolver(). If $unserialized is an array putting it in $upcasted_route_arguments is not going to work because it's not an object - see \Drupal\Component\Utility\ArgumentsResolver::__construct().

Proposed resolution

• Fix the bug
• Stop \Drupal\Tests\rest\Kernel\RequestHandlerTest::testHandle() from triggering deprecations - it is not a legacy test
• Add a new \Drupal\Tests\rest\Kernel\RequestHandlerTest::testHandleLegacy() to ensure we don't lose legacy coverage

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

N/a

In the docs for drupal_attach_tabledrag() it mentions

In a more complex case where there are several groups in one column (such as the block regions on the admin/structure/block page), a separate subgroup class must also be added to differentiate the groups.

I've been trying to get that working with minimal additional JS and I think I might've uncovered some bugs in tabledrag. When trying to use subgroups I was finding that dragging a row from one group into the other didn't seem to copy the subgroup class across correctly.

In #2489826: tabledrag is broken (dcf9ab4) some changes were made to some tabledrag jQuery selectors. I think the changes were meant to be functionally equivelent, just a little more efficient, eg:

-    var $indentationLast = $item.find('td').eq(0).find('.js-indentation').eq(-1);
+    var $indentationLast = $item.find('td:first-of-type').find('.js-indentation').eq(-1);

IIUC the starts of both of those lines basically do the same thing - grab the first td. But there are some other situations where I think the behaviour changed, and I wonder if that was unintentional.

1. --- a/core/misc/tabledrag.js
   +++ b/core/misc/tabledrag.js
   @@ -718,7 +718,7 @@
            // take into account hidden rows. Skip backwards until we find a draggable
            // row.
            while ($row.is(':hidden') && $row.prev('tr').is(':hidden')) {
   -          $row = $row.prev('tr').eq(0);
   +          $row = $row.prev('tr:first-of-type');
              row = $row.get(0);
            }
            return row;
   

   In this case $row.prev('tr:first-of-type') will only return a value if the previous row is also the first row in the table, rather than iterating each previous row. I've reverted that in the patch, but I wonder if the whole while block is redundant: $row is set from $(this.table.tBodies[0].rows).not(':hidden') at the start of findDropTargetRow(). Should it just be removed?

2. @@ -766,9 +766,9 @@
        }
        // Siblings are easy, check previous and next rows.
        else if (rowSettings.relationship === 'sibling') {
   -      $previousRow = $changedRow.prev('tr').eq(0);
   +      $previousRow = $changedRow.prev('tr:first-of-type');
          previousRow = $previousRow.get(0);
   -      var $nextRow = $changedRow.next('tr').eq(0);
   +      var $nextRow = $changedRow.next('tr:first-of-type');
          var nextRow = $nextRow.get(0);
          sourceRow = changedRow;
          if ($previousRow.is('.draggable') && $previousRow.find('.' + group).length) {
   

   This is what caused the original problem and prevented the weight subgroup class being copied over when moving a row into a different group. As before it's looking for the previous row using first-of-type and in this case it means the source row for sibling relationships isn't correctly set. The patch should fix and test this.

3. @@ -811,7 +811,7 @@
            // Use the first row in the table as source, because it's guaranteed to
            // be at the root level. Find the first item, then compare this row
            // against it as a sibling.
   -        sourceRow = $(this.table).find('tr.draggable').eq(0).get(0);
   +        sourceRow = $(this.table).find('tr.draggable:first-of-type').get(0);
            if (sourceRow === this.rowObject.element) {
              sourceRow = $(this.rowObject.group[this.rowObject.group.length - 1]).next('tr.draggable').get(0);
            }
   

   The original line found the first row with the draggable class but the modified version looks for a row which is both the first and has the draggble class. This causes an issue with field_group on a table with a non-draggable first row: #3085858: Drag and drop acts weird, sometimes not resetting the parent, or even clearing the region value. The patch should fix and test this.
   

This is my first time touching tabledrag so careful review welcome :p

Also it's quite an old commit that introduced this, I know tabledrag is used in lots of places, so I'm not sure if I'm just missing something obvious... (:

Remaining tasks

• Wait for #2769825: Cannot swap tabledrag rows by dragging the lower over the upper row in tests to land so the tests work.
• Decide whether the first JS block above should be removed entirely.
• Should this be split up into multiple tickets with more meaningful names?
• Fix and test tabledrag in the Claro theme as well.

Problem/Motivation

We currently have a token [site:url]. The URL of the site's front page. The language prefix is added if the page is multilingual (e.g. http://www.example.com/pl).

In many cases a language prefix is unnecessary.

Example:

Open graph image path
[site:url]/sites/default/files/og_image.jpg

JSON LD ImageObject path
[site:url]/sites/default/files/logo.jpg

We need a new token that returns the base url without the language prefix.

Proposed resolution

Add token [site:base-url]. Base URL.

Remaining tasks

Add test.

User interface changes

Users can use the new token [site:base-url].

API changes

Data model changes

Small spelling mistake I noticed in hook_views_query_alter, the sentence:
// If this is the part of the query filtering on title, chang the

Should be change instead.

Problem/Motivation

The string '_none' is repeated throughout the module and tests, using a constant makes it easier to refactor.

Proposed resolution

1. Convert _none to a constant.
2. Move form_select_options() to a helper class.

API changes

String '_none' is converted to constant.

Beta phase evaluation

Problem/Motivation

\Drupal\migrate\Plugin\Migration::get() has been deprecated since Drupal 8.1. It is an artifact of the heady days when migrations were config entities, and was kept as a BC layer when they were converted to plain plugins.

Proposed resolution

Remove this method in Drupal 9.

Remaining tasks

Do it.

User interface changes

None.

API changes

Deprecated method removal.

Data model changes

None.

Release notes snippet

None?

Problem/Motivation

This was discovered in #2841291: Fix NOT NULL handling in the entity storage and 'primary key' changes when updating the storage definition of an identifier field.

The field schema data doesn't accurately store the schema for identifier fields (ID and Revision ID): Fields that are stored as serial in certain tables are actually saved as int in the field schema data for those tables.

Proposed resolution

Move the ::processIdentifierSchema() calls from process*Table() to getSharedTableFieldSchema().

My theme uses Bootstrap and I noticed I cannot change the library load order to appear before any module CSS libraries, no matter the group I specified (base, component, theme, etc.) - even if specified manually (`group: -200`). I tracked this down to core/lib/Drupal/Core/Asset/LibraryDiscoveryParser.php:165:

$options['group'] = $extension_type == 'theme' ? CSS_AGGREGATE_THEME : CSS_AGGREGATE_DEFAULT;

This essentially forces any theme CSS libraries into the CSS_AGGREGATE_THEME group (100) and overwrites/ignores any specified SMACCS group settings, e.g. 'base' (my_theme.libraries.yml):

bootstrap:
  css:
    base:
      libraries/bootstrap/bootstrap.min.css: {}

And also overwrites setting group specified like this:

bootstrap:
  css:
    base:
      libraries/bootstrap/bootstrap.min.css: { group: -200 }

So this doesn't function according to 'group' property described in the docs: Adding Stylesheets CSS and Javascript JS to a Drupal Theme which specifies the "rarely used" group setting causes assets to be aggregated per group - because it's overwritten in the case of themes and modules.

Even if my module (e.g. Faculty Cards) libraries file specifies 'css: theme' grouping, it still appears in the HTML loaded before the theme bootstrap library (which specifies 'base'):

faculty-cards:
  css:
    theme:
      css/faculty-cards.css: {}
   

The line in LibraryDiscoveryParser means that module CSS libraries are always loaded before theme CSS libraries regardless of SMACCS category (base, layout, component, theme, etc.) specified in respective files. Which means that greater CSS specificity or even worse !important needs to be used in module CSS files to override a theme that uses Bootstrap.

If I comment out the affected line in LibraryDiscoveryParser, ordering is as I would expect and group settings are respected.

There is a @todo in \Drupal\Tests\media_library\FunctionalJavascript\MediaLibraryTestBase::pressInsertSelected to consider adding screen-reader assertions every time the method is called. That should be implemented in a patch and reviewed to confirm it is an effective addition.

The other methods in \Drupal\Tests\media_library\FunctionalJavascript\MediaLibraryTestBase should also be evaluated to see if any of them result in consistent screen-reader behavior. If so, screen-reader assertions should be incorporated into those methods as well

Problem/Motivation

This issue is part of the #2721129: Workflow Initiative. And #2786133: WI: Phase B: Extend the revision API with support for parents (the parent of this issue) is the first step towards #2867707: WI: Phase H: Conflict management and local workspace merging support.

The specific problem the Workflow Initiative is trying to solve here in this issue, is that of conflict management between revisions of the same entity that are created in different workspaces. When an entity can be edited in multiple workspaces, we start having a graph or tree (or branches) of revisions that needs to be tracked and managed.

In any scenario like this, there will never be more than two parents of a single revision; one parent revision, and optionally one revision that was merged into the current line. Very much like a Git tree with merge commits.

Proposed resolution

Introduce a new type of reference field, with an associated API, that keeps track of the aforementioned revision tree. This new field needs to be able to reference the two possible parents.

1. Add two new revision metadata keys: revision_parent and revision_merge_parent
2. Add two new base fields, revision_parent and revision_merge_parent to all revisionable entity types
3. Ensure that the value of the parent revision is populated automatically by default with the latest revision ID of the active branch from the revision graph
4. Write an update hook that back-fills data for the new field. The strategy that will be used is described in #13
5. Add a new revision_tree entity handler that is able to determine the Lowest Common Ancestor of two revisions from the graph, using an algorithm that is agnostic to the branching strategy that is being used

Remaining tasks

None.

The default branching strategy for the revision tree will be discussed and implemented in #3023194: [PP-2] Add parallel revisioning support.

User interface changes

None.

API changes

New methods available on \Drupal\Core\Entity\RevisionableInterface, with default implementations provided in \Drupal\Core\Entity\ContentEntityBase.:

• getParentRevisionId()
• setParentRevisionId($revision_id)
• getMergeParentRevisionId()
• setMergeParentRevisionId($revision_id)

A new revision_tree entity handler is added by default to all revisionable entity types, with a default implementation provided in \Drupal\Core\Entity\Sql\SqlRevisionTreeHandler.

A new revision_reference field type is added, not shown in the Field UI and without having a widget or a formatter.

Data model changes

All revisionable entities will have two additional revision metadata fields installed, revision_parent and revision_merge_parent.

Acc to https://www.drupal.org/node/2000204 .Dependencies should be namespaced in the format: {project}:{module} in .info.yml file.

Problem/Motivation

#2492171: [PP-1] Provide options to sanitize filenames (transliterate, lowercase, replace whitespace, etc) is blocked on #3032390: Add an event to sanitize filenames during upload which is itself languishing.

People are re-rolling older versions of #2492171 and confusing things in the parent issue.

Proposed resolution

Post "composer-friendly" re-rolls here, so as not to further confuse the parent issue.

Remaining tasks

-

User interface changes

-

API changes

-

Data model changes

-

Release notes snippet

-

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the views, views_ui module(s).

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

In HEAD, the d7_node_title_label migration runs much later than all d7_node:* migrations. While not wrong, this is … confusing.

In HEAD, I first have to run d7_node_type, but then I can run d7_node:*befored7_node_title_label. Which means that if I go to /admin/structure/types/manage/client to inspect my data model prior to importing the actual data, I see this:

It also means that if I run my migration with entity validation enabled (#2745797: Add option to content entity destinations for validation), that the validation errors use the incorrect field label.

Proposed resolution

Refine the migration dependencies, so we see this instead:

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Every once in awhile, a new dependency gets added to a module, for example #3084983: Move all the code related to path aliases to a new (required) "path_alias" module added path_alias as a dependency to the path module.

When this happens, as in the above example, trying to import configuration which had been exported with a previous version of Drupal will result in:

[error]  Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization.
Unable to uninstall the <em class="placeholder">Path alias</em> module since the <em class="placeholder">Path</em> module is installed. in Drupal\Core\Config\ConfigImporter->validate() (line 755 of /var/www/html/core/lib/Drupal/Core/Config/ConfigImporter.php). 

This is because, in the core.extension.yml generated before the new dependency was added, we have (in this example):

   path: 0

but not:

   path_alias: 0

So Drupal tries to enable path but disable path_alias; which fails. Thus, configuration which was fully acceptable with a previous version of Drupal (before the new dependency) is now corrupted (unusable) and needs to be regenerated with "drush config-export" to be valid again.

Upon enabling modules based on a core.extension.yml file, could we compute the dependencies automatically so that whether or not we have "path_alias: 0" in core.extension.yml, we would enable it? The code to do so already exists in ModuleInstaller::install.