PHP doesn't care much about the name (in terms of case sensitivity)
but I think we should make sure the names of the method should be as
they're in their definition.
Change-Id: I6e38d8be64efaec4200471f2d3007275d7ddecec
When creating the various notification sources,
the server was indexing them with wfWikiID() but
the client was using wgDBname to find which one
is local and which are remote. On some wikis,
like TWN, wfWikiID() includes a db suffix so
the JS app on Special:Notifications is failing to
find the local source and errors.
Bug: T167336
Change-Id: Id60f723b615fb7db54a6f17b1c1be20dfe98e36c
That way we'll be able to mix it into non-query modules as well.
Unfortunately, PHP traits don't let overridden methods call their
original versions, which had to be worked around in a few places:
- $this->foreignNotifications can't be initialized in the constructor
any more, so it's now lazy-created through $this->getForeignNotifications()
- Adding the 'wikis' parameter to getAllowedParams() now happens by
calling getCrossWikiParams() rather than calling the parent
- Overriding getForeignQueryParams() can't call the parent anymore, so
instead we just inline it
Change-Id: I415e6d921819fc1f7869c7d2f8bb62830a84c2a1
There are about 200 of such generic "array" type hints in this code base,
the majority in @param tags. I started with what I found most relevant:
@var and @return tags. I might continue working on this later, but
wanted to stop for now to keep this patch moderately small.
Change-Id: Iff0d9590a794ae0f885466ef6bb336b0b42a6cd3
See Iae0e2ce3. Since Echo master requires core master, this just depends
on the master patch instead of trying to maintain BC.
Depends-On: Iae0e2ce3bd42dd4776a9779664086119ac188412
Change-Id: Icc088b31bc99e03ac88dfb44329df55318bf99b5
This was causing a strict standards warning due to inconsistent
parameters.
Rename it to getUnreadNotificationPagesFromForeign . Since
this does a data transformation (it doesn't have the same response
structure as the parent), I decided to rename it rather than
make the parameters match.
Change-Id: I259def82b933cbde0e94a49f9a9d6f754f681808
Make it optional through the unpgrouppages parameter, so that
generic usage of the unreadnotificationpages API is still possible.
In the front-end, store which display title maps to what set of titles,
and pass in the full set rather than just the display title when
filtering by a page.
Bug: T137502
Change-Id: I443ca00ff5e5d36fd6910101226358942e6aa8ee
To allow individual notifications to be
marked as read/unread or moderated,
bundles are created by grouping associated
notifications when they are fetched for display
instead of when they are created.
From a product perspective, this change doesn't
introduce moderation or expandable bundles but
it counts each individual notifications.
For instance, the bundled notification
"3 new topics on PageA" now counts as 3
notifications.
Bug: T93673
Bug: T120153
Change-Id: Iacd098573efd92bb1e3fcd7da4cd40cea9522f15
Adding up numbers in the front-end is not enough, because it could
be that not all pages are listed (it's a top 10). So get the
total count from the backend.
Change-Id: Ibbc76691ef88333b92132a514fdba3cde3797e10
The query shouldn't be too expensive: it'll use an index to narrow
down the resultset for 1 user. After that, it'll be sorted based on
a grouped by value, but that should fit in memory: it'll never be
on more than 2000 entries, which is the max amount of notifications
per user.
Change-Id: I271ea7f7a6e010284739bfce02c4ec8a077148fc
