This is exactly the same as #3105925: The description of the arguments for FieldDefinition::setDisplayOptions() conflicts with what reported in FieldDefinitionInterface::getDisplayOptions(), but for BaseFieldDefintion instead of FieldDefinition. The docblock of BaseFieldDefinition::setDisplayOptions wasn't updated either in #2796581: Fields must store their region in entity displays, so it still mentions setting type='hidden' instead of region='hidden'.

Apparently, entity types can use four different tables to store their data (not counting field tables).

I had to Google this and find https://drupalwatchdog.com/blog/2015/3/entity-storage-drupal-8-way to understand what the tables are meant to do. Looking at \Drupal\Core\Entity\EntityType doesn't tell you much:

  /**
   * The name of the entity type's base table.
   *
   * @var string|null
   */
  protected $base_table = NULL;

  /**
   * The name of the entity type's revision data table.
   *
   * @var string|null
   */
  protected $revision_data_table = NULL;

  /**
   * The name of the entity type's revision table.
   *
   * @var string|null
   */
  protected $revision_table = NULL;

  /**
   * The name of the entity type's data table.
   *
   * @var string|null
   */
  protected $data_table = NULL;

Can we document this better and if so: Where would be the best place to do so?

Problem/Motivation

#2574767-36: Views listing page displays too few items on a page removed the "Tags" column from the list of views at /admin/structure/views, because it was rarely used.

I don't personally use Views Tags on every project, so I understand with, and largely agree with the reasoning in that issue. Also I couldn't find any other issues asking for it to be re-added, which probably also indicates that the feature is not used that often.

That being said, I do find Views tags very useful in specific situations, e.g.: for managing technical debt on a site with multiple developers and a tight timeline... I tag views by their base table, contextual filters, whether they use aggregation, and where they are used; so that it is easy for developers to find an existing view they can add a new display to (rather than creating an entirely new view), and it is easy to see which views could be combined when they are already a mess.

Ideally, the list of views at /admin/structure/views would become a view of its own (e.g.: as part of #1823450: [Meta] Convert core listings to Views), which would allow me to simply add a tags column on the sites that required it; and leave it at the default everywhere else.

However, in the meantime, it would be handy to have a patch to apply to add the tags column back.

Proposed resolution

Write a patch to re-add the tags column.

Remaining tasks

1. Write a patch.

I'll leave it to others to determine whether this is something we want to add back to Drupal core; or just leave here for people to apply when they need it.

User interface changes

Adds a "tags" column between Description and Displays to the list of views at /admin/structure/views

API changes

None.

Data model changes

None.

Problem/Motivation

Currently usernames as links are trimmed when over 20, to 15 + 3 periods.

Proposed resolution

Trim when over 30, to 29 + an ellipsis character. Use a constant for trimming length as suggested in #93 and fix other mentioned issues.

Remaining tasks

#111 Do we need any theming (for mobile)?
#161 In #120, the $variables['trim_length'] was added. Verify that this works. Is there actually a way for a theme (such as the Seven theme) to set this variable?Answered in comment #226.

User interface changes

Longer usernames, see screenshots.

Beta phase evaluation

Additional Explanation

A whole lot of board posts, questions and articles out on the web are calling for usernames not getting truncated to 15 characters when displayed as links, for example in node view:
- https://drupal.org/node/82672
- https://drupal.org/node/80953
- https://drupal.org/node/85476
- https://drupal.org/node/810938
- http://drupal.stackexchange.com/questions/54054
- http://data.agaric.com/stop-drupal-from-shortening-long-usernames
- http://sscnet.ch/content/keep-drupal-truncating-user-names
- http://grokbase.com/p/drupal/support/07667d4acm/long-username-getting-tr...
- ...

While some limit might be necessary to avoid extremely (!) long usernames breaking the layout, 21 or 25 or even 30 characters are perfectly right and quite usual, especially if a full name or email address is provided.
We don't want to make configurable whatever can be overridden by code, but at least we want to provide a diligent default that makes overriding the exception rather than the regular case.
Therefore I'd propose to raise or waive the limit given in theme_preprocess_username().

Screenshots after applying patch in #91

Long Usernames MOBILE BEFORE

Long Usernames MOBILE AFTER

Long Usernames DESKTOP BEFORE

Long Usernames DESKTOP AFTER

Problem/Motivation

For custon migration it's a very common request to filter the migrated items. Some real use cases are:
- migrate nodes older than {date};
- skip blocked users or users with certain emails or users that never accessed the website;
- migrate users with certain roles;

It would be great to be able to use conditions to narrow down your SQL source data for content/config entity types. The resulting functionality would provide much more capabilities to how you can migrate nodes one content type at a time, and the same for taxonomy terms -- but for users (by role), menu links (by menu), and so on.

The functionality would let you narrow your data during the source/extraction phase, instead of during the process/transformation phase (which you can do using skip_on_value/empty + method: row). Benefits would include general tidiness of data :) And! Speed/performance!

