Page MenuHomePhabricator

Integration of Wikibase Local Media
Open, MediumPublicFeature

Description

Feature summary: Integration of the extension Wikibase Local Media in Wikibase.cloud

Use case(s): There is currently no possibility to display images and other media in a Wikibase.cloud-instance. The only option is to show a link, but not the media.
The integration of the Local Media extension would change that.

Benefits: There are a lot of reasons, why displaying media is beneficial. Especially for archives, it is a relevant if not crucial feature.

Event Timeline

If Wikibase.cloud does not wish to host images itself, some users might be served by being able to reference images from a foreign file repo via API, which could perhaps reduce licencing concerns. Others will desire local hosting, though.

Use case(s): There is currently no possibility to display images and other media in a Wikibase.cloud-instance. The only option is to show a link, but not the media.
The integration of the Local Media extension would change that.

As @GreenReaper pointed out there are other possible solutions.

  1. The LocalMedia extension could be used, this would mean that wikibase.cloud would also need to enable file uploads in MediaWiki, which would be a precursor task to enabling LocalMedia extension.
  2. Something could be changed in the UI? One can already link to URLs, and URLs can be images, however as highlighted in the usecase The only option is to show a link, but not the media., perhaps this could change depending on the media at the end of the URL? Or something similar
  3. foreign file repos may also be an option, but unless that get implemented in LocalMedia might be sometihng to avoid?

perhaps it's an option to add the extension to the wikibase bundle image, and let the user decide if they want to enable/disable it through a toggle, or directly through localSettings.override.php? I'm not sure what the consequences for wikibase.cloud would be though... It might lead to a jump in storage usage so maybe a limit would be wise?

According to its extension page, Wikibase Local Media has been in the "suite" bundled releases since 1.35. There would be no real benefit to an off button since you could just turn off uploads instead.

Regarding Cloud, if WMDE would just allow site JavaScript it might be relatively easy to implement. 😼

That said, relying on an external image store is at best dubious architecture, and at worst bad manners if you enable loading images from anywhere. I think we need to bite the bullet here and enable uploads, or else decide that image hosting is out of spec. This will mean project like DAAP (the backend to its frontend) is not feasible on Wikibase.cloud without an external image store. Obviously, it is already using Suite (or source), but it is not clear that it has to as it otherwise has a fairly bare-bones implementation: https://daap.bannerrepeater.org/wiki/Special:Version

I was missing it in cloud, so I figured it wasn't in the bundle either. For me an off button wouldn't be needed, I just wasn't sure how much of an impact enabling it might have. In what way is it dependent on site javascript? To show the images?

What I was getting at is that it might be fairly easy to write our own script to turn an image URL in a statement into an image tag with JS. In fact I think this might be how Kartographer handles embedded map previews, though I could be misremembering.

That wouldn't resolve having to host the images off site though. It would just mean that something like this item could have an actual image rather than a link to it.

Redirected from the Telegram channel. I would like to chip in. Hope to have the option for something like JS tags.

We're putting this at the bottom of the product backlog for now in fvor of prioritising to enable InstantCommons T357055

In the future, if some user needs are not covered with that solution, we can revisit this ticket.

I had a feeling that might be the case. As noted, some existing Wikibases can't be done without upload. But many of those cases would want to use suite or source.

For the limited case of instance admins wanting specific images hosted elsewhere to be shown in templates and on specific non-Wikibase pages, it is possible to define a background image to a class in MediaWiki:Common.css and MediaWiki:Mobile.css, then use that class on a div:

.brok {
	background-image: url(https://en.wikifur.com/w/images/e/e7/Confuzzled-brokbadger.jpg);
	background-position: center;
	background-size: 206px 414px;
	background-repeat: no-repeat;
	content: "";
	display: inline-block;
	width: 206px;
	height: 414px;
	opacity: 0.7;
	vertical-align: middle;
}

<div class="brok" />
Obviously the image must be available for use on the instance, i.e. not blocked by referer header checks.

I had a feeling that might be the case. As noted, some existing Wikibases can't be done without upload. But many of those cases would want to use suite or source.

For the limited case of instance admins wanting specific images hosted elsewhere to be shown in templates and on specific non-Wikibase pages, it is possible to define a background image to a class in MediaWiki:Common.css and MediaWiki:Mobile.css, then use that class on a div:

.brok {
	background-image: url(https://en.wikifur.com/w/images/e/e7/Confuzzled-brokbadger.jpg);
	background-position: center;
	background-size: 206px 414px;
	background-repeat: no-repeat;
	content: "";
	display: inline-block;
	width: 206px;
	height: 414px;
	opacity: 0.7;
	vertical-align: middle;
}

<div class="brok" />
Obviously the image must be available for use on the instance, i.e. not blocked by referer header checks.

This of course raise some concerns about security, as I'm a bit paranoid about the CSP here.

I guess you mean XSS? You can't load JS since you don't have access to edit site or user JS, even as local admin. You do have the power to edit CSS, but regular users don't. There is no Content Security Policy set that I can see (perhaps if there were, it wouldn't be such a big deal to enable JS), or at least if it does it is not using an img-src or default-src that would prevent image loading. It's up to the editor to warrant that the linked image will always be the right one.

I guess you mean XSS?

Perhad. It just what I think after what once happened to me.

I had a feeling that might be the case. As noted, some existing Wikibases can't be done without upload. But many of those cases would want to use suite or source.

For the limited case of instance admins wanting specific images hosted elsewhere to be shown in templates and on specific non-Wikibase pages, it is possible to define a background image to a class in MediaWiki:Common.css and MediaWiki:Mobile.css, then use that class on a div:

.brok {
	background-image: url(https://en.wikifur.com/w/images/e/e7/Confuzzled-brokbadger.jpg);
	background-position: center;
	background-size: 206px 414px;
	background-repeat: no-repeat;
	content: "";
	display: inline-block;
	width: 206px;
	height: 414px;
	opacity: 0.7;
	vertical-align: middle;
}

<div class="brok" />
Obviously the image must be available for use on the instance, i.e. not blocked by referer header checks.

This of course raise some concerns about security, as I'm a bit paranoid about the CSP here.

One solution for the feature requested here would of course be to implement this option within the data objects and to be able to refer to the templates in MediaWiki:Common.css there.

Anton.Kokh triaged this task as Medium priority.Jun 11 2024, 3:27 PM