Problem/Motivation

#states do not work with 'datetime' form elements:

• Toggling visibility of the form element fails since there's no wrapper container to target.
• Trying to toggle disabled fails since we can't find the nested form elements to disable.
• Trying to toggle "required" fails since we can't find the label to add the right class(es) to.
• ...

Proposed resolution

• Fix datetime-wrapper twig templates to actually generate a wrapper div.
• Update logic in states.js to handle the nested elements like datetime.
• Consistently use <label> not <h4> for the datetime wrapper label. Moved to solving this in #3078334: Datetime and Datelist elements should render as fieldsets

Remaining tasks

1. Land #3078334: Datetime and Datelist elements should render as fieldsets
2. Write and verify automated tests. Complete. See comments #91-102
3. Update code and tests once #3078334 is in
4. Markup review of all the changes to the datetime-wrapper twig templates:
   • System module's default temple - Fixed, but needs final approval.
   • Classy - Decided to leave broken. See #122.
   • Stable - Decided to leave broken. See #122.
   • Bartik - Fixed in #136 - can we do this?
   • Seven - Fixed in #136 - can we do this?
   • Claro - Fixed in #136 - can we do this? Yes. From #admin-ui Slack meeting 2019-11-06: @lauriii "We can make changes to Claro 🎉"
5. JavaScript review of the changes to core/misc/states.es6.js.
6. Other reviews + manual testing (optional).
7. Decide if we can backport to 8.7.x (if so, working patch in #139).
8. RTBC
9. Commit.
10. Unblock child issues.

User interface changes

#states actually works on datetime form elements.

Changes to the datetime-wrapper.html.twig templates (default templates from system and both the classy and stable themes) to:

• Actually include a wrapper div (!)
• Always use <label> not <h4> for the label. The label is generated using the existing core theme templates for form labels (form_element_label). (Now the responsibility of #3078334.

API changes

None.

Data model changes

None.

Original Report

While trying to create a custom field widget containing a "datetime" form element, I discovered that the #states attribute does not work on it.

Some states can be achieved with a workaround: put the datetime element in a container, and put the #states on the container. But this is obviously no clean fix, and it doesn't work for all states. (Works for "visible" for example, but not for "required".)

I was not able to figure out why this is not working, but I noticed that there have been a lot of issues regarding the #states attribute in the issue tracker. Most of them for were for specific elements like submit buttons, select elements with multiple values, ...

Problem/Motivation

In order to be able to cache the rendered output of views result rows, we need support for it when we render entity operation links, see the https://qa.drupal.org/pifr/test/1022293 test failure.

Steps to reproduce

• I added a new content type.
• Role X has "edit own" permissions for this content type, but no other node permissions except view published content.
• User A and User B both have Role X.
• Admin user creates two nodes of the new content type, and makes User A the author of one node, and User B the author of the other node.
• View is created to display all nodes of the new content type; the view includes the Operations Links field.
• When Admin is logged in, the operations links (Edit, Delete) are available in the view for both nodes (which is the expected behavior).
• User A logs in, and the Edit link is available in the view only for the node that has User A as author (which is the expected behavior).
• User B logs in, and the Edit link is available in the view only for the node that has User A as author, when it should be for User B as author.

Taken from #2653690: Operations links field in Views fails between users with "edit own" user permissions

Proposed resolution

Add an access key to each entity operation which contains an AccessResult object to determine whether the user has access to the operation. Use this to apply access to the rendered link, and bubble cacheability from the AccessResult object to the link.

Remaining tasks

Patch review

Problem/Motivation

There are a couple unwritten rules around how to make a patch for the current minor version, for example use underscores for method names.

Proposed resolution

• Use underscores in front on new method names to avoid conflicts ...
• Try to always make the least amount of changes
• meh

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Follow-up to two Forum related issues

• Term migrations: #2903007: [D7] Forum containers are migrated as forums
• Vocabulary migrations: #2914249: Translated forum vocabulary migration creates duplicate forum vocabularies

Clean Forum specific logic from Term migrations

From comment #56:

Separately, it feels super grody to the max and decidedly un-tubular and non-radical to shove a bunch forum logic in the taxonomy term migrations. Maybe we could also get a non-critical follow-up to make Forum a sub-class of Term so we can better encapsulate the one-off logic here.

And comment #59:

I'm wondering if the forum migration could be a secondary migration (i.e. allow taxonomy to migrate the terms, then have forum get the forum/container metadata from the source site, load the terms already migrated and save the field values etc.).

Clean Forum specific logic from Vocabulary migrations

From comment #18

We should open a follow-up to move this logic into a Forum-specific variant of this plugin. Forum could even swap in its own implementation of the plugin (using the ol' plugin hijacking technique) which implements this logic.

And comment #13

Move the process plugin from Taxonomy to Forum.
Set the forum_vocabulary source property somewhere other than the d6_taxonomy_vocabulary and d7_taxonomy_vocabulary source plugins. I am not sure what the best way is, but we must have an event or an alter hook that lets us modify a row.
Implement hook_migration_plugins_alter() to insert the process plugin into 6 migrations, and remove the corresponding step from those migrations.

I am not sure it is worth the effort, but it would have the effect of simplifying the code that is left behind when we remove the Forum module.

Similar: the code related to the is_container source property (set in the d7_taxonomy_term and d7_taxonomy_term_entity_translation source plugins) and the forum_container taxonomy field (boolean?) should be moved to the Forum module

Steps to reproduce

Proposed resolution

Remaining tasks

Discuss

User interface changes

API changes

Data model changes

Release notes snippet

Hello all, it’s time for the biweekly migration subsystem meeting. The meeting will take place in slack in various threads
This meeting:
➤ Is for core migrate maintainers and developers and anybody else in the community with an interest in migrations
➤ Usually happens every second Thursday and alternates between 1400 and 2100 UTC.
➤ Is done on the #migration channel in Drupal Slack (see www.drupal.org/slack for information).
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to. See the parent issue for an idea of the typical agenda.
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

Core migration issues

• RTBC
• NR
• all open
• Needs subsystem maintainer review
• Statistics, Google spreadsheet

Next video meeting 2023-07-27 2100Z (tentative)

0️⃣ Who is here today?

1️⃣ What should we talk about today? Suggest topics here and I will add threads. I will also check for comments on the issue for today's meeting.

2️⃣ Action items. To be added later.

3️⃣ Statistics

4️⃣ Comment in this thread if you are looking for ways to contribute. Give us some idea of what you would like to do: documentation, code review, testing, project management, ...

5️⃣ Previous minutes.

6️⃣ Announcements

7️⃣ Consolidate code in the migrate_drupal module.

8️⃣ Add XPath-style filtering ability in JSON data parser plugin

9️⃣ Expose full set of debugging data in migrate_message table (filterable/searchable)

Running PHPStan on *all* files.
 ------ -------------------------------------------------------------------------------------- 
  Line   core/modules/migrate_drupal_ui/tests/src/Functional/MigrateMessageControllerTest.php  
 ------ -------------------------------------------------------------------------------------- 
  49     Missing call to parent::setUp() method.                                               
 ------ --------------------------------------------------------------------------------------

1️⃣0️⃣ Change plugin class for comment/user migration to the standard migration plugin class

1️⃣1️⃣ Allow process plugins to flag a row to be skipped (edited) 

1️⃣2️⃣ Wrap up

Participants:

Problem/Motivation

Numeric views filter (\Drupal\views\Plugin\views\filter\NumericFilter) and all child filters (Date, SearchApiDate, etc) throw a php notice when using grouped exposed filters with a group identifier that doesn't match the filter identifier.

Notice: Undefined index: value in Drupal\views\Plugin\views\filter\NumericFilter->acceptExposedInput()

Since PHP 8 this is upgraded to an error:

TypeError: Cannot access offset of type string on string in Drupal\views\Plugin\views\filter\Date->acceptExposedInput()

Steps to reproduce

(require updates)

1. Install Drupal standard profile
2. Edit the default Content view at /admin/structure/views/view/content
3. Add a "Changed" filter
4. Select "Expose this filter to visitors, to allow them to change it"
5. Select "Grouped filters"
6. Change the "Filter identifier" value from "changed" to "date"
7. Set the Grouping 1 label to "Last week", operator to "Is greater than", value type to "An offset from ..." and value "-7 days"
8. Press Apply and then Save
9. Navigate to /admin/content
10. Set the "Changed" filter to "Last week" and press "Filter".

Proposed resolution

Update \Drupal\views\Plugin\views\filter\NumericFilter::acceptExposedInput to target the exposed group identifier as per patch in #48.

Remaining tasks

1. Add an automated test;

Problem/Motivation

This is the meta-issue for fulfillment of deliverables for the winning "Pitch-Burgh" proposal shown here. It will be updated as subtasks are identified/completed.

Remaining tasks

• Implement #3031367: Introduce "schematic" normalizers, including any requisite policy decisions for core to use JSON-schema for normalized representation of field data structures. This is the core API that will enable contrib representations of these schemas.
• Gain community/existing ecosystem maintainer consensus on issues summarized in #3258113-5: [META] Future of Schemata/Compatibility with other ecosystem modules. The goal is either new major versions of exisitng contrib schema modules or (more likely?) a new, greenfield module to represent core entity & field data exposed by JSON:API via OpenAPI 3.x.
• Complete IS and engage community & relevant core maintainers on #3343634: [META] Add "json" as core data type for Schema API and requisite child issues for Drupal to ship JSON field data type definitions for all supported database engines.
• Complete IS and MVP implementation of #3276818: [META] Add support for JSON field queries in entity queries, querying JSON fields supported by core with entity query.

Problem/Motivation

#3357583: [Ignore] In space (and/or this issue), no one can hear patches scream V

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

On the first iteration of the prototype from https://www.drupal.org/project/drupal/issues/3343940, we noticed that the way that we chose to represent the available field types was overwhelming. One of the ideas we had was to try to come up with a better grouping of the field types, to hide some of the complexity.

Proposed resolution

Group fields together to make it less overwhelming based on the findings from https://www.drupal.org/project/drupal/issues/3346539#comment-14999770

Remaining tasks

User interface changes

Fields

"Subfields"

API changes

Release notes snippet

Problem/Motivation

The label for Descriptions fields are not consistent throughout the UI.

Proposed resolution

Change the Description field label at /admin/structure/menu/add to 'Description'
Change the Description field label at Add custom block to 'Description'

Problem/Motivation

When creating a new Content type, the button text is: 'Save and manage fields'
When creating a new Comment, Media or Block types, the button text is: 'Save'

Proposed resolution

Proposing that we have two separate buttons on each entity type add form:
#1 'Save', which directs users back to the entity type overview page
'#2 Save and add fields', which directs to the Manage fields page

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

On https://www.drupal.org/blog/drupal-10-0-0 it states that "Drupal 7 support was extended until November 1, 2023, [...]". This is now incorrect and should be 5 jan 2025 (as per https://www.drupal.org/psa-2023-06-07 ). Now I know that the content type is a blog and therefor the content might be out of date, but it doesnt feel like a blog, more a newswire. So could we please change the eol date of d7 to reflect the current changes?

Proposed resolution

change eol d7 date.

Problem/Motivation

As part of the final merge of Help Topics into Help
#3037230: Finalize the merge of Help Topics into Help
once it is stable, we need to move all of the classes that are currently in Help Topics module into the Help module, leaving behind a BC layer (except for test classes, which do not need to support BC).

Proposed resolution

- move classes, config and topics
- update hooks (install schema and fix config) & test
- disable help_topics if enabled (debatable)

Remaining tasks

- discuss transition
- finish patch
- review/commit

User interface changes

- Help topics available in Help module

API changes

- TBD

Data model changes

- new table help_search_items

Release notes snippet

The Experimental Help Topics module has moved to stable and been subsumed by the existing Help module. An update path will uninstall the help topics module and leave behind an empty shell. The Help Topics module should no longer be used, the functionality has been moved to the existing Help module.

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-is, which targets the jQuery is function.

Steps to reproduce

Proposed resolution

Remaining tasks

• In core/.eslintrc.jquery.json Change "jquery/no-is": 0, to "jquery/no-is": 2, to enable eslint checks for uses of jQuery css(). 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 is() 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-css, which targets the jQuery css function.

Steps to reproduce

Proposed resolution

Remaining tasks

• In core/.eslintrc.jquery.json Change "jquery/no-css": 0, to "jquery/no-css": 2, to enable eslint checks for uses of jQuery css(). 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 css() to use Vanilla (native) JavaScript instead.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Drupal\Core\Entity\ContentEntityInterface says in the docs:

When implementing this interface which extends Traversable, make sure to list
IteratorAggregate or Iterator before this interface in the implements clause.

Drupal\Core\Entity\FieldableEntityInterface has the same doc section.

However FieldableEntityInterface does not seems to extend \Traversable so either (1) it should, or (2) this code section should be removed.

This change seems as old as issue #2275659 Perhaps a copy and paste error?. https://www.drupal.org/project/drupal/issues/2275659#comment-8857705

Proposed resolution

Remove this doc from FieldableEntityInterface since it only applies to ContentEntityInterface.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Problem/Motivation

From the eternal random failure gold mine that is the qa runs (https://www.drupal.org/node/3060/qa):

There was 1 error:

1) Drupal\Tests\ckeditor5\FunctionalJavascript\CKEditor5AllowedTagsTest::testMediaElementAllowedTags
Behat\Mink\Exception\ElementNotFoundException: Form field with id|name|label|value "filters[media_embed][settings][allowed_view_modes][view_mode_2]" not found.

/var/www/html/vendor/behat/mink/src/Element/TraversableElement.php:207
/var/www/html/core/modules/ckeditor5/tests/src/FunctionalJavascript/CKEditor5AllowedTagsTest.php:386
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:728

https://www.drupal.org/pift-ci-job/2696423

Steps to reproduce

This one had me searching for a while...

Over here I took a screenshot and dumped the HTML when the ElementNotFoundException is thrown.

The screenshot shows that view_mode_2 is actually not present, there's no AJAXing going on, and the page looks (and turns out to be) completely loaded:

(HTML as txt-file is here)

As it turns out, we start the test by going to the 'admin/config/content/formats/add' page in \Drupal\Tests\ckeditor5\FunctionalJavascript\CKEditor5TestBase::createNewTextFormat, do some stuff and then create two new EntityViewModes.

This can be appearantly to slow for the page to pick up on it, or at least sometimes to pick up on the last of the two, which then does not get displayed when we enable the embed media option.

Proposed resolution

Move the creation of the two new EntityViewModes to the front of the test.

Also, as already said in #7, the waitForField without checking its output is basically a convuloted way to add a sleep.

We remove it, replace it with a $assert_session->assertWaitOnAjaxRequest(), since the line before it ($page->clickLink('Embed media')) triggers an AJAX request.

Finally we remove the $assert_session->assertWaitOnAjaxRequest() below the two checkFields in line 387-388, since they don't trigger any AJAX request and waiting on that is useless.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The code managing database transaction is very complex - part of it sits in the Connection class, part of it in the Transaction class, and there's back and forth of calls between the two objects.

This makes hard to implement transaction management in contrib database drivers if they need to deviate from the core implementation. Also when looking at #3348590: Add transaction-related events to the Database API, it's complicated to find the right places to dispatch events.

Proposed resolution

Disentangle the transaction management code, introducing a transaction manager that does all the client operations and deals with the calls stack; reduce code in Connection and Transaction to a minimum i.e. calls to the manager's methods.

In the course of that, fix #3074033: Add a test for Connection::addRootTransactionEndCallback

Deprecate something (???)

Remaining tasks

Review by committers if something we want.
Identify if anything needs to be deprecated.
Change Record
Final Review

User interface changes

NA

API changes

TODO

Data model changes

TODO

Release notes snippet

TODO

Problem/Motivation

Config entities require validation for REST support. Add a generic "machine_name" type and validate the value.

Proposed resolution

Add type: machine_name with validation constraints — with both the regex and length overridable to allow non-standard machine name shapes.

Impact as measured by #3324984: Create test that reports % of config entity types (and config schema types) that is validatable's ConfigSchemaValidatabilityTest (and diff before124.txt after124.txt):

Config entity types

• ⏸️ 0.00% → 0.00% validatable (0 of 30 config types — excludes base types)
• 🆙 24.16% → 31.24% average config type validatability
• 🆙 36.10% → 39.35% validatable property paths (200 → 218 of 554 property paths — this excludes property paths for base types)

Config types

• 🆙 4.61% → 4.76% validatable (29 → 30 of 629 → 630 config types — excludes base types)
• 🆙 25.95% → 26.40% average config type validatability
• 🆙 36.80% → 37.29% validatable property paths (1392 → 1411 of 3783 → 3784 property paths — this excludes property paths for base types)

Remaining tasks

None.

User interface changes

None.

API changes

API addition: machine_name config schema data type

Data model changes

None.