🇷🇴Romania @claudiu.cristea

claudiu.cristea → created an issue.

Fixed.

claudiu.cristea → created an issue.

Credits

claudiu.cristea → created an issue. See original summary → .

At this point events don't provide any benefits than hooks don't cover already.

Except "stop propagation"

Thanks

Maybe related ✨ [PP-1] Enum cases stored in config Postponed

The CR also needs to adapted

#30 is right. When this issue has been created there was no enum support or, at least, we’ve still supported old PHP versions. I think this should be rescoped to deprecate and convert some, if not all, to enums

joelpittet → credited claudiu.cristea → .

claudiu.cristea → created an issue.

Credits

Thank you

Tank you. This is RTBC

This has been fulfilled in 📌 Support Drupal >=10.3. Modernize the code Active . Closing as duplicate.

I was about to open a ticket in this regards. Will cut a release to include the changes

Thank you for review, @joelpittet. The work will continue in 📌 Modernize code (part 2) Active

Should we move this to 2.x? No idea if 8.x-1.x will get a stable release ever

claudiu.cristea → created an issue.

The current development branch is 2.x. Let's move the work there. We will evaluate later if this needs backport to 1.x

Unassigned

Postponing on 📌 Support Drupal >=10.3. Modernize the code Active

The MR affects ~200 files. That's already huge and hard to review. I'm proposing that we split scope to 📌 Modernize code (part 2) Active . See IS to learn what was covered din the current MR

claudiu.cristea → created an issue.

Adding credits

Released in 3.0.0-beta4

Thank you. Merged

Thank you. If you’ve tested and it’s working it would help to mark the issue as RTBC so that we can merge the changes and release a new version

@jrochate @jerrac, could you test the latest version? I've made some changes compared to the first attempt.

@jrochate, thank you for testing. However, now the tests are failing and I need to investigate this. Also, it would be good to get some input also from @jerrac

Ok, looks like a bug. I'm into it

OK, I got it. It seems you can use only one provider at a time. Closing.

claudiu.cristea → created an issue.

claudiu.cristea → created an issue.

This looks like an API change which could break backwards compatibility for 3rd-parties. I would suggest to create new methods which are returning AccessResultInterface and deprecate the methods returning boolean

I did but not sure is what you've expected. Pleas Seth this issue as fixed if it's OK

On a clean install, with PHP 8.2.27 and 10.4.4, I cannot reproduce the issue. Please add more details about your installation.

It's very weird that those path of the code is taken with Drupal 10.4

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

It looks like FormState's submit handlers should be an array when set, but I think it's possible that they're not set, like if a form doesn't define submit handlers for some reason

Looking at FormBuilder, I see a form always initializes the form's submit handlers as array. My guess is that another module alters the form breaks this. The bug is not in CAS module, submit handlers should always come as array. That said, it doesn't hurt if we add this check on CAS code. But, again, I think this has uncovered a bug in other module (or even core) it might be worth investigated.

I have created the MR but I have an suggestion in MR

Please check the code for usages of CasHelper::EVENT_PRE_USER_LOAD and CasHelper::EVENT_PRE_LOGIN in other places than cas and cas_attributes modules. These constants are deprecated and should be replaced according to the message.

Is blocked by ✨ PHP 8.4 support Active

• Added testing with PHP 8.4
• Fixed PHP 8.4 deprecation "Implicitly marking parameter ... as nullable is deprecated, the explicit nullable type must be used instead"
• Depending on a forum module version that is PHP 8.4 compatible
• Fixed some PHPUnit data providers to be static.

claudiu.cristea → created an issue.

Fixed,

claudiu.cristea → created an issue.

Moving to 1.1.x as we drop Drupal 8 & 9 compatibility

Outdated

core_version_requirement needs also to be adapted

This was fixed in other issue

Please provide a patch. Thank you

This might have been fixed in 📌 Automated Drupal 11 compatibility fixes for error_page Needs review . Could you test with that branch?

Not clear what's going on. Need more info

Weird. For me works for years. Please follow the README carefully.

Obsolete

Twig cannot be used. We need a low-level theming. Please see the README

This has been fixed 📌 Automated Drupal 11 compatibility fixes for error_page Needs review . Closing as duplicate

Fixed version

I have tested the middleware part. It's nice but for some errors acts too late (see 💬 Does not seem to work when database is down Active ). For this reason, the solution to set the handlers in settings.php is better.

For the beautify part the module allows customization of the template. We should only provide a minimal template.

This is "Won't fix" but thank you for contribution.

IMPORTANT: Please check carefully https://www.drupal.org/node/3514863 → before testing because there are some changes needed for settings.php, even it should work with the current settings.

To test, just set an invalid MySQL password

Some exceptions are occurring very early, before Kernel gets a chance to initialize. Such a case is the database connection error. In that circumstance, the extension classes are not yet added to the class autoloader, making it impossible to load the classes.

We had to make the whole code more robust.

Let's switch the error & exception handlers to procedural code. Let's keep the current classes as deprecated to ensure BC.

Thank you for reporting

This bug was cause by the fact that we are forking in this module the core/includes/errors.inc file. I've discovered that the file has diverged. I've added a test in this MR (see .gitlab-ci.yml) that detects if the core's file will change, so that we can adapt our code.

Please refer to #6 🐛 Undefined constant "DRUPAL_TEST_IN_CHILD_SITE" Active for testing the changes.

I've added the fix. However, tests are not covering all types of errors, such as user and notices. It would be good if who's gonna review this is able to manually test all possible scenarios. You can use the testing module to simulate errors. It's easy to run the site now:

ddev start
ddev poser
ddev symlink-project
ddev install

Do some changes to templates and go and visit the pages from error_page_test.routing.yml

Released in 2.1.0-beta1

Hiding patches

Thank you. Merged in both, 2.0.x and 2.0.1

Some changes are requested. Also changed the base branch to the new 2.1.x so that we can drop also the Drupal 9 support

Released in 4.1.0-alpha1

Thank you all!

Fixing target branch

Adding credits

Two issues here:

1. It would be good to address also #8 📌 Automated Drupal 11 compatibility fixes for duration_field Needs review because is listed by upgrade_status as an issue
2. To make sure everything works, we need to add a .gitlab-ci.yml that ensures testing for both, Drupal 10 and 11.

Yes, please (followed by a release, of possible)

I see changes in tests but tests are not enabled. It needs a .gitlab-ci.yml in order to be approved.

Thank you

Looks good

Fixing credits

Thank you all

Fair enough. Thank you for catching & fixing.

Either we implement a full deprecation path, or we keep it as it is and remove the @todo

A full deprecation path would look like:

1. Remove the initial property value assignation.
2. CasRedirectData to implement RefinableCacheableDependencyInterface and use RefinableCacheableDependencyTrait
3. Remove all properties and methods already inherited from trait
4. Add config object as 3rd param in CasRedirectData::__construct() which will default to NULL
5. In CasRedirectData::__construct() check if config object has been passed. If not set it to \Drupal::configFactory()->get('cas.settings') and trigger deprecation (see https://www.drupal.org/about/core/policies/core-change-policies/how-to-d... → )
6. In CasRedirectData::__construct(), add config as cache dependency of CasRedirectData
7. In redirector add $data (CasRedirectData) as cache dependency

But I'm OK also to keep the property as it is, but then remove the TODO

I have a question, see the MR