Last modified: 2009-07-25 18:32:03 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T20464, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18464 - Implement the ScriptLoader into the core.
Implement the ScriptLoader into the core.
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Michael Dale
http://www.mediawiki.org/wiki/Extensi...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-14 18:36 UTC by Michael Dale
Modified: 2009-07-25 18:32 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Michael Dale 2009-04-14 18:36:57 UTC
For an overview of the script loader see: http://www.mediawiki.org/wiki/Extension:ScriptLoader

It will add some configuration variables so its easy to turn on or off. More info to follow as the patch develops.
Comment 1 Michael Dale 2009-04-14 19:16:49 UTC
some thoughts.. the fact that we have wiki pages for user language / msg updates means we have to pull the revision id of the latest updated msg text from the javascript we are including before we write out the unique id for the javascript grouped request... likewise for articles I need to grab the latest revision id from all of wiki page javascript includes and them hash that with the svn version id of the actual files used to create the unique request identifier. 

How does the system insure that once the squid version of a resource is "purged" all the requests that happen in the mean time while the resource is being updated don't hit un-cached version of things? hmm need to think about how that would work in this context .. I guess it should render it out when its rendering out when the head of the page that points to that unique identifier / script group request. So its just part of the page rendering process that can take ~ seconds ~ so when the user gets a page with a new <script tag pointing to some grouped resource request that grouped resource request should already be rendered out and cached. 

Not sure if that completely solves the problem... more updates shortly. 
Comment 2 Michael Dale 2009-04-16 23:08:24 UTC
update: there is a new branch latest commit is "getting there" see r49581
Comment 3 Michael Dale 2009-05-07 00:00:41 UTC
synced with trunk in revision: r49581
currently supports grouping of script requests. CSS/style sheet grouping is on the way.
Comment 4 Michael Dale 2009-05-21 00:22:22 UTC
The Script loader branch has been merged with the new-upload branch. This was necessary as they started to share a few cross dependencies.
New-upload branch tracking is done in bug 18563. But bugs related to the script-loader code can continue to be placed here. 

The script-loader code underwent some major refactoring as it got adapted to the inclusion of the mwEmbed javascript. This enables the mwEmbed interface to "stand alone". This enables other sites that want to include mediaWiki interface components to include a single script and let the javascript handle the rest. More examples on this shortly but you can see the example stubs in /js2/mwEmbed/example_uage
Comment 5 Michael Dale 2009-07-25 18:32:03 UTC
Script Loader is now available with $wgEnableScriptLoader configuration var. 

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links