Proposed resolution

Introduce new configuration properties in SqlBase base class: conditions, joins and distinct:
conditions - to filter the results;
joins - to join additional tables (required to filter by fields/properties stored in separate tables);
distinct - to avoid duplicated results when joining one-to-many records;

If such configuration is present, it's being applied to the query in prepareQuery method, when the base query is already defined.

Remaining tasks

1. Review and validate the approach;
2. Resolve #2833060: SqlBase::prepareQuery() should be called also on count, which is kind of a blocker (the source count is not updated after applying conditions, because the count() ignoring prepareQuery method);
3. Add more tests;
4. Write a change record;

Widgets for entity reference fields are responsible for passing along the entity the widget is rendered on (aka host entity) so entity reference selection plugins know about the entity making the request.

The options buttons (checkbox/radio) and options select pass along the entity. These widgets create selection settings via:

1. \Drupal\Core\Field\Plugin\Field\FieldWidget\OptionsWidgetBase::getOptions
2. \Drupal\Core\TypedData\OptionsProviderInterface::getSettableOptions
3. \Drupal\Core\Entity\EntityReferenceSelection\SelectionPluginManager::getSelectionHandler

The entity autocomplete is not passing along the entity. Its selection settings are created in \Drupal\Core\Field\Plugin\Field\FieldWidget\EntityReferenceAutocompleteWidget::formElement

Steps to reproduce:

Select widget

1. Set up an entity reference field and reference it to content.
2. Use the select list widget for the entity reference field.
3. Edit an entity with the entity reference field.
4. When the form is being rendered, inspect \Drupal\Core\Entity\Plugin\EntityReferenceSelection\DefaultSelection::getReferenceableEntities, notice $this->configuration['entity'] contains the entity the field is rendered on.

Autocomplete widget

1. Set up an entity reference field and reference it to content.
2. Use the autocomplete widget for the entity reference field.
3. Edit an entity with the entity reference field.
4. When the form is being rendered, inspect \Drupal\Core\Entity\Plugin\EntityReferenceSelection\DefaultSelection::getReferenceableEntities, notice $this->configuration['entity'] does not exist.

Problem/Motivation

MigrateDestinationInterface::rollback() has a $destination_identifier parameter.

This is an array of ID values, which are keyed by the key names.

The documentation should say that the array is keyed.

Problem/Motivation

Test for aggregator module are scattered around in other modules. We need to consolidate these tests into the modules directory (core/module/aggregator) and into the modules namespace.

This way it will be easier to move the current Core module almost as-is to the Contrib realm

Steps to reproduce

Proposed resolution

Move all tests to the aggregator module.

Remaining tasks

Move all tests to aggregator module.
#3265424: Move migrate related aggregator tests to the module in preparation of removal in d10

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

I've spent too many hours debugging that LogicException and finding the root cause now, so I thought it's time to open this issue.

Finding the root cause for that is very hard and frustrating, and there really isn't a good reason to die hard, since all the information is there that we need, it's just not done 100% properly.

To give some ideas what I had to do:
* In Monitoring in a rest service, I'm calling hook_requirements() and because system_requirements() creates a URL for the cron link, I have to add 10+ lines of code to execute it in my own render execution wrapper. I've also helped 2+ people in IRC that did run into similar problems
* In a payment response processing, I'm saving a node, that node is indexed by search API, and then the solr backend generates a URL to figure out the current domain, so it can index for that. I couldn't care less what it does there, but it completely breaks my page and I have no way of fixing that except changing search_api_solr or executing my node save in such a render execution wrapper.

The exception does not give *any* information about what the missing cacheability it is, where it is coming from and how to fix it. You need to debug that yourself, for example by figuring out what max-age/context/tag bubbled up and then break on Cache::merge*() or similar places and then backtracking. Not many developers will figure that out, you need to know lots of internal stuff.

