Add test to validate composer.json files

August 2, 2019, 12:15 pm

≫ Next: NumericItemBase never sets minimum value constraint if minimum value is zero.

≪ Previous: Clean-up CommentStorage constructor

$

0

0

Problem/Motivation

Removing the Composer merge plugin from core has led to the need for some complex workarounds like this: #3057094-86: Add Composer vendor/ hardening plugin to core

A workaround like that makes it easy to commit a lock file that is out of date, or otherwise out of sync with the package composer.json file.

We also have components and Composer plugins, some of which are not installed during normal development workflows.

Proposed resolution

Add a Composer validation phase to the drupalci.yml, after the codebase is patched.

This can currently be accomplished using the composer testbot plugin.

A more sophisticated composer_validate plugin could also be developed: #2708751: Run composer validate --strict if a composer.json exists

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

---

NumericItemBase never sets minimum value constraint if minimum value is zero.

October 28, 2019, 1:09 pm

≫ Next: Rename 'Authenticated user' to 'logged-in user' and 'anonymous user' to 'visitor'

≪ Previous: Add test to validate composer.json files

$

0

0

Problem/Motivation

Numeric item fields do not have their minimum value validated if the minimum value is zero. This allows for negative values for decimal items or numeric item fields that are not flagged as unsigned.

This is due to a not-empty check:

    if (!empty($settings['min'])) {
      $min = $settings['min'];
      $constraints[] = $constraint_manager->create('ComplexData', [
        'value' => [
          'Range' => [
            'min' => $min,
            'minMessage' => t('%name: the value may be no less than %min.', ['%name' => $label, '%min' => $min]),
          ],
        ],
      ]);
    }

Zero is technically empty.

Proposed resolution

Check if the value is not equal to ''

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Rename 'Authenticated user' to 'logged-in user' and 'anonymous user' to 'visitor'

June 2, 2009, 7:13 am

≫ Next: Make Workspaces and Content Moderation work together

≪ Previous: NumericItemBase never sets minimum value constraint if minimum value is zero.

$

0

0

Problem/Motivation

Partly inspired by http://www.d7ux.org/roles-the-admin-header/ but I've been thinking about it for a while.

1. Authenticated user and anonymous user are somewhat drupalisms - or at least I've never seen them used elsewhere
2. It's been shown in UB user testing and anecdotally that lots of people don't understand giving a permission to auth users gives it to every logged in user. See #78941: Usability: Auto-check permissions if "authenticated" has them.
3. Anonymous users is terrible - these are visitors to the site, authenticated users can be 'anonymous' too.

So I suggest just 'logged in users' and 'visitors'.

Proposed resolution

"Anonymous user" role label changes to "Visitor" (singular)
"Authenticated user" role label changes to "Logged-in user" (singular)

Limit the change only to front-end labeling for Drupal 8.9.x and Drupal 9.0.x; change beyond UI needs to wait for Drupal 9.1.x.

Make Workspaces and Content Moderation work together

March 3, 2019, 3:17 am

≫ Next: Allow adding dynamic configuration schema

≪ Previous: Rename 'Authenticated user' to 'logged-in user' and 'anonymous user' to 'visitor'

$

0

0

Problem/Motivation

At the moment, the Workspaces module can not be installed if Content Moderation is also installed, see #2971699: Content Moderation and Workspace don't work together.

After #3027598: Omit workspaces entity presave and predelete hooks for internal entities is done, there is very little work needed to make them compatible.

Proposed resolution

Remove the 'latest-revision' link template when both Workspaces and Content Moderation are installed, because Workspaces always shows the active revision on the canonical page of an entity, so the latest revision tab is not needed.

Make Content Moderation skip and pre-save logic if an entity is syncing, for example when it is being published from a non-default workspace to the Live one.

Remaining tasks

Add test coverage.

User interface changes

The Latest revision tab will not be shown when both Workspaces and Content Moderation are installed.

API changes

Nope.

Data model changes

Nope.

Release notes snippet

Workspaces and Content Moderation are no longer incompatible and can be installed and used together. Advanced workflows like moderating an entire workspace are possible as well.

Allow adding dynamic configuration schema

July 25, 2019, 5:30 pm

≫ Next: Use site name in From: header for system e-mails

≪ Previous: Make Workspaces and Content Moderation work together

$

0

0

Problem/Motivation

When we want to add a dynamically determined key to typed data scheme via hook_config_schema_info_alter, we get an exception that adding keys is not allowed.

Proposed resolution

Add a hook_config_schema_info_build.

(Paralleling hook_library_info_build / hook_library_info_alter)

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Use site name in From: header for system e-mails

January 13, 2008, 6:19 pm

≫ Next: Text formats that are migrated from D7 to D8 get a numerical ID instead of a sensible name

≪ Previous: Allow adding dynamic configuration schema

