Problem/Motivation

Currently there are three Installation Profiles: Minimal, Standard and Demo: Umami Food Magazine.

When you install a new Drupal site with the Standard profile, you get three user roles by default: Admin, Authenticated user (logged-in user when this issue is fixed) and Anonymous.

• Admin role: for site building and development purposes and comes with almost every existing permission by default.
• Authenticated/logged-in role: has the same permissions as the Anonymous user (viewing content) plus is able to post comments.
• Anonymous role: for visitors to the site not logged in.

Drupal is a content management system but we don’t have any default user role for creating, editing or managing content.

Proposed resolution

Based on our discovery, this proposal aims to create an out-of-the-box editor role to serve Drupal’s main purpose: manage content.

We propose that this new role is named “Content Editor.”

Installed with the standard profile, this new role will be created with a new set of permissions and options. Our initial proposal for this set is:

• Create and edit new content — articles and pages
• Use the basic HTML text format
• View unpublished content
• Create and edit terms (tags and categories)
• Access the administration theme

Remaining tasks

• Agree on the name and machine name for the new role
• Define the new set of permissions
• Create a patch
• Code Review
• Create tests?

User interface changes

• Roles and permissions screen:
  • Content Editor role will be included.
  • The new permissions for the role will be checked.
• Edit or Create user screens should include the Content Editor role in the options to select the role(s).

API changes

No changes to existing API changes?

Data model changes

No changes to existing data models?

Following from #2908391: Add a rule for expected format of @deprecated and @trigger_error() text we need to fix core to adhere to the two new coding standards.

This issue will fix the @trigger_error() function calls to adhere to standards.
Ideally wait for #3041983: Fix unused imports and update Coder to 8.3.4 so that testing the new sniff will be simpler, but we can use the new coder code by patching it via drupalci - see comment #28. The patch in #28 can be used now to start fixing the standards.

Step 1: Preparation

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

Step 2: Install & configure PHPCS

Install PHP CodeSniffer and the ruleset from the Coder module:

$ composer install
$ ./vendor/bin/phpcs --config-set installed_paths ../../drupal/coder/coder_sniffer

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

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

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

Step 3: Prepare the phpcs.xml file

To speed up the testing you should make a copy of the file phpcs.xml.dist (in the core/ folder) and save it as phpcs.xml. This is the configuration file for PHP CodeSniffer. We only want this phpcs.xml file to specify the sniff we're interested in. So we need to remove all the rule items, and add only our own sniff's rule. Rule items look like this:

<rule ref="Drupal.Semantics.FunctionTriggerError"/>

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

Step 4: Run the test

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

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

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

Step 5: Fix the failures

When the test is complete it will present you a list of all the files that contain violations of your sniff, and the line numbers where the violations occur.

Problem/Motivation

In #3074043: Move simpletest.module DB-related functions to TestDatabase, deprecate we're trying to deprecate top-level simpletest module functions by moving them to Drupal\Core\Test\TestDatabase.

It so happens that we can't test many of our changes, because TestDatabase is mostly static and thus can't be mocked.

Proposed resolution

• Test runners (simpletest.module and run-test.sh) run tests opening TestRun objects that have state and an execution log.
• TestDatabase objects only cares about setting up the SUT database, not the results logging.
• Each TestRun object is associated with a TestRunResultsStorageInterface object, which responsibility is to store permanently the state and execution log of each test run. This interface is storage agnostic, implementations could use a database or anything else.
• SimpletestTestRunResultsStorage is at the moment the only implementation of TestRunResultsStorageInterface, which is using the database and the legacy {simpletest} and {simpletest_test_id} tables for the purpose.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

This task will try to get Drupal 9 installable on PHP8.0 alpha so we can work out issues to address.

Proposed resolution

Make Drupal 9 testable on PHP 8 and PHP 7 at the same time.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Steps to reproduce

1. Go to admin/config/people/accounts
2. Navigate to REGISTRATION AND CANCELLATION > When cancelling a user account
3. Inspect the radio buttons. Seeing that aria-describedby="edit-user-cancel-method--description" which edit-user-cancel-method--description doesn't exists.

Those 3 radio buttons don't have any description. So I think they don't need to have aria-describedby attribute.
For example, in REGISTRATION AND CANCELLATION > Who can register accounts?, the radio buttons don't have aria-describedby attribute since they don't have description.
However, the description below (Users with the Select method ...) is a description of the fieldset wrapper.

