Problem/Motivation

In #3118147: [meta] Set Drupal 10 platform and browser requirements six months before the release we're setting Drupal 10 platform and browser requirements.

Due to release cycles, the MySQL and sqlite version requirements are unlikely to change much for Drupal 10, however it already looks more clear what we should raise them to in Drupal 11.

Proposed resolution

Define some 'not less than' minimum version requirements for Drupal 11.

• PHP 8.2, 8.3 ?? [needs issue]
• Mysql 8 and MariaDB 10.4: #3215207: [policy] Require MySQL 8.0 (increased from 5.7) or MariaDB 10.5 (increased from 10.3) for Drupal 11
• sqlite 3.27? [needs issue]
• PostgreSQL? [needs issue]
• Composer requirements?
• Browser requirements?

In Drupal 10

1. #3267879: [meta] Add compatibility for the latest major and minor versions of dependencies to Drupal 10
2. #3265680: Deprecate dependencies, libraries, modules, and themes that will be removed from Drupal 11 core

In Drupal 11

1. #3214954: [meta] Set Drupal 11 platform and browser requirements at least six months before the release
2. Set and address requirements for tagging 11.0.0-alpha1.
3. Set and address requirements for tagging 11.0.0-beta1.
4. Additional betas as needed

Currently, theme_fieldset() uses empty() to determine whether or not to display a title for the fieldset. This means that a #title such as a zero will not be displayed. The attached patch converts #title to a string and displays the title unless the string is the empty string.

Steps to reproduce: Create a fieldset with a title of zero. It will not appear, but it should.

Problem/Motivation

Trying to create sample nodes found the issues linked.

Proposed resolution

How do you test random?

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

When creating a view through the UI (with a wizard), it seems the query type saved with the view will always be set to views_query, even if the base table uses another query plugin.

As far as I can see, this is the fault of WizardPluginBase::defaultDisplayOptions(), which is hard-coded to always set the query type to views_query, without looking at the base table's data (which it does for something else, so it's definitely "allowed"). And since it's not actually possible to edit the used query plugin, once set it will never be changed (I think).

Since the view internally still looks at the base table data for loading the right query plugin, this isn't that much of a problem, but it will to config schema validation errors, since the wrong type is used for the query options.

If you try the Top Search Phrases report (admin/reports/search), and click on the Message column to sort by the message, the messages are not sorted alphabetically. See screen shot.

I have also tried clicking repeatedly to change from forward to reverse sorting order, and the sort order does not change.

Other "top" reports do not seem to have this same problem, just the top search phrases report.

Problem/Motivation

The Entity Reference field has two display widgets: "Autocomplete" and "Autocomplete (Tags style)".
Both widgets allow users to add new taxonomy terms to a vocabulary as long as "Create referenced entities if they don't already exist" is enabled on the edit tab of the field. Terms cannot be added if that tick box is not ticked.

Proposed resolution

Since there doesn't seem to be any difference in the functionality of the two widgets "Autocompelete (Tags style)" could be removed.

Remaining tasks

User interface changes

API changes

Problem/Motivation

Create view with attached views.view.test.yml

Schema fails to validate. For example install the config_inspector module and run "drush inspect_config"
views.view.test:display.feed_1.display_options.defaults.sitename_title missing schema

Attach patch fixes it

Steps to reproduce

Steps to reproduce:

1. Create view show content of type all
2. Create a page and include an RSS feed
3. Edit the feed display, edit title for "this feed (override)" and enable "Use the site name for the title"

From #8

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

I just noticed that when an admin sends an email to a user, it has this message:

Brad Landis (site/user/1) has sent you a message via your
contact form (site/user/12/contact) at siteName.

If you don't want to receive such e-mails, you can change your settings at
site/user/12.

Ironically, even if you change the settings, the admin can still contact you, which was the case for this email. If the admin user sends the email, this message should not be included.

Problem/Motivation

I tried to identify if a checkbox / radio is part of checkboxes / radios. For proper form theming I require to add a CSS class to single form elements that are of type checkbox / radio, but not if these checkbox / radio is part of a group of checkboxes / radios.

After long debugging I found \Drupal\Core\Render\Element\Checkboxes class, but it is far away from doing something reliable for this themers situation. My findings have shown that there are no good keys in checkbox/radio render arrays that indicate if the element is a checkbox / radio of checkboxes / radios - except abusing some other keys like:

1. #error_no_message = TRUE
2. #weight =
   • data type integer (value = 0) - if a single checkbox
   • data type float (value = 0.001+) - if multiple checkboxes

Proposed resolution

Add key '#is_group_of_elements' = TRUE to the element to indicate that a checkbox/radio is part of a checkboxes/radios group.

Remaining tasks

Patch
Review
Commit

User interface changes

None

API changes

No breaking change, just an addition.

Data model changes

None.

To reproduce:

- create a reference field, say on article nodes
- set its widget to autocomplete
- create a new article node
- enter one node title in the widget and let it autocomplete
- enter a comma and start typing another node title
- the widget lets you do this: it should not.
- save the node
- the node saves: it should not. The form should fail validation
- edit the node: only the last entered node title is shown
- check the DB: only the last entered node was saved in the field value