$

0

0

Problem/Motivation

The aim of this issue is to give e-mails from the site administrator a "from" title set to the website name and not just an e-mail address.

In Drupal 5 this was possible by configuring "Site Webmaster"<webmaster@site.com> in Site information, but since 6.x the additional validation prevents such an e-mail address configuration.

You are now limited to just the e-mail address, without a name. Hence site e-mails appear to be from just webmaster@site.com, which is just not as nice :)

Proposed resolution

Specify in the "From:" header the site name along with the site email address.

Remaining tasks

• Get RTBC.
• Commit the backported patch at #209672-120: Use site name in From: header for system e-mails to 7.x.
• Create patch and reroll for Drupal 6 if desired.

User interface changes

In your email, you'll see the Site name instead of the email address.

Screen capture attached of my email client:

API changes

None.

Original report by dshaw

In Drupal 5.x, I configure the site e-mail address to be something like "Site Webmaster"<webmaster@site.com> (at the site info page: example.com/admin/settings/site-information). The effect of this is that e-mails from the site have a nicely formatted "From" field. That is, they appear to be from "Site Webmaster", rather than webmaster@site.com. Which is a bit nicer and cleaner.

In Drupal 6.x, the additional validation prevents such an e-mail address configuration. You are now limited to just the e-mail address, without a name. Hence site e-mails appear to be from just webmaster@site.com, which is just not as nice :)

Very minor style issue, I know. But is it possible to retain nice addresses, while still validating the e-mail address?

(The field validation could be altered. Or a site name field could be added to site info. Mail could then be sent from "site name" )

Text formats that are migrated from D7 to D8 get a numerical ID instead of a sensible name

November 19, 2019, 4:09 am

≫ Next: There has been more than one failed login attempt for this account. It is temporarily blocked.

≪ Previous: Use site name in From: header for system e-mails

$

0

0

Problem/Motivation

It's not the name column in the Drupal 7 filter_format database table that determines the ID of the FilterFormat config entity, but the format column, which is an auto-incrementing integer.

Consequence: this makes any future debugging on your Drupal 8 site a pain, because rather than sensible formats such as basic_html or markdown_all_html_allowed, you get 3 or 7 as text format IDs.

Proposed resolution

Use the name column in the D7 table and apply the "machine name" algorithm to it to generate a sensible name.

Remaining tasks

TBD

User interface changes

N/A

API changes

N/A

Data model changes

More sensible D8 destination data model.

Release notes snippet

TBD

There has been more than one failed login attempt for this account. It is temporarily blocked.

November 19, 2019, 4:41 am

≫ Next: Text formats disabled in D7 are migrated to D8 as enabled

≪ Previous: Text formats that are migrated from D7 to D8 get a numerical ID instead of a sensible name

$

0

0

The error message that appears after a defined number of failed logins is currently not translatable. The message is set within the UserLoginForm.php in line 224

$form_state->setErrorByName('name', $this->formatPlural($flood_config->get('user_limit'), 'There has been more than one failed login attempt for this account. It is temporarily blocked. Try again later or <a href=":url">request a new password</a>.', 'There have been more than @count failed login attempts for this account. It is temporarily blocked. Try again later or <a href=":url">request a new password</a>.', [':url' => $this->url('user.pass')]));

---

Text formats disabled in D7 are migrated to D8 as enabled

November 19, 2019, 4:13 am

≫ Next: comment_entity_storage_load() is too expensive on cold caches

≪ Previous: There has been more than one failed login attempt for this account. It is temporarily blocked.

$

0

0

Problem/Motivation

On my Drupal 7 wimleers.com I have the following text formats in the DB and the UI:

And this results in the following DB + UI in Drupal 8 after migration:

Proposed resolution

Ensure that the status column is carried over from Drupal 7 to Drupal 8.

Remaining tasks

TBD

User interface changes

N/A

API changes

N/A

Data model changes

The destination data model is now correct, it now matches the source data model.

Release notes snippet

N/A

comment_entity_storage_load() is too expensive on cold caches

May 26, 2015, 7:01 am

≫ Next: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates

≪ Previous: Text formats disabled in D7 are migrated to D8 as enabled

$

0

0

Problem/Motivation

comment_entity_storage_load() attempts to optimize away a database query each time entities are loaded that don't have comment fields attached.

Unfortunately when caches are cold - such as after submitting the modules page, the field check takes 125ms and 4mb of memory.

Proposed resolution

Query statistics just-in-time and in bulk to avoid needing the loading etc and the field checks.

Remaining tasks

Uploading a patch for #1, but I think we should do #2 (which will be slightly more work).

User interface changes

API changes

New service
New data-types

Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates

August 14, 2019, 11:14 am

≫ Next: Error when saving config entity with "Link to entity" checked if field formatters

