We still have 2 different mechanisms in place, maybe even 3:
* We simplify the CSS selector when we know a popup type is
disabled, and it's impossible an anonymous user can enable it
at run-time.
* We create that "initiallyEnabled" map that allows anonymous
users to toggle the individual popup types at run-time.
* This map is also used to check if the footer link should be
shown.
* There is also a wgPopupsReferencePreviews global that acts as
a "kill switch". However, this is not a pure feature flag,
but incorporates the user setting for registered users. This
is currently partly redundant (checking
`mw.user.options.get( 'popupsreferencepreviews' )` does the
same) and can be removed later when the feature flag is not
needed any more.
The footer link currently acts odd because anonymous users are
unable to enable ReferencePreviews, but get the footer link.
This patch introduces a 3-state model:
* `true` acts as before.
* `false` means a popup type is disabled, but anonymous users
can enable it (i.e. this is the opt-out behavior for anonymous
users).
* `null` means a popup type is not available at run-time, for
nobody. Anonymous users can't do anything about this.
Registered users must leave the page and change a setting.
Bug: T277640
Change-Id: Id8d1396c09cf0f706034a66f9cd3c880a8b33df8
To reduce size of code added to the <head> and increase performance.
The increased bundlesize is still less than the size spared bytes in
ResourceLoaderGetConfigVars. - But nevertheless the main gain is loading
less in the <head> anyways.
To avoid further complexity in the code, the bitmask is converted to
the according config setting early on instead of adding checks on the
bitmask all over the place.
Tests will be added in follow ups.
Bug: T276716
Change-Id: Ib4f82bed58295b25f0a41cb37e36244e45f16317
Update copy and remove unnecessary reference preview preference
in favor of using the default preference. It seems there is no
stable method to link to the subsections on the preference page
for gadgets. So in all cases does the link just point to the
gadgets pref page.
These changes should only be visible when reference previews
are no longer marked as a beta feature.
Bug: T265709
Change-Id: I7b8ab91331092ada04b230315373548673b9272c
I added the common styling for the setting icon to the popup.less
and removed the now empty pagePreview.less.
Bug: T234205
Change-Id: I2a82831bc71a4208c4b66c18e2a4613127c43e1f
In this patch we introduce a new config variable and update its default
to be the same as the production value of $wgPopupsPageBlacklist.
When this code is deployed everywhere, we will remove wgPopupsPageBlacklist
from mediawiki config and defer to the Popups extension as the source of
truth from now on.
Bug: T254676
Change-Id: Ifebdcf8f5eec854a2b947dc390eaf47704a5c5eb
AVoid the term if possible, in all internal code. The only remaining
use of the word is in the public $wgPopupsPageBlacklist config
variable.
Change-Id: Ib238731270f473ad44fcff13df617a70433f2452
Remove pluralization from the service wiring filename for consistency
with similar files in other Web repos. There are multiple services in
this file but the point of distinction doesn't seem worthwhile.
Change-Id: I6ff4f9caf66a6156f6aa6a8b808f51c356df3414
This is a direct follow up for I4d31805. Note the previous patch was
only testing the code path when Beta is disabled. But the bug was about
what happens when Beta is enabled. This is now properly covered by
these tests.
Bug: T240947
Change-Id: I54c5e9751e14a94808e85d935e1972eea0395002
It appears like we accidentially copy-pasted the behavior for
PagePreviews and made ReferencePreviews behave the same, not taking
into account that the later feature is in Beta mode.
Bug: T240947
Change-Id: I4d31805ee9b2045c49c7ab4179c5a4adbcba0394
This user option is currently used in the BetaFeatures tab, but we
are going to change this with T233813. We are going to make this a
regular preference on the rendering tab, and would like to keep the
name "popupsreferencepreviews" along with all decisions the users
previously made.
Bug: T233813
Change-Id: I703d8a1a4eee2e7dccc9c597a846cf58a973ee13
This was motivated by two things:
1. Notice the bad class name in UserPreferencesChangeHandlerTest. This
was possible because the default mock builder does not check if a class
exists, *and* there was no type hint in place. createMock() *does* check
if a class exists.
2. We are free to use createMock() from PHPUnit 5+ now. It's not only
shorter but more strict and reliable.
Change-Id: I301a171d587026eab0a62575ab2fdbfd7733c661
This is done in preparation for the main patch I8920565. This patch
here is not supposed to change anything. Tests should prove this.
Bug: T233813
Change-Id: I0bdc35dc8cb7bca643f45734b30e374f26b24ad2
It is set based on the same conditional that loads the code,
thus checking it inside the loaded code is a no-op and adds
extra HTML to the <head> that blocks text/layout rendering and
delays fetching of Popups JS.
Bug: T219342
Change-Id: I9c1f4b3861ce2cecb654eb0a78469a616730a40b
I believe these additional newlines all make the code easier to read.
It's easier to see what belongs together, and what is a separate thing.
I found the Squiz.WhiteSpace.FunctionSpacing sniff very helpful to
enforce this code style. We enabled this already in almost all WMDE
codebases. It is not yet part of the upstream MediaWiki rule set, but
discussed.
Change-Id: Ibdf788529b28637bf98e7940c2516852c3afcef7
* Explain the difference between the two hooks that both set config vars.
* Remove by-ref & that are not needed. This is a non-breaking change.
Even if the code calling a hook handler provides a variable by reference,
the hook handler being called does not need to require a reference.
Removing these & makes the code less confusing and easier to read.
* Replace an OutputPage type hint with a more narrow IContextSource.
That's all this code actually needs to know. It doesn't need access to
the entire OutputPage, so it doesn't need to require it.
* Update the signature of the ResourceLoaderGetConfigVars handler to
match the caller.
Bug: T215896
Change-Id: Ie1e4b50cd954812f71dd628003b8e9d40fdf5fe8
-> Objects by default as passed by reference so removed & in front
method header.
In addition, updated the PHPDoc comments to reflect the changes.
Change-Id: I69ad2090205f6bd694744779d2c46a3506c85378
As suggested in I69ad209.
As far as I can tell the idea was to be able to pass logger-specific
configuration to the logger factory, e.g. to be able to toggle certain
things the loggers would do. But this is not used at the moment. There
is not much value in keeping unused code around. It can esaily be
introduced again later when it turns out it is needed.
Furthermore, I'm told most of the logging functionality should be
removed anyway. See T193051.
Change-Id: I6b1ddb2a65eacc0e096f2ba44922d63e63212a65
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
