In Umami theme login link not showing underline on hover. All other links are underlined on hover e.g: the main menu, footer links are underlined on hover.

Blocked by: #2853509: Don't render status messages if there are no messages but also include their assets if there might be

Problem/Motivation

Provide a consistent method for displaying messages in JavaScript.

Currently the Settings tray module needs to provide various message via JavaScript in:
#2773601: Display "You are now in edit mode" prompt when user enters edit mode
#2785047: In Outside In mode, form validation messages should appear in the off-canvas tray, not the main page

And also Inline Form Errors needs to be able to update messages through JavaScript:
#2876321: Update inline form errors summary after form validation with AJAX

Proposed resolution

Change div for {{ messages }} to always be rendered and add a data-drupal-messages attribute for JavaScript to select.

Add new methods for:

• Adding a message
• Removing one or multiple messages
• Clearing all messages of a specific type
• Clearing all messages

How to test manually

1. Apply the latest patch
2. Install standard
3. Install the js_message_test module. You need to ensure $settings['extension_discovery_scan_tests'] = TRUE; is in your settings.php in order to enable it.
4. Visit the url /js_message_test_link on your site.

Remaining tasks

Review patch
Write change record

API changes

Persistent div for {{ messages }} would be required in themes.

API Additions

const messageInterface = new Drupal.Message();

const messageId = messageInterface.add(message, options);
const messageList = messageInterface.select(type);

messageInterface.remove(messageId);

messageInterface.clear();

Original report by kkaefer

While developing some JavaScript enhancements for Drupal, I am facing the problem of how to indicate the status of an action properly. For example, when editing a label, the user needs to know if the action has been successful (saving the new title) or if it failed. Of course, some widgets can use their own status indicating system (like the autocomplete textfield), but others have to display text.

But – we already have status messages in Drupal! Take a look at theme_status_message(). We just need to make sure that the status message div is always there so that we can inject new items via JavaScript... How about that? Post your opinion or your own suggestion for this issue.

I've setup a content type having several field groups configured as horizontal tabs with field collections inside it (several ones including text, dropdowns, date, etc) one field collection for each field group (tab)

Im using:
Field collection 7.x-1.0-beta3+4-dev
Fieldgroup 7.x-1.1
File entity 7.x-2.0-unstable3+21-dev
Entity API 7.x-1.0-rc2+0-dev
Field Collection Table 7.x-1.0-beta1

Everything is working fine except for the issue of having 1 added empty row for each time I save the node. I know there's a bug report about that and Its in progress.

When I hit the remove button on each row to remove those empty lines (from the bottom-up), happens this:

1st row: deleted OK

2nd row: deleted OK but I got the following on the FF javascript console:

Error: $("#" + base, context).once is not a function
Source File: (obscured)/node/123/edit
Line: 16

3rd row: looks like goes to server, but when the "working" animated gif dissapears, nothing happens and I got this on javascript console:

Error: $("fieldset.path-form", context).drupalSetSummary is not a function
Source File: (obscured)/sites/all/modules/pathauto/pathauto.js?m3nlsr
Line: 5

Im setting this before that line on the other module's scripts

if (typeof jQuery.fn.drupalSetSummary == 'undefined') {
  return;
}

and works, but then another module (like metatag) that uses drupalSetSummary raises the error. etc.

Looks to me like jQuery is breaking and then everything that depends on it cease to work.

Plus, if I try to save the node on this instance (when remove button stopped working) im getting "An illegal choice has been detected. Please contact the site administrator."

I cannot find $("#" + base, context).once on the module's code to see whats going on. Any help?

Edit:
Additional data: http://drupal.org/node/445130#comment-2851276
/misc/form.js is loaded on my edit page when I see the source code, but maybe when this module makes ajax calls somehow the drupalSetSummary() function is removed or something.

Thanks for reading this.

Problem/Motivation

The following error message appears:
Argument 1 passed to Drupal\Core\Render\Element::children() must be of the type array, null given, called in /var/www/news-linux.byu.edu/web/core/lib/Drupal/Core/Field/FormatterBase.php on line 84 in Drupal\Core\Render\Element::children() (line 71 of core/lib/Drupal/Core/Render/Element.php).

Proposed resolution

Add a null check before passing the elements variable.

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

