Part of meta-issue #2016679: Expand Entity Type interfaces to provide methods, protect the properties.
See the detailed explanations there and look at the issues that already have patches or were committed.
Add get*, set* and additional methods as it makes sense to replace the public properties (e.g. isSomething() and something())
---------------------
Please read the meta linked above. Put other information specific to this issue here, especially if there is anything complicated or different from the other sub-tasks of that meta.
---------------------
The focus of this issue is to add methods for base fields. See Entity/Comment::baseFieldDefinitions().
Adding methods for other properties will be saner to do after this is separate issues.
Not to be done in this issue, and done in other issues:
- removing redundant name token #920056: [comment:name] duplicates [comment:author], and the latter should use format_username()
- tidying up is_anonymous and is_preview #2170439: $comment->is_anonymous and $comment->is_preview variable should be removed or converted to be explicit properties with getter and setter menthods
Not to be converted at all:
- ->comment_body See @Berdir in #28 Why? Because body is a configurable field.
- ->changed->value to setChangedTime() See @Berdir in #28. Why? Because: It's only set internally. We dont want a public way to set it.
- ->seen in CommentLinksTest Why? It's only used in that one test, only ever set. Can be a separate issue to take it out.
- ->last_comment_name ->last_comment_uid ->comment_count ->cid ->last_comment_timestamp Why? Because: these are on node comment fields, not on comments.
- ->view in views.module Why? Because: is not on a comment object. Is part of an array used for theme alter. (?)
These are not converted here:
because this issue is focused on adding methods for base fields. Might be useful though, as separate issues.
- ->in_preview
- ->divs ->divs_final and ->depth Why? Additionally because maybe we shouldn't be doing that anyway. Can be discussed in separate issue.
- ->link ->rss_namespaces ->rss_elements Why Because in core/modules/comment/lib/Drupal/comment/Plugin/views/row/Rss.php ... those are internal only?
- ->date in CommentFormController
Not to be refactored:
- permalink() to getPermalink() while comment #44 of the meta points out that in general methods without get/set/has/is should do something, refactorings of those, if they are to be done, can/should be done in a separate issue #2113323: Rename Comment::permalink() to not be ambiguous with ::uri().
Other issues for bugs/things noticed:
Q: Why is the patch so large?
A: The size of this patch increased a bunch after #731724: Convert comment settings into a field to make them work with CMI and non-node entities went in. See #24
Q: What is going on besides a simple conversion?
A: Not much, but there are a lot of properties and a lot of code that accessed them. There is a little bit of standards fixing in near lines, but not enough to needs work it to take them out.
| Comment | File | Size | Author |
|---|---|---|---|
| #97 | comment-interface-patch-diff.txt | 3.96 KB | berdir |
| #97 | comment-interface-2028025.97.patch | 114.17 KB | berdir |
| #94 | comment-interface-2028025.94-interdiff.txt | 5.45 KB | berdir |
| #94 | comment-interface-2028025.94.patch | 114.19 KB | berdir |
| #87 | comment-interface-2028025.87.patch | 114.46 KB | berdir |
Comments
Comment #1
David Hernández commentedWorking on this.
Comment #2
David Hernández commentedHere is a first version of the patch, only refactoring the CommentInterface and the Comment class implementing it.
Comment #4
David Hernández commentedPHP syntax issues should be fixed now.
Comment #5
berdirLooks good, feedback below, mostly on documentation and naming.
Should start with verb in third tense, for getters usually Returns.
@return type for this is \Drupal\comment\CommentInterface|null.
All @return's need a description even if it's very similar to the method description.
For example in this case, I would suggest to keep the method description very short, e.g. "Returns the parent comment entity."
And the @return description can extend it additional with an " or NULL if there is no parent".
No need for the @todo here (it's already called parentId so the todo is weird).
Instead, let's move the @todo to CommentStorageController::baseFieldDefinitions(), where pid is defined.
Here the type is \Drupal\node\NodeInterface.
We have the generic language() method, I think we don't need to duplicate that.
This is a \Drupal\user\UserInterface.
All interfaces are in the main namespace directory, see above, Drupal\comment\CommentInterface in this case.
Possibly also name this setAuthorName(), to be consistent with getAuthorName()
Also add a setter for this?
We usually use getCreatedTime() and getChangedTime() for these.
Description doesn't match.
Not sure if we want to have a setter for this. We're setting it but only internally in the Comment class. It's not something that can be set really, because it's forcefully overwritten every time the entity is saved.
I'd go for setPublished(), that's what I did in NodeInterface.
this is not actually the node type, it's comment_$node_type, and that is covered by the bundle() method.
Changing the bundle is not something that's really supported, crazy things can then happen and it would essentially mean that we move the comment to not only a different node a but a node of a different type :) So I would leave that out, indicating that it can't be changed.
Comment #6
David Hernández commentedRenamed the patch file to be a correct description.
Fixed issues from #5.
Comment #8
David Hernández commentedStill working on this, just a quick update. There were some inconsistencies on the naming of the getters/setters that are now fixed. This will fix most of the tests, but still lots of things that need to be reviewed.
Comment #9
David Hernández commentedStill working on this, just a quick update. There were some inconsistencies on the naming of the getters/setters that are now fixed. This will fix most of the tests, but still lots of things that need to be reviewed.
Comment #10
David Hernández commentedStill working on this, just a quick update. There were some inconsistencies on the naming of the getters/setters that are now fixed. This will fix most of the tests, but still lots of things that need to be reviewed.
Comment #11
David Hernández commentedSorry for the duplicated comments. drupal.org was acting funny...
Comment #12
David Hernández commentedI missed a couple functions renaming. That should fix a few more tests, but still no green light.
Comment #13
seantwalshChanged to needs review so test runs against patch.
Comment #15
David Hernández commentedNew patch. Still not completly green, but getting close.
Comment #16
David Hernández commentedOk, this might be green.
Comment #18
David Hernández commentedI think that's it.
Comment #19
yesct commentedWhy are setters, like setAuthorName, returning the type or null?
I think sometimes |null makes sense, but when it's return $this, it's just the class?
See @Berdir's comment in #2028037-11: Expand FeedInterface with methods
I see in this issue in #5
it was said to make the return \Drupal\comment\CommentInterface|null but I think that is only in the case where the description was like "if this is a reply to a comment" like for getParent and getParentId. And the null is what is returned if it is not a reply to a comment.
Comment #20
David Hernández commentedUnassigned
Comment #21
johnennew commentedLooking at this now - patch needs a reroll.
Comment #22
berdirYou might want to only keep the methods on the class and interface for now. There's a critical issue that's completely turning comments upside down and this would conflict quite a bit with that.
Comment #23
johnennew commentedTaking myself off this one - say when the comment patch goes in and I'll come back again if I can.
Comment #24
tim.plunkett@ceng, it went in last night!
Comment #25
johnennew commentedPicking this up now.
Comment #26
johnennew commentedHi, new patch ready for review. I can't create an interdiff, probably because its too different now?
Comment #27
larowlanPretty sure there's a #value field in the comment form-controller called is_anonymous, so in this instance its a property from submitted form values.
This is a field, we can switch it to ->get('comment_body') or leave as is
There is no property for this, but its set when the 'preview' button is clicked. We should look at how node does it or add a in_preview property with get/set
I agree, lets make it TRUE or FALSE only
Comment #28
berdirIf that's the case, then I doubt that's set. The NG (now ContentEntity) form controller only sets explicitly defined fields, everything else is ignored. You have to override and extend buildEntity() to set more stuff, see NodeFormController.
Yes, comment_body is a configurable field, shouldn't get it's own method.
I don't think getEntityType() and ..Id() as method names work. That's extremely close to entityType() but something else.
Is mentioned before, we need a term for the entity that a comment is attached to and then us that. parent? host?
Note that https://drupal.org/node/2078387 also adds getAuthorId(), getAuthor() and setAuthorId() to comments and does some conversions.
We shouldn't add a setChangedTime() method. There are some cases where it is set, but it's not really a public API.
According to this logic, if the status is NULL then it would be published? +1 on isPublished() to return bool btw.
I think this kind of logic should be hidden in getAuthorName(), see getUsername() on users. Then we don't have to set somewhere above.
So we have a name and an author token which is more or less the same?
No need for the !empty() check, if ($parent_id = $comment->getParentId()) is fine. !empty() is a left-over of the stdClass $entity object times.
We could even add a getParentComment() method?
similar for this, not yet sure how to name it, but there should be a method to get the entity.
get*EntityId()
get*EntityType()
get*Entity()
Depending on *, "Entity" might or might not be necessary.
Ah, you do have a method, just not used yet there :)
This, unfortunatly, doesn't work.
the field definition of entity_id is a lie.
No idea why it got in like this, but it's wrong. entity_id needs to be simple integer_field and getEntity needs to manually load the entity based on the other two methods.
Hint: If you add the new methods at the end or near the end of the class, then the diff might be much easier to read as it should first remove all properties and then add the new methods instead of this mix. Try it out.
Comment #29
larowlanvote 1 commentedEntity
Comment #30
andypost+1 to getCommentedEntity()
Comment #31
tstoecklerWith threaded comments, comments can sometimes be on other comments yet getCommentedEntity would return e.g. the parent node, right? So not sure getCommentedEntity() works well in that case.
Comment #32
berdirgetCommentedEntity() works for me, in threads, we have getParentId() and possibly getParentComment().
Comment #33
johnennew commentedThanks all for your comments - I'm going to add all these items into this patch then rather than creating any follow up issues.
Comment #34
johnennew commentedin PHP, this is actually TRUE ... (0 == NULL), so the logic is right, despite reading badly! Will work out the boolean return.
Comment #35
johnennew commentedI've gone for getCommentedEntity(), getCommentedEntityId() and getCommentedEntityType() as suggested.
I've left these modifications - will probably have to remove when this patch goes in?
OK, I've removed this and set back to setting the value directly. What about setCreatedTime()?
isPublished() returns a bool now - I've updated the places it was used in the code and checked the workflows and all seems well (tests seem to be passing too)
I copied the same process as getUsername() in User Entity as suggested so it happens in the Comment class and and updated the external versions.
I've dropped the name token and updated the tests.
I removed getParentId() and added a hasParentComment() method instead since getParentId() was mostly used for determining if there was a parent at all. This makes the code easier to read. To get the parent comment itself there is now a getParentComment() as suggested.
As per 1 above, added getCommentedEntity*() methods.
Made use of the getCommentedEntity() function in the appropriate places.
entity_id is now an integer field defined in the Comment::baseFieldDefinitions() function. getCommentedEntity() loads the entity as suggested.
Woah, pro tip FTW!
This leaves the $comment->is_anonymous and $comment->is_preview variables still to tidy up. I think this patch is good to go if these are moved out to follow up issues, the patch is getting quite big with a number of changes. Or I can add to this one if everyone is happy with that.
Comment #36
berdir- setCreatedTime() is a valid use case, so that is fine.
- Yes, you can leave the author stuff, one of those two issues will need a re-roll if the other one gets in but that's fine
- Not too sure about removing the token. That's basically an API change and one that is ugly to take care of because we don't know where that token was used. Maybe better to keep and add a @todo that says it's identical to author and should be dropped.
Everything else sounds fine, haven't looked at the patch yet.
-
Huh, why is that necessary? get('changed')->value should work fine? (changed->value too, but I prefer get() in those methods).
Comment #38
johnennew commentedPut name back in, its the same code as author
It isn't necessary and I've taken it out.
Test fail because of the hook_comment_* - needed to go through and update all implementations of the hook_comment_* in node, tracker, rdf and forum modules.
Comment #39
andypostFor the 'name' token we have a separate issue #920056: [comment:name] duplicates [comment:author], and the latter should use format_username()
Comment #40
berdir38: drupal8.comment-module.2028025-38.patch queued for re-testing.
Comment #42
johnennew commentedRerolled patch attached
Comment #43
a_thakur commentedPatch in comment #42 did not apply.
Comment #44
a_thakur commentedChanging to Needs work.
Comment #45
a_thakur commentedPlease ignore this file.
Comment #46
berdir42: drupal8.comment-module.2028025-42.patch queued for re-testing.
Comment #48
berdirLots of conflicts.
Comment #50
berdirComment #53
berdirAnother merge conflict...
Comment #55
berdirCopy & paste stupidity
Comment #56
berdir55: comment-methods-2028025-54.patch queued for re-testing.
Comment #58
larowlanreroll
Comment #61
larowlanShould fix the threadLock test
Comment #63
larowlangrumble grumble
Comment #65
larowlanpasses locally, but clearly testbot is different kettle
Comment #66
larowlanRe-roll after removal of comment_alphadecimal_to_int() etc went in
I'm happy this is ready
Comment #68
larowlan66: comment-interface-2028025.67.patch queued for re-testing.
Comment #70
larowlan66: comment-interface-2028025.67.patch queued for re-testing.
Comment #71
yesct commenteddid I see somewhere else we are not using the constants, but using true and false?
I looked at this logic change from else to elseif, and got confused by the whole first bit of comment_preview(). It's like it loads based on the name and then sets the name..
We shouldn't refactor comments to make more sense in this issue, so as long as it is correct, I guess it is fine.
Here is the logic in context:
why was the logic rewritten like this instead of the original if/else?
So code inspection in an IDE does not warn that the return value might not be set? (chx in irc says code inspection is smart enough, so that wasn't the reason)
sometimes getX() is called once, and then the var used. more often in its ... ? filter_xss($c->getX()) : $c->getX(); with two calls to the get. We could later do a follow-up to make it consistent if that would be useful.
adding issue for this todo. #920056: [comment:name] duplicates [comment:author], and the latter should use format_username()
huh. comments get attached to specific comment fields on the entities they are attached to? (larowlan says yes) Can we have more than one comment field on an entity? (larowlan says yes) Do we "enable commenting" by adding a comment field? (answering my own question: add the field, then edit settings on that field to enable commenting.) So. That leads me to think that the getCommentedEntity() returns the entity that field is on. and comments on different fields might be attached to the same entity. Maybe I'll draw myself a picture.
a) commment is mis-spelled. I fixed it.
b) is the field ID a string? My guess is it would be an int, like getFieldId(). But larowlan, via irc, says. it might be getFieldId that the type is wrong on. "FieldId is of the form {entity_type}__{field_name}" I'll leave it as string for now. Maybe we need to change the return type of getFieldId(). Seems Entity/Field has $id which is a string, but a different format. OK. so talked more to larowlan. Idea for followup is: since bundle() might be the same as getFieldId(), getFieldId() might not be needed and we could repurpose it "to map node__comment to node.comment, and make it useful, and a place to document this."
c) missing period. I added it.
no parent is no longer determined by checking if (depth) is 0. I almost changed the comment about the if... but
I read the next bit of code about max depth, but I could not decide if noting something with no parent had a depth of 0 would be useful. I left it.
Not done yet. Posting what I have so far so I dont lose it.
Comment #72
yesct commented(@cend I think it's ok to assign it to me, it's been a while. :) I have some changes I'll post after I go through the rest.)
Comment #73
yesct commentedoops. meant to save this comment I had open in another window earlier.
--
I started reviewing this. It is a lot to read through.
in #35 by @ceng
grepping for is_anonymous and is_preview I dont see is_preview at all, and in
core/modules/comment/lib/Drupal/comment/CommentFormController.php
These were also discussed in #26, #27, and @Berdir says in #28
The patch has no instances of is_anonymous and is_preview, so it wasn't this patch that took it out. Maybe it was another issue.
I'll create an issue as was mentioned and we can sort it out there. Here it is #2170439: $comment->is_anonymous and $comment->is_preview variable should be removed or converted to be explicit properties with getter and setter menthods
I'll keep going with the review. I have a few small changes so far.
--
also started updating issue summary.
Comment #74
yesct commentedI changed a few first line function summaries to be third person verbs.
read a little strange that the docs mentioned title and not subject. larowlan suggested checking what the column is called in {comments} table in comment_schema, which is in comment.install It is 'subject'. So changing the docs.
This made me wonder if $commented_entity->entityType() should become $comment->getCommentedEntityType(). I decided it wasn't necessary and I didn't change it.
changing that comment from entity to current nid seems out of place. I dont think it is node specific. changing comment back.
seems like this should be:
$this->setChangedTime($this->getCreatedTime()); Oh, but I see in comment #5 @berdir mentioned something related. and this is in preSave(). Ok.
I stopped at CommentActionTest
posting the patch so far, and taking a break.
Comment #75
yesct commentedcoming back to try and finish review.
Comment #76
yesct commentedtrying to clarify what is *not* being done in this issue, and why. please edit the summary and fill out the why where the reason is missing.
Comment #77
yesct commentedI think $comment->uid->target_id in the assert should be $comment->getAuthorId()
seems strange to be doing these direct access to properties. but I see them set in comment.module (around line 912).
phew. read the whole thing.
next, I wanted to try the hint for patch producers in the meta which says "Ideally the visibility of the properties which are getters and setters in this case can force people to use the property directly and instead of using it directly, use it as a method so while working on the patch you can make the visibility as protected and change them back to public before RTBC"
But that is assuming there are properties. And here, looks like ->set(' ') and ->get(' ') are used not properties that could be set to protected.
So I guess I cannot make a patch that can "check" we have gotten all the replacements and not missed any. ... maybe a grep could be done?
might as well guess at something...
$ ag "comment\-\>" coreA:
comment.module template_preprocess_comment()
should use getAuthorId() ?
as mentioned previously #2078387: Add an EntityOwnerInterface might do them? but maybe we should change there here too, and then at least they are all done, and the which ever issue gets in first can go, and the other can be rerolled to account for that.
B:
in CommentFormController form()
should that be getCreatedTime() ?
C:
in CommentFormController submit()
should use getAuthorId() ?
D:
in CommentFormController submit()
should use setSubject() ?
E:
in CommentViewBuilder buildContent()
should that comment be replaced with getCommentedEntity() ?
Like (line wrap would need correcting):
or maybe
// Load entities in bulk. This is more performant than using
// $comment->entity_id->value or $comment->getCommentedEntity() as we can load them in bulk per type.
F:
in CommentAdminOverview in buildForm()
should that use getCommentedEntityType() and getCommentedEntityId() ?
G:
in core/modules/comment/lib/Drupal/comment/Plugin/views/field/Link.php
Are these (entity_id and entity_type) going to cause a problem?
H:
in CommentCSSTest
Should that be getChangedTime() ?
I:
In CommentLinksTest
->status, if that were ->status->value, I would say it should be ->isPublished() But I'm not sure.
->seen ? huh? is that just in this test, and so can be ignored?
J:
in CommentNewIndicatorTest
K:
in core/modules/rdf/lib/Drupal/rdf/Tests/CommentAttributesTest.php
Looks like these were missed?
L:
in rdf.module
Looks like this should be getParentComment()->id()
M:
in EntityCrudHookTest
is this direct set of subject ok? CommentTokenReplaceTest uses setSubject(). Maybe this should also?
N:
in tracker.module
Should that use getChangedTime() ?
Comment #78
berdirWow, lot's of letters.
#77
2. This is information on the comment field on a node, not comment entity. So that's OK, don't touch that stuff.
A) Hm, author interface provides a clean solution for the whole hunk, this would just change the hack a bit. I'd rather avoid commit conflicts.
B) Yes.
C) set...(), but also taken care of in the AuthorInterface issue I think.
D) Should probably live somewhere else but yes, setSubject()
E) Yes, just method is fine.
F) Yes.
G) Cases where there is no ->value are special, there two reasons for that: a) It is broken and untested (because it's then working with an object) b) It is not a comment entity object, but something else, like a raw fetched database row. Checking the context, and seeing the argument type hint and $comment->id() above, we know it is a) in this case. Should use the method and should have a follow-up to add test coverage for this code block.
H) Yes.
I) Another case of a comment field, you can see that it's $this->node->comment, not $this->comment or $comment, so it's part of a node object and a different kind of status. Ok. ->seen is also ok (at least in this context)
J) Yes, same as H)
K) Yes, should be updated too. I guess this test is newer than the early patches.
L) There is a specific method for these checks: hasParentComment(), see other uses of that method.
M) Well, it's OK in "it works", but as you found it, let's replace it too, yes.
N) See G), in this case, it's b), tracker.module still has a lot of direct database queries and raw value objects, so don't touch it here.
Comment #79
berdirEntityOwnerInterface landed (yay!), so this will need a pretty tough re-roll). This might not be the one you want to pick if you're doing your first re-roll :) I'll see if I have time to do it and also apply the points above.
Comment #80
berdirHere's a re-roll, probably messed up a few things, will also need more work after recent renames and I have some ideas on how improve this further, but enough for tonight.
Was hoping this would get a bit smaller, but most author/owner changes have additional changes around the. It's also a bit a mess of author and owner now... :(
Comment #83
yesct commentedNot sure if @Berdir had a different place to put this hunk... but it didn't go there. :)
edit: I also diffed the patches 74 and 80 and noticed these couple niffty improvements
1.
berdir says:
saves code and avoids a call out to that function
so unit tests or so would be easier/possible
2.
Comment #85
berdirOk, I think this should fix those test fails and I also tried to address everything that was pointed out above and a few more.
Comment #87
berdirUps.
Comment #88
yesct commentedI looked at the interdiffs in #85 and #87 And they look great.
Issues to open for later might be
#78 D (a minor should live else where),
#78 G (needs fix and test coverage)
added to issue summary.
Updated issue summary especially regarding possible issues to be opened (not necessarily "follow-ups", but to be opened.)
Looking really good. What's next? One more final look by.. ? @larowlan
[edit:] I didn't delete those. See #2191619: New on-page comment form is deleting all hidden files :(
Comment #89
andypostThere's meta issue to clean-up tests #1847540: [META] Clean up comment module tests and decouple from node
Comment #90
berdirThanks @YesCT. Note that D and G *are* addressed as far as this patch is relevant for them (changed to method calls, fixing the bug in case of G), but doesn't add test coverage.
Comment #91
andypostUpdated summary about permalink #2113323: Rename Comment::permalink() to not be ambiguous with ::uri()
Issue is RTBC and needs change notice draft, suppose @larowlan will fire rtbc and set 'avoid commit conflicts'
Comment #92
yesct commented@Berdir, ah yes. :)
tiny issue summary clarifications.
I'll start a draft change record. (following https://drupal.org/contributor-tasks/draft-change-record)
[update]
Actually "New Entity Field API based upon the Typed Data API" https://drupal.org/node/1806650 covers this and the meta is already listed there.
@Berdir says we dont need to clutter that with each one of the sub issues.
Looked for an example in one of the others for what to do. In #2028037-53: Expand FeedInterface with methods @webchick says
Maybe what we can do here is list the change records that we edit.
"Comment settings are now a field. Comments allowed on any entity type." https://drupal.org/node/2100015 might be one.
Comment #93
larowlanwould have been nice to use String::checkPlain and the corresponding XSS util while touching these lines, but unless we need another reroll, leave as is
out of scope: missing t() here, please fix if re-rolling
Can this use CommentInterface::getCommentedEntity now?
Mental note: we need to inject the User storage controller here (needs follow up).
I believe new coding standard is these should just say
@return $thiswith no description/other commentsi don't think this is any different to CommentInterface::bundle(), I think we can replace all calls with ::bundle() instead and remove the duplication?
love it!
extra space?
Mental note: we really need to be able to inject into Entity classes. entity_load (puke)
schmick!
Can be simplified to CommentInterface::getCommentedEntity()?
Comment #94
berdir1. Hm, looked at it, but we only touch a part of those lines, so I'd prefer to leave it for this issue.
2. This is used as a css class, so no :)
3. Yes :)
4. Yeah, note that the code will look a fair bit more complicated then, though, because there's no loadByName() method.
5. We do. Fixed. I did leave it on getParentComment(), because that's a different comment. Same for getCommentedEntity().
6. We had quite some discussions on the node issue related to this and came to the conclusion that it makes sense to have node specific getType() and getTitle() methods there, because they often make much more sense in a context where you have a comment and are working with that specific field. For example, someMethod($comment->getFieldId()) explains itself much better than someMethod($comment->bundle()), then you first have to know what the bundle actually is. Term doesn't follow that, but that's because it happened before the discussion in the node issue. We also have getSubject() and don't use label() here.
8. Fixed
11. Yes :)
Comment #95
larowlanAssuming bot agrees
Comment #96
alexpottcomment-interface-2028025.94.patch no longer applies.
Comment #97
berdirRe-roll, conflicted as expected in tracker.module, this just re-replaces the changed code with the method, so only changes in the removed code, see attached patch diff.
Comment #99
berdir97: comment-interface-2028025.97.patch queued for re-testing.
Comment #100
yesct commentedlooks like this passed the testbot. so setting to needs review.
Comment #101
berdirI think we can go back RTBC here, there's a diff above that should that nothing in the patch actually changed, only the previous code did.
Comment #102
xjmDraft change records are now required before commit. I searched for
CommentInterfacein the existing change records and none of the matches for that will need an update.So I think these are all the deleted thingers that we'd need to search the change records for?
https://drupal.org/node/2100015 only references comment count, which is not changed per the summary, so that one is still okay I think.
Comment #103
alexpott97: comment-interface-2028025.97.patch queued for re-testing.
Comment #104
xjm@alexpott asked me about #102 and whether I deliberately didn't set the issue NW. To clarify, I was replying to @YesCT's comments in #92. https://drupal.org/node/1806650 is the change record for the meta and is nicely written to cover all these changes, linking off to the API documentation, so this issue already is covered as far as change records go. (Though, that change record needs to have a reference to this issue added.)
It would be good for someone to look around a little in comment change records for references to the removed comment member variables in #102, but based on my review of what's currently there, I think that need not block commit and the issue is still RTBC.
Comment #105
andypostFiled related critical #2197723: Comment::getFieldId() should return actual field ID
Comment #106
alexpottThe DX win means that this should be major. Can someone add this issue to https://drupal.org/node/1806650?
Committed f3732c6 and pushed to 8.x. Thanks!
Comment #107
andypostadded reference to https://drupal.org/node/1806650
Comment #108
berdirNote: I suggested to not add this issue to that change notice before, because this is part of a meta issue that is already referenced, adding every single issue in there would mean that we add like 10 additional issues and there are already a lot. This conversion is not that relevant compared to a lot of the other issues referenced there.