🇬🇷Greece @dimitriskr

Setting priority back to Major per #10

vensires → credited dimitriskr → .

dimitriskr → changed the visibility of the branch 3476166-deprecate-rolestorage to hidden.

dimitriskr → made their first commit to this issue’s fork.

dimitriskr → changed the visibility of the branch 11.x to hidden.

Fix typo

dimitriskr → made their first commit to this issue’s fork.

Added the constructor property promotion.
About the constructor docs, I cannot remove them because PHPCS will complain and tests will fail. Do I need to add a phpcs bypass for this to work?

@larowlan BC layer exists, it's crossed out because it is already done

Is it browser-agnostic? We have the same, but only on Chrome, Firefox works fine

dimitriskr → created an issue.

Yes exactly
It becomes null because the argument starts with an invalid character and since the "Use multiple values" option is enabled, it tries to filter it for "+"(OR) and ","(AND) characters, anything else is invalid.

I think we need to re-evaluate the scope of the issue, per #57 comment, to filter out invalid characters in arguments (as an option in UI maybe, to cover all use-cases), and keep this feature disabled, in order not to break anything during updates. If this option is disabled, we show an error to the user, as is the current proposed resolution, and if it's enabled, no harm done

vensires → credited dimitriskr → .

system.install already checks for tokenizer extension here

@patelh84 can you upload an interdiff from #12? Thank you

dimitriskr → made their first commit to this issue’s fork.

bumping this

dimitriskr → created an issue.

OK. but this patch just hides the error, not solving the actual issue. The problem originates from the fact that an argument in your view is invalid

@pcambra did you maybe forget to push to the issue branch? Otherwise there's nothing to review

dimitriskr → created an issue.

Can someone close the MR?

No format_string() found in core

Wim Leers → credited dimitriskr → .

You can override the target_db_type and version variables

automatic_updates did this here and haven't heard any complaints for almost 2 weeks. That will use MariaDB 10.6 in your tests

The differences in my.cnf is that #3401846: Add supported mariadb container images → has extra transaction_isolation = READ-COMMITTED and innodb_thread_concurrency = 0, while the committed my.cnf only has innodb_use_native_aio = 0

I ran again the jobs and got the same error as before

Original phpunit error: https://git.drupalcode.org/issue/drupal-2015121/-/jobs/817769
Latest phpunit error: https://git.drupalcode.org/issue/drupal-2015121/-/jobs/918319

I re-ran the job and it passed. Upon checking the browser output, I noticed it throwed different exception for the same reason. Is it something in the mysql driver?

Failing:

PDOException: SQLSTATE[HY000] [1698] Access denied for user 'cij44wcj6ozuljp5'@'127.0.0.1' in Drupal\Component\DependencyInjection\PhpArrayContainer->createService() (line 79 of /builds/issue/drupal-2015121/core/lib/Drupal/Component/DependencyInjection/PhpArrayContainer.php).

Drupal\Component\DependencyInjection\PhpArrayContainer->createService(Array, 'database') (Line: 177)
Drupal\Component\DependencyInjection\Container->get('database', 1) (Line: 219)
Drupal\Component\DependencyInjection\PhpArrayContainer->resolveServicesAndParameters(Array) (Line: 62)
Drupal\Component\DependencyInjection\PhpArrayContainer->createService(Array, 'cache.container') (Line: 177)
Drupal\Component\DependencyInjection\Container->get('cache.container') (Line: 574)
Drupal\Core\DrupalKernel->getCachedContainerDefinition() (Line: 960)
Drupal\Core\DrupalKernel->initializeContainer() (Line: 514)
Drupal\Core\DrupalKernel->boot() (Line: 734)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Passing:

Drupal\Core\Database\DatabaseAccessDeniedException: SQLSTATE[HY000] [1045] Access denied for user 'w7oihw6z5qupbfy5'@'127.0.0.1' (using password: YES) in Drupal\mysql\Driver\Database\mysql\Connection::open() (line 207 of /builds/issue/drupal-2015121/core/modules/mysql/src/Driver/Database/mysql/Connection.php).

