Changes 3: New Version class

[bastianallgeier]

This PR …

• 🚨 Merge first: Changes 1: Refactor content storage to use new VersionId class #6436
• 🚨 Merge first: Changes 2: Plain Text Handler Refactoring #6439

Refactoring

• New Version class which inherits most of the logic from the ContentStorage handler and will eventually replace it.

Outlook

• This PR will be followed by a later PR to improve the Version class and add additional unit tests (Changes 6: Version class improvements and unit tests #6450) The steps are separated to make sure that all other unit tests always keep passing. It's sometimes a bit of a chicken and egg situation here.
• Once the ContentStorageHandler methods accept a Language object instead of a string (Changes 4: Refactor PlainTextContentStorageHandler to use Language object #6448) the Version class also needs to pass a Language object instead of language codes. It will therefor get a new protected Version::language() method that is mostly adapted from ContentStorage::language() but will always return a Language object - even in a single-language installation. There's a new Language::single() method coming up in Changes 4: Refactor PlainTextContentStorageHandler to use Language object #6448 for that.
• The Version class will also inherit a few more specific logic methods from ContentStorage in preparation of removing ContentStorage entirely
  • ::deleteLanguage
  • ::touchLanguage
  • ::contentFile
• Version::modified will later return null if the version does not exist.
• Version::ensure will later use ContentStorageHandler::ensure Changes 10: New MemoryContentStorageHandler #6457

Breaking changes

None

Ready?

• In-code documentation (wherever needed)
• Unit tests for fixed bug/feature
• Tests and checks all pass

For review team

• Add changes & docs to release notes draft in Notion

[lukasbestle]

With our current translation architecture (automatic field fallbacks to the default language) we can only lock all language versions together to the same user when editing.

So e.g. when creating a changes version from an existing published version, the changes version must always contain all languages that the published version has.

I don't fully understand how this $version->create() instance method is going to be used. To ensure that the version is complete and consistent, I feel like creation needs to happen atomically, e.g. with a static Version::create(ModelWithContent $model, VersionId $id) method that then takes care to take the content fields from the right source (changes takes content from published, drafts start with empty content, published cannot be created standalone) and to ensure all languages.

[bastianallgeier]

You are right. This was implemented before we talked about returning null for non-existing versions. That would have meant that the version instance could be initalized and the creat method could have been called like that before it exists.

[lukasbestle]

How do we proceed here? I guess we will produce a lot of merge conflicts if we change it here. So maybe let's continue and add it to the todo list?

[bastianallgeier]

Yes, sounds good to me. We already have a todo list item in Notion. I think it makes sense to fix it in a separate PR when we get to that point.

[lukasbestle]

What is the use case for deleting a single language? Do we already support that in v4?

[bastianallgeier]

Tbh I mostly just moved over what we had in ContentStorage here. I think you are right and we don't need it so far. This would also clean up the method some more. I'm not super happy about the ambiguous usage depending on what's passed.

[lukasbestle]

I'll check the code and concept history again. If there is no reason, I'll remove it. We can still add it back if we ever need it.

[bastianallgeier]

Did you have time to check it already or should I have another look at it?