Problem/Motivation

New developers, learning how to code using Drupal "the Drupal way", often struggle to grasp the concept of render arrays. A large component of this is in my opinion, that render arrays often have their type documented, but there is no list of render array keys available. This leads to developers relying on posted questions and solutions on other platforms such as StackExchange, or guides solving a particular problem (if there is any guide at all), instead of consulting the documentation and trying to find the best way to solve the problem.

Steps to reproduce

Documentation of render array types (for example "File") can be found on their classes, if available. Examples:

• File class
• ManagedFile class

Proposed resolution

All the possible render array keys (also the default ones like #title and #description) should be listed and described in the first part of the documentation.

On the File class, there are two out of seven possible render array keys listed and described. On the ManagedFile class, there are none documented. There should be at least every render array key listed in the description section (like on the File class) with a quick description on what can be achieved by defining this setting.

Additionally, a small section of code examples should also be included afterwards, so users see the logic and the syntax to define these setting.

The list of allowed keys could be based on public function getInfo() which is implemented on these classes.

Remaining tasks

• List candidates for documentation changes (could be based on this list)
• Add said descriptions to the documentation pages

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

#2796173: Add experimental Field Layout module to allow entity view/form modes to switch between layouts adds a "Layout settings" detail element to the Field UI to select new layouts.
Layouts can provide their own settings, and would appear once the layout is selected.

However, many layouts (including the ones added in that issue) do not provide settings.
The Ajax progress indicator appears, then disappears with no apparent changes.

Additionally, the table with all the fields in it does not update to represent the new layout until the whole form is saved.

This is confusing on its own, but even more so given the Ajax-ified select element.

Proposed resolution

1) Make the whole form rebuild with the new regions
2) If none of the layouts in the select list have settings, don't perform the Ajax operation at all
3) Both 1 & 2
4) Your idea here!

Remaining tasks

Decide on an approach

User interface changes

Yes, but TBD

API changes

N/A

Data model changes

N/A

Twig using the \Countable interface when it does an if on an object - all of our SafeStringsInterface implementing objects should do this.

Follow-up to #2572659: Fix 'Drupal.Commenting.InlineComment.SpacingAfter' coding standard

Part of #2571965: [meta] Fix PHP coding standards in core.

Approach

We are testing coding standards with PHP CodeSniffer, using the Drupal coding standards from the Coder module. Both of these packages are not installed in Drupal core. We need to do a couple of steps in order to download and configure them so we can run a coding standards check.

Step 1: Add the coding standard to the whitelist

Every coding standard is identified by a "sniff". For example, an imaginary coding standard that would require all llamas to be placed inside a square bracket fence would be called the "Drupal.AnimalControlStructure.BracketedFence sniff". There are dozens of such coding standards, and to make the work easier we have started by only whitelisting the sniffs that pass. For the moment all coding standards that are not yet fixed are simply skipped during the test.

Open the file core/phpcs.xml.dist and add a line for the sniff of this ticket. The sniff name is in the issue title. Make sure your patch will include the addition of this line.

Step 2: Install PHP CodeSniffer and the ruleset from the Coder module

Both of these packages are not installed by default in Drupal core, so we need to download them. This can be done with Composer, from the root folder of your Drupal installation:

$ composer require drupal/coder squizlabs/php_codesniffer
$ ./vendor/bin/phpcs --config-set installed_paths ../../drupal/coder/coder_sniffer

Once you have installed the phpcs package, you can list all the sniffs available to you like this:

$ ./vendor/bin/phpcs --standard=Drupal -e

This will give you a big list of sniffs, and the Drupal-based ones should be present.

Step 3: Prepare the phpcs.xml file

To speed up the testing you should make a copy of the file phpcs.xml.dist (in the core/ folder) and save it as phpcs.xml. This is the configuration file for PHP CodeSniffer.

We only want this phpcs.xml file to specify the sniff we're interested in. So we need to remove all the rule items, and add only our own sniff's rule. Rule items look like this:

<rule ref="Drupal.Commenting.InlineComment.DocBlock"/>