Drupal\mysql\Driver\Database\mysql\Connection::open(Array) (Line: 460)
Drupal\Core\Database\Database::openConnection('default', 'default') (Line: 191)
Drupal\Core\Database\Database::getConnection('default')
call_user_func_array('Drupal\Core\Database\Database::getConnection', Array) (Line: 79)
Drupal\Component\DependencyInjection\PhpArrayContainer->createService(Array, 'database') (Line: 177)
Drupal\Component\DependencyInjection\Container->get('database', 1) (Line: 219)
Drupal\Component\DependencyInjection\PhpArrayContainer->resolveServicesAndParameters(Array) (Line: 62)
Drupal\Component\DependencyInjection\PhpArrayContainer->createService(Array, 'cache.container') (Line: 177)
Drupal\Component\DependencyInjection\Container->get('cache.container') (Line: 574)
Drupal\Core\DrupalKernel->getCachedContainerDefinition() (Line: 960)
Drupal\Core\DrupalKernel->initializeContainer() (Line: 514)
Drupal\Core\DrupalKernel->boot() (Line: 734)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

RestExport plugin is updated because it extends PathPluginBase, which itself extends DisplayPluginBase

I'm moving the work to https://git.drupalcode.org/project/drupal/-/merge_requests/6774. The other MRs can be closed

dimitriskr → changed the visibility of the branch 10.1.x to hidden.

dimitriskr → changed the visibility of the branch 11.x to hidden.

I came up with this error today. In my project, we're calling views programmatically and some contextual filters started with a comma ",". In 9.5.x this was no problem, but we upgraded to 10.2 few days ago and got this. I first tried to re-save the view but didn't have any changes in the config.

I think we need to add a check that if is_null($break->operator), it means the filter values used to call the view are invalid and return that error to the user

Also, for the actual problem, if the property 'break_phrase' of the 'nid' argument is set to 'true', it will produce this error when using invalid arguments. The 'break_phrase' argument in the UI is "Allow multiple values" in "More" when editing a contextual filter

I'm uploading a test patch that reproduces this error

Tests now pass :)

I've pushed some code changes.
There needs to be a change at \Drupal\Tests\ckeditor5\FunctionalJavascript\CKEditor5TestBase::createNewTextFormat in order to grant the required permission to the current user to allow using each text format. I guess that will make CKEditor5 tests pass and the whole pipeline go green

#62 📌 Deprecate the 'roles' property of text formats Needs review Do we still need this?

Sure, I can give it a go!

Could you also update the remaining tasks in IS?

Hey mstrelan,

Thank you for looking into this issue
I don't see a commit pushed to this branch/MR

For ComposerIntegrationTest, I asked in Slack if the replacement was valid, got only one positive response so I committed it.

As for the PagerTest, it came from a related issue and specifically this commit which was reverted there and added here

dimitriskr → changed the visibility of the branch 11.x to hidden.

Thanks Wim for taking care of this, it was getting difficult for me

1. I put the upgrade path to the tasks, since I thought it was necessary. Since #53, it was made clear it's not necessary, so we can remove it

2. Is it possible to point a URL to /admin/people/permissions, in the filter module permissions so they can be set directly from there? Or just tell people that in Drupal 11, in order to set permissions for the text formats, you must go to the URL above, in the release notes. And add a note in the current field that in 11 this will change

The failures in the Functional Tests mean that the test user has no access in ckeditor5.upload_image so it cannot upload the image.

We have to set to the user the permission to use the text format, with maybe the following? Otherwise the tests will fail. (tested locally)

    $format_permission = FilterFormat::load('basic_html')->getPermissionName();
    user_role_grant_permissions(RoleInterface::AUTHENTICATED_ID, [$format_permission]);