≪ Previous: comment_entity_storage_load() is too expensive on cold caches

$

0

0

Problem/Motivation

Because of #2807145: [policy, no patch] Allow contrib projects to specify multiple major core branches Drupal 9 may need to retrieve modules that start with 8.x-.

These maybe compatible with Drupal.

Proposed resolution

1. Do not send \Drupal::CORE_COMPATIBILITY(8.x) in update requests. Replace this with 'all'
2. Determine if more information needs to be returned from the update server to determine if the module is compatible with the current version of Drupal. It may need the new core_dependency key added in #2313917: Core version key in module's .info.yml doesn't respect core semantic versioning

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Error when saving config entity with "Link to entity" checked if field formatters

November 14, 2019, 1:52 am

≫ Next: Remove PHPDoc reference to CommentStorage::buildQuery() on SqlContentEntityStorage

≪ Previous: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates

$

0

0

Steps to repeat:

1. Add a Text (plain) field to a config entity (Contact Form)
2. Edit the display of the field and check "Link to the Content" setting in the format settings.
3. Display the field in the default view mode
3. Submit such form .

Expected Results:

User successfully submits contact form.

Actual Results:

PHP Error: Drupal\Core\Entity\EntityMalformedException: The "contact_message" entity cannot have a URI as it does not have an ID in Drupal\Core\Entity\EntityBase->toUrl() (line 191 of /app/core/lib/Drupal/Core/Entity/EntityBase.php).

Remove PHPDoc reference to CommentStorage::buildQuery() on SqlContentEntityStorage

May 5, 2019, 2:01 pm

≫ Next: Better handle replacement of missing filters with filter_null

≪ Previous: Error when saving config entity with "Link to entity" checked if field formatters

$

0

0

PHPDoc references CommentStorage::buildQuery on SqlContentEntityStorage::buildQuery. This method no longer exists nor there is any other example adding conditions in core, so I think it can just be removed.

