Last modified: 2014-11-20 09:15:23 UTC
If I write some <source>, I cannot use LivePreview to preview them.
Is this a bug against Live Preview or against the preview tab in Extension:UsabilityInitiative?
I guess it's Live Preview. I found this bug on a Wikimedia wiki. But if another has the same bug it should be fixed as well.
(In reply to comment #2) > I guess it's Live Preview. I found this bug on a Wikimedia wiki. But if another > has the same bug it should be fixed as well. It probably does. Cloning this bug for live preview.
(In reply to comment #3) > (In reply to comment #2) > > I guess it's Live Preview. I found this bug on a Wikimedia wiki. But if another > > has the same bug it should be fixed as well. > It probably does. Cloning this bug for live preview. bug 24162
I hear Adam is poking at preview anyway...
*** Bug 24843 has been marked as a duplicate of this bug. ***
*** Bug 25021 has been marked as a duplicate of this bug. ***
This might be something we could fix in a clever way now that we have the resource loader.
*** Bug 24162 has been marked as a duplicate of this bug. ***
Reassign to default per bug 37789
(In reply to comment #8) > This might be something we could fix in a clever way now that we have the > resource loader. Yes, but to solve this bug we need more than just JavaScript though. Using ResourceLoader makes sense. Possible implementation: * Use an API module to parse it (action=parse I suppose) * Somehow keep track of modules being added to the load queue by the parser (I think some component in the parser already has its own addModules() list) * Expose that through a new property in action=parse We already have something a bit like it (action=parse&prop=headitems) but that is 1) plain html, 2) includes default ones that are already on the page. https://www.mediawiki.org/w/api.php?format=jsonfm&action=parse&text=%3Csource%3Etest%3C/source%3E&prop=text|displaytitle|headitems|headhtml
*** Bug 36060 has been marked as a duplicate of this bug. ***
Removing 1.20.0 milestone since it doesn't look like any actual work has been done on this.
*** Bug 51770 has been marked as a duplicate of this bug. ***
Krinkle's solution from comment 11 looks reasonably straightforward to implement, ParserOutput does in fact track its own module list. Doing the above won't help for SyntaxHighlight, which doesn't use ResourceLoader for its styles (instead generating the <style/> element itself). It shouldn't be very hard to change this, either.
Change 126843 had a related patch set uploaded by Bartosz Dziewoński: Use ResourceLoader modules for style loading https://gerrit.wikimedia.org/r/126843
Change 126848 had a related patch set uploaded by Bartosz Dziewoński: ApiParse: Add prop=modules https://gerrit.wikimedia.org/r/126848
The two backend patches above I submitted should make it totally possible to do this by using the action=parse API. Anyone feels like doing that?
Change 126848 merged by jenkins-bot: ApiParse: Add prop=modules https://gerrit.wikimedia.org/r/126848
Change 131346 had a related patch set uploaded by TheDJ: Improve LivePreview https://gerrit.wikimedia.org/r/131346
Change 126843 merged by jenkins-bot: Use ResourceLoader modules for style loading https://gerrit.wikimedia.org/r/126843
Did some more work on this, but I don't have a full picture of the exact dependencies of the mw modules yet, and i'm quite certain that they are also a bit 'sloppy' right now, so some stuff isn't working 100%. On a normal page transclusion, it works without the dreaded loaderScripts param now though.
