Automated Drupal 10 compatibility fixes

I've created a fork and applied the changes in the automated patch in #2 and opened up an MR

The changes in the patch file are solid, let's get this one committed.
Personally I would be dropping support for D8

The MR also adds a composer.json file. I am not sure whether this is of critical importance.

Any chance of a D10 compatible release for this great little module - we need it!

Took @bserem → 's suggestion and pushed the commits. Would like to see this get merged as well.

Added as patch file for easy use.

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

I tested the patch as this blocks D10 upgrade right now for us. It's working fine, RTBC+

Yes, let's get this done. Thanks.

Patch for D10

Just for anybody whose update to D10 is blocked by this module, it might be worth checking the module's code: the module is basically one-line of code that is easily replicable if you have any custom modules or themes in use on your site to put it in and need to get to Drupal 10 quickly.

Or use the lenient plugin which tells composer that the module is compatible with '^8 || ^9 || ^10' instead of what is defined in the module code right now.

I have pushed a fix to dev for D10 if you could test it thanks. Will do a full release once its confirmed to be fine.

The pushed fix adds the following:

core_version_requirement: ">=8"

Please note that the "core_version_requirement" key is not understood by versions prior to Drupal 8.8. I believe that if you want to add an unbounded core_version_requirement-key it should instead be this:

core_version_requirement: >=8.8

the patch in #15 looks good to me, as it also adds a composer.json file, but I'd gladly accept the patch in #11 either.

Can we get this merged and released soon please?

Neither the patch in #11, nor the one in #15 looks good to me. As for #11, a composer.json file should not be added if the project has no third party dependencies.

The patch in #11 says "this module is only compatible with Drupal 9 an Drupal 10", it doesn't give any indication that it's compatible with Drupal 8.

-core: 8.x
-core_version_requirement: ^8 || ^9
+core_version_requirement: ^9 || ^10

Let's look towards getting that merged and release. We shouldn't have such a long running issue for a module that is only 1 line of code.

You are right. My bad.

The patch in #11 by ikit-claw is OK, and should be committed.

However, I reviewed comment #18. This is also by ikit-claw, and this (wrong) fix is already committed. You can see it in the repo here:
https://git.drupalcode.org/project/disable_html5_validation/-/blob/8.x-1...

It wrongly claims compatibility with anything 8.0 and higher. I stupidly assumed that ikit-claw had committed his own patch #11, but what was committed was actually something else.

I am perfectly OK with patch in #11 being committed. The status "Needs work" was based upon comment #18 and the line of code that was actually committed.

It is confusing when the maintainer posts a patch for review, then goes ahead and commits something completely different. But I should have been more careful.

Thanks Gisle & Mark I will bump it 9+ as we will be doing a new release.

I see that the just released 2.0.0 now has an open ended "core_version_requirement" >9.

That's fine for Drupal 9 and 10, and will probably will not need updating for the future Drupal 11.

So then, can we close this issue as there is now a D10 compatible stable release?

I'd prefer if the core version requirement was ^9 || ^10. We can't be sure this will work for D11, D12, etc.

In any case, >=9 is RTBC and committed and released, so good enough for me.

Well, while the form_alter() hook, and the current way of attribute changing in a form won't be deprecated in the future, the module will continue to work.

The merits of an open constraint given as "core_version_requirement" is debated elsewhere, please see: 📌 Add a composer plugin that supports 'composer require-lenient' to support major version transitions Active , where the pros and cons of this (and other) approaches are neatly summarized in the issue summary.

Cool. Let's close this so.