Or, if we move the calls of $this->createBasicFormat(); to setUp() (since it's called in every test method + in inherited ImageUploadAccessTest), we can add the permission as parameter in drupalCreateUser()

As for the FunctionalJavascript fails, I have no idea what is going on.

I've removed the expectDeprecation calls in the tests, as also remove the roles property in the formats

I've kept it in \Drupal\Tests\ckeditor5\Kernel\SmartDefaultSettingsTest since it loads config from a folder called ckeditor4_config and don't want to mess up anything there. If it's ok to remove it, let me know.

The deprecation message testing already exists in \Drupal\Tests\filter\Kernel\FilterLegacyTest

Alright, I'll continue on this.

And what about the upgrade path? Don't we need to change the configuration of the existing installations?
I was thinking about a hook_post_update (since it's configuration) and load all filters and remove the roles property. Would this be enough?

If there is an example on testing the upgrade path, I could add this too.

forgot about php

dimitriskr → created an issue.

dimitriskr → created an issue.

dimitriskr → made their first commit to this issue’s fork.

Check 📌 Set the module deprecated and add info to the module page, now where the core issue is fixed RTBC
It does no longer apply for D10

I've injected the plugin managers to DisplayPluginBase, in the related issue, so I think if doing 📌 Inject various dependencies into DisplayPluginBase Needs review , this must be done too.

Luckily it requires only 2 plugin managers, so it should be quick :)

Finally, ready for review.

P.S. I've deliberatly put the issue node instead of the draft CR link to the trigger_error(), per a conversation with @berdir at Slack.

Well, after the 3rd consecutive retry, the previously failed test passed.. Random? Connected with infrastructure issues?
https://git.drupalcode.org/issue/drupal-2015121/-/jobs/818007

MariaDB 10.6: https://git.drupalcode.org/issue/drupal-2015121/-/pipelines/95023
MySQL 8: https://git.drupalcode.org/issue/drupal-2015121/-/pipelines/95019

There's something going on with Drupal\FunctionalTests\Bootstrap\UncaughtExceptionTest test

I've also created a draft CR for this change

Done and done

dimitriskr → changed the visibility of the branch 11.x to hidden.

In https://drupal.slack.com/archives/C1BMUQ9U6/p1707853736065729 , catch agreed to remove form_get_options() completely

https://hub.docker.com/r/drupalci/mariadb-10.6 includes a fix for the IO problem.

Whoever has this problem in contrib, can you change to that database and see if it still occurs?

dimitriskr → made their first commit to this issue’s fork.

Thanks for the review Wim! One question. In some previous issues regarding deprecation, it had to have one test that would test that the deprecation message would pop up.

I'll remove the deprecated config from the test configuration but shouldn't exist one test to test the deprecation message? (by creating a separate test module with the deprecated config for this exact purpose)

Can someone close the MR 6042 too? Since this issue is committed. Thank you

Now it's ready again

dimitriskr → changed the visibility of the branch 11.x to hidden.

dimitriskr → created an issue.

I'm uploading one of the logs and make it more readable due to gitlab's raw output

For now, 6126 can be closed.
We've found the cause for nightwatch, but we don't know what's happening with phpunit tests. If we see an increase in random phpunit failures, we could, in the end, commit the changes of 6126 to 11.x and monitor all jobs. But due to the fact phpunit failures are not that common, and usually a re-run of the job works, its priority can be considered minor

I'm reopening this issue as it's a feature that would improve the user experience, when using the field plugin.
I'm also attaching a patch for 2.x codebase

dimitriskr → changed the visibility of the branch 11.x to hidden.

Changed the title so people can easily find this issue

Maybe something like this? Only for str_ends_with() replacements
https://regex101.com/r/cd29ZX/1

I've rebased the branch to latest 11.x and incorporated some changes from the latest patches, so that someone else can work on this easily and to have automatic tests (which currently pass)

Leaving at NW due to some open comments by @wimleers, @phenaproxima and @smustgrave in the MR + no CR yet

No, it's just that dww reported one more of the failures, because we gather whatever we can find, in order to find the cause of it.

I have to say that the nightwatch failures do not feel like they have the same cause of failure with PHPUnit tests.. Let's fix them one by one. Also, since in #7 we have a nightwatch along with DB logs, we don't need to enable CI_DEBUG_SERVICES yet. Let's fix the nightwatch jobs, that seem pretty straightforward and then we can check the phpunit ones

dimitriskr → made their first commit to this issue’s fork.

Thanks @smustgrave.
Moreover in 📌 Deprecate form_get_options() Closed: duplicate it was proposed to remove form_get_options() as there is no usage in core and (then) in contrib. We need to see if we still want to do that here

It was a PHPStorm inspection that identified the changes and not manually, so I got no regex for you

Failed nightwatch job with debug enabled
https://git.drupalcode.org/issue/drupal-2448545/-/jobs/633899

In the related issue, there is work done to move it to a new class. If we want to remove it, it should be decided there and proceed with it in the other issue