Remove all of them, and add only the sniff from this issue title. This will make sure that our tests run quickly, and are not going to contain any output from unrelated sniffs.

Step 4: Run the test

Now you are ready to run the test! From within the core/ folder, run the following command to launch the test:

$ cd core/
$ ../vendor/bin/phpcs -p

This takes a couple of minutes. The -p flag shows the progress, so you have a bunch of nice dots to look at while it is running.

Step 5: Fix the failures

When the test is complete it will present you a list of all the files that contain violations of your sniff, and the line numbers where the violations occur. You could fix all of these manually, but thankfully phpcbf can fix many of them. You can call phpcbf like this:

$ ../vendor/bin/phpcbf

This will fix the errors in place. You can then make a diff of the changes using git. You can also re-run the test with phpcs and determine if that fixed all of them.

Problem/Motivation

Importmaps allow a browser to resolve naked ES imports.

e.g.

import React from 'react';

Ordinarily a browser doesn't understand how to resolve that, but with an import map it can.

However, you can only have one <script type="importmap"> element on a page, so therefore it makes sense to have an API in core to support this. In addition you cannot dynamically update this, so e.g. things like Ajax responses cannot add new importmaps. As a result we need to declare all possible import maps on the page.

Adding this API will allow us to do more interesting things with JavaScript. E.g. consider two modules that rely on a JavaScript library. If both of them bundle the same library into their code, there will be two instances of this in the page.

A concrete need for this is for the React module and the Gutenberg and Decoupled layout builder modules. Both of them need React loaded into the page.

Without importmaps, both of them will need to hard-code a reference to the URL of the bundled react libraries provided by the React module.

With importmaps, both of them can configure their bundler (Vite/Webpack) to mark React as external - this will result in the bundler leaving import React from 'react' in the bundled code.

Then the React module could specify an importmap via this new API and Drupal would take care of emitting an <script type="importmap"> into the page.

Proposed resolution

Add an API to core for importmaps. Base this off the Importmaps contrib module.

At present the importmaps module uses hook_page_top to unconditionally add the <script type="importmap"> tag to the page.

Remaining tasks

Agree we want to do this.
Adapt the code in importmaps (e.g. YML discovery, plugin manager).

User interface changes

API changes

New plugin manager and YML plugin discovery for importmaps

Data model changes

Release notes snippet

Problem/Motivation

Follow-up to #2572659: Fix 'Drupal.Commenting.InlineComment.SpacingAfter' coding standard

Part of #2571965: [meta] Fix PHP coding standards in core.

In line comments are missing the final final stop to complete the sentence.

Steps to reproduce

Proposed resolution

Enable Fix 'Drupal.Commenting.InlineComment.InvalidEndChar
Most changes made by phpcbf but not all.

Remaining tasks

Review

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

This sniff relates to Drupal API documentation standards for classes and namespaces.

Hello this fixes the Drupal.Commenting.ClassComment.Missing standard listed in this parent, #2571965: [meta] Fix PHP coding standards in core.

In the pull request two classes are skipped:
- one is being fixed via the https://www.drupal.org/project/drupal/issues/3105880
- and another one intentionally doesn't include the class doc block due to testing the empty plugin annotations (therefore the adjusted phpcs.xml.dist).

Steps to reproduce

Proposed resolution

Comply with Drupal API documentation standards for classes and namespaces and another relevant part of the Drupal coding standards.

Remaining tasks

Break into child issues for

• Core test #3498158: Fix 'Drupal.Commenting.ClassComment.Missing' in core/tests
• Functional tests #3498152: Fix 'Drupal.Commenting.ClassComment.Missing' in Functional tests
• test modules #3498297: Fix 'Drupal.Commenting.ClassComment.Missing' in test modules
• module #3498302: Fix 'Drupal.Commenting.ClassComment.Missing' in modules

This issue will enable the sniff and fix any remaining issues

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

If you try to use #ajax on a Views exposed filter form element, the callback is never invoked.

Steps to reproduce

1. Attach #ajax in a views exposed form
2. Expect the callback to be trigger as if attached elsehwere
3. No callback is triggered

Proposed resolution

