Allow access to CEB::$validated from outside of the entity

Can't see any reason not to do this.

+++ b/core/lib/Drupal/Core/Entity/ContentEntityInterface.php
@@ -71,4 +71,12 @@ public function getLoadedRevisionId();
+  public function isValidated();

We can't add methods to an interface - its a BC break.

Hmm, I wasn't aware of that - it seems counter intuitive.

Will check with another committer.

Thanks for pointing it out.

The documentation for that is here: https://www.drupal.org/core/d8-bc-policy#interfaces

We decided on allowing that (where there's a base class we expect every implementation to inherit from) to avoid having to add a new interface (and deprecation) every time we add a new method. In theory this would seem more disruptive than adding new interfaces, but in practice it's worked out well so far.

Ok, can we have a change record describing the new functionality.

Then I think it's ready

Thanks

Think we can go back to RTBC then?

Should the change record provide a possible use case or a real world example? I often find it much easier to understand something with an example.

The reason we need the CR is because of the BC break, so the CR should cover that. The method is being added to ContentEntityInterface. ContentEntityBase includes a default implementation, so most content entity definitions won't be affected; however, anyone implementing ContentEntityInterface directly will now need to implement this method as well.

This actually makes me wonder if this is the right interface for this method. The parent interface FieldableEntityInterface is the one that provides the concept of validation. Should this method go there instead?

That makes sense. Thanks @hchonov. If the plan is to move them to the proper interface in D9, then let's please put @todos on them and create an explicit followup. (Also @see to the validation methods on the parent interface, because I had to go look for them.)

I thought a minute about how this would work in the continuous upgrade path. There isn't a BC break for implementors of CEI because they inherit the method when it's moved to the parent. But direct implementations of FEI are disrupted in this D9 change. I don't really think there's any way to mark a deprecation for this. Any thoughts on how we inform developers in advance in the continuous upgrade path model?

The CR updates will still be needed then also. We can include this information about moving the method in the future in the CR as well.

Thanks!

Different ways this could be done with the continuous upgrade path stuff:

1. Add the deprecation on ContentEntityInterface for 9.0.0 to be removed in 10.0.0

2. A new ContentEntityInterface in a different namespace with less methods, then ContentEntityInterface inherits from it in 8.x and not in 9.x

3. A new FieldableEntityInterface with the additional method. Have ContentEntityInterface inherit from the new interface, which in turn inherits from the old interface.

The trouble with #1 is that it's time-bound between opening 9.x and and releasing 9.0.0, and that it leaves the method until 10.0.0

The trouble with #2 is that for each method we want to remove from ContentEntityInterface, we could end up with a new interface in 8.x.

Trouble with #3 is it requires an instanceof check where FieldableInterface is type hinted and you want to use the new method, and it has the interface-proliferation drawback of #2.

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!