Our documentation generator Doxygen is not able to understand @var tags
on constants. A constant is neither a "variable", nor is it possibly to
specify an allowed type for a constant. The type of a constant is strictly
derived from it's value. There is no way to change it, other than changing
the constant itself. There is not much value in repeating the type either.
If it's critical to know the type of a constant (which is a very rare
situation), that should be better explained in the comment.
Doxygen strips all @… tags it does not understand, and renders everything
else as a plain string. This makes it possible to use something like:
/**
* @const Description…
*/
But this is not different from:
/**
* Description…
*/
Change-Id: I4531d4f6b2ab2aca7a62f13f10a655f31c4d6a7a
So $config is used instead of $conf for consistency and this
is how it's used across many many Wikimedia repos (exts) and
even in core.
Change-Id: Ia8e7335bf6892628e0a8b5d901776d726a8ad743
This does make generic `array` type hints more specific when possible.
I'm also applying my personal best practice to not have any @return
documentation on test @dataProviders. These don't provide any useful
information, and can't. The best type we could use is `@return array[]`,
but that would be the same for every single data provider. Copy pasting
these comments around is of no real value.
Also it was already inconsistent as some did not had this comment.
Change-Id: Id401c7e32493b6a9faaf6d47cddc01e2227102af
This is a prerequisit for the later patch Ie0ccb03.
Any JavaScript code can check this feature flag via
mw.config.get( 'wgPopupsReferencePreviews' )
Bug: T213415
Change-Id: I17687c62cc8d738a4eb41738c9ce6662a5ec68d8
This makes the following code work much better in IDEs, e.g. it's now
possible to click method names and actually go there.
Change-Id: Iddbe838f1402c5017ffeb3bc03b4a017b05d8b02
The code literally explains itself. The comments don't add anything
to this. They are more distracting because one must read them first
to understand they don't contain anything.
Change-Id: I6f152962ec634ae15d2bff4472e332453cb9b0bf
I figured a single "@covers ::__construct" in PopupsContextTest should
be enough, especially since this constructor is super trivial.
There is nothing to test in NullLogger. I also removed the duplicated
documentation as it does not really apply, and is still available in the
base class.
Change-Id: I9a2e4b06e5bfd015efa4a92ba802c942290ec49d
Somhow the testIsTranslatedTitleBlacklisted start to fail, the test
looks like it's broken but because of some reason it used to work.
For now let me fix the test because it blocks merged, and later
I'll try to investigate whats wrong.
Changes:
- testIsTranslatedTitleBlacklisted() has to define blacklisted
pages in canonical way (eg: Special:Preferences, not in a language
variant)
- use MediaWikiServices::getSpecialPageFactory() as
SpecialPageFactory static calls are deprectated
Bug: T203522
Change-Id: I0db1481c96c9c0e27364d028a57c1178865741ba
Changes:
- ignore autocreated flag and always set the popups visilibity state
CentralAuth will create users with `autocreated=on` when user logs
into different wikis
- do not call saveSettings(). AuthManager will call
$user->saveSettings() s after calling all hooks.
Bug: T191888
Change-Id: Iac753ebbaaf175636fdc3e20d8f37883771c33d2
The PreferencesFormPreSave hook now may return any HTMLForm
subclass, not just a PreferencesForm. It may be the new
PreferencesFormLegacy, or the future PreferrencesFormOOUI.
Change the function signature to accept any HTMLForm,
which seems to fix saving of preferences.
Bug: T195580
Change-Id: I41e37d78d87ab8965995c6e19ef76db87f7616fa
PagePreviews are visible to anonymous users, we would like to match
the same experience, when user creates a new account. On account
creation we mark PagePreviews settings to ON or OFF (configurable
via PopupsOptInStateForNewAccounts settings). With that approach
we can provide the best experience for new users, and keep existing
users happy (not enabling feature by default for everyone).
Bug: T191888
Change-Id: I39f42aa7268ce59c51f038048025ccf1bdf16481
No longer needed. We can't turn something off again for people
now they expect it to exist.
Clarified usage instructions of PopupsEventLogging to make sure
it's more scary given the implications
Bug: T173952
Change-Id: I7be005b79da498d8e7b7df8f18b60c1327636a2c
Popups is out of beta feature and this code is no longer needed.
Removing code is the happiest activity a developer can do.
Other changes:
* Remove redundant type field on extension.json
(If not set, the extension will default to the "other" section.)
* Repurpose `name` with `namemsg` and make use of existing i18n
messages
Bug: T193053
Change-Id: Iea832cd1f37b0e7df6ff95efd66e4a1ff2a9004e
On all wikis Popups use Restbase as default gateway. In that case we
do not require the TextExtracts nor PageImages extensions. Code should
reflect that.
Bug: T190818
Change-Id: If4ce8f709b2ca1bb3cc381afa5e80e978adf2498
Allow developers to use different endpoints for summaries
= developer happiness
This is useful for the following use cases:
* A developer wants to test against a production endpoint via
CORS
* A developer has setup an API where REST is hosted elsewhere
e.g. http://localhost:6927/en.wikipedia.org/v1/
* A user wants to create their own REST summary compatible
endpoint
* A wiki e.g. wikidata wants to use a different endpoint which is compatible
with the summary endpoint.
We are unlikely to use it ourselves on Wikimedia wikis (the
default should suffice) but this will be a powerful tool for
When not configured this will continue to work as per normal
Change-Id: I8a7e12fbc43cddbac678e0d7b81d1e877b747b22
* New action added PREVIEW_SEEN
* The action will be used to signal that a page view needs
to be recorded.
* PREVIEW_SEEN is a delayed action which is triggered
as a side-effect of the previewShow action. It is only dispatched
if the user is still previewing the same card and the page
related to the card has preview type `page`
* The pageview changelistener is added when
$wgPopupsVirtualPageViews is set to true.
* The page view changelistener listens for page views and logs
them using EventLogging when needed using
https://meta.wikimedia.org/wiki/Schema:VirtualPageView
Note:
* Currently if a user has enabled the DNT header, the
event will not be logged. There is ongoing discussion on the
ticket and fixing this will be addressed separately.
* Only title and referrer are logged in the initial version.
The task demands that "namespace" is logged but this information
is not provided by the summary endpoints we use so will need
to be added later (if indeed needed) either via a change to that
endpoint of by using JavaScript to parse the URL.
Bug: T184793
Change-Id: Id1fe34e4bdada3a41f0d888a753af366d4756590
* The 'help' parameter expects a string, not a Message object. It
seemed to be working, but caused fatals when switching the
preferences form to the OOUI implementation (T117781).
* Use 'help-message' instead, which also avoids using the global
request context for Message objects.
Bug: T117781
Change-Id: I5b2e44df35a2696da0e7ba8394eccf41914f6dda
Changes
- when verifying title use canonical names for pages in
special namespace
- improve unit tests to verify canonical names and translated titles
Bug: T170169
Change-Id: I49592133eb8286eacf04fd3034df091f7ef2aa50
This caused random extensions to not be able to load any ResourceLoader
modules (or do other things) on a random subset of pages and wikis.
Follows-up 29770a3.
Bug: T173411
Change-Id: I8dfc1085cb7d902f9e9be8a71324dc4cd850a500
Introduce PopupsAnonsExperimentalGroupSize config variable. This defines
a population size who will be subject to experimentation. If the group
size is undefined or 0 (default) and PopupsBetaFeature is false
(default value) Popups will be enabled for everyone. If it is any other
value, half that group will see page previews.
Drop the config variable PopupsSchemaSamplingRate - we will now only
EventLog when an experiment is occuring. This means we can simplify the
MWEventLogger class as shouldLog will always be truthy. Given server
side eventlogging is only used for preference changes
traffic should be low and not need sampling.
Introduce getUserBucket which determines whether a user is in a bucket
on, off or control based on the value of
PopupsAnonsExperimentalGroupSize. Add tests showing how these
buckets are calculated.
Caution:
A kill switch wgPopupsEventLogging is provided for safety.
It defaults to false. Before merging, please check if any config changes
are necessary.
Bug: T171853
Change-Id: If2a0c5fceae78262c44cb522af38a925cc5919d3
Introduce a config variable `PopupsPageBlacklist`. Previews code won't
be shipped to pages listed in the config variable.
Bug: T170169
Change-Id: Ia8342b55c682f444ba79e959dcc1180527a31374
Changes:
- removed ugly PopupsContext::getInstance
- removed ugly PopupsContextTestWrapper helper
- defined all services inside ServiceWirings
- fixed unit tests to test classes directly or use MediawikiServices
Change-Id: Ie27e28bb07aebe01014848c290369b1b1f098e9b
Changes:
- introduced new UserPreferencesChangeHandler class that listens to
PreferencesFormPreSave hook
- introduced wrapper for EventLogging extension plus NullLogger when
EventLogging extension is not availalbe
- when user changes PagePreview to disabled system will trigger
disabled event
Bug: T167365
Change-Id: I63faecb0495eb30a9fc2763e7ddf3944baf7f55a
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingParamComment
* MediaWiki.Commenting.FunctionComment.MissingParamTag
* MediaWiki.Commenting.FunctionComment.MissingReturn
* MediaWiki.Commenting.FunctionComment.ParamNameNoMatch
* MediaWiki.FunctionComment.Missing.Public
* MediaWiki.WhiteSpace.SpaceBeforeSingleLineComment.NewLineComment
Change-Id: Id9e98b7a4e87d00c63e7b509506c23f12cf0d380
Refactor existing Restbase gateway and extract shared logic into
shared Restbase provider. Also introduced new createNullModel()
which defines an empty preview model.
Additionally improve naming in new gateways/formatter so function
names are more explicity.
* Htmlize() became formatPlainTextExtract() as it should be used
only with plain text extracts
* removeEllipsis() became removeTrailingEllipsis() as it removes
only trailing ellipsis.
* src/gateway/index.js defines gateways by configuration name stored
in extension.json
Bug: T165018
Change-Id: Ibe54dddfc1080e94814d1562d41e85cb6b43bfc1
Depends-On: I4f42c61b155a37c5dd42bc40034583865abd5d7a
Introduced PHPCS check in CI - using same configuration as in
MobileFrontend. Additionally fixed wrong code style.
Change-Id: I0c879553d355c2a277fcc4349a93e85c65eb2291
Tests are basically unchanged, except for some stubs on beforeEach.
Supporting changes:
* Bring stubs from the mediawiki library for mw.Uri,
mw.Title.newFromText and mw.RegExp into stubs.js
* Remove hook onResourceLoaderTestModules given there are no resource
loader test modules after migrating processLinks.test.js
Why bring stubs from real source? This is not optimal. It could be the
case that the stubs would need to be updated at some point in the
future. That's why in the comment of each stub, it is specified where it
came from, and what was changed to make it work. It is not optimal but
it should help with a future update if necessary.
Also checked the history of the stubs and these three stubs are very
stable with a small commits per year, usually adding some extra
functionality (not breaking changes) (the rest of the commits are
docs/format stuff), so the core behavior that we rely on here shouldn't
change in a fundamental way. See the github links:
* https://github.com/wikimedia/mediawiki/commits/master/resources/src/mediawiki/mediawiki.Uri.js
* https://github.com/wikimedia/mediawiki/commits/master/resources/src/mediawiki/mediawiki.Title.js
* https://github.com/wikimedia/mediawiki/commits/master/resources/src/mediawiki/mediawiki.RegExp.js
Right now this stubs allow us to bring the test to run in isolation in
node.
The initial plan was to do change the test to be less test-case oriented
with dependencies on mediawiki.*.js and not to bring fake "real" stubs,
but after looking into it, given that:
1. the test cases in the test seem pretty informative showing the kind
of links that popups accepts
2. the stubs are acceptably easy to bring in, and are pretty stable
I decided to go with this approach initially to finish the migration
without changing the meaning of the tests.
If we want to remove the stubs and morph the test to verify stub calls
and move the test cases to documentation on the source, I'll tackle that
on a future commit.
Bug: T160406
Change-Id: Ieea378c9b7fec9116222b4a099c226d1f1131f65
MediaWikiGadgetsDefinition does some basic gadget name sanitization
and we have to do the same when checking "is gadget enabled for user"
Changes:
- sanitize gadget name same way as
MediaWikiGadgetsDefinitionRepo::newFromDefinition() does.
- add try{} catch() when loading gadget as getGadget might throw an
exception
Bug: T160081
Change-Id: Ia7a57e9dcfa3b25129d6d2bf75795372fad2b251
As noted in T160406, the only QUnit tests that requires a running
MediaWiki instance is the test for mw.popups.processLinks. The function
itself is isolated from the rest of the codebase.
Now, as noted in T162876#3182198, during boot the
ext.eventLogging.Schema module is loaded asynchronously with
mw.loader.using. Since boot is unconditional and happens ASAP this
happens when the tests are loaded and run.
In the short term this can be avoided by not making the tests depend on
the entire codebase. The long term solution is laid out in T160406.
Supporting changes:
* Bundle assets with webpack@2.4.1.
Bug: T162876
Change-Id: If1ee1853ba7a9b2a66b24bb93b4e6062b92b0dba
For logging to work:
1. $wgWMEStatsdBaseUri needs to point to a valid statsv endpoint,
e.g. 'https://en.wikipedia.org/beacon/statsv'.
2. $wgPopupsStatsvSamplingRate needs to be set. Note that the codebase
already contains the EventLogging functionality, which is configured
separately. Separately configuring different logging mechanisms
allows us to avoid sampling mistakes that may arise while choosing
one or the other. For example, let's say we want to use EventLogging for
10% of users and statsv for 5%. We'd sample all users into two
buckets: 50/50. And then we'd have to set the sampling rates as
20% and 10% respectively, only because of the bucketing above. To avoid
this kind of complications, separate sampling rates are used for each
logging mechanism. This, of course, may result in situations where a
session is logged via both EventLogging and statsv.
3. The WikimediaEvents extension needs to be installed. The extension
adds the `ext.wikimediaEvents` module to the output page. The
logging functionality is delegated to this module.
Notable changes:
* The FETCH_START and FETCH_END actions are converted to a timed action.
* The experiments stub used in tests has been extracted to the stubs
file.
Logged data is visualized at
https://grafana.wikimedia.org/dashboard/db/reading-web-page-previews
Bug: T157111
Change-Id: If3f1a06f1f623e8e625b6c30a48b7f5aa9de24db
* Logged in users bypass bucketing. They keep working as before.
* When Page Previews is configured as a beta feature, logged out users
won't see the feature.
* If an anonymous user has enabled/disabled the feature using
the settings cog then they will see or not see the feature
depending on the value of their setting.
* The other anonymous users are bucketed. By default 90% of these
users see the feature, the other 10% don't. These numbers can be
controlled by the config variable `wgPopupsAnonsEnabledSamplingRate`.
Bug: T157700
Change-Id: I5307587b10f4849c4e82d3b064ff759121c2de67
I225019b8 introduced a regression where empty Resource Loader modules,
i.e. modules without any scripts, were being added in the
ResourceLoaderTestModules handler because the base directory wasn't
being calculated properly.
Change-Id: I25b01b2b5a4fe78e5c784eeba25bdaec37198abf
Sometimes we make choices on the users behalf if we don't have
sufficient information, so this name is more applicable.
If beta features is disabled and the user is anon they have not
explicitly opted in.
Change-Id: I5d816f569fc54f8bf74d6e5a06246b7fa7036e06
If the Popups code is enabled in beta feature mode only then
only add it to the page if the beta feature is enabled.
isEnabledByUser now returns false if the user is anonymous
and Popups is restricted to beta mode.
Bug: T156290
Change-Id: If152d2a67a079050173c6d642e0960b59730bc6d
Changes:
- introduced PopupsGadgetsIntegration class handles all checks
- show help message on Preferences page when NavPopups is enabled
- unit test everything
Bug: T151058
Change-Id: Ia474b1b30378efe84dedf3ad47c1f833e88d69b5
Changes:
- removed onExtensionRegistration and related TODOs
- introduced onUserGetDefaultOptions hook
Change-Id: I6648802c19d90df36a211d6494033aca30c078ca
Changes:
- added missing unit tests
- introduced PopupsContextTestWrapper, removed all unit-tests logic
from Hooks/Context classes
- removed getModule() from Popups.hooks.php, it's hooks responsibility
to keep single context instance
- removed class_exists calls, use ExtensionRegistry instead
- pass ExtensionRegistry as a dependency so it's easy to mock
- reach 100% code coverage
- introduce PoupsContext::isBetaOn() as it was used in many places
Change-Id: Id014efe72edf24628539c76968e53eb3e06709f4
This changes introduces new option on Special:Preferences page that
allows users to enable/disable Page Previews feature.
By default feature is disabled. Temporarily option in Preferences
page is smoke and mirrors as switching logic is still WIP.
Bug: T146889
Change-Id: Ifdd17ce265d2d4c7583433ed4991443c563f1fe3
