Problem/Motivation
Found here https://git.drupalcode.org/project/drupal/-/merge_requests/12445#note_55...
EntityListBuilder::getDefaultOperations is protected, but the ConfigEntityListBuilder subclass and all its sub classes override that visibility to public. This seems like an accident when this was initially added in https://git.drupalcode.org/project/drupal/-/commit/b504423ed07e9bb437e96...
Proposed resolution
Change all methods to protected somehow (BC?)
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|
Issue fork drupal-3538658
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
libbna commentedI will give this a try!
Comment #4
libbna commentedI’ve only changed the
getDefaultOperations()method of theConfigEntityListBuilderclass to protected. Is there any other place where this change needs to be reflected or updated?Comment #5
godotislateComment #6
godotislateOh, and a couple content entity list builders override as public as well:
Comment #7
godotislateI wonder that since these methods are public now, we can't just change them to protected right away, but need to trigger deprecations and add a CR that they will be changed to protected in D12.
Comment #8
acbramley commentedComment #9
libbna commentedHi @godotislate thanks for providing the whole list. So instead of changing it to protected should I add deprecated message?
Comment #10
berdirI'm not sure how the deprecation message would work. We'd need the differentiate the between internal and external calls, that sounds complicated and slow (checking backtrace?).
These were never meant to be called directly and doing so would be result in incomplete and broken results. Making it protected won't break subclasses, it's possible to extend the visibility of a protected method in the parent class.
I can't find any calls that aren't $this->getDefautOperations(), I'd say we either just do it or we don't bother and leave it?
Comment #11
godotislate@libbna sounds like you can go ahead and change all those methods to protected per #10.
Comment #12
libbna commentedSure. Thanks! I will do it EOD.
Comment #13
libbna commentedComment #14
godotislateThere was test failure, so I rebased. Test pass now, so this LGTM.
Comment #15
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #16
godotislateRebased.
Comment #17
acbramley commentedBack to RTBC
Comment #18
astonvictor commentedseems like all methods were updated
+1 RTBC
Comment #20
catchI think this is fine - the chances of someone calling these are very, very small. However just in case I've only committed it to the 11.x branch (will become 11.4.x) so there's plenty of time to discover if someone somehow is doing that.
Committed/pushed to 11.x, thanks!