This is postponed on #3112249: [backport] Migrate d7 menu translation.

Problem/Motivation

Menu links in Drupal 7 are translated using i18n_menu submodule of the suite i18n, we need to migrate those respecting the language settings. This should be similar to the D6 version, #2225587: Migrate D6 i18n menu links

The D6 patch included a migration for language content menu settings as well. For D7 that was done in a separate issue, #3110669: [backport] Migrate d7 menu language content settings.

Proposed resolution

Ensure that the menu_links migration sets a default value for the langcode. From #3013625: Menu language not properly migrated from D7 localized menu links..

Add two migrations one for localized menu links, d7_menu_links_localized, and another one for translations that are not localized, d7_menu_links_translation.

This migration should also set the state of the menu_links migration to finished.

Remaining tasks

Write a patch
Review
Commit

Issue Summary Updates

The actual cause of recovery mail's token not respecting user account's preferred language is due to the $langcode set in submitForm (UserPasswordForm.php), further detailed discussion can be found at #86287: "reset password" page ignores the user's language selection.

As discussed in #21#22, #23, MailManagerInterface::mail() (which will further invoke user_mail_token) should actually be using the $langcode provided by _user_notify_mail().

Original Problem/Motivation

In the user_mail function, the language manager is set to the preferred langcode of the user.

$language = $language_manager->getLanguage($params['account']->getPreferredLangcode());
$original_language = $language_manager->getConfigOverrideLanguage();
$language_manager->setConfigOverrideLanguage($language);

In some cases if we load config, the mail_config is translated in the language of the user:

$mail_config = \Drupal::config('user.mail');

While loading the token options, an other langcode is set?!

Steps required to reproduce the bug

While sending a "Password Recovery" mail, the mail subject and body is in the language of the user.
The [user:one-time-login-url] token is in another language.

Solution, see patch.

Proposed resolution

Set the correct langcode in $token_options array:

  $token_options = ['langcode' => $language->getId(), 'callback' => 'user_mail_tokens', 'clear' => TRUE];

See Patch.

Remaining tasks

Review patch.

User interface changes

None

API changes

None

Data model changes

None

It is somewhat disconcerting to users who have the 'administer book outlines' permission to see the 'outline' tab and 'outline' fieldset on every single node type, regardless of whether that node type has been configured to be allowed in books. I can see a use-case where that might be a desired feature, but i think its probably relatively rare.

The steps to repeat this are:
with a clean install of drupal,
1) turn the book module on
2) configure book module to only use 'book' content type
3) as admin or a user with 'administer book outlines' permission, create or edit a 'page' node (not a book node)

i would expect that 'outline' would not show for 'page' nodes since only 'book' nodes are set to use outlines.

I created the following patch to gracefully address this issue. The simplest solution I could think of was to create an additional checkbox in the content/book/settings form that when checked restricts book outlines to only the designated book-types. By default this is not checked, so that any drupal installs that might rely on "seeing outline information on all node types regardless of config settings" wont be broken by this patch after upgrading.

Its pretty basic, doesn't change anything by default and so hopefully it will be well received (and help someone too!)

Problem/Motivation

As noted in #3156881-35: Various methods of \Drupal\Core\Database\StatementInterface have changed their signature for PHP 8, the database Statement class is extending from PDO, and is therefore exposed to the changing winds of new PHP versions.

We should have our own Statement envelope instead, encapsulating a PDO (or, potentially, other) lower-level Statement object.

In https://github.com/mondrake/drudbal/blob/master/src/Driver/Database/dbal..., I have an example: the Statement object implemented for the DruDbal driver encapsulates a doctrine/dbal Statement (which is not a PDO Statement).

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Hello all, it’s time for the weekly migration initiative 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 here: https://www.drupal.org/project/drupal/issues/3174626. 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

0️⃣ Who is here today? What is your favorite flavor of ice cream?

1️⃣ What should we talk about today? Suggest topics here and I will add threads.

2️⃣ Action items. To be added later.

3️⃣ Statistics

4️⃣ Documention

5️⃣ MigrateExecutable should catch not only exceptions, but also fatal errors

6️⃣ Move memory management from MigrateExecutable to an event subscriber

7️⃣ Recent successes that we can share.

8️⃣ Add a migration source plugin for JSON:API