Handle the mix of GET from the View and POST from the callback by determining if the triggering element is not the exposed form submission, but is instead the element with the attached ajax callback.

Remaining tasks

Fix the issue described in #155

User interface changes

None

Introduced terminology

None

API changes

None

Data model changes

None

Release notes snippet

Ajax callbacks can now be attached to elements inside a Views Exposed Form.

Problem/Motivation

Follow up to Issue #3116377
When autocomplete fields have long labels (or the viewport is just narrow), the loading text overlaps the label

Also, when autocomplete field has long input text, It overlaps the search icon.

Proposed resolution

Get rid of the "Loading" text altogether and swap the magnifying glass for a loading animation?

Remaining tasks

Add screenshots
Review code
Commit

User interface changes

todo

API changes

Data model changes

Release notes snippet

Problem/Motivation

https://www.drupal.org/sa-core-2024-006 was released in November 2024.

This is a public issue to add the tests that were used in the development of the fix in a private issue, as several weeks have now passed to allow sites to update.

Steps to reproduce

Run tests in an MR.

Proposed resolution

MR / test / commit.

Remaining tasks

Problem/Motivation

This Plan/Meta issue gathers all of the usability tests and surveys related to the toolbar redesign. It does not expect any code/MR.

As a result of the exploration of the possible integrations with the new left toolbar we’ve discovered that the existing left sidebar is missing the capacity to accommodate some of them. Items that are more actionable and related with the content of the existing elements on the page can’t be easily accommodated there.

The validation of this feature is happening in #3396125: Toolbar Prototype Usability Testing Phase 4 with the existing prototype to test on #3398483: Create a functional prototype of the new top contextual bar.

FIGMA initial designs:
here

Proposed resolution

The Top bar is going to provide 3 main areas, extendables:
1. The Tools area. Core and contrib modules will be able to provide inject content here that will serve as a set of tools for the page.
2. Contextual area. This will provide info about the existing entity or route with the goal to give info about where you are.
3. Actions area. Primary action and other action should be grouped here.

Remaining tasks

Must have (for both Navigation and Top Bar Stable releases)

For the whole Navigation module to be Stable, but also the Top Bar to be Stable, the following issues need to happen:

• #3508199: Navigation Top Bar accessibility issues found by Nightwatch tests

Nice to have (for Stable release)