#2208429: Extension System, Part III: ExtensionList, ModuleExtensionList and ProfileExtensionList makes it possible to deprecate system_rebuild_module_data() and replace it with calls to \Drupal::service('extension.list.module')->reset()

Proposed resolution

Replace all usages and deprecate system_rebuild_module_data() and trigger a silenced error. Also, when replacing the usages we should ensure that we don't unnecessarily rebuild the module list.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Problem/Motivation

The content translation handler relies too much on the form state even for stuff that could be read-out directly from the entity. Coupling it so much on the form state makes it really hard for nested entity forms to use it.

Proposed resolution

Instead of determining if the entity is being editing in a new translation by

$new_translation = !empty($source_langcode);

change it to

$new_translation = $entity->isNewTranslation();

and instead of retrieving the source langcode through

$source_langcode = $this->getSourceLangcode($form_state);

retrieve it through

$source_langcode = $metadata->getSource();

but for this adjust
ContentTranslationController::prepareTranslation to set the source language code on the prepared entity - this is actually something we have to do anyway when creating the translation and instead in the content translation entity builder.

Remaining tasks

Review.

User interface changes

None.

API changes

None.

Data model changes

None.

Issue Summary:

A REST resource configuration with an invalid plugin id will throw a PluginNotFoundException in Drupal\rest\Routing\ResourceRoutes::getRoutesForResourceConfig during cache rebuild, resulting in missing routes and potentially WSODs.

This can be caused by resources created from modules that were uninstalled, corrupted configs, etc.

Proposed Resolution:

When a plugin_id is not found this function should fail gracefully returning no routes and log an error so as not to affect routes from other modules.

Problem/Motivation

CKEditor's default styles and resets are being overridden by off-canvas' CSS. As a result, CKEditor is basically un-usable when rendered inside of the off-canvas dialog.

How it looks now:

You can see this locally by following these steps:

1. Apply the provided "layout-builder-debug.patch" patch
2. Install the Standard profile
3. Enable the "Layout Builder Debug" (layout_builder_debug) module
4. Visit /admin/structure/types/manage/article/display-layout/default
5. Click "Add Block"
6. Select "Debug Form Styling" from the block listing
7. See that CKEditor looks funky

Proposed resolution

I started working on this and I'm not really sure what to do - we need a way to exclude CKEditor from off-canvas styling, but this is really hard without modifying all of off-canvas' CSS.

Currently the selector "#drupal-off-canvas" is a part of almost every selector in off-canvas' CSS, and that makes overriding any off-canvas style really tough. I think a good long-term solution to prevent problems like this is to stop selecting off-canvas elements with an ID, and instead use a class like .off-canvas-reset. This would allow more specific class selectors to override off-canvas without the use of !important or ID/element names.

Remaining tasks

Discuss the problem, determine what solution we should use.

User interface changes

n/a

API changes

n/a

Data model changes

n/a

A programmatically created translatable content type added to an install profile results in SQL error "Unknown column 'content_translation_source' in 'field list'" when attempting to add new content of that type.

Steps to replicate:
1. Create a content type with 'Enable translations' checked
2. Export content type as a feature
3. Add feature to install profile's info.yml dependencies along with language and content_translation modules
4. Install site profile
5. Log in, Add content of this type, Save

Error returned:

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

