Last modified: 2014-06-09 14:55:40 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 T65623, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 63623 - Specifiable Wikidata context for LUA debug console
Specifiable Wikidata context for LUA debug console
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
WikidataClient (Other open bugs)
unspecified
All All
: High normal (vote)
: ---
Assigned To: Wikidata bugs
u=dev c=backend p=0
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-07 14:01 UTC by FelixReimann
Modified: 2014-06-09 14:55 UTC (History)
8 users (show)

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


Attachments

Description FelixReimann 2014-04-07 14:01:52 UTC
The LUA debug console can hardly be used to debug modules which use Wikidata: 
mw.wikibase.getEntityObject() always returns nil.

To test the module in combination with the data retrieved from Wikidata you would need to specify an article (as frame?) to test. The Wikidata item connected to this article would be loaded if the module calls getEntityObject() or other inclusion functions.

This could be similar to "Context title" from Special:ExpandTemplates.
Comment 1 Brad Jorsch 2014-04-07 16:44:00 UTC
If I go to a module that actually has Wikidata data, such as [[en:Module:Citation/CS1]], using mw.wikibase.getEntityObject() returns a valid object. The issue is probably that mw.wikibase.getEntityObject() is using the current page and most modules don't have any associated entity.

I suspect this will be blocked by bug 47288, just like bug 47930. If you want to fix this for the console only in the mean time, do be warned that our users are ingenious in working around restrictions ;) See bug 62291 for example.

At any rate, the bug is in WikidataRepo, not Scribunto, so reassigning.
Comment 2 Marius Hoch 2014-04-07 18:45:32 UTC
(In reply to Brad Jorsch from comment #1)
> [...]
> At any rate, the bug is in WikidataRepo, not Scribunto, so reassigning.

I think what's meant over here is the debug console on action edit (it should be possible to set a context title over there). So this is not a Wikibase bug.
Comment 3 FelixReimann 2014-04-07 20:17:34 UTC
Marius is right: The missing tracking feature prohibits a module to display the data for a different item, with mw.wikibase.getEntityObject('Q1234'). This is not the problem.

However, most modules work on the item connected to the article which uses the module (by #invoke). Given the module to debug is used in article en:Seaborgium , with mw.wikibase.getEntityObject() (empty argument) you would get the data item Q1234 connected to Seaborgium.

Thus, to debug this module and, especially, a misbehavior if used in Seaborgium, you want to specify for the debug console that the module should behave as if used in Seaborgium and return Q1234 instead of nil or the item of the module itself.
Comment 4 Brad Jorsch 2014-04-07 21:07:18 UTC
(In reply to Marius Hoch from comment #2)
> 
> I think what's meant over here is the debug console on action edit (it
> should be possible to set a context title over there). So this is not a
> Wikibase bug.

You set the "context title" using frame:newChild(), passing a title. But does mw.wikibase use the frame? I don't know, and it's not in Scribunto's code, it's in Wikidata's.
Comment 5 Marius Hoch 2014-04-07 21:10:48 UTC
(In reply to Brad Jorsch from comment #4)
> (In reply to Marius Hoch from comment #2)
> > 
> > I think what's meant over here is the debug console on action edit (it
> > should be possible to set a context title over there). So this is not a
> > Wikibase bug.
> 
> You set the "context title" using frame:newChild(), passing a title. But
> does mw.wikibase use the frame? I don't know, and it's not in Scribunto's
> code, it's in Wikidata's.

Wikibase uses mw.title.getCurrentTitle() to get the title of the current page. This should be "mockable" in the Lua debug console on the edit page.
Comment 6 Brad Jorsch 2014-04-07 21:32:31 UTC
(In reply to Marius Hoch from comment #5)
> Wikibase uses mw.title.getCurrentTitle() to get the title of the current
> page. This should be "mockable" in the Lua debug console on the edit page.

If Wikibase wants a mockable title, it should take a frame somehow and use frame:getTitle(). That's what frames are for. Or it could just take a title.
Comment 7 Marius Hoch 2014-04-07 21:48:34 UTC
(In reply to Brad Jorsch from comment #6)
> If Wikibase wants a mockable title, it should take a frame somehow and use
> frame:getTitle(). That's what frames are for. Or it could just take a title.
But how can one mock frames in the debugging toolbar without also letting that happen in the "real world" (remember, Wikibase must not be fooled on real pages... users are actually trying that...)
Comment 8 FelixReimann 2014-04-08 07:35:44 UTC
Another example: The module under test behaves differently depending on the namespace:

	if mw.title.getCurrentTitle().nsText == 'Module' then
		mw.log('found Module namespace')
	else
		mw.log('found another namespace')
	end

Now, in the debug console, you want to trigger the else case and see the corresponding log message. This branch would be active whenever this module is used (transcluded) in a namespace other than Module:

The same holds for the Wikidata example: You what to debug the module as if it is transcluded, together with the context of a specifiable article.
Comment 9 Jackmcbarn 2014-06-09 14:55:40 UTC
Note that once https://gerrit.wikimedia.org/r/#/c/124473/ is merged, a user script will allow user of the Lua console on pages that aren't modules, which sort of fixes this (or at least works around it).

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


Navigation
Links