This might be a matter of personal preference. Not sure if it's
worth it. Both is well readable. On the other hand, the method
exists. Why not use it?
Change-Id: Id66fc6c888db6ae1cf28e60a51f90d9ae2cdb6ee
MediaWiki's PHPCS plugin requires documentation comments on all
properties, unless those properties are typed.
This has potential to introduce bugs – in particular, because typed
properties without a default value will throw an exception if their
value is accessed before it's defined, while previously they defaulted
to null. I fixed this when I found it (making them nullable and null
by default), but I may have missed some cases.
Change-Id: If5b1f4d542ce3e1b69327ee4283f7c3e133a62a0
Change code to match the documented consensus formed on T321683:
https://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP#Exception_handling
* Do not directly throw Exception, Error or MWException
* Document checked exceptions with @throws
* Do not document unchecked exceptions
For this extension, I think it makes sense to consider DOMException an
unchecked exception too (in addition to the usual LogicException and
RuntimeException).
Depends-On: Id07e301c3f20afa135e5469ee234a27354485652
Depends-On: I869af06896b9757af18488b916211c5a41a8c563
Depends-On: I42d9b7465d1406a22ef1b3f6d8de426c60c90e2c
Change-Id: Ic9d9efd031a87fa5a93143f714f0adb20f0dd956
When a comment almost exactly matches the range of an
accidental complex transclusion consisting only of
pages from the 'Template' namespace and wikitext fragments,
I think we can safely allow replying to the comment.
Even if this turns out to be incorrect in some cases,
the failure will be more graceful after the changes in T313100:
instead of potentially duplicating contents from a template,
the worst case now is that the reply will appear in the wrong
place (at the end of the transclusion).
Bug: T313093
Change-Id: Ie8da09d74a652d893fd8c3e2435ef6cb70fad64a
We can't use these is class method function signatures, but we
can use within the functions themselves.
Change-Id: Ic24e47d6647226172a3bfacd81398d26143d98e4
The implementation in Parser doesn't descend into sub-thread.
Re-use the getThreadSummary method in ThreadItem and traverse
the thread properly.
Bug: T298617
Change-Id: I318d9012eb83f37ccbe463923524ef2e9f995ced
This changes a vast number of test expected-outputs because it affects
the order of the keys when serialized.
Bug: T315400
Change-Id: I6ad2cded6ba7cb2cc5e5ba37ea60f4b18ecc26be
We can no longer change IDs so easily, because they're stored in the
permalink database, so remove this mechanism to make sure it's not
accidentally used in the future.
Change-Id: I392ee1f49c48fc2f23d05e9a37c643438b4f2b9a
Rename ThreadItem to ContentThreadItem, then create a new ThreadItem
interface containing only the methods that we'll be able to implement
using only the persistently stored data (no parsing), then create a
DatabaseThreadItem. Do the same for CommentItem and HeadingItem.
ThreadItemSet gets a similar treatment, but it's basically only for
Phan's type checking. (This is sad.)
Change-Id: I1633049befe8ec169753b82eb876459af1f63fe8
