Problem/Motivation

Noticed while reviewing #3259179: Split ckeditor5_alignment CKEditor 5 plugin, to allow for more precise upgrade path.

Alignment controls show up twice! They are present as dedicated toolbar buttons for given type of alignment, then they also present in a dropdown that includes all enabled alignment options.

Aside from this being noisy and feeling a bit "broken", this is especially confusing for non-sighted users that don't have the visual context clues to confirm these are duplicated controls in a slightly different package. It could be misinterpreted as a navigation bug - returning to an already-navigated element. It may also lead to the false impression that the control does something different without the visual cue of an identical icon.

CKEditor 5's default appears to be the dropdown https://ckeditor.com/docs/ckeditor5/latest/features/text-alignment.html

Steps to reproduce

Proposed resolution

1. Keep the dropdown, lose the buttons
2. Make the dropdown configurable (similar to headings), where the user can choose what alignment options will be available in the dropdown.
3. Modify the upgrade path in \Drupal\ckeditor5\Plugin\CKEditor4To5Upgrade\Core::mapCKEditor4ToolbarButtonToCKEditor5ToolbarItem() to instead generate the dropdown, and then also expand ::computeCKEditor5PluginSubsetConfiguration() to generate the appropriate configuration (much like headings).

Remaining tasks

- Implement UI to configure the alignments in the dropdown
- Implement an upgrade path from CK 4 to 5
- Implement an upgrade for already migrated CKE5 configs (to be defined, see #6)
- Implement test coverage both for the functionality and the CKE version upgrade
- Review that all until RTBC

User interface changes

Adds a configuration for the alignments (similarly to what headings does) in the text format configuration page when the alignment dropdown is added to the page.

API changes

The API will need to change in the CKE 4 to 5 upgrade path methods.

Data model changes

Release notes snippet

Problem/Motivation

Symfony allows you to specify _defaults key in your services.yml file. This allows you to specify defaults for all of your services. See https://symfony.com/doc/current/service_container.html

In Symfony it often looks like

# config/services.yaml
services:
    # default configuration for services in *this* file
    _defaults:
        autowire: true      # Automatically injects dependencies in your services.
        autoconfigure: true # Automatically registers your services as commands, event subscribers, etc.
        public: false       # Allows optimizing the container by removing unused services; this also means
                            # fetching services directly from the container via $container->get() won't work.
                            # The best practice is to be explicit about your dependencies anyway.

    # makes classes in src/ available to be used as services
    # this creates a service per class whose id is the fully-qualified class name
    App\:
        resource: '../src/*'
        exclude: '../src/{Entity,Migrations,Tests,Kernel.php}'

    # ...

Whilst autoconfigure is not relevant yet it would be nice for a module to be able to declare all of its services as public: false (if for example it wants to prevent the service locator pattern - yes this is hard is Drupal because plugin managers and events don't work with them but maybe in the future) and autowire will be supported by #3021803: Document and add tests for service autowiring.

Proposed resolution

Implement this by copying code from YamlFileLoader once #3021803: Document and add tests for service autowiring has landed.

Remaining tasks

User interface changes

None

API changes

@todo

Data model changes

None

Release notes snippet

@todo

Problem/Motivation

Modernizr is not necessary for features we uses and D10 browser support

Steps to reproduce

Proposed resolution

Remaining tasks

The following issues must be completed before Modernizr can be removed:

• #3101922: Find replacement for Modernizr touchevent test and deprecate
• #3256549: Deprecate core/drupal.date asset library in 9.4.0
• #3269082: Remove HTML5 details collapse polyfill

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

This is an issue that we haven't had to deal with since the Drupal 6 to Drupal 7 upgrade path, but now we do again.

The following scenarios are broken:

hook_update_N()

system_update_8900() is added to 8.9.x and 9.0.x

[time elapses]

system_update_9100() is added to 9.1.x to support a new feature, it is not backported to 8.9.x

[time elapses]

A critical bug fix which is eligible for backport to 8.9.x, but requires a small update, is committed to 9.1.x.

[dragons emerge from the darkness, volcanos erupt]

If this update is added as system_update_9101() and backported to 8.9.x, then when 8.9.x sites are updated to 9.1.x, they won't run system_update_9000() because their schema version will be higher already.

If this update is added as system_update_8901() in 9.1.x, and 8.9.x, it won't run on 9.1.x sites because their schema version will be higher already.

hook_post_update_NAME()

This is less of an issue, but still a problem:

system_post_update_fix_config() is added to 9.2.x, it is backported to a 9.1.x patch release, and 8.9.x because it's the LTS, but not 9.0.x because it's security-only.

If a site updates from 8.9.x to 9.0.x, then the post update goes 'missing' from the code base. It will then re-emerge when the site updates again to 9.1.x or 9.2.x

Sequential backports to minor branches without skipping a release are OK though for post updates regardless of how far they go back, since they don't interfere with other post updates.

Proposed resolution

tl;dr

Don't add any 9.x-only hook_update_N() to Drupal 9.0.x, Drupal 9.1.x, or Drupal 9.2.x

If we do, and we have to subsequently backport an update to 8.9.x, this is what we need to do instead:

1. Add the update as system_update_8901() in Drupal 8.9.x. This updates sets a semaphore in state or key/value like system_update_8901_run.

2. Add the update, with nearly identical code, as system_update_9101() to 9.1.x. This update instead of setting the semaphore, checks if we have one, and if so deletes the semaphore and returns early because it's a no-op.

This does not affect modules until they add 9.x-only updates, until then we can continue adding 89** updates and backporting them.

It also doesn't affect post-updates because ordering/dependencies do not matter for those.

To avoid this:

Remaining tasks

There is no actual code to write here, this issue is mainly for documentation and to explore if there are any alternative approaches.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The StatusReport render element uses the REQUIREMENT_INFO & friends constants, but these are defined in core/includes/install.inc. In all the places core uses this render element, that file is included, but if contrib or custom code uses this render element, it will crash, e.g. #3276251: admin/reports/redis crashes if redis is not available.

Steps to reproduce

Proposed resolution

Document on the render element that the file must be included.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

#3231364: Add CKEditor 5 module to Drupal core added CKEditor 5 module to core but it did not add an entry to the MAINTAINERS.txt.

Steps to reproduce

Add bnjmnm, lauriii, and Wim Leers as maintainers for CKEditor 5.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

This issue is to coordinate and track the steps needed to remove color from core to contrib after it is deprecated. See Remove a core module and move it to a contributed project of the deprecation policy.

The removal of color was approved in #2808151: [policy] Move the Color module to a contributed project when Bartik is deprecated

Proposed resolution

Remaining tasks

1. Create a child issue, 'Remove module MODULE_NAME from core'. #3270899: [PP-1] Remove Color module from core
   • The change record for this issue should include a link to recommendations page, https://www.drupal.org/node/3223395#s-MODULE_NAME. (For example, the CR for removing HAL)
   • Tag this issue 'Needs release note.'
   • Remove the module ;-).
   • Remove references from core/phpstan-baseline.neon.
   • Check for references in @todo.
   • Handle migration tests. In all the functional tests in migrate_drupal_ui make sure that MODULE_NAME is not installed. MODULE_NAME should also be removed from the methods getAvailablePaths() and moved to getMissingPaths() in the tests using those methods.
2. Open an issue, 'Ensure that module MODULE_NAME does not get special core treatment' in the packages.drupal.org issue queue to ensure that the composer namespace for the contributed project matches the core one after removal. This is to allocate the drupal/MODULE Composer namespace to contrib module rather than the core module. For example, #3272246: Ensure that aggregator doesn't get special core treatment.
3. Manually test upgrading from the core module to the contrib module.
4. Move core issues for MODULE_NAME module from the core queue to the contrib module.
5. Move all core documentation for MODULE_NAME module to the contrib project.
6. When the issue in https://www.drupal.org/project/project_composer is Fixed update the documentation with the new Composer command.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

It is not necessary to storage information about disabled filters in the config system, because they describe state of system where the config is saved and pollute the config system.

It is also impossible to release a dependency on a module or plugin by disabling it from the filter.

Steps to reproduce

Proposed resolution

Filter disabled filters before config save.

Remaining tasks

Tests?

User interface changes

API changes

Problem/Motivation

The migration plugin block_plugin_id looks up blocks using the hardcoded migration IDs ['d6_custom_block', 'd7_custom_block']:

class BlockPluginId extends ProcessPluginBase implements ContainerFactoryPluginInterface {

  public function transform($value, MigrateExecutableInterface $migrate_executable, Row $row, $destination_property) {
    ...
    $lookup_result = $this->migrateLookup->lookup(['d6_custom_block', 'd7_custom_block'], [$delta]);
    ...
  }

}

As a result the plugin cannot be used if the blocks were migrated by an alternative migration (i.e. not by d6_custom_block.yml or d7_custom_block.yml).

Proposed resolution

Is it possible to turn the hardcoded migration ID's into a configurable value ? The value would default to ['d6_custom_block', 'd7_custom_block'] for backward-compatibility reasons. See patch attached.

Remaining tasks

Review patch attached to this issue. Unless there is another solution ?

Thanks

Problem/Motivation

File field widget could erroneously create multiple empty items under special circumstances. For example, within a multi-step form that excludes the file field on the initial step using the #access render property.

Steps to reproduce

Quick and easy multi-step node form simulation:

1. Create a content type with a file field.
2. Alter the node form to rebuild on submit.
3. Hide file field widget with ['#access' => FALSE] on the element.
4. Open the node form.
5. Remove #access property from the file field widget element.
6. Click submit to rebuild node form.
7. Observe the duplicated empty item (compare with screenshot).

Proposed resolution

Do not create elements for empty items. Empty elements are created after existing items are processed.

Problem/Motivation

A follow up to #2015307: \Drupal\Core\Render\RendererInterface::render() docs do not mention most of the base # attributes, adding default attributes to elements or how rendering works to change the indentation of the docs of \Drupal\Core\Render\RendererInterface::render() to comply with the Drupal API documentation and comment standards. See #34.

I think Making lists in documentation is the relevant section.

Steps to reproduce

Proposed resolution

Fix the indentation.

Remaining tasks

Make a patch
Review
Commit

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

When a drupal form is opened in a dialog, the submit buttons are automatically turned into jquery ui dialog buttons.

Sometimes this is not wanted and the drupalAutoButtons options is supposed to control if this is needed or not. Setting this at FALSE from the PHP doesn't do anything, buttons are still created.

Patch fixes the missing js that makes this option work as expected. This can be tested with the outside-in module. Before patch submit buttons are at the bottom of the dialog styled like jQuery dialog buttons, after the patch they're regular form submit buttons.

Problem/Motivation

- Create decimal field, set precision to 10 (minimum in the UI and scale to 4
- Saving new node with value 19999.0000 succeeds (precision is 5+4 = 9).
- Saving new node with value 99999.0000 fails (same precision as above).

or

- Create decimal field, set scale to anything over 6 (need 8 to store bitcoin values for example). I used 16 as precission.
- Saving new node with value 20.12345678 fails validation while 0.1234567 succeeds.

This is because Drupal\Component\Utility\Number::validStep() returns false. Detailed investigation on this function (which is only used once in Drupal), reveals that the first argument ($value) is received as a string, but $step and $offset are floats. PHP seems to slightly mangle the $step value on the first case above from 0.0001 to 0.00010000000000000001438. Passing the step parameter as a string in the case of decimal numbers maintains the correct precision, and allows a correct approximation calculation.

Proposed resolution

Bypass weak PHP floating-point handling by passing the step as a string.

Remaining tasks

Merge. Commit. Decimals FTW!

User interface changes

None.

API changes

None.

Data model changes

None.

Possible workaround if you need big decimals

Disable this validation by setting the render element #step to 'any'

i.e.

$element['#step'] = 'any';

In the case of fields, you can do

function MYMODULE_form_FORM_WITH_BIG_DECIMAL_FIELD_alter (array &$form, FormStateInterface $form_state) {
  $form['field_some']['widget'][0]['value']['#step']='any';
}

And if you want to target all decimal fields:

/**
 * Prevents validation of decimal numbers
 * @see https://www.drupal.org/node/2230909
 */
function MYMODULE_field_widget_form_alter(&$element, \Drupal\Core\Form\FormStateInterface $form_state, $context) {
  $field_definition = $context['items']->getFieldDefinition();
  if ($field_definition->getType() == 'decimal') {
    $element['value']['#step'] = 'any';
  }
}

Problem/Motivation

A view of users, with sort criteria only sorting on some fields in the user entity... It does NOT sort on creation date, or update date, or most recent login... or anything related to WHEN something happened. Just the content in the user profile.

When a user logs in, and changes a value in their user/UID/edit screen... It changes the sort order of the view.

Those users fly to the top of the view results, but UNDER the first sort criteria.

The first sort criteria is a boolean on the user profile. If its checked, show them first, unchecked below,...

Users who login and edit something move to the top, under that boolean check.

Steps to reproduce

See image above.

user profiles have many fields, some are entity references to taxonomy terms.

the view sorts based on the following.

* A boolean switch
* The weight of a "School" term. (relationship)
* The Weight of a "Major" term. (relationship)
* Last Name
* First Name

When the data was first displayed with this new sort logic, it was correct.

As soon as a user changed a value in their user/UID/edit screen, they popped up to the top of the sort, BELOW the boolean.

This image shows the behavior. The two circled results are user profiles who edited their user/UID/edit screen

The first one is out of order based on last name, but is in the first "school".

The second one, the pink one, should be 2 pages down...

I have tried to change SQL queries and caching... to no result.

Does it have something to do with the relationships on the terms?
we need that to control the sort order based on the weight position for the term -- not the term ID...

The SQL query

SELECT "user__field_phd_candidate"."field_phd_candidate_value" AS "user__field_phd_candidate_field_phd_candidate_value", "taxonomy_term_field_data_user__field_user_school"."weight" AS "taxonomy_term_field_data_user__field_user_school_weight", "taxonomy_term_field_data_user__field_user_major"."weight" AS "taxonomy_term_field_data_user__field_user_major_weight", "user__field_user_last_name"."field_user_last_name_value" AS "user__field_user_last_name_field_user_last_name_value", "user__field_user_first_name"."field_user_first_name_value" AS "user__field_user_first_name_field_user_first_name_value", "users_field_data"."uid" AS "uid", "taxonomy_term_field_data_user__field_user_major"."tid" AS "taxonomy_term_field_data_user__field_user_major_tid", "taxonomy_term_field_data_user__field_user_school"."tid" AS "taxonomy_term_field_data_user__field_user_school_tid"
FROM
{users_field_data} "users_field_data"
LEFT JOIN {user__field_user_major} "user__field_user_major" ON users_field_data.uid = user__field_user_major.entity_id AND user__field_user_major.deleted = '0'
LEFT JOIN {taxonomy_term_field_data} "taxonomy_term_field_data_user__field_user_major" ON user__field_user_major.field_user_major_target_id = taxonomy_term_field_data_user__field_user_major.tid
LEFT JOIN {user__field_user_school} "user__field_user_school" ON users_field_data.uid = user__field_user_school.entity_id AND user__field_user_school.deleted = '0'
LEFT JOIN {taxonomy_term_field_data} "taxonomy_term_field_data_user__field_user_school" ON user__field_user_school.field_user_school_target_id = taxonomy_term_field_data_user__field_user_school.tid
LEFT JOIN {user__roles} "user__roles_value_0" ON users_field_data.uid = user__roles_value_0.entity_id AND user__roles_value_0.roles_target_id = 'student'
INNER JOIN {user__field_user_year} "user__field_user_year" ON users_field_data.uid = user__field_user_year.entity_id AND user__field_user_year.deleted = '0'
LEFT JOIN {user__field_phd_candidate} "user__field_phd_candidate" ON users_field_data.uid = user__field_phd_candidate.entity_id AND user__field_phd_candidate.deleted = '0'
LEFT JOIN {user__field_user_last_name} "user__field_user_last_name" ON users_field_data.uid = user__field_user_last_name.entity_id AND user__field_user_last_name.deleted = '0'
LEFT JOIN {user__field_user_first_name} "user__field_user_first_name" ON users_field_data.uid = user__field_user_first_name.entity_id AND user__field_user_first_name.deleted = '0'
WHERE ((user__field_user_year.field_user_year_target_id = '148')) AND (("users_field_data"."status" = '1') AND ("user__roles_value_0"."roles_target_id" = 'student'))
ORDER BY "user__field_phd_candidate_field_phd_candidate_value" DESC, "taxonomy_term_field_data_user__field_user_school_weight" ASC, "taxonomy_term_field_data_user__field_user_major_weight" ASC, "user__field_user_last_name_field_user_last_name_value" ASC, "user__field_user_first_name_field_user_first_name_value" ASC
LIMIT 25 OFFSET 0

Thoughts?
Thank you!

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The module uninstall form lists all modules in alphabetical order, this means that non-stable modules are mixed in with stable modules.

In #3266397: Highlight non-stable modules on the admin/modules/uninstall form we are introducing the non-stable statuses for modules on the uninstall form.

During a UX calls it was identified that grouping such modules together at the top of the list would be preferable as it would draw more attention to them. This is particularly important for obsolete modules where immediate action may be required.

In #3266397-7: Highlight non-stable modules on the admin/modules/uninstall form it was agreed to push that change to a follow-up issue, this is that issue.

Steps to reproduce

Proposed resolution

For non-stable modules in the module uninstall list, promote those modules to the top of the list so that they appear first, then all other stable modules appear below in the list.

Remaining tasks

User interface changes

Before

After

API changes

None.

Data model changes

None.

Release notes snippet

Not needed.

When the HAL module was moved out of core, the test for DBLogResource was also moved, because it uses the HAL module. This move of the test case was done in #3263654: Move all HAL tests to the module in preparation of removal in D10. The assumption seems to be that because the test used "hal", it was a test OF "hal" - that's not the case. DbLogResourceTest was written to test the DBLogResource, not to test "hal". It happens to use the hal format for the test, but that can easily be changed to json.

DbLogResourceTest should be restored to core D10 and rewritten so it does not depend on the HAL module.

Marking this as "major" because we're supposed to have tests for every feature, and we did have a test for this feature until it was removed.

Problem/Motivation

In our old Drupal 7 site (Bartik admin theme), when editing content, there was a little arrow to adjust the size of a text area field.

In our new Drupal 9 site (Claro theme, but also tested in Seven with same result), when editing content, there is no little arrow to adjust the size of a text area field.

Proposed resolution

Restore the ability to resize textarea boxes. I do not know what this would entail, or even whether this would happen in the theme or somewhere else.

Problem/Motivation

Under the right conditions, the "Insert from Media Library" button in the WYSIWYG editor causes the media library dialog to open off-center. This is jarring at first for the user, but then it re-centers itself if the user scrolls the page or selects a different tab in the media library viewer.

Steps to reproduce

1. Go to Home | Simplytest
2. Click the “Umami Demo” button
3. Wait for the environment to generate
4. Click the log in link in the top right (/user/login)
5. Log into the site (admin/admin)
6. Create a new custom block
   • Admin > Structure > Block layout > Custom block library > “Add custom block” > Basic block (/en/block/add/basic)
7. In the WYSIWYG editor, click the “Insert from Media Library” button
   • Observe the positioning of the modal (expect it to be centered, but this issue positions it off-center toward the right of the screen)
8. If this did not produce the issue, follow the remaining steps to attempt to reproduce it.
9. Disable JS aggregation by navigating to Admin > Config > Development > Performance (/en/admin/config/development/performance)
10. Uncheck the box next to “Aggregate JavaScript files”
11. Save the form
12. Navigate back to the block creation screen (or refresh if you kept this open in a different tab) (/en/block/add/basic)
13. In the WYSIWYG editor, click the “Insert from Media Library” button
14. Observe the positioning of the modal (expect it to be centered, but this issue positions it off-center toward the right of the screen)

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In Drupal 7, when you had an exposed Date filter on a View, and the user selected a start & end time that were both the same day, the View would return all results from that day. That is, the end date was interpreted as 23:59:59 and the start date as 00:00:00 on that day. However, when you do the same thing in Drupal 8, both the min and max filter values are interpreted as 00:00:00, such that only results for precisely midnight are returned.

Steps to reproduce

Create some data with date values, such as nodes with created timestamps. Create a View with an exposed filter on those values, with the operator set to "is between". Set both the min and max filter values to the day of one of the results. Note that the result no longer appears, because the day it occurred is not within the range of the filter.

Proposed resolution

Add a checkbox to the exposed filter configuration allowing the max date to be specified as "inclusive." When that box is checked, change the max value to 23:59:59 on the given date before running the query.

Remaining tasks

Add the checkbox. Rewrite the filter value.

User interface changes

Add the checkbox.

API changes

none.

Data model changes

none.

Release notes snippet

Allow date filters to be inclusive of the specified date.

A number of us agree that it would be useful to allow searching UI strings without case-sensitivity when translating the UI. This should not be too hard to implement.

Depends on #1452188: New UI for string translation being committed.