Drupal 11 compatability

Tests pass, gave it a manual test and works as expected on D11 - fixed the phpcs and cspell jobs.

Would be awesome to get this an as I am working on several other issues that would benefit from having the tests running.

Beautiful! Thank you.

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

+1 for merging, successfully tested on a Drupal 11 PHP 8.3 instance with Views Data Export module.

You can test the xls_serialization module easily in Drupal 11 using composer.

Add the following lines to your composer.json repositories section:

  "repositories": [
    {
      "type": "vcs",
      "url": "https://git.drupalcode.org/issue/xls_serialization-3481580.git"
    },

and then run:

composer require drupal/xls_serialization:dev-3481580-drupal-11-compatibility

mably → changed the visibility of the branch 3481580-d11_ready to hidden.

Just merged the Drupal 11 compatibility fixes, thanks to all!

@jhedstrom should we make a 8.x-1.6 release or switch to 2.0.0 semantic versioning?

@mably looking at the changes you committed, because you renamed the setConditionalFormating method, that's technically a BC break, so I'd suggest that, you either need a 8.x-2.0 version, or 2.0.0 if you were being strict about things.

You could add the originally named method back, with a deprecation notice, and then all the other changes would be totally fine to go out in a 8.x-1.6 version, that might be the nicest way forward here?

Hi @steven-jones, thanks for having a look at the code.

You're right, I'll readd that renamed protected method with a deprecation message.

@steven-jones could you have a look at my MR above before I merge it? Thanks.

Looks good to me!

Merged.

@mably ah, oops. You could just change the constructor back, and then using a non-dependency injection-y way to get that service, and then release a 8.x-1.7, and then work out if you really need to adjust the constructor in a 2.x

Ok, I will do that. Thanks.

Re the typo in the protected method there is a policy for bc changes which mentions that protected methods are internal and subject to change https://www.drupal.org/about/core/policies/core-change-policies/bc-polic... →

I think it's totally fair to fix a typo in that method without needing a major version bump.

May be some people override the default Xls service?

The rollback issue is here : 📌 Rollback BC breaking change for encoder constructor Active

Rollback code is ready for review:

https://git.drupalcode.org/project/xls_serialization/-/merge_requests/29...

Thanks.

The Drupal BC policy → currently states this for constructors:

The constructor for a service object (one in the container), plugin, or controller is considered internal unless otherwise marked, and may change in a minor release. These are objects where developers are not expected to call the constructor directly in the first place. Constructors for value objects where a developer will be calling the constructor directly are excluded from this statement.

Lets move this convo to 📌 Rollback BC breaking change for encoder constructor Active since the constructor change was nothing to do with this issue

Automatically closed - issue fixed for 2 weeks with no activity.