For compatibility with Parsoid's document abstraction (Parsoid may
switch to an alternate DOM library in the future), don't explicitly
create a new document object using `new DOMDocument`; instead use
the Parsoid wrapper `DOMCompat::newDocument()`. This ensures that
the Document object created will be compatible with Parsoid.
There are a number of other subtle dependencies on the PHP `dom`
extension in DiscussionTools, like explicit `instanceof` tests; those
will be tweaked in a follow-up patch
(I3c4f41c3819770f85d68157c9f690d650b7266a3) since they do not affect
correctness so long as Parsoid is aliasing Document to a subclass of
the built-in DOMDocument. Similarly, the Phan warnings we suppress
do not cause runtime errors (because of the fixes included in
c5265341afd9efde6b54ba56dc009aab88eff83c) but phan will be happier
once the follow-up patch lands and aligns all the DOM types.
Bug: T287611
Depends-On: If0671255779571a91d3472a9d90d0f2d69dd1f7d
Change-Id: Ib98bd5b76de7a0d32a29840d1ce04379c72ef486
The user interface only allows you to subscribe to level 2 headings.
But we would generate events for whatever heading was the closest,
If it was e.g. level 3, no one would receive that notification.
Now we generate events for the closest level 2 heading, or we don't
generate the event at all if there isn't one (if the only headings are
of level 3 and below, or level 1, or if the comment is added before
the first heading on the page).
Bug: T286736
Change-Id: Iae99853070e353ab81c9cc29ef1d53c877adfc66
This is the same method as used by VisualEditor
(ve.init.mw.DesktopArticleTarget.prototype.replacePageContent).
Bug: T275698
Change-Id: Idcf7c79b8d5565b0ae36c6e9d42b66662c1acc8d
We used an internal API requests to fetch page content because it was
easy, but there's no way to guarantee that it returns data from the
primary database.
Use ParserOutputAccess::getParserOutput() to fetch from cache if
available. Also, use canonical output instead of user-specific,
not that it should matter.
Bug: T285895
Change-Id: I7dcd9659be77746dc2a0c4eeae2319887936b555
* Move getTitleFromUrl() from parser to utils. It's a generic method,
the PHP equivalent is already in utils.
Bug: T277371
Change-Id: Id960e5f60af02bdeb0a3a68f43b7a695eb035139
I noticed that the NWE new section editor would open sometimes even
though we attempt to prevent it. This way seems to work more reliably.
Change-Id: I0ce1640b8c1dd098bf3f0d41dc4fdc276a0c5fd5
Problems with the current setup:
* Each CommentController must have exactly one link.
For T277371 we want multiple, and for T282205 we might want zero.
* CommentController objects must be constructed immediately.
They are implemented to make this pretty fast, but it's still
unnecessary work to do on page load.
* Only one link may be activated at a time, and activating one affects
the styling of others, so CommentController has to use global state
to check if it can set up and to update them.
Instead introduce ReplyLinksController, which knows about all reply
links and which one is active, and emits events that allow
CommentControllers to be constructed on demand.
Change-Id: Iabdeded2e71e598ae78703a6ff9410d0cfba397c
Considerations:
* Using the same edit notices as VisualEditor, except 'anoneditwarning'
* No extra frame/styling is added (on Wikimedia wikis, the notices
often already have them)
* 'talkpagetext' message is not shown (on Wikimedia wikis, they are
mostly about signing your posts with tildes, which is not necessary)
Bug: T269033
Change-Id: Idc5ff29f093c75a14c3a3479888295d5bf630f6d