Drupal\Core\Entity\EntityStorageException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'content_translation_source' in 'field list': INSERT INTO {node_field_data} (nid, vid, type, langcode, title, uid, status, created, changed, promote, sticky, revision_translation_affected, default_langcode, content_translation_source, content_translation_outdated) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14); Array ( [:db_insert_placeholder_0] => 2 [:db_insert_placeholder_1] => 2 [:db_insert_placeholder_2] => page [:db_insert_placeholder_3] => en [:db_insert_placeholder_4] => asdf [:db_insert_placeholder_5] => 1 [:db_insert_placeholder_6] => 0 [:db_insert_placeholder_7] => 1445445894 [:db_insert_placeholder_8] => 1445445901 [:db_insert_placeholder_9] => 0 [:db_insert_placeholder_10] => 0 [:db_insert_placeholder_11] => 1 [:db_insert_placeholder_12] => 1 [:db_insert_placeholder_13] => und [:db_insert_placeholder_14] => 0 ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 757 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
Drupal\Core\Database\Statement->execute(Array, Array)
Drupal\Core\Database\Connection->query('INSERT INTO {node_field_data} (nid, vid, type, langcode, title, uid, status, created, changed, promote, sticky, revision_translation_affected, default_langcode, content_translation_source, content_translation_outdated) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14)', Array, Array)
Drupal\Core\Database\Driver\mysql\Connection->query('INSERT INTO {node_field_data} (nid, vid, type, langcode, title, uid, status, created, changed, promote, sticky, revision_translation_affected, default_langcode, content_translation_source, content_translation_outdated) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14)', Array, Array)
Drupal\Core\Database\Driver\mysql\Insert->execute()
Drupal\Core\Entity\Sql\SqlContentEntityStorage->saveToSharedTables(Object)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->doSaveFieldItems(Object)
Drupal\Core\Entity\ContentEntityStorageBase->doSave(NULL, Object)
Drupal\Core\Entity\EntityStorageBase->save(Object)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object)
Drupal\Core\Entity\Entity->save()
Drupal\node\NodeForm->save(Array, Object)
call_user_func_array(Array, Array)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object)
Drupal\Core\Form\FormBuilder->processForm('node_page_form', Array, Object)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object)
Drupal\Core\Entity\EntityFormBuilder->getForm(Object)
Drupal\node\Controller\NodeController->add(Object)
call_user_func_array(Array, Array)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1)
Stack\StackedHttpKernel->handle(Object, 1, 1)
Drupal\Core\DrupalKernel->handle(Object)

Related to https://www.drupal.org/node/2418563 but a drush updb does not resolve the issue.

Problem/Motivation

When you add 'not null' => TRUE to the schema of a base field with multiple columns and add an according update path, that update path will fail.

That is because SqlContentEntityStorageSchema::updateSharedTableSchema() wrongly assumes that $field_name === $column_name.

Proposed resolution

Use the correct variable name in SqlContentEntityStorageSchema::updateSharedTableSchema().

Remaining tasks

User interface changes

None.

API changes

None.

Data model changes

None.

How does the following solution for migrating files referenced into content can apply with migrate for D8: #2122479-1: How to migrate files from embedded references ?

Was starting to parse the html to extract files paths in process plugin but what would be the recommended way to do this?

Problem/Motivation

When updating the storage definition of an identifier field (e.g. 'id' or 'revision_id'), the primary keys are not updated properly in the SQL schema.

This was the original scope of #2841291: [PP-1] Fix NOT NULL handling in the entity storage and 'primary key' changes when updating the storage definition of an identifier field but that has expanded and changed scope significantly so that this now splits it into a separate issue (again).

Proposed resolution

Add primary keys when adding a field that is part of the primary key.

Problem/Motivation

It looks like someone removed the ability to attach inline JS. No idea why, but I need this and I cannot move this to a library file.

Issues:

• JS cannot attached with 'html_head' as the order is random.
• The order of code is broken as inline JS need to be added after JS files and not before.
• CDATA is not added automatically and could be theme specific
• Inline JS code cannot moved to files in many cases as these are dynamic and may not automatically drupalSettings.

LogicException: You are not allowed to use js in #attached in drupal_process_attached() (line 1759 of drupal8\core\includes\common.inc).

Example code. See http://cgit.drupalcode.org/google_analytics/tree/google_analytics.module... for more:

    if ($config->get('track.adsense')) {
      // Custom tracking. Prepend before all other JavaScript.
      // @TODO: https://support.google.com/adsense/answer/98142
      // sounds like it could be appended to $script.
      $page['#attached']['js'][] = array(
        'data' => $googleanalytics_adsense_script,
        'group' => JS_LIBRARY-1,
        'type' => 'inline',
      );
    }

    $page['#attached']['js'][] = array(
      'data' => $script,
      'scope' => 'header',
      'type' => 'inline',
    );

Additionally Wim pointed indirectly to #2368797: Optimize ajaxPageState to keep Drupal 8 sites fast on high-latency networks, prevent CSS/JS aggregation from taking down sites and use HTTP GET for AJAX requests. The presentation Optimizing the critical rendering path in this case shows that the objections about inline JS are fairly invalid and the document proves that inline CSS/JS assets are highly critical feature and placing all stuff in external files is simply incorrect for page load speed and mobile first, too.

