Leave rule off for now as manual fixes are required.
Also temporarily disable prefer-const rule as that
will also require some manual fixes.
Change-Id: I8c3478f26f51287acb943bd38c9c1020c06b9f39
The PHP code should never see a `<span class="mw-headline">` node
since MediaWiki change If04d72f427ec3c3730e757cbb3ade8840c09f7d3,
but we have to support it for our old integration tests (T363031).
Improve code comments to explain this and move the handling to
one place, so that it can be deleted more easily in the future.
Follow-up to 08f61b2609.
Change-Id: I5ab9d3373a6911c1456c30d844b66576b278a1b5
Change the HeadingItem constructor to take a 'null' headingLevel
and store this internally with the constant. Change the JSON
serializer to convert this back to null.
Change-Id: I27508eed75d94b99c5189548919309f8da7deb75
We call CommentUtils::getHeadlineNodeAndOffset() before constructing
the HeadingItem in CommentParser, so the range's startContainer
is always the headline node.
Change-Id: I2afb6ba9100e785cd91f31d82f4cea59fa8b5443
This matches the PHP implementation and was only used in
one place (when fetching authors in new topic tool).
Change-Id: I9d9e774616112e8dc6ab4919846e3abecc24553d
1. Extend the JS modifier to allow adding top-level comments
(that is, replies to headings). PHP modifier doesn't do this
because we'll save the changes using paction=addtopic instead.
2. Subclass CommentController to allow adding a new heading and a
top-level comment underneath it at the same time.
3. A lot of ugly code in ReplyWidget to customize the interface
for this case. Much of it should probably be moved to
CommentController/NewTopicController.
Bug: T267595
Change-Id: I9c707bb7f7aae1b92c72fb4dee436490f8c8409b
We avoided fixing these because it causes changes in just about all of
the test data, which is annoying when reviewing or blaming changes.
But the previous several commits also caused changes in just about all
of the test data, so we might as well do this too.
Change-Id: I83b64d83b6f12c04dc06c0cadff7cdd89417e137
Our threads now also contain all replies to their sub-threads.
This is similar to how sections work in MediaWiki, where the parent
section also contains the content of all the lower-level sections.
We're going to need this for notifications about replies in a thread.
Bug: T264478
Change-Id: I241fc58e2088a7555942824b0f184ed21e3a8b6f
