Implement Gadgets 2.0 (tracking)
Open, NormalPublic

Tokens
"Mountain of Wealth" token, awarded by RandomDSdevel."Love" token, awarded by Qgil."Love" token, awarded by Luke081515."Love" token, awarded by Ricordisamoa."Love" token, awarded by He7d3r.
Assigned To
None
Authored By
Krinkle, Jun 4 2011

Details

Blocks
T110014: Review/Update/Merge/Deploy Gadgets' branch "gadgetprefs" from 2011
T36958: Gadgets 3.0: Implement ability to create wiki-modules at a user level
T34169: Action to join scripts and styles in one file
T37126: Gadgets issues that will be resolved in Gadgets 2.0 (tracking)
T72019: Add the ability to configure gadgets on a per site or wiki basis
T60462: Gadgets enabled by default should be held to a higher level of quality
T4007: [DO NOT USE] Tracking bug [superseded by the #Tracking tag]
Blocked By
T125582: Get community feedback on Gadgets 2.0 before migrating
T119008: Gadget importing script only imports first skin in required skin list
T118224: Gadgets 2.0: Write documentation
T110633: Investigation: Creating an i18n framework for gadgets
T108653: WikiModule class should follow redirects for JavaScript/CSS content
T106177: Implement Gadget and Gadget definition namespaces plus their content models
T106176: Implement GadgetRepo class
T71906: 2.0: Make it clearer that Scripts and CSS must be in Gadget namespace when defining a gadget
T73201: Support redirects in CssContent
T73200: Support redirects in JavaScriptContent
T71368: 2.0: Remove timestamp from Gadget constructor
T71344: Gadgets 2.0 branch doesn't pass jshint
T71318: Convert Gadgets 2.0 namespaces to use ContentHandler
T72841: 2.0: Document best practices for creating local overrides of global gadgets
T72835: Remove assumption from MediaWiki core that JS/CSS are only in MediaWiki namespace or User subpages
T72824: 2.0 Figure out how gadget naming collisions should work, and document it
T31398: 2.0: Implement Gadget Manager
T32914: Embeddable ResourceLoader modules (user.options, user.tokens) should be loaded in <head> for proper dependency resolution
T41027: rl2.wmflabs.org: RL executes the module before the i18n messages are available
T41025: Gadgets 2.0: "hidden" doesn't work
T31153: Pages loading without formatting too often
T32160: Add public method to mw.loader to get module names from registry
T32022: Add support for (custom) loadScript sources to ResourceLoader
Reference
bz29272
There are a very large number of changes, so older changes are hidden. Show Older Changes

Are there any news on this? Is it dead?

(In reply to comment #3)

Are there any news on this? Is it dead?

Not dead, just dormant, I think.

(In reply to comment #4)

(In reply to comment #3)
> Are there any news on this? Is it dead?

Not dead, just dormant, I think.

Indeed - see [https://www.mediawiki.org/wiki/ResourceLoader/status#2012-12-24 ruling from WMF Engineering management]. I do not know whether it will be taken forward as part of the 2013/14 work. Sorry for the lack of information.

greg added a comment.Dec 13 2013, 8:44 PM

See also bug 57891.

He7d3r edited the task description. (Show Details)Nov 30 2014, 6:29 PM
He7d3r added a project: Crosswiki.
He7d3r set Security to None.
Krinkle edited the task description. (Show Details)Jan 11 2015, 10:42 PM
Krinkle removed a subscriber: Unknown Object (MLST).
greg removed a subscriber: greg.Jan 12 2015, 4:39 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 17 2015, 1:37 AM
Legoktm added a comment.EditedJul 17 2015, 2:39 AM

@Krenair, @Krinkle, and I sat down today to figure out how we're going to move forward:

  • Drop the concept of global/shared gadgets
    • We expect global gadgets to be implemented in a different manner, and will defer to (T71445#1459477)
    • Removes *a lot* of complexity
  • Start moving code from RL2 branch into master in a way that is deployable before the migration. (e.g. we can create the new namespaces and a few of the classes before moving gadgets into them). We will be introducing some Gadget 2.0 concepts into Gadgets 1.0 (master)
    • We will not be doing a complete branch merge of RL2 into master.

We also did some code review and talked about what changes we need to make, I will file separate blocking tasks for each of those.

Full notes from aforementioned conversation:

  • drop remote shared repos
  • getModifiedTime replace with getDefinitionSummary, use blob
  • investigate getting rid of "gadgets" db table
  • redirects for JavaScript and CSS
  • i18n-ify API modules
  • Update for JsonContent updates in core
  • extension.json-ify
  • don't allow non-JS/CSS pages in the gadget namespace
  • determine migration deployment plan
  • prejs --> css
  • Move property validation into Content instead of Gadget
  • Rename GadgetScript* classes to GadgetCode?
  • migrate script should have a narrower select query
  • Introduce GadgeRepo class
  • New namespace with content models, restict editing to userrights which aren't granted
  • gadgetpagelist API module
  • Special:Gadgets
    • consider making a base Gadget interface
      • or gadgetrepo

objectcache through WANCache:

  • One key is the list of gadget names
    • do a purge if the list changes, don't try populating
  • Each gadget definition has its own cache key

restict editing to userrights which aren't granted

?

TTO added a subscriber: TTO.Jul 21 2015, 9:33 AM

restict editing to userrights which aren't granted

?

Wikis would have to explicitly trust specific user groups to edit gadget code, rather than it just being a default sysop right.

Nemo_bis added a comment.EditedJul 21 2015, 9:13 PM

Wikis would have to explicitly trust specific user groups to edit gadget code, rather than it just being a default sysop right.

Doesn't sound like a coding decision; the status quo should be preserved until an explicit decision to change is happens (which can't be on this bug). Or rather, the MediaWiki defaults can change because probably most sysadmins don't care, but in that case a Wikimedia configuration change should happen first, to be reversed later if necessary based on a new consensus at meta.wikimedia.org.

restict editing to userrights which aren't granted

?

We can create the namespaces and their content models in the master branch ahead of time, but until we actually do the migration (running a script + config changes), don't let people edit them by not granting the associated rights. Once the migration happens, we grant the rights to sysops (or another group depending on local consensus).

  • Drop the concept of global/shared gadgets
    • We expect global gadgets to be implemented in a different manner, and will defer to (T71445#1459477)
  • drop remote shared repos

Don't expect everyone to use Git even for simple gadgets that could easily be made global.

  • prejs --> css

?

Don't expect everyone to use Git even for simple gadgets that could easily be made global.

Please comment on that task then. All I'm saying is that for the purpose of implementing and deploying Gadgets 2.0, we will defer on implementing global gadgets for now.

  • prejs --> css

?

There's a module named ext.gadgets.specialgadgets.prejs which should instead be called something like styles.

Don't expect everyone to use Git even for simple gadgets that could easily be made global.

Please comment on that task then.

In T71445#968479, I actually wrote:

I know this has probably been discussed before, but... what about hosting gadgets via Git/Phabricator?
At least the largest ones will benefit from more thorough review.

Aklapper edited the task description. (Show Details)Jul 26 2015, 7:48 AM

We should be able to get away with not implementing separate content models/handlers for the Gadget namespace, all we needed were data updates on edit and on deletion, which are available through the SecondaryDataUpdates & WikiPageDeletionUpdates hooks. But not implementing a full content model might bite us later on...thoughts?

We will need one for the Gadget definition namespace regardless.

  • determine migration deployment plan

Here's what I'm thinking:

  1. Run script to populate Gadgets definition namespace pages
  2. Run script to move MediaWiki:Gadget-* pages to Gadget namespace. Because we will leave redirects behind, existing gadgets will continue to work, albeit with a performance hit due to extra HTTP requests.
  3. Flip configuration switch to use GadgetDefinitionRepo (or whatever it is named)

I don't know how bad the performance hit in #2 is going to be...if it's terrible we could do the configuration change first, and then move pages and have a small time where gadgets don't work until the page move script finishes running.

Nemo_bis removed a subscriber: Nemo_bis.Aug 2 2015, 10:11 AM
Restricted Application added a subscriber: Luke081515. · View Herald TranscriptAug 9 2015, 8:14 PM
He7d3r edited the task description. (Show Details)Aug 27 2015, 3:23 PM
Catrope removed a subscriber: Catrope.Nov 13 2015, 8:21 PM
Base added a subscriber: Base.Dec 7 2015, 11:14 PM

Add Comment