* Adds a new webpack entry point for references previews
* Reference related code in src/index.js is moved to new
file resources/ext.popups.referencePreviews/index.js
The changes:
* References previews now in its own module ext.popups.referencePreviews
* Loaded via getCustomPopupTypes
* OWNERS.md files make clear which team owns which part of the code.
Bug: T326692
Change-Id: Iea8a5b9221c0b1fd41e40bff2cbe01e42124d53f
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: Ib30da35841aadb558709dbbe6e30be2241048c87
User-options related classes are being moved to
the MediaWiki\User\Options namespace in MediaWiki Core;
reflect that change here.
Bug: T352284
Depends-On: I9822eb1553870b876d0b8a927e4e86c27d83bd52
Change-Id: Icb39d3f73e120fd0d9dad5ae362787cd19d47bfb
The extension is out of beta and will be enabled by default now.
Leaving some hints if we decide to also remove the feature flag.
Bug: T282999
Bug: T351708
Change-Id: I1556b2f3592294d094770ede2c276eddeef8bbe9
The …AFTER_BETA constant is the one we want to keep after we removed
all BetaFeature code. The naming scheme is just confusing.
Safe to rename. Not used anywhere else:
https://codesearch.wmcloud.org/search/?q=REFERENCE_PREVIEWS_PREFERENCE_NAME
We also decided to keep the $wgPopupsReferencePreviews feature flag.
Update the documentation accordingly.
This is split from I1556b2f to make it easier to review.
Bug: T351708
Change-Id: Ifbb41156f2a5a4d8a81e79f613754869c5c89690
Allow extensions to register new types of previews via
extension attributes.
Changes:
- The check for reference previews doesn't make sense
as $('a[ href*="#" ]' ) will match any elements with a hash
fragment, so the additional check to Title.getFragment
will not provide a different result. This was introduced in
I9ec57e0fbb0d21beaaa7b359c1c2bef64d2c14f5
- Links that point to themselves are marked with mw-selflink
in MediaWiki so this can use the not selector we already have.
- The new API is used internally and only available via extension
Attributes
- An example is provided in SkinJSON
(https://github.com/jdlrobson/mediawiki-skins-skinjson/pull/14)
Bug: T233099
Change-Id: Iefe98c1f0422dbf034e385b1a41a859d030a2cf4
User::setOption() is deprecated and should be replaced with UserOptionsManager::setOption()
Bug: T277818
Change-Id: I5698b4422755a921c9c9c01ce29084ebfe5f5385
The behavior for PagePreviews – implemented years ago – was
different. For old users it was disabled by default. This
behavior is wrong for ReferencePreviews.
Bug: T271206
Change-Id: I28c43ab3348ffdc27b068fc1ac1d6a6a06ee90a6
This is the smallest possible patch for a backport.
While it seems there is zero technical reason to limit user
option keys to lowercase with dashes, it's best-practice.
Same as message keys.
Bug: T281235
Change-Id: Ia4a45cf4459543c81b23b757ae9c2cfaf9676894
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
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
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 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
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
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
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