hi ! i had build profiles setup install system Drupal . My database installed successful in step "Setup database" . I have error when i submit form step "Configure site" ..this show error"SQLSTATE[HY000]: General error: 1364 Field 'wid' doesn't have a default value" . I posted issues hope someone guide for me how to do fix error this ? Thanks

Problem/Motivation

When configuring password behaviour on the registration form, there is no way to force the rendering of the password fields on the registration form if e-mail confirmation is enabled.

An option to configure / force the password fields on the user registration form, while e-mail verification is enabled, might offer a way for site owners to alter the process and make it fit more to their case. (flexibility++)

There is a module that offers this behaviour in Drupal 7, called User Registration Password, the current concept patch started with code that's partially based on this module, but evolved a bit beyond this.

Proposed resolution

Develop a patch that offers minimal functionality. Patch exists, see #58.

Remaining tasks

• Cleanup. Done
• (novice) document steps to test/reproduce (how to: http://drupal.org/node/1468198)
• (novice) manual testing (how to: http://drupal.org/node/1489010)
• (novice) Remove that 1 whitespace error. Done (how to: http://drupal.org/node/1487976)
• (novice) Improve text on checkbox and help text. Done. See #49 (how to make patch: contributor task: http://drupal.org/node/1424598)
• Writing tests. (how to: http://drupal.org/node/1468170)
• Improve tests. (how to: http://drupal.org/node/1468170)
• More testing.
• (novice) Update / create new screenshots after pull. Done. (a new option was added on this page)

User interface changes

• Adds 1 checkbox on the 'admin/config/people/accounts' page.
• The patch will add 2 extra e-mail templates for sending a welcome and activation e-mail.

API changes

• Adds 1 new variable: 'password_register'.

Screenshots

Before:

After:

First screenshot:

Second screenshot:

Possible checkbox combinations:

[X] Require e-mail verification when a visitor creates an account.
[_] Require people to choose a password during registration.
This is the first screenshot, people are not able to set a password during registration, because verification is enabled.

[X] Require e-mail verification when a visitor creates an account.
[X] Require people to choose a password during registration.
This is the second screenshot, people are required to set a password during registration, while verification is enabled.

[_] Require e-mail verification when a visitor creates an account.
[..] Require people to choose a password during registration.
No separate screenshot, but this is the same as the second screenshot, users need to set a password during registration and are directly authenticated after submit. [..] is the disabled checkbox (via #states).

Notes

This patch overrides the 'status' on the submit form for new users and set the status to '0' (disabled). This makes it possible to facilitate our new option and functionality with minimal changes to the existing code.

The current patch also implements a change in user_pass_reset() to facilitate re-sending password_register activation e-mails to users that never logged in yet. (and also didn't receive the first activation e-mail.) They can re-request it via the password reset page.

For Drupal 8 the current patch works, but while it does already improve the account options a bit, some wonder if we should implement this as-is, without implementing some new account status workflow first.

For Drupal 9 we might want to think about refactoring the workflow even more, really decouple the password option from the 'verify' code, and maybe even implement a workflow for accounts, but most people agree to continue with the current patch / idea and focus on more / bigger changes in D9.
(possible future issue: Decouple 'email verify' and 'password' options.)

Original report by finalternatives

Hi, I run a daily news site and have been getting a lot of complaints about people who say it is confusing to log in using the temporary password. Is it possible to have people choose their own password when signing up? Ideally they would then receive an email telling them to click on the link to verify the account. My guess is that people log in the first time and then are too lazy to change the password, and when they return to the site they can’t log in again.

Does anyone have any other ideas for streamlining the registration/login process to make it more user friendly?

Problem/Motivation

When using the field group module, groups that contain required fields are not styled to have the red asterisk to denote that group has required fields. The form-required class is in the mark, but no styles for it.

Steps to reproduce

1. Added fields to a node that are required
2. Create fields groups
3. Ensure the Mark group as required if it contains required fields. option is selected for a group
4. Observe when creating content that the red asterisk is missing

Proposed resolution

Update the styles to account for this. The core/themes/claro/css/components/form.pcss.css has some styles already for the form-required class, but they are too specific. I would think making this style selector less specific would fix it, but there could create issues if the after pseudo element is intended for other use.

This issue is follow-up to How to set original language for views?.

I installed a second language (Swedish) and set it as default in /admin/config/regional/language.
Now all my views suddenly show Swedish as original language, which means I can not translate them to Swedish.
It is not recommended to change the default language on a working site.
How do I change them back to English?

The biggest problem for me appeared if I trying to translate contrib's views. I edit Svenska (original) and change strings to Svenska, and all is OK for a while. But suddenly at one point on time this changes are reseted.

What should I do?

This is to decide if views should filter results by the current page language by default (but still be configurable to not filter by language).

Problem/Motivation

Views has a system in order to render fields in different languages. Either it's determined from a langcode which is part of the result, or it's taken from the current content / interface language, or simply a hardcoded langcode.

While the basic case works fine, the rendering by langcode of the current row [which is the default in Views] does not support using a relationship.

Example:

• Add a text field to the User entity, and edit a user account to populate it.
• Create a node from this author.
• Create a node view, displaying fields (not teasers)
• Add the author as relationship
• Add the text field from User to the display
• Select the translation to be based upon the row language [default setting]

You'll end up in an exception similar to this [shown exception is from a Taxonomy relationship, but User exception is similar]:

Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1052 Column 'langcode' in field list is ambiguous: SELECT node_field_data.title AS node_field_data_title, node_field_data.nid AS nid, node_field_data.langcode AS node_field_data_langcode, taxonomy_term_field_data_node_field_data.name AS taxonomy_term_field_data_node_field_data_name, taxonomy_term_field_data_node_field_data.vid AS taxonomy_term_field_data_node_field_data_vid, taxonomy_term_field_data_node_field_data.tid AS taxonomy_term_field_data_node_field_data_tid, users_field_data_node_field_revision__users.uuid AS users_field_data_node_field_revision__users_uuid, taxonomy_term_field_data_node_field_data__taxonomy_term_data.uuid AS taxonomy_term_field_data_node_field_data__taxonomy_term_data, node_field_data.created AS node_field_data_created, users_field_data_node_field_revision.uid AS users_field_data_node_field_revision_uid, langcode AS langcode FROM {node_field_data} node_field_data LEFT JOIN (SELECT td.*, tn.nid AS nid FROM {taxonomy_term_field_data} td LEFT JOIN {taxonomy_index} tn ON tn.tid = td.tid WHERE (td.vid IN (:db_condition_placeholder_1)) ) taxonomy_term_field_data_node_field_data ON node_field_data.nid = taxonomy_term_field_data_node_field_data.nid INNER JOIN {node_field_revision} node_field_revision ON node_field_data.vid = node_field_revision.vid LEFT JOIN {users_field_data} users_field_data_node_field_revision ON node_field_revision.uid = users_field_data_node_field_revision.uid INNER JOIN {users} users_field_data_node_field_revision__users ON users_field_data_node_field_revision.uid = users_field_data_node_field_revision__users.uid INNER JOIN {taxonomy_term_data} taxonomy_term_field_data_node_field_data__taxonomy_term_data ON taxonomy_term_field_data_node_field_data.tid = taxonomy_term_field_data_node_field_data__taxonomy_term_data.tid WHERE (( (node_field_data.status = :db_condition_placeholder_0) )) ORDER BY node_field_data_created DESC LIMIT 10 OFFSET 0; Array ( [:db_condition_placeholder_0] => 1 [:db_condition_placeholder_1] => tags ) in Drupal\Core\Database\Connection->query() (line 581 of core/lib/Drupal/Core/Database/Connection.php).

Proposed resolution

The problem is in the following piece of code:

    $langcode_key = $this->entityType->getKey('langcode');
    foreach (array('data_table', 'revision_table', 'base_table') as $key) {
      if ($table = $this->entityType->get($key)) {
        $table_alias = $query->ensureTable($table);  // HERE
        $this->langcodeAlias = $query->addField($table_alias, $langcode_key);
        break;
      }
    }

This code is trying to add the right 'langcode' field to an entity table in the view, basically by guessing what table it needs to add it to. So, $table is found, in this example, to be {users}. By default views doesn't know how to join from {node} to {users}.
In order to be able to do that, it has to take into account the relationship. Also, the langcode field that is added may need to have a better alias.

The solution is to pass along the relationship and leverage it.

Remaining tasks

Postponed on #2457999: Cannot use relationship for rendered entity on Views, which may fix this.

User interface changes

API changes

imho there should be a way to change the constants defined for the system requirements
as 'DRUPAL_MINIMUM_PHP' or 'DRUPAL_MINIMUM_PHP_MEMORY_LIMIT'.
there could be some complex install profiles that requires "more power" from the system.
for example there's a Commerce Kickstart issue about this : #1763632: The install needs to check Kickstart requirements before starting.

Hello all, it’s time for the weekly 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 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
• Statistics, Google spreadsheet

Next video meeting 2022-07-07 2100Z (tentative)

The hope is that most or all of the maintainers will attend. We will try to focus on longer-term goals than in the weekly meeting.

Hello all, it’s time for the weekly 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 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
• Statistics, Google spreadsheet

Next video meeting 2022-07-07 2100Z (tentative)

The hope is that most or all of the maintainers will attend. We will try to focus on longer-term goals than in the weekly meeting.

0️⃣ Who is here today? What is the most frustrating thing about working with Drupal?

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 help. Give us some idea of what you would like to do: documentation, code review, testing, project management, ...

5️⃣ Previous minutes.

6️⃣ Announcements

7️⃣ Add content in tests only when needed (NR) (edited) 

8️⃣ $migration_dependencies has inconsistent structure

9️⃣ Patches vs. MRs

1️⃣0️⃣ Wrap up