Problem/Motivation

If a column in a view has the option "Add default classes" turned off, then its header and data cells get the same classes as the prior column. This can lead to more than one column seeming to be "active" for sorting, and other possible problems with incorrect classes being applied.

Steps to reproduce

Install the attached view. In the views UI, note that the first field (Title) has "Add default classes" turned on, whereas the second field (Authored On) has it turned off. This results in the Authored On field getting the is-active class when it should not.

Proposed resolution

The bug occurs twice in the views-view-table.html.twig that is part of every theme. The first time is:

<tr>
        {% for key, column in header %}
          {% if column.default_classes %}
            {%
              set column_classes = [
                'views-field',
                'views-field-' ~ fields[key],
              ]
            %}
          {% endif %}

Because column_classes is not reset when column.default_classes (the "Add default classes" option) is turned off, the list of classes is reused from the previous column. The solution is simply to add a line:

<tr>
        {% for key, column in header %}
          {% set column_classes = [] %} {# ADDED THIS LINE #}
          {% if column.default_classes %}

A similar fix must be made further down in the template, where the data cells are generated. The attached patch addresses this problem for all of the themes in core, as well as the default template in Views itself.

It's worth noting that any custom themes that include a version of this template, such as the contrib version of Classy, also need this fix.

Currently we don't track the state of AJAX views. Users trigger reloads, but no state information is logged. Specifically, it is not possible for users to return to a particular state, short of repeating the steps to get there (e.g., load page, click a particular pager link).

Ideally we'd have full browser history support, but that's difficult given the state of jQuery history plugins (sketchy).

An interim approximation would be:

* set a URL fragment when loading by AJAX
* on initial page load, look for a fragment and, finding one, load it.

Problem/Motivation

I'm using a drupal 10.1.1 site that migrated from drupal 7, then 9

Submitting the "Content language and translation" form (ContentLanguageSettingsForm) does not save the "Custom language settings" checkboxes.

Steps to reproduce

In "Custom language settings" section, I have 3 values already checked: Content, Redirect, Url Alias.
If I uncheck them, they remain checked after the submit.
If I check a value that's not selected, it won't be saved after submission.

I wanted to activate translations for the menu. Checking the "Custom menu link" value doesn't change anything.

Proposed resolution

This is not a solution, but to correct my problem I modified the ContentLanguageSettingsForm. I had to set the value "language_alterable" to true for "menu_link_content" settings

Problem/Motivation

There is a first() method in Drupal/Core/TypedData/Plugin/DataType/ItemList.php but no last(), which seem to be a pretty standard and easy method to implement.

Proposed resolution

Something like:

public function last() {
  return $this->get($this->count() - 1);
}

Remaining tasks

• Add new method
• Write Test coverage
• Write Documentation
• Write Release note

Problem/Motivation

Stylelint updated to 15 #3344087: Update Stylelint and Prettier for Drupal 10.1 and use Prettier for formatting PostCSS

But seems we ignore its `Significant changes`:

https://stylelint.io/migration-guide/to-15#significant-changes

Now stylelint only cares about `Code-quality rules` and never cares about `Formatting rules`

That formatting rules removed from our base config
`Removed: 64 rules deprecated in stylelint@15.0.0. For details, see the migration guide.`
https://github.com/stylelint/stylelint-config-standard/blob/main/CHANGEL...

More info: https://prettier.io/docs/en/comparison

Steps to reproduce

Put any bad formatted postcss into any core pipeline and it pass all checkings

Proposed resolution

Use https://github.com/prettier/stylelint-prettier

3 MRs here

1. `proof-of-failures ` explains that after upgrade we don't have formatting errors reported. I downgraded stylelint and stylelintconfig and got pipeline reports about formatting errors which younger than 14-15 stylelint upgrade (UPD + new max-line-length recently removed)

2. `success-on-anything` explains why this ticket is major. Right now any unformatted postcss can appears in core without pipeline reports

3. `3409048-postcss-file-formatting` Fix MR. With stylelint-prettier.
One commit for review config fixes. And other to check what formatter errors it fixes.

Criteria for adding dependencies

1. Maintainership of the package:
Well maintained https://github.com/prettier/stylelint-prettier/activity by existing in core prettier https://github.com/prettier

2. Security policies of the package:
stylelint-prettier has not any reported security issues to date. The library is well documented.

3. Expected release and support cycles:
Looks like 6 month between 2 latest versions.

4. Code quality:
The codebase of stylelint-prettier is well written, well documented.

5. Other dependencies it would add:
stylelint-prettier has one dependency from same maintainer https://github.com/prettier/prettier-linter-helpers and it is already presented in our yarn.lock

Problem/Motivation

Views page with exposed text filter set as required filter will show an empty error message and a form error for the required filter when first loading the page, before you actually have a chance to input anything

Steps to reproduce

A.
- Go to the Content admin view
- Make the title filter to required
- Look at the preview or go to the content admin page

B.
The issue also occurs if you have a filter entered, then click a Reset button.

Proposed resolution

Only show the error after searching without the required filter.

From @nrogers

I found this problem also occurred with a webform plugin we were using and decided hard coding the plugin id types was a bad idea. So I reworked the patch to just test for any input regardless of plugin type. I also moved the code outside of the reset button condition so that it works when the form does not contain a reset button. This does not cause the regression in #77 as it's looking at the form state for the input values instead of the view.

I also added a test to demonstrate the problem

Remaining tasks

Improve testing
Review

Problem/Motivation

The Drupal\Component\Gettext component doesn't appear to have much test coverage (PHPUnit or otherwise).

Proposed resolution

Add some PHPUnit tests!

Remaining tasks

User interface changes

API changes

Problem/Motivation

Hello, when switching to VanillaJS, setting the width of the sticky table header (tableheader.js) broke due to the lack of units of measurement.

Steps to reproduce

Create a table with a sticky header in the view, activate the sticky header and check the width of the sticky header table.
You also need your theme to add the .sticky-enabled class to the table. Therefore, the Claro admin theme from core is not suitable for testing as it does not do this. The Gin theme was used for testing.

Proposed resolution

Add units (px) to the .outerWidth() result.

Problem/Motivation

Execute two ajax requests - the first one has a processing time of e.g. 5 seconds and the second one of 1 second.
What now happens is that the form is processed for the first and for the second request with the initially requested form, but the second request has to be processed with the form generated by the first request, otherwise the new form array and form state generated by the second request will not have the data from the first request and caching them will overwritte the first request which on submitting the form will result in user data loss.

Issue is the chaotic situation that arises on the frontend due to this bug. When the bug occurs, the entire paragraph or brick subform is replaced by unrelated fields. The potential loss in this case is not the saved data, but rather the contributed content.

The main concern discussed in the title and summary is related to the backend aspect of the problem, which should be addressed through validation.

Attaching a patch demonstrating the problem.

Proposed resolution

Subsequent ajax requests have to wait on the previous ones before executing - however we have to still offer the ability that ajax requests could be executed regardless if another ajax request is currently running or not, only ajax requests modifying the form/the form build id have to be put in a queue or something similiar.

We need to solve this both in FormBuilder (not allowing processing of the same form build id twice) on the server side and in ajax.js (wait submitting with the same form build id) on the client side.

Remaining tasks

User interface changes

API changes

Data model changes

Problem / Steps

Using the latest docker image ( 10.2.2 ), the form goes until asking the info about the name for the website, contact and user info.
On submitting that form, it just gets back to the same form, does't show any error.

On the docker service log shows the error:

trace:\n#0 /opt/drupal/web/core/modules/mysql/src/Driver/Database/mysql/TransactionManager.php(31): Drupal\\Core\\Database\\Connection->getClientConnection()\n#1 /opt/drupal/web/core/lib/Drupal/Core/Database/Transaction/TransactionManagerBase.php(278): Drupal\\mysql\\Driver\\Database\\mysql\\TransactionManager->processRootCommit()\n#2 /opt/drupal/web/core/lib/Drupal/Core/Database/Transaction.php(88): Drupal\\Core\\Database\\Transaction\\TransactionManagerBase->unpile()\n#3 [internal function]: Drupal\\Core\\Database\\Transaction->__destruct()\n#4 {main}\n thrown in /opt/drupal/web/core/lib/Drupal/Core/Database/Connection.php on line 306, referer: http://rasp51:8001/core/install.php?rewrite=ok&langcode=pt-pt&profile=standard&id=3&op=start

Ignoring the form and going to the main page, the title for the website is correct, but the login page doesn't accepted the user.

On the Docker service cmd line, you can create the user with "drush uli".

It seems that it isn't able to create new users on a MySQL database from the installation form.

Proposed resolution

Merge request link

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Starter Kit and Umami details.css contain this comment:

/* @todo Regression: The summary of uncollapsible details are no longer
     vertically aligned with the .details-wrapper in browsers without native
     details support. */

This is irrelevant because all browsers support <details> natively now.

Steps to reproduce

Proposed resolution

Remove the comment.

Merge request link

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

These words are all words prefixed with 'un'. Most occurrences are in tests but some are variable names.

Steps to reproduce

1. unassigning
2. unassigns
3. unbans
4. unbundleable
5. unclickable
6. uncollapsible
7. ungenerated
8. unparseable
9. unpromoted
10. unregisters
11. unvalidated
12. unwrapper

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

These three words are mostly used in *.api.php files and other documentation. They are often together so I have grouped them into this one issue.

Steps to reproduce

Proposed resolution

1. anothermodule
2. mydriver - removed from ignore lines
3. mymodule

Merge request link

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Creating this issue so we can backport @douggreen's d7 patch from https://www.drupal.org/project/drupal/issues/2016739#comment-14807613.

Problem/Motivation

While scanning a list of spelling errors and the related files I notices that some words had a significant number of migration files. Since I am familiar with migrate I thought this would be an easy set of words for me.

Steps to reproduce

Proposed resolution

In cases where the word is the name of a database field, the best option is to add an ignore line at the top of the file.
In some files, $mlid is changed to $menu_link_id instead of adding an ignore line and $parent_mlid to $parent_menu_link_id.

1. daycount
2. idconflict
3. imagecache
4. mlid
5. multifield
6. newnode
7. onoff
8. otsikko
9. plid
10. textgroup
11. totalcount

Merge request link

Remaining tasks

Review, especially the variable renaming

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

As mentioned in the parent issue #3238306: [META] Where possible, refactor existing jQuery uses to vanillaJS to reduce jQuery footprint, we are working towards reducing our jQuery footprint. One of the ways to accomplish this is to reduce the number of jQuery features used in Drupal core. We have added eslint rules that identify specific features and fail tests when those features are in use.

There are (or will be) individual issues for each jQuery-use eslint rule. This one is specific to jquery/no-sizzle, which targets the selector extensions provided by Sizzle .

Steps to reproduce

Proposed resolution

Remaining tasks

• In core/.eslintrc.jquery.json Change "jquery/no-sizzle": 0, to "jquery/no-sizzle": 2, to enable eslint checks for uses of Sizzle. With this change, you'll be able to see uses of the undesirable jQuery feature by running yarn lint:core-js-passing from the core directory
• Add the following lines to core/scripts/dev/commit-code-check.sh so the DrupalCI testing script can catch this jQuery usage on all files, not just those which have changed
  

  # @todo Remove the next chunk of lines before committing. This script only lints
  #  JavaScript files that have changed, so we add this to check all files for
  #  jQuery-specific lint errors.
  cd "$TOP_LEVEL/core"
  node ./node_modules/eslint/bin/eslint.js --quiet --config=.eslintrc.passing.json .
  
  CORRECTJQS=$?
  if [ "$CORRECTJQS" -ne "0" ]; then
    # No need to write any output the node command will do this for us.
    printf "${red}FAILURE ${reset}: unsupported jQuery usage. See errors above."
    STATUS=1
    FINAL_STATUS=1
  fi
  cd $TOP_LEVEL
  # @todo end lines to remove

  Add the block about 10 lines before the end of the file, just before if [[ "$FINAL_STATUS" == "1" ]] && [[ "$DRUPALCI" == "1" ]]; then, then remove it once all the jQuery uses have been refactored.

• If it's determined to be feasible, refactor those uses of Sizzle to use Vanilla (native) JavaScript instead.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

As mentioned in the parent issue #3238306: [META] Where possible, refactor existing jQuery uses to vanillaJS to reduce jQuery footprint, we are working towards reducing our jQuery footprint. One of the ways to accomplish this is to reduce the number of jQuery features used in Drupal core. We have added eslint rules that identify specific features and fail tests when those features are in use.

There are (or will be) individual issues for each jQuery-use eslint rule. This one is specific to jquery/no-closest, which targets the jQuery closest function.

Steps to reproduce

Proposed resolution

Remaining tasks

• In core/.eslintrc.jquery.json Change "jquery/no-closest": 0, to "jquery/no-closest": 2, to enable eslint checks for uses of jQuery .closest(). With this change, you'll be able to see uses of the undesirable jQuery feature by running yarn lint:core-js-passing from the core directory
• Add the following lines to core/scripts/dev/commit-code-check.sh so the DrupalCI testing script can catch this jQuery usage on all files, not just those which have changed
  

  # @todo Remove the next chunk of lines before committing. This script only lints
  #  JavaScript files that have changed, so we add this to check all files for
  #  jQuery-specific lint errors.
  cd "$TOP_LEVEL/core"
  node ./node_modules/eslint/bin/eslint.js --quiet --config=.eslintrc.passing.json .
  
  CORRECTJQS=$?
  if [ "$CORRECTJQS" -ne "0" ]; then
    # No need to write any output the node command will do this for us.
    printf "${red}FAILURE ${reset}: unsupported jQuery usage. See errors above."
    STATUS=1
    FINAL_STATUS=1
  fi
  cd $TOP_LEVEL
  # @todo end lines to remove

  Add the block about 10 lines before the end of the file, just before if [[ "$FINAL_STATUS" == "1" ]] && [[ "$DRUPALCI" == "1" ]]; then, then remove it once all the jQuery uses have been refactored.

• If it's determined to be feasible, refactor those uses of jQuery .closest() to use Vanilla (native) JavaScript instead.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

As mentioned in the parent issue #3238306: [META] Where possible, refactor existing jQuery uses to vanillaJS to reduce jQuery footprint, we are working towards reducing our jQuery footprint. One of the ways to accomplish this is to reduce the number of jQuery features used in Drupal core. We have added eslint rules that identify specific features and fail tests when those features are in use.

There are (or will be) individual issues for each jQuery-use eslint rule. This one is specific to jquery/no-parents, which targets the jQuery parents function.

Steps to reproduce

Proposed resolution

Remaining tasks

• In core/.eslintrc.jquery.json Change "jquery/no-parents": 0, to "jquery/no-parents": 2, to enable eslint checks for uses of jQuery parent(). With this change, you'll be able to see uses of the undesirable jQuery feature by running yarn lint:core-js-passing from the core directory
• Add the following lines to core/scripts/dev/commit-code-check.sh so the DrupalCI testing script can catch this jQuery usage on all files, not just those which have changed
  

  # @todo Remove the next chunk of lines before committing. This script only lints
  #  JavaScript files that have changed, so we add this to check all files for
  #  jQuery-specific lint errors.
  cd "$TOP_LEVEL/core"
  node ./node_modules/eslint/bin/eslint.js --quiet --config=.eslintrc.passing.json .
  
  CORRECTJQS=$?
  if [ "$CORRECTJQS" -ne "0" ]; then
    # No need to write any output the node command will do this for us.
    printf "${red}FAILURE ${reset}: unsupported jQuery usage. See errors above."
    STATUS=1
    FINAL_STATUS=1
  fi
  cd $TOP_LEVEL
  # @todo end lines to remove

  Add the block about 10 lines before the end of the file, just before if [[ "$FINAL_STATUS" == "1" ]] && [[ "$DRUPALCI" == "1" ]]; then, then remove it once all the jQuery uses have been refactored.

• If it's determined to be feasible, refactor those uses of jQuery parents() to use Vanilla (native) JavaScript instead.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

I'm creating a contrib Drupal module using the Batch API to create a .zip archive and populate it with some data. The issue is that I cannot find a clean way to start client-side download of the archive once the batch is finished.

Simplified version of my code

I have two main files. The file Form/ExportForm.php that takes some parameters and on submit, calls a service to start the batch and my second main file is Service/BatchService.php. This service handles the whole batch process. Here are the simplified contents of these files:

ExportForm.php

class ExportForm extends FormBase {
    // ...
    public function submitForm(array &$form, FormStateInterface $form_state) {
        $this->batchService->batch_start($form_state->getValue('parameter'));
    }
}

BatchService.php

class BatchService {
    // ...
    public function batch_start($parameter) {
        $archiveName = "archive.zip";
        
        $realpath = \Drupal::service('file_system')->realpath("private://export");
        $zip = new \ZipArchive();
        $zip->open($realpath . '/' . $archiveName);

        // Get data to process
        $data = $this->helperService->getData();

        $operations = [];
        foreach ($data as $element) {
            $operations[] = [
                '...\BatchService::batch_operation_process_element', [$element]
            ];
        }

        $batch = [
            'title' => t('Processing...'),
            'operations' => $operations,
            'finished' => '...\BatchService::batch_operation_finished'
        ];

        batch_set($batch);
    }

    public static function batch_operation_process_element($element, &$context) {
        // Process element and add it to the zip archive.
    }

    public static function batch_operation_finished($success, $results, $operations) {
        if ($success) {
            unlink($results['archivePath']);
        }
    }
}

Already tested solutions

• I've already tried to put a readfile(...) with the correct headers before removing the temp file in BatchService::batch_operation_finished. This solution works for downloading the archive, once it's downloaded, it's removed and it's fine for this. But this solution creates a new issue. Once the file is downloaded, the user isn't automatically redirected to the previous form page. The user stays on the batch loading page at 100%.
• I've tried to create a new BinaryFile response in BatchService::batch_operation_finished. This creates exactly the same behaviour as the last test
• I've tried to do a $form_state->setResponse($binaryResponse); in my Form submit after the batch_start call. This throws an error saying that the requested file in the binary response doesn't exist. To pinpoint this issue, I tried to put a dd('test'); after the call to batch_start and it's executed before the end of the batch process. I think that it's because of the asynchronous behaviour of the Batch API.

Additional information

I searched for issues and solutions but didn't found anything. If someone finds a patch, a solution or another issue answering this question, let me know. Thank you all!

Problem/Motivation

Currently, setting revision user, revision log message, and revision creation time on a new revision is a manual process for every entity type. In Core we have individual implementations for Block Content, Media, and Node. All 3 do things slightly differently. Contrib then has to repeat this process for any entity type that supports revisions and these fields (usually when an entity type implements RevisionLogInterface

Proposed resolution

This can be done generically in entity base classes (ContentEntityBase and EditorialContentEntityBase).

Set revision user, revision creation time, and revision log message based on an entity implementing RevisionLogInterface automatically

Remaining tasks

Framework manager signoff for using user module code in the Core namespace. See #68
Refactor code in EditorialContentEntityBase to use RevisionLogInterface if possible.

User interface changes

None

API changes

Deprecating getRequestTime in Media entity.

Data model changes

None.