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
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
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
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
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
* Introduce the new config variable `PopupsAPIUseRESTBase`.
* Create a gateway interface that exposes the getPageSummary
method. Both MediaWiki API gateway and RESTBase gateway
implement this interface.
Bug: T123445
Change-Id: I71a8a848f3143fa4a0dfd4ca182ee086903110bc
As before, we need to send the Page Previews blob that logged out users
can enable/disable previews.
Changes:
* Unconditionally add the ext.popups RL module to the output.
* Send the value of Popups\PopupsContext#isEnabledByUser to the client
as $wgPopupsIsEnabledByUser.
* Make mw.popups#isEnabled return $wgPopupsIsEnabledByUser if the user
is logged in.
Bug: T146889
Change-Id: Id2ccfaa81a327e222fff400f4a5f22f96c99ea31
The SchemaPopupsSamplingRate config variable is inconsistently named and
even forwarded to the client as wgPopupsSchemaPopupsSamplingRate.
Changes:
* SchemaPopupsSamplingRate -> PopupsSchemaSamplingRate
* Forward PopupsSchemaSamplingRate to the client as
$wgPopupsSchemaSamplingRate.
Bug: T146889
Bug: T146434
Change-Id: I80d6a0abccf462e2eb0fd96af6849b5e82b49c26
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
Per #Design's mocks, the "Reading preferences" section should appear
immediately beneath the Skin section, if it's present.
Changes:
- onGetPreferences will try to inject PagePreviews option after
skin section or on the end of section when skin select is not available
- unit tests for new behaviour
Bug: T146889
Change-Id: Id14c0774aee917b7e949ab3ba5968a038b3ca933
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