Also, all the required information *is* present, and for render arrays, we happy accept it and move on, only in case of Response objects, we die with an exception.

Workaround

- See change record All rendering must happen in a render context, early rendering's metadata no longer lost
- #19
- #20
- Matt Oliveira @ https://www.lullabot.com/articles/early-rendering-a-lesson-in-debugging-...
-#33
-#47

Proposed resolution

Remove the exception, just add the cacheability metadata, or ignore it with a warning log message or so if that's not possible.

And if the response object is *not* cacheable, then the exception is completely pointless anyway. This is also related to #2626298: REST module must cache only responses to GET requests and would fix that in a more generic way.

Maybe we could introduce some sort of check again later, as an assert or so.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Drupal 8 propose to use a settings.local.php file to allow project to disconnect general settings ( in settings.php file) and local settings.
In hightly scripted environnement, we need the installation process write local informations (database/profil information) directly in settings.local.php when installing.

Proposed resolution

The proposed patch add a test on availability of the settings.local.php ( file exist and settings.php include it) in drupal_rewrite_settings function.
If the file are available ( exits and included by settings.php) it will be used during installation write settings process.

Remaining tasks

NA

User interface changes

NA

API changes

NA

Data model changes

NA

Original report by [username]

NA

Problem/Motivation

follow up #3041659: Remove the layout tab from translations because Layout Builder does not support translations yet

Part of #3044386: [META] Make Layout Builder layouts translatable

Right now you are not able to translate layouts at all.

The most common use case is probably translating the block labels and inline blocks but having the actual layouts not change from language to language. For different layout per language: see #3040487: Allow Independent Layout Override Translations

Proposed resolution

1. Provide access to the Layout table on translations
2. On Translations the Layout builder would only allow translating labels and inline blocks
3. Translated settings for block would be stored a new field that would be translatable(the current Layout field would still be untranslatable)
4. Most blocks could only have labels as translated settings
5. Inline blocks could additionally have a block revision ID stored.

Remaining tasks

• Get#3013197: Cloning an implementation of SectionListInterface does not deep clone the Section or SectionComponent objectscommitted.
• Write more tests for Inline blocks. <-- We are here.
• Needs update path test for existing content before this change

User interface changes

API changes

Data model changes

Problem/Motivation

When creating exposed grouped filters in a view, if a group is named and using autocomplete widget to add group items (can be taxonomy terms or users), the form throws the error on save:

The value is required if label for this item is defined.

Here is the screenshot of the error:

The problem behind this is that array of arrays is not recognized here:

$min_values = $operators[$group['operator']]['values'];
$actual_values = count(array_filter($group['value'], 'static::arrayFilterZero'));

In case autocomplete, it has the following data format:

[
  0 => [
    ' target_id' => 1
  ] ,
]

but the code above expects it to be:

[
  1 => 1
]

so it doesn't pass the filtering in static::arrayFilterZero

Affected plugins:

1. \Drupal\user\Plugin\views\filter\Name (#2920039: Views' User Name exposed group filter validation)
2. \Drupal\taxonomy\Plugin\views\filter\TaxonomyIndexTid (this issue)

Steps to reproduce

1. Install Drupal with "Standard" profile
2. Open content view (/admin/structure/views/view/content)
3. Add an exposed grouped filter by "Tags" (Taxonomy). Make sure the group item is using autocomplete widget
4. Add at least one item to the group configuration
5. Submit

Proposed resolution

Convert values into array with ids, which is expected by base filter plugin.

Remaining tasks

1) Wait for #1810148: Grouped exposed taxonomy term filters do not work;
2) Review/commit;

Out-of-the-box the only row plugin Drupal 8 provides for entity revisions is the "fields" plugin. This is a bit of a nuisance! Why not allow entity rendering of revisions? Patch to follow.

Problem/Motivation

Drupal 8/9 ship with CKEditor 4's StylesCombo plugin/feature: https://ckeditor.com/docs/ckeditor4/latest/features/styles.html

This shipped with the original CKEditor 4 issue: #1890502: WYSIWYG: Add CKEditor module to core. It provides a configuration UI:

When talking to the CKEditor developers:

We didn’t work on a replacement yet. We’re not even sure whether it’s needed and what’d be the use cases.
There’s a very old ticket: https://github.com/ckeditor/ckeditor5/issues/648 where we started some discussion. There’s also https://github.com/ckeditor/ckeditor5/issues/5700. But in general it’s unclear for us what would this feature be for.

