Problem/Motivation
In #2929496: Add dedicated interfaces to group methods dealing with revision translation and clean up the related documentation we cleaned up the interfaces providing revision and translation support to the Entity system. However, to complete the clean-up an API change would be needed: changing TranslatableStorageInterface::createTranslation() to accept a \Drupal\Core\Entity\TranslatableInterface parameter instead of a ContentEntityInterface parameter. However this is technically a BC break.
Proposed resolution
Perform this change anyway, as it may be considered an acceptable change in broad terms because:
TranslatableStorageInterface is not an @api interface and it has an implementing base class;
- no existing code will actually break, aside from implementers not extending the base class, which is consistent with method additions, or overriding the method (unlikely);
- API consuming code should keep working in the future, as
::createTranslation() is a quasi-internal method that almost no one will actually need to use directly;
- implementers just need to keep returning an instance of the same class of the
$entity parameter for everything to work smoothly.
Remaining tasks
Write a patch
Perform reviews
- Obtain release manager signoff
User interface changes
None
API changes
public function createTranslation(ContentEntityInterface $entity, $langcode, array $values = []); // Before
public function createTranslation(TranslatableInterface $entity, $langcode, array $values = []); // After
Data model changes
None
Comments
Comment #2
plachHere's the patch.
Comment #3
plachComment #4
plachLet's try again
Comment #5
plach#2929496: Add dedicated interfaces to group methods dealing with revision translation and clean up the related documentation was committed.
Comment #7
plachComment #8
plachThis change was already RTBC'ed in the parent issue, however @catch wanted to discuss with @xjm about it.
Comment #9
plachComment #10
plachUpdated IS
Comment #11
plachComment #12
larowlanComment #14
plachBot fluke
Comment #16
plachClearly testbots are -1 on this change.
Comment #17
xjmWhat are the implications of not doing this? It really does seem like a BC break to me, and a "clean-up" is not justification for a BC break in my mind.
Comment #18
catchSo there's a way to do it without an API break, but it's long-winded:
- we could add a new interface/method name and deprecate the old one, however there's no better name so it would be a worse/less self-documenting method name.
- because we've deprecated the current method, in 9.x we can then copy the new method signature back, leaving the one we just added deprecated.
- Then in Drupal 10 we remove the method we deprecated in 9.x, and end up in the same situation as if this patch was committed as-is - with the same method name we have now, but a new signature, each step preserving backwards compatibility.
There are a further two options:
1. Defer the signature change to 9.x, on the basis that while it breaks the bc policy, once the change is made a module will still work with both 8.x and 9.x (in the same way modules sometimes have to make changes for compatibility with minors). I didn't think of this option until just now though.
2. Don't change the method signature at all.
Comment #19
plachThis is not super-urgent and right now the committer team is pretty busy with the 8.5.x lifecycle so we agreed to get back to this when things calm down.
Comment #22
amateescu commentedJust opened a somewhat related issue: #3028319: Specialized entity interfaces should extend the main EntityInterface
Comment #29
xjmDefinitely should not have been assigned to me all these years. Also does not need to be postponed. :)
Comment #30
ravi.shankar commentedAdded reroll of patch #4 on Drupal 9.4.x.
Comment #33
catchThis has had release manager review, removing the tag.