After upgrading to 8.8 i keep getting errors related to path_alias

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal.path_alias' doesn't exist: SELECT 1 AS expression FROM {path_alias} base_table WHERE (base_table.status = :db_condition_placeholder_0) AND (base_table.path LIKE :db_condition_placeholder_1 ESCAPE '\\') LIMIT 1 OFFSET 0; Array ( [:db_condition_placeholder_0] => 1 [:db_condition_placeholder_1] => /node% ) in Drupal\Core\Path\AliasRepository->pathHasMatchingAlias() (line 111 of core/lib/Drupal/Core/Path/AliasRepository.php).

I'm running pathauto 1.6 so that should be ok according to the release notes.

Am I missing anything?

The CSS provided by the Workspaces module that is responsible for styling the off-canvas drawer isn't explicit enough to prevent themes from breaking the box sizing.

How to reproduce the bug

1. Install the Umami demo profile
2. Install the Workspaces module
3. Navigate to the front page (or any page using the Umami theme)
4. Bring down the Workspaces off-canvas drawer by clicking on the workspace name in the toolbar
5. Notice how the styling is broken
6. Additionally, resize the browser window to simulate a mobile viewport and notice that the styling is broken there as well.

Before applying the patch

After applying the patch

Mobile viewport - Before applying the patch

Mobile viewport - After applying the patch

Problem/Motivation

The current UI for Workspaces has various shortcomings, mostly coming from the fact the initial designs were not completely implemented. It also falls short in regards to compatibility between different browsers, both for the desktop and mobile experience.

Proposed resolution

Fix the following problems, identified in various issues:

• #3093032: Workspaces has a confusing UI when opening the link on top of pages - add a "Other workspaces" label on the top left corner, above the links that can be used to switch to a different workspace
• #2988101: Distorted workspace list in Canvas tray and #3090904-25: Workspace drawer CSS fix for better consistency - make the UI look the same across all supported desktop and mobile browsers in Standard, Minimal and Umami
• Always show the "View all workspaces" label and alight it to the right above the workspace tabs in the drawer
• Implement the hover/highlight effect from this screen: https://marvelapp.com/14027i8/screen/17754081
• Change the "Manage workspaces" link shown below the active workspace to "Manage workspace" and direct it to the workspace edit form for now, until we create a dedicated screen for this action

Remaining tasks

Review.

User interface changes

Desktop

Before

After

Mobile

Before

After

API changes

Nope.

Data model changes

Nope.

Release notes snippet

Nope.

Problem/Motivation

After enabling workspaces, and clicking on Live/Stage link (visible at the top of every page)

It becomes very clear what to do on the RIGHT side of the screen,
I can see the current stage I am working on,
I can see that I can deploy content,
I can see that I can manage my workspaces.

Then on the LEFT side of screen is where it is no longer intuitive:
It takes a huge horizontal space, but using only half of the vertical space.
Now it's confusing, is "live" my current workspace, or another workspace I can switch to? (yes, on the ride side it does say "current workspace", but the left side takes much more space and doesn't have that kind of description which can cause additional confusion)
How can I tell that this whole space is clickable and will get me to switch a workspace?
There are no explanations just a name of workspace.

On mobile, opening the workspaces drawer takes over the WHOLE screen, which I did not expect.
Would be nice to open whatever space is needed for the drawer and let me see the rest of the page below it.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

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

• 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.

One thing I am always missing when running tests through command line is finding HTML output file by URL of HTTP request logged in it. I propose adding a meaningful label above each reference on HTML output file (see attached screenshots).

Hi

config-import getting error while deploy to remote server using CI

drush cim --partial

after update core 8.7 to 8.8

Unable to install the <em class="placeholder">path_alias</em> module since it
does not exist. in Drupal\Core\Config\ConfigImporter->validate() (line 755 of
/var/www/html/abc/deployments/1575986970/web/core/lib/Drupal/Core/Config/ConfigImporter.php).
The import failed due for the following reasons:                              [error]
Unable to install the <em class="placeholder">path_alias</em> module since it

Resolution: Needs to clear the cache in deployment script before import the configs

Right now when you run a config import and have a storage conflict you get an error that says

"Cannot change the field type for an existing field storage."

While this might be clear when working on one field at a time, it is not specific enough when working with many fields. I propose changing the error message to say something like

"The field storage forcurrent_field_name is already set to current_field_type. Cannot change the field type for an existing field storage"

