Implement Gadgets 2.0 (tracking)
OpenPublic

Assigned To
None
Priority
Normal
Author
Krinkle
Blocks
T36958: 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: Tracking bug (tracking)
Blocked By
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
Subscribers
TTO, Aklapper, Liuxinyu970226 and 19 others
Projects
Tokens
"Love" token, awarded by Ricordisamoa."Love" token, awarded by He7d3r.
Security
None
Reference
bz29272
bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz29272.
Krinkle created this task.Via LegacyJun 4 2011, 5:22 PM
MarkAHershberger added a comment.Via ConduitJan 23 2012, 3:46 PM

switch to milestone, remove release tracking dep

Krinkle added a comment.Via ConduitApr 2 2012, 1:53 PM

Moving a few bugs to ResourceLoader component in general, renaming and moving this bug to Gadgets extension specific things.

He7d3r added a comment.Via ConduitDec 19 2012, 9:06 PM

Are there any news on this? Is it dead?

MZMcBride added a comment.Via ConduitMay 17 2013, 12:58 PM

(In reply to comment #3)

Are there any news on this? Is it dead?

Not dead, just dormant, I think.

Jdforrester-WMF added a comment.Via ConduitMay 17 2013, 3:39 PM

(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.Via ConduitDec 13 2013, 8:44 PM

See also bug 57891.

He7d3r awarded a token.Via WebNov 24 2014, 12:54 PM
He7d3r edited the task description. (Show Details)Via WebNov 30 2014, 6:29 PM
He7d3r added a project: Crosswiki.
He7d3r set Security to None.
Ricordisamoa awarded a token.Via WebJan 10 2015, 4:59 PM
Krinkle edited the task description. (Show Details)Via WebJan 11 2015, 10:42 PM
Krinkle removed a subscriber: Unknown Object (MLST).
greg removed a subscriber: greg.Via WebJan 12 2015, 4:39 PM
Krenair added a subscriber: Krenair.Via WebJan 28 2015, 8:12 AM
Amire80 added a subscriber: Amire80.Via WebFeb 12 2015, 1:31 PM
Matanya added a subscriber: Matanya.Via WebMay 26 2015, 11:14 AM
Liuxinyu970226 added a subscriber: Liuxinyu970226.Via WebMay 27 2015, 6:21 AM
Krinkle moved this task to Triaged on the MediaWiki-ResourceLoader workboard.Via WebMon, Jul 13, 3:06 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptVia HeraldFri, Jul 17, 1:37 AM
Legoktm added a comment.EditedVia WebFri, Jul 17, 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.

Legoktm added a comment.Via WebTue, Jul 21, 5:54 AM

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
Nemo_bis added a comment.Via WebTue, Jul 21, 9:20 AM

restict editing to userrights which aren't granted

?

TTO added a subscriber: TTO.Via WebTue, Jul 21, 9:33 AM
Krenair added a comment.Via WebTue, Jul 21, 5:05 PM

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.EditedVia WebTue, Jul 21, 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.

Legoktm added a comment.Via WebTue, Jul 21, 9:28 PM

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).

Ricordisamoa added a comment.Via WebWed, Jul 22, 2:11 AM
  • 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

?

Legoktm added a comment.Via WebWed, Jul 22, 2:53 AM

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.

Ricordisamoa added a comment.Via WebSun, Jul 26, 7:30 AM

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)Via WebSun, Jul 26, 7:48 AM
Legoktm closed blocking task T73201: Support redirects in CssContent as "Resolved".Via WebTue, Jul 28, 6:03 PM
Legoktm added a comment.Via WebSun, Aug 2, 6:39 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.

Legoktm added a comment.Via WebSun, Aug 2, 6:55 AM
  • 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.Via WebSun, Aug 2, 10:11 AM

Add Comment