Automated Drupal 10 compatibility fixes

Checking this issue branch using PHPStan and the upgrade_status module, a few remaining D10 issues are still remaining. Which should be fixed.

The module is installable under Drupal 10, the field cloning functionality is working and all "/admin/reports/fields/..." routes are all accessible.

The only problem is, that I can not seem to use the filter function on these sites. Trying to filter anything will lead to

A client error happened

.

Checking the recent log messages the following error is displayed as a result:

Symfony\Component\HttpKernel\Exception\BadRequestHttpException: Input value "host_entity_bundle" contains a non-scalar value. in Symfony\Component\HttpKernel\HttpKernel->handle() (line 81 of /var/www/html/vendor/symfony/http-kernel/HttpKernel.php).

This problem, isn't existent in the current 8.x-1.x version of the module, so we have to resolve it before releasing the D10 version.

Ok no idea, how to resolve this issue...

The problem either resides in "FieldList" or "FieldListTrait" and has probably something to do with the "$query_params" variable which is defined to \Drupal::request()->query->all(). $query_params['host_entity_bundle'] is an array and therefore a "non-scalar value". But I can not seem to understand where this error comes from. I commented out most of the "$query_params" occurrences, to only let the sort form render, but I am still getting the same error...

Maybe @Anybody has an idea on how to solve this problem. But of course, anybody is free to help to solve this problem here!

@Grevil: Looks related to https://github.com/symfony/symfony/issues/44432

Perhaps the maintainer has an idea?

I've no idea what the Symfony exception means.

I would try removing this line:

    $query_params = \Drupal::request()->query->all();

and instead get individual param values from \Drupal::request()->query->someMethodOrOther().

Thanks @joachim! We'll have a further look. I think we can track this down to https://github.com/symfony/symfony/blob/6.2/src/Symfony/Component/HttpFo...
and these lines:

$value = parent::get($key, $this);

if (null !== $value && $this !== $value && !\is_scalar($value) && !$value instanceof \Stringable) {
  throw new BadRequestException(sprintf('Input value "%s" contains a non-scalar value.', $key));
}

and yes, that behaviour was introduced in Symfony 6 (Drupal 10).

So I'm not sure if the ->all() call is the problem or the ->get() ...
See https://github.com/symfony/symfony/pull/41766

@Grevil: Could you please post the whole backtrace or have a look together with me? I guess I'll be able to fix this with the provided information.

Fixed! The problem was a "query->get()"!

Thank you @Grevil for solving this together very efficiently :)

Confirming RTBC. It's fixed now.

I added a composer.json file so that I could use it in composer without the need for the patch, allowing me to upgrade to Drupal 10.

The following (or similar) is required in your projects composer.json:

    "repositories": {
        "drupal": {
            "type": "composer",
            "url": "https://packages.drupal.org/8",
            "exclude": [
                "drupal/field_tools"
            ]
        },
        "drupal/field_tools": {
            "type": "git",
            "url": "https://git.drupalcode.org/issue/field_tools-3297214.git"
        }
    },

Then add the module using: composer require drupal/field_tools:dev-3297214-automated-drupal-10

I hope this is helpful to others.

Tried to contact both maintainers, but no luck. No reply. :(

Sorry -- I'll merge this soon.

Thanks @joachim all good :) This is open source, and we're very grateful for this great module.

A few things to fix:

- The calls to ->accessCheck() should be FALSE, as we're on an admin form and we can assume the user should be able to work with all entities.

- The commit with the composer.json should be reverted, as we don't need it -- d.org generates it automatically.

Done.

• Reset the last commit on this fork's issue branch
• Added FALSE to accessCheck()

Thanks!

Setting back to active so the bot keeps posting patches.

Should we expect more patches? Drupal 10 is released right, I feel like all necessary changes should be known by now.

Drupal 10.1 is out so we should push this forward, however MR needs rebasing.

Merge blocked: fast-forward merge is not possible. To merge this request, first rebase locally.

@tyler36 Version "8.x-1.0-alpha10" is already Drupal 10 compatible and changes from this issue have already been applied! I'd say we close this (feel free to reopen the issue @joachim, if you are against it).

The bot says to leave it open to get further patches.

> The bot says to leave it open to get further patches.

I undertood that as for the initial push though. Are you saying BP is keeping it active until Drupal 10 is stopped in a few years?

The module is D10 compatible, right? I don't see how it can be any more compatible than it is right now.