9️⃣ DrupalSpoons vs. d.o for Migrate Plus, Migrate Tools, etc.

1️⃣0️⃣ Config schema definitions for plugins aren't applied to their derivatives - Migration plugins

1️⃣1️⃣ Wrap up

Participants:

damienmckenna, larowlan, benjifisher, dinarcon, alison, irinaz, quietone, heddn

Problem/Motivation

The Drupal 7 date module allowed the site builder to configure whether to collect an end date or not:

(This is called 'todate' in the code.)

For example, on my personal site, I have a projectNodeType which has a "time range"date. Example: https://wimleers.com/work/project/ledgrid.

Upon migration, the start value (value) is migrated, but the end value (value2) is dropped

D7

D8 HEAD

That's because this is being migrated to a @FieldType=datetime field in D8 instead of a @FieldType=daterange field in D8!

Proposed resolution

Make \Drupal\datetime\Plugin\migrate\field\DateField detect the todate setting and:

1. expand the process chain to also transform data for @FieldType=daterangeend_value property, instead of only the value property
2. dynamically override the statically computed destination field type: return daterange instead of datetime when appropriate
3. most simple, but perhaps most controversial: change the destination_module key in the @MigrateField annotation to datetime_range instead of datetime. The migration system seems to not have been designed for dynamic conditional edge cases like this one, and the harm of requiring that module to be installed even if unused is minimal; and certainly does not outweigh the data loss that is currently happening.

Remaining tasks

• Fix failing tests.
• Add a new test (and provide a test-only patch).

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

TBD

Problem/Motivation

This issue is postponed on #3000050: Replace \Drupal\Component\Utility\Environment::checkMemoryLimit with a PHP memory checking helper class and service.

MigrateExecutable has a lot of code devote to managing and reclaiming memory, since memory usage is quite relevant to migration. There's nothing wrong with this code per se, but we'd like to remove MigrateExecutable entirely. To that end, let's move all the memory management code into a new internal class (Drupal\migrate\MemoryManager) and have MigrateExecutable's constructor instantiate it.

The new MemoryManager class will be explicitly internal because it is not an API. Eventually we may want to add an interface to it (and possibly plugin-ize it), at which point we can remove the internal designation, but that's all way out of scope for this issue. For now, we just want to remove as much code from MigrateExecutable as we can.

Cool enough I implemented it and replaced my wonky hook_row_alter :-D

I don't like the setMessage but our message "service" logic is just all over and I wasn't sure how to handle it.

Remaining tasks

• Change record - Explain why the threshold is 0.9 and the memory limit is 0.85
• Inject the new EnvironmentMemory class from #3000050: Replace \Drupal\Component\Utility\Environment::checkMemoryLimit with a PHP memory checking helper class and service into the MemoryManager class and remove redundant methods like getUsageInBytes().
• Instead of setting integer properties in the dispatched event, pass the EnvironmentMemory object. Update the event subscriber.
• Update the MemoryManager test to use a mocked version of EnvironmentMemory.
• Implement the suggestion in #79.2. Or argue against it.
• Respond to the suggestion in #80.
• Use returnCallback() as suggested in #82 or open a follow-up issue to do this. See also the last part of #83.

After upgrading from Drupal 8.9 to Drupal 9.0 I get the two following error/warning messages when trying to create new content using some (not all) of my content types, among them the native “page”-type:

Error message:

The website encountered an unexpected error. Please try again later. Error: Call to a member function getAccountName() on null in Drupal\node\NodeForm->form() (line 155 of core/modules/node/src/NodeForm.php).

Warning message:

call_user_func() expects parameter 1 to be a valid callback, class 'Drupal\node\Entity\Node' does not have a method 'getCurrentUserId' in Drupal\Core\Field\FieldConfigBase->getDefaultValue() (line 397 of core/lib/Drupal/Core/Field/FieldConfigBase.php).

Does anyone know what causes this?

Problem/Motivation

In #2583041: [PP-2] GD toolkit & operations should check for available memory we identified how \Drupal\Component\Utility\Environment::checkMemoryLimit, being a static method, cannot be unit tested under assumption of unavailable memory.

Proposed resolution

Spin off a part of #2583041-66: [PP-2] GD toolkit & operations should check for available memory:

• Add a EnvironmentMemory class that manage calculating the actual memory size from php.ini, and provide methods to return total, used and free memory, as well as methods to check against a memory requirement (either total or remaining available).
• Enable providing PHP Unit test that stub the currently used memory.
• Add PHP unit tests.
• Deprecate \Drupal\Component\Utility\Environment::checkMemoryLimit.

Remaining tasks

User interface changes

none

API changes

\Drupal\Component\Utility\Environment::checkMemoryLimit deprecated.

Data model changes

none

Problem/Motivation

@pameela was added as a provisional committer team facilitator almost a year ago in #3087694: Add pameeela to MAINTAINERS.txt as a provisional committer team facilitator. She has been doing absolutely amazing, and it is time to promote her to non-provisional.

Proposed resolution

Make @pameela a full committer team facilitator.

Remaining tasks

Review and commit patch to MAINTAINERS.txt

We are running our Drupal on Postgres and have a view with 2 relations (joines tables). The Preview SQL is attached below.
Due to the table names and field names, Views2 is generating a field alias, which is longer than 63 chars. In the SQL below, it's the alias "node_node_data_field_parent_node_node_data_field_pbcontent_year_field_pbcontent_year_value", causing Postgres not to throw an error, but truncation the name in the resultset. Postgres will only return "node_node_data_field_parent_node_node_data_field_pbcontent_year" as the column name in the resultset, which causes Views2 to break, as there is no data in the expected field "node_node_data_field_parent_node_node_data_field_pbcontent_year_field_pbcontent_year_value".

SELECT node_node_data_field_parent_node_node_data_field_pbcontent_year.field_pbcontent_year_value AS node_node_data_field_parent_node_node_data_field_pbcontent_year_field_pbcontent_year_value,
   COUNT(DISTINCT(node.nid)) AS num_records
 FROM node node 
 LEFT JOIN content_type_video node_data_field_video_gallery ON node.vid = node_data_field_video_gallery.vid
 INNER JOIN node node_node_data_field_video_gallery ON node_data_field_video_gallery.field_video_gallery_nid = node_node_data_field_video_gallery.nid
 LEFT JOIN content_type_video_gallery node_node_data_field_video_gallery_node_data_field_parent_node ON node_node_data_field_video_gallery.vid = node_node_data_field_video_gallery_node_data_field_parent_node.vid
 INNER JOIN node node_node_data_field_parent_node ON node_node_data_field_video_gallery_node_data_field_parent_node.field_parent_node_nid = node_node_data_field_parent_node.nid
 LEFT JOIN content_type_pbcontent node_node_data_field_parent_node_node_data_field_pbcontent_year ON node_node_data_field_parent_node.vid = node_node_data_field_parent_node_node_data_field_pbcontent_year.vid
 WHERE (node.status <> 0) AND (node.type in ('video'))
 GROUP BY node_node_data_field_parent_node_node_data_field_pbcontent_year_field_pbcontent_year_value
  ORDER BY node_node_data_field_parent_node_node_data_field_pbcontent_year_field_pbcontent_year_value DESC

Could anyone provide me with a workaround? Renaming the base fields and thus getting an shorter alias for the column name would work, but is not an option at the moment.
I tried to rewrite the SQL with hook_views_query_alter(), replacing all aliases in $query->fields with an generic one, if the alias is longer than 63 chars. The query then runs fine, but Views2 continues to search for the long columnames in the resultset. Any way I can tell Views2 that it shouldn't expect the data in field "node_node_data_field_parent_node_node_data_field_pbcontent_year_field_pbcontent_year_value" but for example in "generic_1"?

Problem/Motivation

Connection::query can overload the $query argument to be either a string or an already prepared statement. This is a bit confusing, since the logic of potentially calling query to get a statement and then query again with the statement as input is weird. Normally in PHP world you would prepare a statement, execute it and iterate to fetch the results - then execute it again with different $args if you want to reuse.

Also the current status will prevent in the future to typehint the $query argument, which is now possible in PHP 7+.

Proposed resolution

- Deprecate passing a StatementInterface as $query argument to Connection::query.
- When a database operation is started with a Connection::prepareStatement, follow suit with StatementInterface::execute and StatementInterface::fetch (in case of a SELECT), or other statement inspection methods for INSERT / DELETE / UPDATE.
- Keep Connection::query as a convenience helper that prepares the statement and executes it in one go.

Remaining tasks

User interface changes