What use cases do you see for it?

My response:

Well … how do we provide an automatic upgrade path in Drupal? 🤔

StylesCombo in CKE4 can only be mapped to heading.Heading in CKE5 as long as it’s only touching <h*>— but StylesCombo allowed much more. How do we automatically take any arbitrary StylesCombo configuration and make it work in CKE5?

It’s fine if it maps to multiple plugins but we do need to provide an upgrade path.

To which they responded:

Yeah, from the upgrade path perspective, there’s certainly a clear reason to do something on our side. What was blocking us so far is that we don’t want to create again a feature that duplicates a big part of the headings dropdown functionality. Thus, product-wise, it’s tricky.

Proposed resolution

Wait for https://github.com/ckeditor/ckeditor5/pull/11349 to ship with the April 6 release of CKEditor 5.

Remaining tasks

TBD

User interface changes

TBD

API changes

None.

Data model changes

None.

Problem/Motivation

This is in ckeditor5_library_info_alter, not inside any conditionals:

// Only add translation processing if the locale module is enabled.
  if (!$moduleHandler->moduleExists('locale')) {
    return;
  }

So if locale isn't enabled, the alter aborts early.

This was discovered while working on #3194084: Support functionality equivalent to ckeditor_stylesheets, as it prevented the solution from working.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The "Add media" button for the Media Library is too general IMO.

Instead, I propose that the label is "Add @label", with @label being the field label.

A couple of examples:

Documents (field_documents)

"Add media" becomes "Add Documents"

Image (field_image

"Add media" becomes "Add Image"

----

It'll also encourage well-named field labels for media fields.

Patch attached.

When using #theme => links, you can set the 'set_active_class' option and get the CSS class is-active added to both the LI and the A element when the link's URL matches the current URL.

However, if the URL in question contains a query, the is-active class only gets added to the A element, and not the LI.

This is because template_preprocess_links() is not correctly getting the query parameters from the URL:

          // Add a "data-drupal-link-query" attribute to let the
          // drupal.active-link library know the query in a standardized manner.
          if (!empty($link['query'])) {
            $query = $link['query'];
            ksort($query);
            $li_attributes['data-drupal-link-query'] = Json::encode($query);
          }

The query is no longer in $variables['links']['query'], but part of the URL object passed in $variables['links']['url'].

Problem/Motivation

Unused full site configuration upload/comparison won't go away.

Steps to reproduce

Tested Synchronize by uploading a full site configuration archive with known changes to see how comparison looked/worked. I had no intention to "Import all." Now it won't go away. Still displaying at: /admin/config/development/configuration. Running cron or clearing cache had no affect.

Proposed resolution

Provide instruction how to clear unused uploaded archives.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

On a layout builder page I am seeing data loss when saving an existing block with source mode enabled in ckeditor. At least the data loss is quite obvious ;)

Steps to reproduce:

• Add block to section
• Create custom block
• Edit text in body field
• Save block
• Edit block
• Switch body field to ckeditor source mode
• Edit text
• Save
• Changes are NOT saved!

Workaround: Once I change back to non-source mode and do some change(!) the changes are saved properly.

Variation

This is a bit more severe with ckeditor_config (on a core 8.7.8 install with a lot modules installed) module enabled.

Steps to reproduce:

• Add startupMode = source to ckeditor_config settings in basic_html
• Edit block
• Switch body field to source mode
• Edit text
• Switch to non-source mode (this makes it work in the first example)
• Save
• Changes are NOT saved!

(Disclaimer: In the variation I am not 100% sure if it is because of the mentioned ckeditor_config settings, at least I haven't verified on a vanilla drupal install)

Proposed resolution

Allow textarea fields to be saved when edited in CKEditor 4's Source mode.

Remaining tasks

1. Valid and remediate issue between patches in #26 and #29.
2. Write valid tests confirming issue has been resolved.

Problem/Motivation

Drupal\ckeditor5\SmartDefaultSettings::addToolbarItemsToMatchHtmlAttributesInFormat isn't necessarily handling use cases where CKEditor plugin only supports specific attribute value in the best possible way. Currently it will enable plugins that allow ALL values for an attribute. This means the attribute+value is now allowed but additional attribute values are permitted as well. This may need to be more selective.

If we don't do that, we could end up allowing <p class> instead of only allowing <p class="text-align-center">, for example.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes