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.

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

felix wrote:

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.

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

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

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

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

felix wrote:

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.

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