None

API changes

Add the wrapper method: Drupal\Core\Database\Connection::lastInsertId(). This method is a wrapper method for \PDO::lastInsertId().

Data model changes

None

Release notes snippet

Deprecate passing a Drupal\Core\Database\StatementInterface object to Drupal\Core\Database\Connection::query() and add new method Drupal\Core\Database\Connection::lastInsertId().

Problem/Motivation

In the Kernel test, there are a bunch of using the assertEqual method and it could be replaced already with assertEquals.

Steps to reproduce

Proposed resolution

Apply the patch in the attachment.

Problem/Motivation

Our current transliteration class has a method to remove diacritics from certain Latin characters. It is desirable this to be expanded to other scripts.

The current behavior is custom. It was written to remove diacritics from a range of characters with an eye on how HTML entities are called, not from a Unicode perspective. The commonly suggested way -- utlizied by Libreoffice and Firefox both -- is to use Unicode decomposition rules, remove Unicode major category "M" (aka combining characters) and re-compose them. But our solution is different. For example, it changes o with stroke to just o and as this SO answer notes, Unicode doesn't decompose it and leaves it alone. There's no right or wrong answer whether it should be rewritten: Wikipedia notes this character is treated as a separate letter in Norwegian and Danish and as such it probably shouldn't be rewritten for those but in other languages it perhaps should be.

In other words, currently the word Øresund will be stored as oresund but if we were to follow the standard way above it would be stored literally. And then searching for oresund finds it currently but wouldn't if we were to follow the standard way.

Out of the 323 characters falling within the ranges PhpTransliteration::removeDiacritics() as many as 48 (~15%) exhibit different behavior under the suggested standard route compared to the current one. Six of them are genuine bugs fixed in #3151364: diacritics are not removed from ǢǣǼǽǮǯ .

Proposed resolution

If intl is not enabled we stick to the current behavior. It is certainly possible to generate the NFD and NFC tables from the UCD and https://gist.github.com/hoehrmann/5652435 and the XO_NFD / XO_NFC properties. I doubt the effort is worth it and also the speed, especially for NFC would be abominably slow.

If intl is enabled then we introduce a pair of new classes, similar to the current Php pairs, the Component one does the work, the Core one does the alter. Also pass the langcode from search to removeDiacritics. We add the rules necessary to achieve parity with PhpTransliterator on the range it operates.

Remaining tasks

Immediate: write the test for alter. Possibly separate the component tests for the two classes by moving the classname to a constant, extending the class for intl and skip the test if intl is not enabled.

Either here or followups: give the community some way to supply sensible rules and settings as adequate. A Hungarian site for a Hungarian audience doesn't want to remove the diacritics Hungarian uses at all. However, a site about Hungary for more international audiences? I do not even know.

User interface changes

API changes

TransliterationInterface::removeDiacritics gets a new, optional argument.

Data model changes

Release notes snippet

Original report

when removing diacritics in function search_simplify(), it not considering remove Arabic diacritics. How to test: add this text to any article: "السُّلَّامُ عَلَيْكُمْ وَرَحْمَةُ اللهِ وَبَرَكَاتُهُ" then search for "السلام". learning form this article, I develop an ugly patch to fix it. It may be better to move it to PhpTransliteration.php but I am not sure.

Problem

The shortcuts star icon doesn't satisfy WCAG Success Criteria 1.4.1 "Use of Color", or 1.4.11 "Non-text contrast".

• The grey outline of the star is too faint. It has a contrast ratio of just 2.78:1 against the grey page background.
• The yellow fill isn't sufficiently distinguishable from the transparent fill. The contrast between the yellow and the grey page background is 1.29:1.
• The yellow-fill is the only indication of state. On it's own, it isn't a reliable signifier. Even if these did have good contrast in the full-colour situation, the state can still be difficult for some users to notice: users with a colour vision impairment, or other visual impairments, or who have adjusted the colour space in some way, or where the screen is overpowered by ambient light.
• When a Windows high-contrast theme is used, the star remains the same colour. We cannot rely on either the grey outline or the yellow fill to be distinguishable from the page background, because we cannot know what the background colour will be.
• The Star is missing entirely in IE 11 when a Windows High Contrast theme is used. It's a CSS background image, and it gets stripped out by the browser. Users cannot perceive, operate, or understand it; they likely won't know it's there at all.