Problem/Motivation

#3102724: Improve usability of core compatibility ranges on available updates report is critical and blocking all sorts of things.
The Claro styles aren't terrible, but not good.
But Claro is experimental, and getting this perfect for Claro isn't a critical blocker.
Moving to a follow-up.

Initial state

Proposed resolution

Quoting @ckrina from #3102724-100: Improve usability of core compatibility ranges on available updates report:

Here's the definition of details in Claro: https://www.figma.com/file/OqWgzAluHtsOd5uwm1lubFeH/Drupal-Design-system..., and here an screenshot of the defined styles including hover.

Anyway, I'm afraid adding a box inside a box here might me too much visual noise, so I'd try to implement the details without the wrapper. Which is actually following the styles for action-link component (https://www.figma.com/file/OqWgzAluHtsOd5uwm1lubFeH/Drupal-Design-system...). Specifically, I'd use the Action link component on its small size (not sure if it's been implemented yet). You can see here all the defined states:

Remaining tasks

1. Consider / confirm design.
2. Implement.
3. Review.
4. ...

User interface changes

TBD.

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

PHP 7 introduces (return and scalar parameter) type declarations. In #2928856: Adopt the PSR-12 standard for PHP7 return types there is discussion going on about adopting the PSR-12 standard for using return type declarations. However, as noted by drunken monkey implementing type hints in existing code in any form would be a breaking change.

The problem comes down to the fact that introducing type-hints in code that is used will make PHP complain that the contract isn't properly implemented by extending objects (see example 1). Implementing the type hints ahead of time does not break but produces warning because the extending case may be stricter (so not drop-in compatible) than the extended object (see example 2).

Issue #2928856: Adopt the PSR-12 standard for PHP7 return types talks about implementing type declarations for new code. However, this still leaves us with a large codebase where the power of strict typing is not yet used to catch bugs ahead of time.

It isn't possible to add parameter type hints, either in extending or extended code unless it's done simultaneously, so we have to workaround this limitation one way or another:

Examples

Example 1

Adding type-hints in code that is extended without adding code to those extensions is problematic.

class Base {
    public function foo(int $x) : array {
        return [];
    }
}

class Child extends Base {
    public function foo($x) {
        return ["array"];
    }
}

$c = new Child();

echo $c->foo("bar");

Produces:
Fatal error: Declaration of Child::foo($x) must be compatible with Base::foo(int $x): array in [...][...] on line 13

Example 2

The opposite is also sort-of true, introducing type hints when the extended object has not already done so produces warning.

class Base {
    public function foo($x) {
        return [];
    }
}

class Child extends Base {
    public function foo(string $x) : string {
        return "great " . $x;
    }
}

$c = new Child();

echo $c->foo("bar");
</code>

Warning: Declaration of Child::foo(string $x): string should be compatible with Base::foo($x) in [...][...] on line 13<h3>Example 3</h3>
Remove the parameter from the parent method altogether, use func_get_args() (possibly with runtime type checking).

The child class can then update the method signature to be Drupal 10 compatible, without breaking compatibility with Drupal 9 (where the method has been changed already).

&#10;&lt;?php&#10;&#10;class Base {&#10;    public function foo() {&#10;       $x = func_get_args()[0];&#10;        return &quot;great&quot; . $x;&#10;    }&#10;}&#10;&#10;class Child extends Base {&#10;    public function foo(string $x = &#039;&#039;) : string  {&#10;        return &quot;great&quot; . $x;&#10;    }&#10;}&#10;&#10;$c = new Child();&#10;&#10;echo $c-&gt;foo(&quot;bar&quot;);&#10;&#10;&#10;

Return type hints

class Base {
  function foo () {
      return 'foo';
  }
 }
 
 class Child extends Base {
    function foo() : string {
      return 'foo';
    }
}

$child = new Child();
echo $child->foo();

Child classes can add return type hints without them being present on the parent, in this case we need to find a way to indicate (code comments, change records, rector) what changes need to be added in advance before adding the return type hint to core methods.

Proposed Solution

One saving grace that we have is that our coding standards already tell us to use PHPDoc type declarations all over Drupal. This means that we could use (an improved version of) a tool such as https://github.com/dunglas/phpdoc-to-typehint. Building this tool means that it can be used to convert Drupal core (possibly in reviewable chunks as sub-tasks of this issue) as well as contrib modules. It can then also be used for any downstream dependencies that we utilise.

Problem/Motivation

Public properties on our entities allow APIs to be circumvented, and increases the likelihood of introducing bugs because an entity object may not be in a reliable or accurate state. (Additionally, ->something->value is cumbersome DX.)

We need an issue for every entity type. The content entities (user comment taxonomy_term) are the most important.

Beta phase evaluation

But impact will be greater than the disruption, so it is allowed in the beta.

Proposed resolution

->getSomething() will provide a proper, reliable API for each entity type.

We did this by, for each entity, opening a new issue (coping one of the ones already existing. dreditor clone patch was helpful #1803622: Add a create follow-up issue link which fills in values (clone an issue)).
http://screencast.com/t/4qPjNP8fEHVw shows one way of creating a sub issue.

Remaining tasks

• (done) Figure out how to list all Entities. See #5.
• (done) Open all issues.
• (done) Write some hints that patch producers will find helpful for creating patches for each issue.
• (still needs more helpful hints) Write review instructions with hints of what reviewers will find useful when reviewing sub issues.

User interface changes

Sub issues have no UI changes.

API changes

Sub issues have API additions, actual getter methods.

Related Issues

TBD.

Testing

Added #2527114: Create PHPUnit test that Entity class variables are protected or are allowed public to make sure that there will be no new public class variables added as a accident.

Sub-Issues

Completed tasks

Hints to patch producers (based off of #12)

Ideally the visibility of the properties which are getters and setters in this case can force people to use the property directly and instead of using it directly, use it as a method so while working on the patch you can make the visibility as protected and change them back to public before RTBC - as stated in this comment leave it protected.

Find each property in the entity and make a getter.
See #2015123: Expand NodeInterface to provide getters and setters for an example.

Please read a couple examples

the discussions in
#2016701: Expand TermInterface to provide methods
and
#2028025: Expand CommentInterface to provide methods
to see some of the common complications so you can avoid them in your issue.

do not duplicate already implemented functionality

Also (see #12),
do not add getter methods for things that already exist on EntityInterface, do not duplicate:

• id() for the primary id of the entity. id() is already doing the same thing, so do not make getId().
• getRevisionId() for the revision id (only relevant for entities that have revisions: node/custom block)
• bundle() for the bundle (e.g. the type for nodes, vocabulary for terms, ...)
• uuid()
• language()

Check if it makes sense

Only add setters if it makes sense conceptually: setId() is not necessary for database/content entities, as the ID is automatically generated for them when they are saved. Another example: setUUID(), this is set automatically initially and must not be changed afterwards.

Sometimes setters might seem to be needed, mostly in tests. Usually tests are setting something they should not. Try opening related issues (to the child) that refactor the test to not need to set something. Usually this can be done by creating a new whatever and passing in the values it needs to have at the time of creation.

Avoid conflicts

Look out for conflicts: EntityInterface for example already has isNew(). but it does something different. If making a new method, with a different purpose, pink a unique name for it.

In general

Links in the tables go to api.d.o
For example, the first config entity: Action
https://api.drupal.org/api/drupal/core%21modules%21system%21lib%21Drupal...
can see it's a class (not an interface).
It's not content entity (compare to Node)
And there is a table which shows the properties. Filter to just show properties, click on the heading Modifiers (twice) to sort and put public properties in a group at the top of that table.

For content entities, for example Node,
all of the public properties are deleted, and the init() method is deleted.

For config entities, for example Action,
the public properties should become protected.

Protected properties can be listed in the sub-issues, and considered case by case if a getter makes sense.

Initial patches in the sub-issues should not rename properties, just do a straight conversion to a getter.

Hints to patch reviewers

For each method added, check the class being extended or implemented. If a new method name is already in that class, watch out, it will be a conflict.

Please read a couple examples

the discussions in
#2016701: Expand TermInterface to provide methods
and
#2028025: Expand CommentInterface to provide methods
to see some of the common points other reviews have made and see if the issue you are reviewing can use similar feedback.

check for duplicated functionality

getter methods should not have been added for things that already exist on EntityInterface. For example, these should not have been implemented

• getId() should not have been added, since primary id of the entity can be gotten with the already existing id()
• read the classes that are being extended or implemented to see if there might have been methods to use that serve the same purpose (even if the name might be a little different).

Check if it makes sense

Setters should only have been added if it makes sense conceptually: setId() is not necessary for database/content entities, as the ID is automatically generated for them when they are saved. Another example: setUUID() is not needed, this is set automatically initially and must not be changed afterwards.

Check for conflicts

Look out for conflicts: EntityInterface for example already has isNew(). but it does something different. If making a new method, with a different purpose, the two will need unique names. It might take some thought to name things by their purpose.

When viewing a page that has query parameters in the URL and adding a shortcut link, things kind of break. The shortcut you get doesn't work right, and sometimes things get messed up even worse (I hear this is particularly bad when combined with the overlay).

A large part of the problem is that menu_link_save() -- where the shortcut link eventually gets passed to -- is not designed to take query string parameters, only full paths. When you try to pass a string containing query parameters to this function, it looks like the router path doesn't get calculated correctly, and other bad things happen...

I suspect this issue is responsible for a number of strange bugs in the shortcut module.

Seems like our options are:

1. Try to make menu_link_save() actually handle query string parameters correctly.
2. Remove the "feature" that allows you to bookmark links that have query string parameters in them. In other words, do not pass along any query string parameters in the "Add to shortcuts" link generated in shortcut_page_build(), and invalidate any links that have them in shortcut_valid_link().

While supporting query string parameters would be nice, it seems like the easier fix is probably option #2.

Problem/Motivation

LanguageNegotiationUrl::processOutbound() includes the manipulation of the 'absolute' option:

<?php
        // Ask for an absolute URL with our modified base URL.
        $options['absolute'] = TRUE;
        $options['base_url'] = $url_scheme . '://' . $config['domains'][$options['language']->getId()];
        // ...
?>

Leading to the situation that if you want to generate a Url string, e.g. from an entity like this:

<?php
$entity->toUrl()->setAbsolute(FALSE)->toString();
?>

... you'll end up having an absolute Url string regardless your previously set option.
This can be a huge problem, as it leads to unexpected (and most probably untested) behavior where errors might not be noticed immediately, but after some period of time when things might be just too late to fix them.

Steps to reproduce

I'll try to find time to be more concise about how to reproduce this problem. Basically you need a multilingual site with domains configured accordingly, then having some part in your code that wants to have a relative Url.

Proposed resolution

Maybe it would help to fail hard by throwing an exception, when the 'absolute' option was explicitly set to FALSE before.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In core we've held off from using final on classes because of the idea that final limits extensibility and a key feature is extensibility.

However there are cases where we've defined specific types of classes in core as not being extensible and @internal by default. These include:

• Plugins
• Events
• Forms
• Controllers
• Paramconvertors

See https://www.drupal.org/core/d8-bc-policy

However people are extending these in contrib and custom code and then when we make changes to the constructors things break. For example:
https://www.drupal.org/project/drupal/issues/2594425 and then https://www.drupal.org/project/menu_block/issues/2968049

Proposed resolution

Use final instead of an implicit @internal. Put in another way we need to prioritise composition over inheritance. So a plugin that wants to borrow functionality from another plugin could create that plugin in it's constructor and then use that object. See #2968049-18: Dependency Injection issue as an example.

Making this change is likely to shift some costs from future maintenance to the here-and-now but in the long run it means that core upgrades to major and minor releases can be done with more confidence because our conventions have moved from wishful thinking to language constructs.

Remaining tasks

• Bring in the technical working group as this is likely to involve coding standards.
• Build core consensus - this is likely to be tricky because there is an idea that the use of final is bad.

User interface changes

None

API changes

None :) everything is already implicitly @internal

Data model changes

None

Release notes snippet

This is Drupal 9 only change.

Problem/Motivation

The D7 test fixture has been steadily getting more difficult too work with, my guess is that this started when the translation work began. It is no longer possible to bring up a site with the fixture and do things through the UI. Attempts to save or create anything or clear cache result in 'An illegal choice has been detected. Please contact the site administrator.'

To reproduce:
1. Use db-tools to import the fixture to D7 site
2. navigate to /admin/config/development/performance
3. Click 'Clear cache'
4. Error msg, "An illegal choice has been detected. Please contact the site administrator."

Since this task blocks all, or nearly all, D7 migration work, marking as Major and a blocker.

Proposed resolution

Fix the D7 test fixture so it is usable via the UI.
Updating the fixture to the latest D7 or adding data is to be done in #3022137: Update migrate fixtures for remaining active issues.

Remaining tasks

Do it.

Problem/Motivation

In FormBuilder::formBuilder function the variable $request is assigned twice with the same vaue:

$request = $this->requestStack->getCurrentRequest();

Probably, one call is enough.

Proposed resolution

Remove the second call.

Remaining tasks

Provide patch.

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

I discovered a very annoying bug in #3219078: Regression: multilingual taxonomy term migrations are failing if user tries to migrate from Drupal 7.81+ and Entity Translation 7.x-1.1 which highlights that core migration tests are testing the migration of a very outdated Drupal 7 instance. While it seems that most of the contributed modules don't got data schema or value updates, settings up an outdated codebase (which works only with unsupported PHP versions) is a constant challenge. ...and it also gives us a false sense of "since core tests are passing, we definitely can migrate most of the Drupal 7 config + data into Drupal9". See #3219078: Regression: multilingual taxonomy term migrations are failing if user tries to migrate from Drupal 7.81+ and Entity Translation 7.x-1.1 .

Steps to reproduce

For an example check #3219078: Regression: multilingual taxonomy term migrations are failing if user tries to migrate from Drupal 7.81+ and Entity Translation 7.x-1.1

Proposed resolution

Update the core database fixture. this means:

1. Scan the system table for module versions (assuming that it contains the right info).
2. Build a codebase with the outdated core + contribs. Make sure you use the right PHP version.
3. Import the DB fixture.
4. Update the codebase with the most recent core and contribs.
5. Execute the database updates.
6. Identify which manual fixture edits caused the errors you see, and try to fix them.
7. Repeat #3, #4 and #5 until you think that the database integrity is fixed.
8. Export the updated DB and add that to core.
9. Preferred: document the versions of core + contrib modules – I would add a drush make file for example.

Imho #3213633: Improve DX of mainaining migration database fixtures: provide an option for creating per-table database fixtures in DbDumpcommand can help us a lot, because it allows you to easily skip adding unnecessary changes made in tables on a per-table-basis, and not only on a per-hunk basis.

Remaining tasks

• Triage this issue
• Agree on a solution.
• Do it.

User interface changes

Nothing.

API changes

Nothing.

Data model changes

Nothing.

In/admin/content, the operation button is broken a little.
Although it may be a priority issue of column width per language.

It is not a big problem.
Please consider improvement if necessary.

Thank you.

Problem/Motivation

On #2664830: Add search capability to help topics, andypost/ambermatz discovered that if you go to admin/search/pages and disable the Help Search page, then any page (such as admin/help) that is displaying the Help Search block will have a WSOD.

The reason is that the Search Block Form doesn't verify that the page it is supposed to submit to exists and is active. It should.

Proposed resolution

Alternative 1:
A patch was proposed by jhodgdon on #2664830-203: Add search capability to help topics -- here's the interdiff:
https://www.drupal.org/files/issues/2019-10-08/interdiff_13.txt

It needs a test. Also the part for the doc block in the interface is on another issue. Only the SearchBlockForm needs the patch.

Alternative 2:
Another way to resolve this would be to remove the ability to disable search pages. It is not clear why you would want to disable them anyway.

Remaining tasks

1. Decide which way to go -- the consensus is that we should remove the ability to disable search pages.

2. Make a patch.

User interface changes

The ability to disable search pages will not exist any more. You will only be able to add and delete pages, not disable them.

API changes

Functions related to disabling search pages and checking status will be removed/deprecated.

Data model changes

The status component of search page plugin configuration will be removed.

Release notes snippet

TBD

Problem/Motivation

It'd be great to be able to only migrate menu links from certain menus (in other words - to filter links by bundle).
We already have these availabilities for nodes and taxonomy terms:

• https://git.drupalcode.org/project/drupal/-/blob/9.2.x/core/modules/node...
• https://git.drupalcode.org/project/drupal/-/blob/9.2.x/core/modules/taxo...

As a workaround, you can accomplish the same outcome using skip_on_value/empty. See comment #6 for an excellent explanation and examples!

Counterpoints ;-)

• An optional config like this one at the source level can make things like migrate-status (the drush command or its GUI equivalent) more informative / better representations of what you're doing.
• There's a speed/performance benefit to limiting items during the source phase rather than skipping in the process phase.

Proposed resolution

Add a condition by menu_name to the existing menu_link source plugin. As a result, links can be limited in the following way:

source:
  plugin: menu_link
  menu_name: [main-menu, navigation]

Remaining tasks

Review, add change record, commit.

Problem/Motivation

We have a deprecation message warning in Drupal\Core\Database\Query\Select::__construct() when the parameter $alias is not null or not a string.

Proposed resolution

Replace the deprecation message for the $alias parameter in Drupal\Core\Database\Query\Select::__construct() with a InvalidArgumentException

Remaining tasks

TBD

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None

Problem/Motivation

When adding or editing a menu link through the Menu UI, the form present a field 'Parent link' in order to create a hierarchical menu structure. However, these options are not limited to the current menu but show all menus available in the database.

For sites using multiple menus, this list quickly becomes unwieldy.
For sites using a lot of menus, this list can create a performance bottleneck because of the large number of menu items being loaded.

Proposed resolution

Limit menu link 'Parent link' to the current menu.

Remaining tasks

1. Write a patch
2. Review
3. Commit

User interface changes

The menu link 'Parent link' field is limited to the current menu.

API changes

None.

Data model changes

None.

Hello,
I am trying to add/upload images with products using API. For that, I guess we need to provide the id of the uploaded image in the API body of the product.

So, I installed module file entity(https://www.drupal.org/project/file_entity). I checked this issue for my solution: https://www.drupal.org/project/drupal/issues/2682341

I am using POSTMAN to run this API.

I am using Drupal 9.2.0

The API I am using to upload image:

URL:
{{Domain}}/entity/file?_format=hal_json

Method: POST

Body:

{
	"_links": {
		"type": {
			"href": "{{Domain}}/rest/type/file/image"
		}
	},
	"filename": [
		{
			"value": "imagename.jpg"
		}
	],
       "filemime": [
		{
		        "value": "image/jpg"
		}
	],
	"data": [
		{
			"value": "base64encoded image string"
		}
	]
}

Response:

{
    "message": "Could not determine entity type bundle: \"type\" field is missing."
}

Any suggestions?

Problem/Motivation

We have node type condition in core \Drupal\node\Plugin\Core\Condition\NodeType. It is specfic to the node types. Drupal 8 has a lot more content entities with bundles and ctools provides EntityBundle condition which allows any bundleable entity to use that condition plugin. Move EntityBundle condition to core and replace it with node type conditon in followup #2914188: Deprecate \Drupal\node\Plugin\Condition\NodeType plugin in favor of \Drupal\Core\Entity\Plugin\Condition\EntityBundle.

Proposed resolution

Moved \Drupal\ctools\Plugin\Condition\EntityBundle to core \Drupal\entity\Plugin\Core\Condition\EntityBundle

Remaining tasks

Commit

User interface changes

None

API changes

Nothing

Problem/Motivation

The docblocks for Connection::select and Select::__construct only describe $table as a string, but in reality it can also be a subquery in form of a SelectInterface object (for example, for rowcount queries).

Proposed resolution

Fix

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Today we have once, autocomplete that are either released or going to be as npm packages.

We have 2 general projects to track bugs host code, etc. the DA needs to do some custom configuration as far as gitlab is concerned to support our testing/npm publishing.

Proposed resolution

use a single general project making use of workspaces (either with yarn workspaces or lerna) like wordpress and many other do.

This would simplify d.o integration: only one project to configure for credit weight for the ranking, only one gitlab project to configure.

This would simplify greatly the maintenance of JS packages, only one queue to follow, code is in one place, same gitlab config for publishing all @drupal packages, etc.

Remaining tasks

Agree on:

1. using a monorepo (with this issue, I'm assuming yes)
2. What the name of the project (core_js, something else?)
3. Yarn itself or lerna?

Problem/Motivation

When running and debugging migrations from Drupal 7, it becomes tedious and frustrating to have to repeatedly set the database connection up.

Proposed resolution

Allow the fields on the Credential form, the database connection and the source base paths, to be set up via settings. Suggested key names are:
migrate - for the source database. This key is the fallback key used by the migrate api.
migrate_source_connection - The database key for the source database connection.
migrate_d6_file_public_path - The source base path for Drupal6 public file
migrate_file_public_path- The source base path for public files
migrate_file_private_path - The source base path for private files

The original proposal was to allow just the source database to be set up via settings by looking for a database with the key name migrate_drupal_source. If it is present, skip the "Source database" section of migrate_drupal_ui's CredentialForm.

Before
Before.
After
For these screenshots the following were in settings.local.php

$settings['d6_migrate_file_public_path'] = '/var/www/html/drupal/sites/default/d6files';
$settings['migrate_file_public_path'] = '/var/www/html/drupal/sites/default/files';
$settings['migrate_file_private_path'] = '/var/www/html/private';

No database selected.
Other selected.
Select a db defined in setting.php.

Remaining tasks

• Reroll (Novice)
• Agree on key names, migrate, migrate_file_public_path, migrate_file_private_path
• Usability review
• Review

User interface changes

If a database is already set up, the "Source database" section of Drupal\migrate_drupal_ui\Form\CredentialForm is omitted.

API changes

Data model changes

None.

Release notes snippet

TBD