It needs to only look at the end of the added comments, and ignore
whatever is going on at the beginning, since the only thing it really
cares about is a functioning "Reply" button at the end.
Bug: T363285
Change-Id: Ia337be754deda741617d1343972f3e0a21c41b05
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
When permalink data is available, display a permalink using
the current page title, instead of a plain link to the section
at the time of subscription.
Consolidate and clean up some existing permalink code.
Bug: T306373
Change-Id: Ie2f63cbfdbfa703530205201dfcfb0e5ad053b35
Mixing different binary boolean operators within an expression
without using parentheses to clarify precedence is not allowed (T358966)
Change-Id: I9e9c9531ab0fa373606b19a5865cec748a3f36ff
MediaWiki's PHPCS plugin requires documentation comments on all
methods, unless those methods are fully typed (all parameters and
return value).
It turns out that almost all of our methods are fully typed already.
Procedure:
1. Find: \*(\s*\*\s*(@param \??[\w\\]+(\|null)? &?\$\w+|@return \??[\w\\]+(\|null)?)\n)+\s*\*/
Replace with: */
This deletes type annotations, except those not representable
as PHP type hints such as union types `a|b` or typed arrays `a[]`,
or those with documentation beyond type hints, or those on
functions with any other annotations.
2. Find: /\*\*/\n\s*
Replace with nothing
This deletes the remaining comments on methods that had no prose
documentation.
3. Undo all changes that PHPCS complains about (those comments
were not redundant)
4. Review the diff carefully, these regexps are imprecise :)
Change-Id: Ic82e8b23f2996f44951208dbd9cfb4c8e0738dac
There's now a different rule for the same thing in
mediawiki/mediawiki-codesniffer v43.0.0. Also document the reason for
the override. Follow-up to 8b00546749.
Change-Id: I392ee10639ffda6de55b091555e8c3cadd2af485
Place the "[subscribe]" links used when the 'VISUALENHANCEMENTS'
feature is disabled in the same DOM position as the "🔔 Subscribe"
buttons used when it is enabled.
Recent changes in MediaWiki core caused them to move inside the
`<span class="mw-headline">`, breaking some gadgets (T13555#9615648).
Moving them all the way outside should avoid problems.
I don't remember why we placed them inside the `<h2>` tags, but there
doesn't seem to be any reason to do it now. It must have been easier
that way before we introduced the `<div class="mw-heading">` wrappers.
Note that I'm keeping the `<!--__DTSUBSCRIBELINK__...-->` placeholder
comments in case it turns out there is a reason, and we need to revert
this change. If everything goes well, they can be cleaned up in change
Ie3348671c486de5bbd9f286772a8d145e3609bd5 later.
Bug: T13555
Change-Id: Idb23b0f5e438d35ed74569ff50302c7fad5ba688
We no longer need to support toggling visual enhancements without
reloading the page, so we can remove the extraneous set of buttons
to reduce HTML size.
Bug: T322457
Change-Id: I54e57c754c54b7e611069f9832d1ebabf141a396
In this case, the generated regexp would match the '/local' part in
the generated URL. Prefixing 'https://local' is no longer necessary
since 10899af666.
Add tests for this, and some tests to cover T261711 as well.
Bug: T358321
Change-Id: Idf54deba13f30b799b7b8d17de1897bc90f95701
We never a DatabaseThreadItem back into the database. If someone
wants to do this in the future they should be thinking very
hard about it first.
Change-Id: Ie073c030905e31d81cb75bc9c46d5bb7c5d85b04
This appears to reference the retry that happens due to
REPEATABLE_READ, but that seems like an implementation
detail so not really useful to have in in the function
name, nor does it disambiguate it from another function.
Change-Id: Iacc95b74f25c166545734818efb1b30e18a1754e
This was intended as a temporary config to facilitate a
staged rollout (T331635) which has now completed.
Change-Id: I432ec0a24b8e8c12b62556ff6703abff32a2fced
We already supported plain headings without the 'mw-headline'
wrappers, but now we need to parse the 'id' from a different
attribute.
Needed-By: If04d72f427ec3c3730e757cbb3ade8840c09f7d3
Bug: T357723
Change-Id: If85f89c40834618f23dc0ace2e599efb3b6d5ed4
In certain cases the parser could go back rather than forward after
finding a signature, causing it to find the same signature forever
until it ran out of memory.
Test cases coming later in a separate patch.
Bug: T356884
Change-Id: I8ac72b05e5e4ed45e6119c012a69708c9d8eda29
* Keep the information about this in the API result, which we were
previously omitting
* Use it instead of duplicating the logic client-side
Bug: T356131
Change-Id: I7e7342e9d94a171b5ef56e646871c18c8c39c44c
In production, indexing the full history of every page will take
too long, so we can't rely on being able to find the target heading
text in the history of the current page.
When this search fails, fall back to the following searches:
* The heading appears in the current revision of a sub-page
* The heading appears anywhere on the wiki, but only once
Bug: T356276
Change-Id: I90e92cb9c85aaf6fb2355f842450981bbe6abf2d
This will be present in parser cache output and can
sometimes be mistaken for user page links.
Bug: T356142
Change-Id: I800b23d8466f72affcadfa336aab07abf7f8d79e
This reuses the existing comment parser code in HookUtils and makes the
DataUpdatesHooks and EventDispatcher code consistent.
Bug: T354792
Change-Id: I58a71b26b3f47898a68a29098a8105ee844403dd
