Config is stored with serialized data

I thought I'd seen this issue in the queue already, but couldn't find it again, apologies if this is a duplicate.

I've got a patch in the works, and the config is great!

content access already sends the config loading through a couple of functions, so we only need to change out those places and it'll work really nicely.

There's some roughly working code for discussion.

I wonder if actually this should go as a 'third party' setting on the NodeType entity, and then let that handle the config storage for us etc.

Due to recent changes MR !9 produces a merge error. I've rerolled it. Please find the reroll in the attached patch.

Would appreciate a review.

So thinking about this more, I really think this should be a third party setting on the NodeType entity, and then it handles all the storage for us, which removes a ton of code etc.
I really don't think my original approach of adding another config entity type was the right way to go here!

I'd suggest:

1. Release 2.0.0 without this change
2. Work on the change, getting the config into the third party settings collection
3. Release a 2.1.0 that contains an upgrade path etc.

That then doesn't hold up the release, but then also reduces the maintenance burden going forward.

@gisle however, you're the module maintainer here, so what do you reckon, should we aim for being a third party setting instead?

Yes, I am the module maintainer (not because I am the most qualified, but because I need this module, and nobody else seemed to be willing to do the job). This is not an area where I claim to be an expert, so I have to rely to the judgement of others, such as yourself.

Lately, I've also become aware that serialized data may be insecure (see, for example, related issue 🐛 unserialize() is insecure unless allowed classes are limited. Use a safe format like JSON or use the allowed_classes option. Fixed ). That's is another strong argument for moving it from serialized data and into a separate settings file.

As for implementing as a third party setting on the NodeType entity, I think that sounds as a better solution, and if it can be done, I m prepared to wait for that.

As for issues holding back a full 2.0.0 release, they are tracked here: 🌱 [meta] Content Access release 2.0.0 Fixed . I haven't added this issue as a blocker. The major one seems to be getting automated tests working again.

PS: I've looked at your profile page and it is impressive. I open to adding a co-maintainer to this project if you're interested.

Thanks @gisle, that makes sense!

Thanks for maintaining this module, it is much appreciated.

I'd be up for being a co-maintainer if you'd have me. It does seem like content access (and acl) need some love to bring them into the modern PHP and Drupal 9 world proper, and they can probably go back into hibernation :)

Thanks for offering to help out! I've added you as co-maintainer.