Proposed resolution

Implement #attach like:

• $build['#attached']['js_inline']
• $build['#attached']['css_inline']

Remaining tasks

Rollback all inline changes made in #2382533: Attach assets only via the asset library system or implement the Proposed resolution.

User interface changes

None

API changes

Problem/Motivation

BTB has lots of helpful methods that could be re-used in https://github.com/weitzman/drupal-test-traits for testing against existing websites.

Debug ones relevant to this issue:

• formatHtmlOutputHeaders
• getHtmlOutputHeaders
• htmlOutput
• initBrowserOutputFile

Others

We could split these up a few ways I guess but they're all pretty much related to UI testing.

• submitForm - Handles submitting forms.
• drupalLogin()
• drupalLogout()
• assertSession() - Handy helper to get a web assertion object.
• drupalGet() - Handles converting URL objects to path strings.
• drupalPostForm() - Same as drupalGet() + handles MarkupInterface objects for the text on buttons.
• click()
• clickLink()
• getTextContent()
• getUrl()
• assertEquals() - Handles markup interface

Proposed resolution

Move them to a trait so the code can be shared.

Remaining tasks

Patch.

Problem/Motivation

After testing the jsonapi I came across this discovery.
I am able to create a comment of a comment (of entity_type "node") of a node. However, I can't go the next level which would be a comment of a comment (entity_type "comment") of a comment of a node.
I can do it from the drupal ui directly. I don't know if this is to protect against circular references or what, but this needs to be looked into.

Steps to reproduce.
Create 2 more comment types.
CommentOfNodeComment
CommentOfCommentComment

Then for Default comments add field General Comments CommentOfNodeComment
Then for CommentOfNodeComment add field General Comments CommentOfCommentComment

Then create an article w/ comments down to CommentOfCommentComment.

Then try to create a CommentOfCommentComment via a rest call. E.g.

POST {{protocol}}://{{host}}/jsonapi/comment/responses HTTP/1.1
Authorization: Basic token
Accept: application/vnd.api+json
Content-Type: application/vnd.api+json

{
  "data": {
    "type": "comment--commentofcommentcomment",
    "attributes": {
      "subject": "test CommentOfCommentComment",
      "entity_type": "comment",
      "field_name": "field_commentofcommentcomment",
      "comment_body": {
          "value": "some text",
          "format": "basic_html"
        },
      "entity_id": [{"target_id": 4}],
      "uid": [{"target_id": 1}]
    }
  }
}

Problem/Motivation

When you create a field as "List (text) (id: list_string)" You can create values for the keys that are "unlimited" in length. There is a limit because the input field is a textarea covering all the key/value pairs.
But, when translating this field, al the key/value pairs are split into separate textfields and the value for the textfield is defined as a "label" (in options.schema.yml), limiting it to 127 characters.

field.storage_settings.list_string:
  type: mapping
  label: 'List (text) settings'
  mapping:
    allowed_values:
      type: sequence
      label: 'Allowed values list'
      sequence:
        type: mapping
        label: 'Allowed value with label'
        mapping:
          value:
            type: string
            label: 'Value'
          label:
            type: label
            label: 'Label'
    allowed_values_function:
      type: string
      label: 'Allowed values function'

This limitation is "wrong", because the actual values can be much longer without causing any problems.

Proposed resolution

Change the type of "Label" in options.schema.yml from "label" to "text.

Remaining tasks

Review the proposed solution, create a patch.

User interface changes

The user interface for translating list_string field types changes so that labels are input in a textarea rather then a textfield.

API changes

None

Data model changes

Change the type of "Label" in options.schema.yml from "label" to "text.

Followup for #2946419-9: Entity: Convert system functional tests to phpunit

Problem/Motivation

It is impossible to make a deprecated no-class (trait, interface) without fails of tests which run:
\Drupal::service('test_discovery')->getTestClasses();

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Updating from 8.4.5 to 8.5 i get following error message on database update via update.php:

views-Modul
Update #8500
Failed: Drupal\Component\Plugin\Exception\PluginNotFoundException: The "file_uri" plugin does not exist. in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (Zeile 52 in /core/lib/