• #3499783: Evaluate if the Top Bar entity title needs to show extra info
• #3500162: Define how to handle secondary local tasks in entity pages when Navigation Top Bar is enabled
• #3499783: Evaluate if the Top Bar entity title needs to show extra info
• Evaluate moving the Preview button to the Top bar staring with #3408500: Move the Save button into the Top Bar
• Decide what to do with the Publish checkbox + workflow (Long term, since it'll depend on the redesign of the Workspaces module workflows and UIs)

Issue with a proof of concept for the front-end: #3484601: Proof of concept for the components that will render the top bar

Problem/Motivation

Drupal has a lot of areas where we have added a new feature/API etc. which is capable of replacing something else, but that replacement has never happened, leading to two or more, often confusing, ways to do things, or a general level of unevenness across core where legacy and new ways to do things conflict or don't combine well. This goes across site builder features, PHP, theming, JavaScript, docs.

Opening this issue to collect some of the issues trying to address this. While the individual issues don't necessarily have much in common, at lot of them have common themes at a higher level. Also because I'm in the middle of drafting a blog post about this and need an issue to link to.

This doesn't have to be strictly about when there are two ways of doing things in core, it can also cover when finishing a core feature properly would allow it to replace a contributed modules (entity API for example).

Steps to reproduce

Proposed resolution

Remaining tasks

Issues with a ** are priorities per #3476431: [discussion] Prioritized issues for Drupal Modernization

Site building features/usability

** #111317: Allow users to login using either their username OR their e-mail address There are child issue to work on for this.
** #1537198: Add a Production/Development toggle
#2353867: [META] Expose Title and other base fields in Manage Display
#3365551: Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points
#3063877: Add access control to /filter/tips
#1823450: [Meta] Convert core listings to Views
#3372932: [Meta] High-performance images (nearly) out of the box
#2954834: Add poster image to HTML5 media videos

Done:
** #3347343: Add Views EntityReference filter to support better UX for exposed filters

HTML/CSS

#2880237: Refactor system/base library
#2158943: Add a native dialog element to deprecate the jQuery UI dialog
#3404214: META: Reduce / eliminate “jank” (layout shifts) within Drupal’s admin UI
#1804614: [meta] Consolidate similar twig templates and properly use theme suggestions in core
#3458587: Deprecate preprocess variable cruft in core
#3252084: [meta] Remove support for IE11
#3426579: Update parts of Umami that are falling behind
#3254529: [PLAN] Drupal CSS Modernization Initiative

PHP APIs

** #3396165: [meta] Convert all core plugin types to attribute discovery
#2025629: [meta] Ensure that all #theme/#theme_wrappers hooks provided by core are associated with a sensible, re-usable element #type
#2346347: Finalize API for creating, overriding, and altering code-defined bundle fields
#2875151: [META] Implement Batch API as a service
#1803948: [META] Adopt the symfony mailer component
#3100110: Convert update_calculate_project_update_status() into a class
#2544110: XSS attribute filtering is inconsistent and strips valid attributes
#2350509: Implement auto-route generation for all core entities and convert all of the core entities.
#2808481: Introduce generic entity template with standard preprocess and theme suggestions

Done:
** #3442009: OOP hooks using attributes and event dispatcher

JavaScript

#3238306: [META] Where possible, refactor existing jQuery uses to vanillaJS to reduce jQuery footprint
#3203920: Replace Contextual Links BackboneJS usage with VanillaJS equivalent
#3398525: Add an API for importmaps
#3028968: Create Javascript library for searching/filtering rendered lists on the client.
#3076171: Provide a new library to replace jQuery UI autocomplete
#2158943: Add a native dialog element to deprecate the jQuery UI dialog

Docs and tooling

** #3463660: Document high-level API concepts in an easier format
#3398293: Consolidate local development environment documentation to recommend DDEV
#3439331: [policy] Decide on format of commit message Implementation is in, #3486271: Change format for git commit message for the Drupal Core project..

User interface changes

API changes

Data model changes

Release notes snippet

This is part of #2015147: [meta] Improve the DX of drupal_render(), renderable arrays and the Render API in general

Currently it is pretty confusing and requires some research to figure out when #theme and #type should be used to render a given HTML element with the Render API.

Since #type can set a default #theme through element_info() it makes sense that #type should actually be the "de facto" starting point for building any renderable array and #theme can just be used to set overrides when the default #theme is not sufficient.

To achieve this we need a few things:

• Every #theme currently set by core in hook_theme() needs a corresponding #type set in hook_element() if it doesn't have one already.
• Every #theme with a corresponding #type already needs to actually be compatible, eg. taking the same parameters, doing the same sanitisation, not using #markup as the default render for the #type, etc..
• Renderable arrays used by core should always be built starting with #type so that core leads by example - this has to be done last and will probably end up being its own meta issue.

There has been a general movement towards this for a while now, but I'm unaware of any existing meta issue bringing them all together and formalising the process so I opened this one.

Introducing new element types for existing "base" theme hooks

For the most basic additions all we need is something like the following for #theme 'foo' and module 'bar':

/**
 * Implements hook_element_info().
 */
function bar_element_info() {
  $types = array();
  $types['foo'] = array(
    '#theme' => 'foo',
  );
  return $types;
}

For these most basic conversions, if #2005970: In renderable arrays, #type should provide a #theme suggestion, similar to how drupal_prepare_form() works ever lands it will remove the need to explicitly set all these #theme defaults but it's unlikely the patch in that issue will land if we don't have a comprehensive set of #types that are compatible with matching #themes - It's kind of chicken or the egg, so we have to start somewhere.

Not everything in this list is this simple however, some are looking to introduce more advanced functionality in the form of new #pre_render callbacks.

It is important to realise that theme hooks may be theming forms based on a form ID, which is set as a theme suggestion in drupal_prepare_form() - this is an example of render defaults being merged into a render array outside the "element type" system. In these cases, defining a #type is useless but I don't know of any easy way to test whether a hook is implementing a form ID based suggestion or not.

There are plenty of other theme hooks that are already overriding a default #theme for a given #type for a specific use-case or are implementing a suggestion - These do not need their own #type. Figuring out what makes sense as an element #type and what only exists as a #theme override/suggestion can take a little research and discussion on a case-by-case basis.

#theme hooks that are only intended to be used with #theme_wrappers do not need a matching #type element.

The concept of a "base" theme hooks are those that are used in core with no #type currently set and that aren't implementing a form ID suggestion.

Categories

A - super simple

If #theme works, the theme hook uses variables instead of 'render element', the theme hook doesn't render #children (we're not using #theme_wrappers anywhere) then all we need to do for this is take:

$foo = array('#theme' => 'foo');

define a type in hook_element_info() that sets the #theme:

bar_element_info() {
  ....
  $types['foo'] = array(
    '#theme' => 'foo',
  );

Then we can replace the #type with #theme in the original array wherever it appears:

$foo = array('#type' => 'foo');

Issues

- #1595614: [meta] Remove all the theme functions and templates in core that simply output a link. Replace with #type 'link' render arrays
- #2086619: #theme 'maintenance_page' should be based on #type 'page'

Deprecated list, see comment #7 (clean me out, find the wheat in all this chaff please):

• #2025661: Introduce #type equivalents for each theme hook in aggregator.moduleAssigned to: dmitrii
• #1300744: Introduce #type 'links'
• #2025665: Introduce #type 'block'
• #2025669: Introduce #type 'custom_block_add_list'
• #2025677: Introduce #type equivalents for each theme hook in book.module
• #2025681: Introduce #type 'ckeditor_settings_toolbar'
• #2025687: Introduce #type 'color_scheme_form'
• #2025689: Introduce #type elements for base theme hooks in comment.module
• #2025703: Introduce #type elements for base theme hooks in field.moduleAssigned to: dmitrii
• #2025709: Introduce #type elements for base theme hooks in file.module
• #2035971: Introduce #type elements for base theme hooks in filter.module
• #2035973: Introduce #type elements for base theme hooks in forum.module
• #2035977: Introduce #type elements for base theme hooks in image.module
• #2035979: Introduce #type elements for base theme hooks in language.module
• #2035981: Introduce #type elements for base theme hooks in link.module
• #2036155: Introduce #type elements for base theme hooks in locale.module
• #2036163: Introduce #type elements for base theme hooks in node.module
• #2036165: Introduce #type elements for base theme hooks in overlay.module
• #2036167: Introduce #type elements for base theme hooks in picture.module
• #2036169: Introduce #type elements for base theme hooks in rdf.module
• #2036171: Introduce #type elements for base theme hooks in search.module
• #2036173: Introduce #type elements for base theme hooks in simpletest.module
• #2036177: Introduce #type elements for base theme hooks in system.module
• #2036183: Introduce #type elements for base theme hooks in taxonomy.module
• #2036185: Introduce #type elements for base theme hooks in toolbar.module
• #2036189: Introduce #type elements for base theme hooks in update.module
• #2036191: Introduce #type elements for base theme hooks in user.module
• #2036203: Introduce #type elements for base theme hooks in views.module
• #2036207: Introduce #type elements for base theme hooks in views_ui.module

Ensuring #type/#theme compatibility between hooks/elements with the same name

There's a few things that can happen here.

All things equal, it would be ideal if when a #type declares a default #theme hook they both have the same name. This won't always be possible, an obvious example is when multiple #types share the same #theme hook, but we should try to consolidate things where we can.

• #2025707: Remove unused #theme "file_widget"
• #2025699: Consolidate 'datetime'/'datetime_form' and 'datelist'/'datelist_form' #type and #theme names for consistency

Any #type that declares a #theme of the same name that also declares #pre_render or #post_render callbacks must use the same parameter names that the #theme hook is expecting, or at the very least not conflict/preclude the #theme hook from operating in the desired way when #type is used.

No #theme hook may set a variable named 'type' as this immediately makes it impossible to ever implement a #type for this theme hook.

• #2010672: Rename 'type' variable of theme_mark to 'status'
• #1828536: Rename 'type' variable of theme_item_list() to 'list_type'
• #1985470: Remove theme_link()

Migrating existing #theme arrays to #type arrays

• #1876712: [meta] Convert all tables in core to new #type 'table'

Squeezed into #1260860-45: Rework language list admin user interface...

Problem

• Link lists are hardly extensible and alterable.

Example

1. You have a table, with Operations column.
2. You have one or more modules integrating with that table, adding operations.
3. You have a renderable structure, but all the links get stacked into an odd #links property of a single element.
4. Say hello to array_splice(), array_slice(), array_search(), array_pop(), and array_unshift()! Your only way to inject a link at a certain position.

Solution

• Introduce #type 'links'.
  1. Renders sub-elements of #type 'link', 'markup', or whatnot first, and as usual. (respecting #weight, #ajax, and whatever else you want to do)
  2. Takes the rendered #children of each sub-element and turns them into items of an item list.
  3. Profit.

Problem/Motivation

While working on #3507866: [PP-1] Enable the Navigation Top Bar when Navigation is enabled found that Navigation Top Bar has some accessibility issues disclosed by aXe Nightwatch tests.

This issues need to be solved before we can make the Top Bar stable.

From https://git.drupalcode.org/issue/drupal-3507866/-/jobs/4431574

️TEST FAILURE (1m 56s):  
   - 2 assertions failed; 1433 passed
   ✖ 1) Tests/a11yTest
   – Accessibility - Navigation Module - Claro page (1.698s)
   → ✖ NightwatchAssertError
   aXe rule: button-name - Buttons must have discernible text
	In element: .toolbar-button--icon--dots
   → ✖ NightwatchAssertError
   aXe rule: region - All page content should be contained by landmarks
	In element: .top-bar__context

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

We have two very similar templates in Drupal links.html.twig and item-list.html.twig. Both of these templates loop through a set of items, and create a HTML list. This creates twice as much code to maintain, and two separate, nearly identical, things to keep up to date.

Proposed resolution

Let's remove links.html.twig, add item-list--links.html.twig and call theme('item_list__links') to generate link lists. This implies adding the heading tag functionality to item-list.html.twig and converting the template to handle keyed item lists, and turning those keys like links.html.twig currently does

Remaining tasks

1. #2032645: Replace calls to theme('item_list') with calls to theme('links') for links, when a heading or wrapper div is warranted
2. #1842140: Remove title and wrapper div from item-list.html.twig
3. #939462: Specific preprocess functions for theme hook suggestions are not invoked
4. Replace links.html.twig with theme('item_list__links') to generate the link list items throughout core (this issue)

User interface changes

None.

API changes

TBD

Related Issues

Postponed by: #939462: Specific preprocess functions for theme hook suggestions are not invoked
#1813426: [meta] Consolidate all item list templates and add theme_hook_suggestions
#1804614: [meta] Consolidate similar twig templates and properly use theme suggestions in core
#1939064: Convert theme_links() to Twig

Original report by @RobLoach

There's a function available to create an HTML list of items (theme_item_list), and there's a function to create an HTML list of links (theme_links). Wouldn't it make sense to make the function that creates a list of links take advantage of the function that creates the HTML list of items?

This patch makes theme_links use theme_item_list to create the list of links.

Proposed commit message

Issue #1842140 by mdrummond, tonystar, gavin.hughes, killerpoke, lauriii, droweski, stevector, omg-its-maggie, jenlampton, Renee S: Remove title and wrapper div from theme_item_list.

Problem/Motivation

We are currently printing a title and wrapper div in item list templates. Templates really should be as concise and semantic as possible, and only print a div when it's really needed, the title should be a separate element. The class from the wrapper div can be moved to the ul/ol tag, and the CSS can be updated to match.

Proposed resolution

When we need a heading tag and/or a wrapper div, we should call theme_links instead. That theme function can then call theme('item_list') which will generate a nice clean list. When we only need a nice clean list, we can call this function directly.

Proposed code fo the item list template:

{% spaceless %}
  {%- if list_type == 'ul' -%}
    <ul{{ attributes }}>
  {%- else -%}
    <ol{{ attributes }}>
  {%- endif %}
    {%- for item in items -%}
      <li{{ item['#wrapper_attributes'] }}>{{ item }}</li>
    {%- endfor -%}
  {%- if list_type == 'ul' -%}
    </ul>
  {%- else -%}
    </ol>
  {%- endif %}
{% endspaceless %}

Remaining tasks

• Remove the title from theme_links
• Move the class from the wrapper div onto the ul itself, and delete the wrapper div
• Update all CSS to reflect the new location of the class

User interface changes

None.

API changes

Call theme('links') when you need a wrapper div and/or a title.
Call theme(item_list) when you only need a list.

Related

#311011: [PP-1] Replace links.html.twig with item-list--links.html.twig
#2032645: Replace calls to theme('item_list') with calls to theme('links') for links, when a heading or wrapper div is warranted
#891112: Replace theme_item_list()'s 'data' items with render elements
#1777326: Replace theme_links() with theme_item_list()
#1910996: Update theme_item_list to call theme_ol or theme_ul
#1980004: [meta] Creating Dream Markup

Problem/Motivation

It seems there is no Action plugin to create content translations.
There could be plenty of uses cases, where such Action is needed.
- Just testing multilingual for existing not-translated content
- Move translations to a new language - complete or partial
- The new multilingual structure needs existing/created translation
- ECA models to translate content
- Build multilingual Demos
- ETC ...

Also there could be other contrib needs that could be used in the new Drupal CMS approach / Recipes - Out of the box tools for Site/Content maintainers:
- ECA
- VBO action
- Maybe AI or AI with ECA for translations

Steps to reproduce

- "Try to create content translations with an action"

Proposed resolution

Within Content Translation module
- Translatable Action Deriver
- Configurable Action Plugin for Creating Content Translations
-- Source language - what language should be used as source for new translations
-- Target languages - the languages to create translations for.
-- Others if needed - ex. update/override if translation exists, unpublish option ... etc
- Tests

Remaining tasks

- All above

User interface changes

- No changes if the Actions are not "configured"

Introduced terminology

- Create/Add Content Translation Action

API changes

- This will not change the existing API, but uses the existing API to bring Content Translation Action.

Data model changes

--

Release notes snippet

--

Problem/Motivation

If for some reason, the notifications.email value is a string, it will produce an error on the update settings page.

Steps to reproduce

1. drush -y cex
2. Edit update.settings.yml and change notifications.email to a string. It is an array after a fresh install of Standard
3. drush -y cim
4. Go to admin/reports/updates/settings

The website encountered an unexpected error. Please try again later.
TypeError: implode(): Argument #1 ($pieces) must be of type array, string given in implode() (line 92 of core/modules/update/src/UpdateSettingsForm.php).
implode('', NULL) (Line: 92)
Drupal\update\UpdateSettingsForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 534)
Drupal\Core\Form\FormBuilder->retrieveForm('update_settings', Object) (Line: 281)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 169)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 68)
Drupal\simple_oauth\HttpMiddleware\BasicAuthSwap->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 49)
Asm89\Stack\Cors->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 718)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Proposed resolution

Change '#default_value' => implode("\n", $notification_emails), for '#default_value' => isset($notification_emails) ? implode("\n", $notification_emails) : NULL,

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

We use serialized columns in many places in core where JSON encoded arrays could be used. This can lead to security vulnerabilities in some contexts and we should move away from it if possible.

Where it is not possible, we should use the "allowed_classes" option for unserialize to reduce risk: https://www.php.net/manual/en/function.unserialize.php

Proposed resolution

Audit core to find instances of serialized columns, and determine where moving to JSON is possible.

In this issue or a follow up:

1. Deprecate SerializedColumnNormalizerTrait and friends in favor of killing unserializes
2. Write a PSA to tell people to fix their custom normalizers that use unserialize, and call out unserialize generally as probably a bad practice

Remaining tasks

See above.

User interface changes

None.

API changes

TBD.

Data model changes

TBD.

Release notes snippet

TBD.