🇨🇭Switzerland @salvis

What about ACL? I think we need to do ACL first, no?
📌 Automated Drupal 11 compatibility fixes for acl Needs review

Thanks to @pfrenssen 's 🐛 Latest stable release for Drupal core is stuck on 10.0.7 Fixed , Drupal CI was updated and the "updated deps" test passed: https://www.drupal.org/node/87985/qa →

I'm now changing all "The latest stable version of Drupal 10" tests to "Drupal 10 development branch", because according to @drumm, the former is not regularly maintained anymore.

I sympathize with #17 and #18, and I've created a new branch 4.x for D10 compatibility.

This issue is a mess. Please provide a combined patch including #4, #12, #16, and (if possible) remove the guessMimeType() hack, against 4.x-dev.

Actually, this is a duplicate of #3287920-10: Automated Drupal 10 compatibility fixes → .

patch applied on D10.

Exactly, this contradicts...

core_version_requirement: ^8.8.2 || ^9

... and makes the module incompatible with D8 and D9.x (x < 3), while it can't be deployed on D10.

/**
 * Array sorting callback; sorts modules by their name.
 *
 * @deprecated in drupal:9.3.0 and is removed from drupal:10.0.0. Use
 *   \Drupal\Core\Extension\ExtensionList::sortByName() instead.
 *
 * @see https://www.drupal.org/node/3225999
 */