to make development easier.

Problem/Motivation

In core/modules/block_content/block_content.module, the documentation block for block_content_query_entity_reference_alter() includes the line,

Block_content entities that are reusable should by default not be selectable

It should be "not reusable" rather than "reusable". Compare with the change record Added the ability to set Custom Block entities as non-reusable: it says, in part,

Since a Custom Block with the reusable field set to FALSE should not be reused in other parts of the site the queries of EntityReferenceSelection plugins will now automatically be altered to add:

$query->condition("$data_table.reusable", TRUE);

Unless the query satisfies one of these two conditions:
...

The API documentation for block_content_query_entity_reference_alter() is generated from this documentation block, so I am adding the "API Documentation" tag.

Proposed resolution

Insert the word "not" and rewrap the affected line and the next to 80 characters.

Remaining tasks

User interface changes

None, except in the API documentation.

API changes

None

Data model changes

None

Steps to reproduce:

1. Create a link field on an entity/content type
2. Create content of that type and enter this URL into the link field:
   
   https://example.com/?f%5Bcollection_name_ssi%5D%5B%5D=Example
3. Render the link field for that entity (i.e., visit the node) and inspect the value of href=""

Expected behavior:

Field will render with href="https://example.com/?f%5Bcollection_name_ssi%5D%5B%5D=Example"

Actual behavior:

Field renders with an extra 0 in the href:

https://example.com/?f%5Bcollection_name_ssi%5D%5B0%5D=Example

Edit the node, and the 0 is not in the URL field. Render the node, and the 0 appears in the markup.

When I translate strings in the translate interface, I would like to be able to edit the "original text" (for the default language) too, and not only fill in the translation strings for other languages.

Indeed, when you manage a website, it's no secret you regularly have to modify or improve it which includes changing some of its text. If the website is multilingual, each time you make such a change, you have to :
1- recreate the translation set by reloading the involved page/template in the desired language
2- fin and delete the initial translation set in the translate interface
3- refill the new translation set with the same translation as the original one in the translate interface
It would bee so much easier to be able to edit the original text of the initial translation set...

Maybe I'm missing this feature somewhere... can anyone help me on this ?
Thanks you in advance.

I get the following error during config import:
The import failed due to the following reasons
Unexpected error during import with operation create for system.action.node_delete_action: The "entity:delete_action:node" plugin does not exist

I have several sites with the problem of this missing plugin. Why is it missing? I tried importing without the plugin in the yml, but it resulted in the same error with The "" plugin does not exist

I run the PhpCodeFixer inside the Drupal 7.61 installation. I receive the following problems:

\modules\simpletest
PHP | File:Line | Type | Issue
7.2 | /drupal_web_test_case.php:451 | function_usage | Function usage assert() (@assert_on_string) is deprecated.
7.2 | /drupal_web_test_case.php:454 | function_usage | Function usage assert() (@assert_on_string) is deprecated.

Usage assert() (@assert_on_string): You should avoid using string code: "'exception'"

/modules/
PHP | File:Line | Type | Issue
5.5 | /filter/filter.api.php:205 | function_usage | Function usage preg_replace() (@preg_replace_e_modifier) is deprecated.
5.5 | /filter/filter.api.php:237 | function_usage | Function usage preg_replace() (@preg_replace_e_modifier) is deprecated.

Usage preg_replace() (@preg_replace_e_modifier): Usage of "e" modifier in preg_replace is deprecated: "|\[codefilter_code\](.+?)\[/codefilter_code\]|se

Your feedback is welcome.

Steps to reproduce:

-Create a custom block: /admin/structure/block/block-content
-Enable layout builder to some content type.
- Add the custom block via the layout builder:
Go to Manage display -> Manage layout:
Add block -> the custom block-> Save layout
- Edit again via layout builder -> check console errors

Uncaught Error: Quick Edit could not associate the rendered entity field markup (with [data-quickedit-field-id="block_content/1/body/en/full"]) with the corresponding rendered entity markup: no parent DOM node found with [data-quickedit-entity-id="block_content/1"]. This is typically caused by the theme's template for this entity type forgetting to print the attributes.

Checked:
https://www.drupal.org/project/drupal/issues/2948828

Edit--

Documentation:
Every field that has 'data-quickedit-field-id', it looks for the attribute 'data-quickedit-entity-id'.
I think we are missing 'data-quickedit-entity-id="block_content/x"' attribute for custom blocks inside the layout builder.

