Wikidata and Wikibase reconciliation services don't load in OpenRefine 3.8.0

[trnstlntk]

Wikidata and Wikibase reconciliation services don't load in OpenRefine 3.8.0. I have seen this on my mac (in Chrome, Firefox) and it has been reported on OpenRefine on PAWS too. On my partner's PC it did work.

Reconciliation does work with various non-Wikibase reconciliation services and with the Wikimedia Commons one. It doesn't work with Wikidata's and with a few Wikibases' I've tried (at least I think they are Wikibases - Kunstmuseum.nl and the EU knowledge graph)

The recon window doesn't appear to load anything

In the terminal log, nothing happens (nothing is logged) when doing the reconciliation steps.

This is what I get in the browser console.

[trnstlntk]

Removing and re-adding the reconciliation services doesn't fix this issue.

[wetneb]

This seems to be caused by the presence of the Commons extension, which embeds a copy of suggest-4_3a.js which conflicts with the version we have in OpenRefine. Removing the extension (until a new fixed version is released) should probably solve the problem.

[trnstlntk]

I can confirm that removing the Commons extension fixes this issue. Thanks!

[sebastian-berlin-wmse]

Removing the files in module/externals/suggest/ fixes this. However, it looks like it also breaks the extension. I had to go back to 3.7.9 because of OpenRefine/OpenRefine#6581, but then you get the error below and clicking on Wikimedia Commons in the source list doesn't do anything.

16:02:35.547 Uncaught TypeError: $.suggest is undefined
    <anonymous> http://127.0.0.1:3333/index-bundle.js:74285
    <anonymous> http://127.0.0.1:3333/index-bundle.js:74403
index-bundle.js:74285:7
16:02:37.050 Uncaught TypeError: tr.find(...).suggestCategory is not a function
    addRow http://127.0.0.1:3333/index-bundle.js:74207
    attachUI http://127.0.0.1:3333/index-bundle.js:74235
    addSourceSelectionUI http://127.0.0.1:3333/index-bundle.js:64550
    CommonsImportingController http://127.0.0.1:3333/index-bundle.js:73843
    _initializeUI http://127.0.0.1:3333/index-bundle.js:64529
    CreateProjectUI http://127.0.0.1:3333/index-bundle.js:64509
    fire http://127.0.0.1:3333/index-bundle.js:3502
    fireWith http://127.0.0.1:3333/index-bundle.js:3632
    done http://127.0.0.1:3333/index-bundle.js:9824
    callback http://127.0.0.1:3333/index-bundle.js:10085
    send http://127.0.0.1:3333/index-bundle.js:10137
    ajax http://127.0.0.1:3333/index-bundle.js:9718
    <anonymous> http://127.0.0.1:3333/index-bundle.js:11293
    prop http://127.0.0.1:3333/index-bundle.js:11095
    _getAllProjectTags http://127.0.0.1:3333/index-bundle.js:65657
    _buildTagsListPanel http://127.0.0.1:3333/index-bundle.js:64837
    _buildTagsAndFetchProjects http://127.0.0.1:3333/index-bundle.js:64831
    OpenProjectUI http://127.0.0.1:3333/index-bundle.js:64801
    renderActionArea http://127.0.0.1:3333/index-bundle.js:64424
    <anonymous> http://127.0.0.1:3333/index-bundle.js:64428
    mightThrow http://127.0.0.1:3333/index-bundle.js:3768
    process http://127.0.0.1:3333/index-bundle.js:3836
index-bundle.js:74207:39

[sebastian-berlin-wmse]

I've started investigating how scripts are bundled and it looks like suggest-4_3a.js is added to the project/scripts bundle. It looks like it shouldn't be if you look in controller.js so something strange seems to be going on there.

[sebastian-berlin-wmse]

Looking at the bundled javascrip code for the project page, suggest-4_3a.js is added again at the end when the extension is enabled. This could be a cause for error if it overwrites modifications that have been made to the original suggest library. E.g. wikibase-suggest.js seems to do this.

[wetneb]

@sebastian-berlin-wmse I have had a look at what we thought was a butterfly bug (incorrect inclusion of the Common's extension's suggest copy into the project scripts).

It seems that adding an empty macros.vm in the module folder of the extension would solve it.
Without it, Velocity fails to load them, and somehow this causes Butterfly to fall back on re-using OpenRefine's main controller.js in place of the Commons extension's own, leading to suggest-4_3a.js being registered again there.
This fallback is very unexpected I would say, so I filed a bug in Butterfly for that (OpenRefine/simile-butterfly#153). I could attempt to fix it, but I have to say the whole thing feels so brittle and broken that I am a bit unsure about whether that's the right thing to do.

[tfmorris]

It seems that adding an empty macros.vm in the module folder of the extension would solve it.

Since this is about the Commons Extension, I'm going to move the conversation to #101

[lokal-profil]

On the Commons Extension side. This is no longer an issue with OpenRefine 3.8.2 and CommonsExtension 0.1.2 right? @trnstlntk

Is there anything left here to do on the Commons-extenison side? @wetneb

[wetneb]

Yes this was fixed by #104