function system_sort_modules_by_info_name($a, $b) {

#4 needs to be discussed in a separate issue, as instructed in the original post.

Thank you, @pfrenssen, I guess they're abandoning Drupal CI as a measure to push GitLab CI...

I don't know what you see under [Automated testing]. Here's what I see:

The configurations that have an link can be changed and even deleted, the other ones seem to be cast in stone.

I cannot remove the "PHP 8.3-rc1 & pgsql-14.1, D9.5 Composer require failure" test because it has no link. Kind of stupid, because 2.x is not intended to run with D9.5, but that's how it is. I should not have created that configuration...

The "PHP 8.3-rc1 & pgsql-14.1, D10.1 Composer require failure tested weekly" test does have an link, so that I could probably change or delete it. Actually, Drupal doesn't support PHP 8.3 at all according to https://www.drupal.org/docs/getting-started/system-requirements/php-requ... → , so it's no surprise that that test fails. We might just wonder why the configuration is offered. Chances are that it will start working some time in the future, so I'm leaving it as it is.

When I click , then I get this:

Here you see that I have no way of selecting 10.0.10.

I could re-run the red "PHP 8.1 & MySQL 5.7 updated deps, D10.0.7 2 pass, 2 fail", but as @pfrenssen pointed out, the failure is due to a bug in D10.0.7 Core. Because this test configuration doesn't appear in the list with the links, we can't change or delete it either. So, the best we can do is to ignore it. Based on @pfrenssen's input I've add the the "PHP 8.1 & MySQL 5.7, D10.0.7" test and this one passes. That's why I'm setting this issue to Fixed.

It would be helpful to me if you can provide the following information:

1. is this issue (regarding failing dep tests) a "problem"? (yes/no)
2. if yes, are you clear about how to resolve the issue? (yes/no)
3. are there other issues blocking us from tagging a 2.x release? (if yes, a simple bulleted list of those tasks would be nice)

So, NO, YES (=no further action required, we did what we can do), and NO. I created 2.0.0-beta1 two days ago.

It would have been nice to fix 🐛 "Invalid user specified." occurs for auto-complete user field if you don't select suggested username Needs work , but I didn't want to wait any longer.

Never mind the D9.5 — it's the code for 8 and 9. The test bot says

fatal: corrupt patch at line 31

By now we have a 2.x branch for D10, and the patch needs to go against 2.x-dev now. The D8 and D10 branches haven't diverged much yet, the code that you're concerned with is probably still the same.

salvis → created an issue.

Thank you for 🐛 [2.x] Failing updated deps test Fixed , @xeM8VfDh!

I'm setting this one back to Fixed.

if you can assist me in setting up a test environment to duplicate the errors.

I'm running the commercial MAMP Pro under Windows, which is pretty powerful in the sense that it allows setting up any number of combinations of Drupal/PHP/DB/etc versions side by side, along with PhpStorm, but I've always had trouble trying to reproduce the results of the testbot, or even to get tests to pass locally that passed on the testbot and vice versa. Oh, and Core|Testing is very slow, even though I have a pretty fast machine. I've never been able to figure out why.

Drupal being what it is, I cannot simply clone the 2.x branch locally and run tests.

Well, for manual testing, here's what I do:

1. and the desired Drupal version
2. run
3. open , creating an sqlite database
4. and the corresponding ACL branch into the modules directory
5. install ACL as usual

I can't think of any Drupal-specific hurdles, you have a working local LAMP environment with the correct PHP version → . Why can you not "simply clone the 2.x branch locally and run tests"?

This is caused by updating symfony/validator from 6.2.5 to 6.3.4, but not updating core to 10.1.x.

Thank you @pfrenssen for explaining, and thanks to the powers in charge for offering a test configuration that is guaranteed to fail...

Indeed, PHP 8.1 & MySQL 5.7, D10.0.7 is passing.

@xeM8VfDh: D10.0.7 is the current "Drupal 10 Stable Release", i.e. "The latest stable version of Drupal 10" — that's the one that we definitely need to run with. The version number is automatically adjusted to whatever is the stable release of the day.

The alternative is "Drupal 10 Development, currently 10.1.x", i.e. the bleeding edge "Drupal 10 development branch". Our test coverage is, sad to say, not very strong, and deprecated, too, and I think it's unlikely that we get hit by breaking D10 changes before anyone else does. Still, I've added a Weekly PHP 8.3-rc1 & pgsql-14.1, D10.1 test, bleeding edge for both D10 and PHP, as an early warning test, but Composer fails because a core dependency doesn't run with PHP 8.3. — Another test configuration that's guaranteed to fail for the time being, but it may come to pass at some point.

The other Composer fail is for PHP 8.3-rc1 & pgsql-14.1, D9.5. Obviously, this is my mistake: 2.x is supposed to run on D10, not on D9.5. I should never have created that configuration, and unfortunately, there seems to be no way to remove it (it has no link).

So, we should be set as far as the testbot goes.

As you can see above, pasting code as text does not work.

Reverting part of acl.admin.inc of v1.1.0 to v1.0.0-beta1 works OK.

Such version number have never existed.

Please provide a patch against the current -dev version.

Apparently, this can be resolved by setting sql_mode to not contain ONLY_FULL_GROUP_BY.

... or it needs to be fixed in Core...

I've tried creating and deleting a role using the current -dev version (requires ACL 8.x-1.1) and I did not get any crash.

Please try this again and let us know.

No feedback whatsoever...

Thank you, @leisurman and @RandalV for testing!

I've pushed 📌 Update ACL dependency and fix some other issues in composer.json and *.info.yml Fixed to require ACL 8.x-1.1, which should make #6 work according to @leisurman's and my own testing.

salvis → created an issue.

salvis → created an issue.

Failed because of not having any tests.

Thank you for your report and patches, @RandalV!

I agree, something is completely broken here! With just ACL and FA, your patch allows opening Forum|Add, but it still crashes when trying to save the new forum. Also, the Moderator element is (obviously) not present on the Forum|Add page. This is the real issue!

Ignoring the absence of the Moderator element is not the right approach — it must be there for us to use.

Here's a new patch, please test it.

Thank you for the patches!

Why does $_SERVER['SERVER_SOFTWARE'] need to be cast to string?

Is this already fixed in the D8 version?

I agree. I'll do so when 2.0-beta1 is out.

Thank you for the nice summary of the situation.

We have a failing test that should pass:
https://www.drupal.org/pift-ci-job/2770495 →

Any ideas why this is failing?

Thank you for the help, but...

I have
[X] Show in project’s download table when branch is supported
checked on the -dev snapshot, but the Supported checkbox is disabled, most likely because we don't have any release yet:

Thank you for the new MR, @pfrenssen, this is what I needed, and All for getting here.

I'll create a BETA1 release.

Great, thank you, @gisle!

Personally, I don't think it is a good idea to encourage the contined use of versions of core that no longer have security support. But this is your project, so you set its policies.

I'm not encouraging people to stay behind, but I don't want to force them to upgrade either. There can be many reasons for not being able to or not wanting to update/upgrade.

And I'm really sorry if I caused pain with WSODs.

Ok, thank you for the investigation, @gisle.

Can we fix it rather than blocking it?

Thank you, @gisle!

I tried to run a test with PHP 8.2 and it failed miserably: https://www.drupal.org/pift-ci-job/2759320 →

Thank you for the positive feedback @gisle!

2.x is now the default branch. 2.x-dev is visible on https://www.drupal.org/project/acl/releases → , but d.o doesn't let me publish it on the front page.

almost nobody uses versions of Drupal 8 prior to version 8.9 anymore.

As of August 27, 2023, https://www.drupal.org/project/usage/drupal → shows about 40'000 sites using 8.x (x < 9) and 53'000 sites using 10.x.

I feel fine about not artificially blocking those 40'000 sites.

I am pretty sure that the the latest stable version of this project cannot be installed on core versions 8.0 - 8.7 because these versions of core don't know about the core_version_requirement key.

Choking on an unexpected key would not be very elegant...

Pushed to D10 and D8.

Thank you @Steven Jones!

Thank you for your feedback, @Stizzi!

I thought there was a deprecation issue with PHP 8.2, or maybe 8.3?

Here's a ^10 version.

Now we need to look into PHP compatibility...

Actually, I'm not sure about version compatibility. I think it should work for all D8 versions, but testing is available only for 8.9, and we don't get any feedback from users.

The word "only" in the OP is not mine, and as long as we don't have evidence to the contrary, I'd leave it at ^8.

Thank you, xeM8VfDh! :-)

And thank you for your help here, too!

mcdruid → credited salvis → .

mcdruid → credited salvis → .

salvis → created an issue.

Thank you, @pfrenssen, that's very helpful!

Back-port to D7.

Failed because of missing tests.

salvis → created an issue.

Port to D7.

salvis → created an issue.

Failed because of missing tests. Pushed anyway.

salvis → created an issue.

This should work. Also expanded some of the docblocks with desirable information.

salvis → created an issue.

salvis → created an issue.

salvis → created an issue.

There are compatibility issues with later PHP versions that are supported by D10. Fixing these will break compatibility with older PHP versions that are still supported by D89, and I don't want to do that unnecessarily.

Therefore this has to wait.

salvis → created an issue.

salvis → created an issue.

Port to D8/9 and use display account names.

Well, I guess I misinterpreted #4.

The feedback that we're getting is not exactly overwhelming...

Sorry, this slipped through the cracks, and interest wasn't that great, obviously.

Whoa, a 10-year-old issue — happy anniversary! ;-)

I've remove the version checking and I'm requiring >= 7.x-2.1 in forum_access.info of the upcoming release.

What a deafening silence here...

Sorry...