4 different scenarios:

1. A block that inside the layout builder:

<div data-layout-content-preview-placeholder-label="&quot;block created from the layout builder&quot; block" class="block block-layout-builder block-inline-blockbasic">
      <h2>block created from the layout builder</h2>
      <div class="content">
            <div data-quickedit-field-id="block_content/2/body/en/full" class="clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p>block created from the layout builder</p></div>

2. Other entites that inside the layout builder. entity refernce for example:

<article data-history-node-id="1" data-quickedit-entity-id="node/1" role="article" about="/node/1" typeof="schema:Article" class="node node--type-article node--promoted node--view-mode-default clearfix" data-quickedit-entity-instance-id="1">
  <header>
    
            <h2 class="node__title">
        <a href="/node/1" rel="bookmark" tabindex="-1">
<span property="schema:name" data-quickedit-field-id="node/1/title/en/layout_builder-default-non_component-c0858af7a82aba2ec7c7ed558d26d297babd406ce385e96d915d68e5fecbc963" class="field field--name-title field--type-string field--label-hidden">some page</span>

3. A block that outside the layout builder:

<div data-quickedit-entity-id="block_content/1" id="block-test-2" class="contextual-region block block-block-content block-block-content7d6f1fdf-86ec-4e36-8ef6-5fd4f42dc984" data-quickedit-entity-instance-id="0">
  
      <h2>Test</h2>
    <div data-contextual-id="block:block=test_2:langcode=en|block_content:block_content=1:changed=1572513265&amp;langcode=en" data-contextual-token="dr7X0PNb0twopWeXtlB0Ckw7pLP5vBE1EZERQ_JZ5xo" class="contextual"><button class="trigger visually-hidden focusable" type="button" aria-pressed="false">Open Test configuration options</button>

            <div data-quickedit-field-id="block_content/1/body/en/full" class="clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item quickedit-field"><p>test</p></div>
      

4. Other entities that outside the layout builder.

<article data-history-node-id="2" data-quickedit-entity-id="node/2" role="article" class="contextual-region node node--type-page node--view-mode-default clearfix" about="/node/2" typeof="schema:WebPage" data-quickedit-entity-instance-id="0">
  <header>    
            <h2 class="node__title">
        <a href="/node/2" rel="bookmark">
<span property="schema:name" data-quickedit-field-id="node/2/title/en/default" class="field field--name-title field--type-string field--label-hidden quickedit-field">test123</span>

Problem/Motivation

in #3085717: [PP-1] Do not rely on version_* tags it was determined that release information version_patch and version_extra are not fully tested.

In that issue we want to remove reliance on this metadata from the update xml and instead get the information directly from version number instead.

We should first make sure we have test coverage for the current functionality. Currently these are taken into account for contrib test and may be under tested for core

Proposed resolution

Determine what test coverage we are missing and create it

Remaining tasks

Duplicate \Drupal\Tests\update\Functional\UpdateCoreTest::testNormalUpdateAvailable() which test version_patch and version_extra for core in \Drupal\Tests\update\Functional\UpdateContribTest for contrib

User interface changes

none

API changes

none

Data model changes

none

Problem/Motivation

Media Library has been marked as stable in 8.8.x and as a result, most of the related styles were moved to Seven. Right now, if someone tries to use Media Library with Claro, it's unstyled for the most part which leads to poor UX.

Proposed resolution

Copy Seven Media Library styles to Claro as a starting point. Work on redesigning Media Library in follow-up issues.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Just crash testing patches

Problem/Motivation

The "Edit Media" button disappears when the "Convert line breaks into HTML" filter is enabled.

There's a javascript error.

Uncaught TypeError: Cannot read property 'insertBeforeMe' of null
    at h._setUpEditButton (plugin.js?t=q1mipb:242)
    at plugin.js?t=q1mipb:174
    at Object.success (plugin.js?t=q1mipb:320)
    at c (jquery.min.js?v=3.4.1:2)
    at Object.fireWith [as resolveWith] (jquery.min.js?v=3.4.1:2)
    at l (jquery.min.js?v=3.4.1:2)
    at XMLHttpRequest.<anonymous> (jquery.min.js?v=3.4.1:2)

The issue is that "Convert line breaks into HTML" is wrapping the drupalmedia tag in a `p` tag. The drupalmedia plugin.js assumes that the first element within the widget is the embed and that it has children (so you can call getFirst() on it). Since the `p` tag is empty, calling getFirst() fails returns null, (this is the null which has no insertBeforeMe property).

Proposed resolution

Modify the client-side JavaScript for the media embed filter so that it is able to anticipate the P tag added by filter_autop.

Remaining tasks

review and commit

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Now that #2807145: [policy, no patch] Allow contrib projects to specify multiple major core branches has been done core_version_requirment can be used to declare core compatibility via Composer semver constraint. It is technically already possible to declare that your module is already compatible with Drupal 9 only. For instance if a module requires one of the newly updated composer dependencies in Drupal 9.

This means that currently the update module could be listing contrib modules that are only compatible with Drupal 9. Previously this would not have been possible.

Once #3009338: [META] Support semantic versioning for extensions (modules, themes, etc) in Drupal core is completed there will no correlation between the module version number and core compatiblity.

Therefore we should display the core compatibility of updates to display this information to the user.

In #3076183: Determine how available updates for modules should be handled if they are not compatible with the current version of Drupal core we determined we want

1. Should a message on all update that display their core compatibility based of the core_version_requirement in info.yml files. This information is now in the update XML from drupal.org as core_compatibility

   The message should be in this format:

   This module is compatible with Drupal core: 8.8.3 to 8.9.1

2. As 2nd step will switch to a update XML feed that is not tied to CORE_COMPATIBILITY but rather all 8.x and future module updates.
   This will be handled in #3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates

Original all this handled in #3074993 because only the /current feed had core_compatibility
but now this available in the current XML we can handle this first in it's own issue.

Proposed resolution

copied from #3076183: Determine how available updates for modules should be handled if they are not compatible with the current version of Drupal core

1. Done: in #3074998: Add explicit information about core compatibility to update data add a new core_compatiblity value for each update. This is will be based on core_version_requirement or if not available it will be based core: 8.x

   This is will be for the project not individual modules in the project. Details to be determine in that issue

2. Display a message for each available project update that displays the core compatiblity range based on 1) actual available updates the update module has retrieved from the update server and 2) the core_compatiblity for the project update xml(see above)
3. For most common possibilities for core_compatiblity this will be able to displayed as a simple range.

   For example
   Installed core: 8.8.3
   latest 8.x patch release: 8.9.1
   Drupal 9 not released yet
   project xml core_compatiblity: ^8 || ^9

   This module is compatible with Drupal core: 8.8.3 to 8.9.1

   If Drupal 9.0.3 had been released this would change to

   This module is compatible with Drupal core: 8.8.3 to 9.0.3

   if project xml wascore_compatiblity: ^: ^8.8.9 || ^9 (not using core_version_requirement because the value will be directly from the project xml not the info.yml files)
   This module is compatible with Drupal core: 8.8.9 to 9.0.3

4. Some less common values for core_compatiblity will not be able to display by a simple range. In that case we should display them in a series of ranges.

   For example
   Given:
   Installed core: 8.8.3
   latest 8.8.x: 8.8.7
   latest 8.x patch release: 8.9.1
   Drupal 9 not released yet

   core_compatiblity: ~8.8.0 || ^9

   This module is compatible with Drupal core: 8.8.3 to 8.8.7

   Because 9 hasn't been released it won't come into play.

   If Drupal 9.0.3 had been released

   This module is compatible with Drupal core: 8.8.3 to 8.8.7 and 9.0.0 to 9.03

5. In this first step no modules will be filtered out of the list.

   This will mean hypothetically you could get projects updates with the message like

   This module is compatible with Drupal core: 9.0.0 to 9.0.5

   In the near term this is very unlikely because 1) Drupal 9 is not out so no module should be compatible with it but not Drupal 8 and 2) 9.0.0 should be compatible with 8.9.0 for modules not using deprecated code. Therefore any module that is compatible with 9.0.0 because it remove deprecations should also be compatible with 8.9.0. So the project would likely have this in the project xml
   core_compatiblity: ^8.9 || ^9 or core_compatiblity: ^8.8 || ^9

Remaining tasks

Finish patch, review

User interface changes

New messages on available updates list

API changes

none

Data model changes

None

Release notes snippet

TBD

Hello all, it’s time for the weekly migration initiative meeting. The meeting will take place in slack in various threads

This meeting:
➤ Is for core migrate maintainers and developers and anybody else in the community with an interest in migrations
➤ Usually happens every Thursday and alternates between 1400 and 2100 UTC.
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to here.
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.