/**
   * Builds the query to load the entity.
   *
   * This has full revision support. For entities requiring special queries,
   * the class can be extended, and the default query can be constructed by
   * calling parent::buildQuery(). This is usually necessary when the object
   * being loaded needs to be augmented with additional data from another
   * table, such as loading node type into comments or vocabulary machine name
   * into terms, however it can also support $conditions on different tables.
   * See Drupal\comment\CommentStorage::buildQuery() for an example.

Thanks

Better handle replacement of missing filters with filter_null

February 22, 2018, 6:30 am

≫ Next: Set filter format in migrations to fallback filter, rather than filter_null, so that body fields show up

≪ Previous: Remove PHPDoc reference to CommentStorage::buildQuery() on SqlContentEntityStorage

$

0

0

Whever I try the upgrade, it hangs at 38%. Checking the error log, I see multiple entries with the message "Missing filter plugin: filter_null."

I know that the PHP plugin was enabled on the old site, so not sure if it's related to that. I did try enabling the contrib version of the D8 PHP filter, but php still showed up as a missing dependency, and there was no change in the import.

Set filter format in migrations to fallback filter, rather than filter_null, so that body fields show up

June 13, 2019, 8:36 am

≫ Next: Entity query not working with multiple languages.

≪ Previous: Better handle replacement of missing filters with filter_null

$

0

0

Problem/Motivation

Right now, when you complete a Drupal 8 migration, AFAICS in all cases, you get your node/comment titles moved over, but the bodies display as blank:

The data for the fields is in the database, but getting stripped out on the front end.

According to the migrate team, this happens when filter formats not recognized by Drupal 8; they get migrated as filter_null, a filter that simply returns an empty string. However, to an "end user" it just appears that migrations don't work, even for very simple core cases where no fancy non-core input formats were used.

Major/Migrate critical because this represents a pretty significant usability hurdle, and harms user confidence in the system early on.

Proposed resolution

Instead, map mismatched filter formats to fallback_format (defaults to plain text).

The one possible reason not to do this is PHP code filter, where you could inadvertently expose database credentials that would now be exposed in plain text. However, we could probably deal with this case specially. (For example, explicitly setting that one to filter_null to indicate it needs attention.)

Remaining tasks

• Write a patch + tests
• Review it
• Commit it!

User interface changes

By default, migrations will now display at least something for body field content for nodes and comments. (As well as other rich text fields.)

API changes

?

Data model changes

N/A?

Release notes snippet

Migrations now default to the fallback filter format, fixing a problem where rich text fields were not displaying post-migration.

---

Entity query not working with multiple languages.

November 6, 2019, 12:08 pm

≫ Next: "Link type" option, to support email links

≪ Previous: Set filter format in migrations to fallback filter, rather than filter_null, so that body fields show up

$

0

0

Hello,

We have a multilingual website working with Domain module. Multiple languages are allowed for a site, for instance we can display nodes in EN/EN-GB/EN-US language in a specific page.

Problem/Motivation

It is not possible use Entity Query with multiple languages. There is a langcode parameter in some functions, but it is always a string :

• https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...
• https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...
• https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...

I'm not able to use QueryInterface::sort() to sort my nodes with several languages or Condition::notExists to work with multiple languages.
Currently I have to do a custom select to retrieve correctly my nodes.

Proposed resolution

Can we find a way to be able to pass an array to the functions above? Or do you have another solution for this?

Thanks for your help.

"Link type" option, to support email links

October 2, 2017, 2:24 am

≫ Next: PHP Phar Stream Wrapper should be updated to fully support PHP7.4

≪ Previous: Entity query not working with multiple languages.

$

0

0

Problem/Motivation

In D8 core, there is no out-of-the-box way to add a mailto link (an email link) using the WYSWIYG editor.
The core 'link' WYSIWYG plugin only supports URLs.

In Drupal 7, the CKEditor Link plugin enabled you to choose the type of link, including an email link type, so non-technical users could easily add mailto: links using the WYSIWYG toolbar.

For users upgrading from D7 to D8, it's now harder to add inline mailto links, as they have to manually create the link by typing in HTML in the WYSIWYG source view.

We'd like to improve the usability of the D8 WYSWIYG editor, by including support for mailto/email links.

Proposed resolution

There's currently no consensus on how to resolve this.

Ideas/options/comments discussed to date include:

1. @Wim Leers stated that the D7 CkEditor link dialog was perceived to be too complex, too cluttered and in D8 priority has been given to simplify the experience, making it better for most use cases. CKEditor 5 have also removed the Link Type option in favour of a simpler approach
2. https://www.drupal.org/project/editor_advanced_link has been suggested as a way to provide advanced link functionality, however it does not provide email/mailto link support and is therefore not a suitable option.
3. not provide a WYSIWYG way to do this, keep it as an 'educational task' to teach authors how to enter HTML manually. Many users disagree with this approach as it's poor usability.
4. the contrib module https://www.drupal.org/project/anchor_link does enable you to create email links (see example screenshots below) but it does this by adding an additional link toolbar tool to the WYSIWYG editor. This is less than ideal because you then have two identical link icons and it's not clear to users which button to use when.

Before/After screenshots

Previous D7 experience (with CKEditor contrib module)

Current D8 experience (core)

Current D8 experience with anchor_link contrib module

Remaining tasks

(reviews needed, tests to be written or run, documentation to be written, etc.)

User interface changes

(New or changed features/functionality in the user interface, modules added or removed, changes to URL paths, changes to user interface text.)

PHP Phar Stream Wrapper should be updated to fully support PHP7.4

October 2, 2019, 12:56 am

≫ Next: Armenian translation

≪ Previous: "Link type" option, to support email links

$

0

0

Drupal core is shipped with https://github.com/TYPO3/phar-stream-wrapper library. It should be updated in order to support PHP7.4

See: https://github.com/TYPO3/phar-stream-wrapper/issues/49

Seems like most of the compatibility issues are in tests, see https://github.com/TYPO3/phar-stream-wrapper/pull/50

Actual issue affecting the library has already been patched (but master branch only, which is PHP7+, and we need v2, which is PHP5+): https://github.com/TYPO3/phar-stream-wrapper/commit/27899b820ae69c500517...

Armenian translation

November 19, 2019, 6:49 am

≫ Next: Remove Firefox workaround for details focus effect

≪ Previous: PHP Phar Stream Wrapper should be updated to fully support PHP7.4

$

0

0

Hi!
When I try to add a translation to a node, I get this message: Notice: Undefined offset:
1 in Drupal\Core\StringTranslation\PluralTranslatableMarkup->render() (line 140 of /home/radionet/public_html/core/lib/Drupal/Core/StringTranslation/PluralTranslatableMarkup.php) #0 /home/radionet/public_html/core/includes/bootstrap.inc(587): _drupal_error_handler_real(8, 'Undefined offse...', '/home/radionet/...', 140, Array) #1 etc.

Full message screen: http://prntscr.com/pz477r
--
Why is this happening and how to fix it?

Remove Firefox workaround for details focus effect

October 4, 2019, 3:54 am

≫ Next: Wrong file extension JS error is hidden after an upload has already been attempted (e.g., after adding then removing a file)

≪ Previous: Armenian translation

$

0

0

Problem/Motivation

We have a workaround for the details focus effect to make it more consistent with Chrome. However, this makes the details element focus inconsistent with some other elements on the same browser. Since this is presumably expected behavior in Firefox and not a bug, we should consider whether we want to have this workaround or not.

Proposed resolution

Remove the workaround and rely on Firefox's default behavior when it comes to details focus effects.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet