https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment lists

• Design review
• Code review
• Review for deployment

Have these steps already taken place? (If code review has not taken place yet, this report should be marked as blocking bug 31235.)

We did not write a new extension, we just want to use the existing extension "Extension:Widgets".

Extension:Widgets already has a "Component" in Bugzilla, so I guess it has been accepted somehow?

Extension:Widgets exists since 2008, whereas the review process article only exists since 2011, so maybe the steps were different at the time?

By the way, here is the Git activity:
https://gerrit.wikimedia.org/r/#/q/project:mediawiki/extensions/Widgets,n,z

If Extension:Widgets indeed needs review, should we start from the "design review" step?
If yes, can the extensive documentation be considered as the design document? Documentation: http://www.mediawiki.org/wiki/Extension:Widgets

(In reply to comment #2)

We did not write a new extension, we just want to use the existing extension
"Extension:Widgets".

From my point of view the document refers to "for deployment" but I see that the "writing a *new* extension" could be misleading.

Extension:Widgets already has a "Component" in Bugzilla, so I guess it has
been accepted somehow?

Getting into Bugzilla has basically no criteria (I'm happy to provide a bugtracker home for any extension) & is unrelated to deployment requirements.

If Extension:Widgets indeed needs review, should we start from the "design
review" step?
If yes, can the extensive documentation be considered as the design document?
Documentation: http://www.mediawiki.org/wiki/Extension:Widgets

Apart from the document I linked to I don't know much about the extension deployment review process either (and I don't want to create any stop energy, was just pointing to the current process documentation which likely needs an overhaul anyway).
CC'ing Sumana and Greg who might know better how to proceed from here.

Hello Sumana & Greg,
Information to help your review:

Goal

Allow administrator-defined widgets to be embedded into articles.
For Wikivoyage, we would only allow the VoyageMap widget, example:

{{#widget:VoyageMap

}}

Facts

Used on 341 wikis
Has been maintained for 5 years
Active forum

Source

Simple source code, only 200 lines.
Uses the Smarty PHP library for templating.

If you need any other info, please ask.
WikiVoyage is currently facing a lack of differenciation with WikiTravel (from which it forked due to legal threats from host), so unfortunately most visitors continue to use the old site. Having maps on each article as soon as possible would be strategic in changing momentum.

singaporemaps wrote:

Hi, can we get an update or direction on how to move forward with this? Will we definitely need to write up a code review for deployment?

Thanks.

Thanks for the reminder.

Not sure how to push for the code review part as "Widgets" is not yet deployed on any Wikimedia production wiki.

Sumana, any idea who to assign?

Torty: I have a feeling the Widget extension will not make it through a security and performance review quickly. Are there any other options you could use, something more focused/limited in scope that only does what you need (instead of just using arbitrary raw HTML)?

Relatedly: the foundation is working on setting up our own tile server for OSM maps. Related RT tickets:
https://rt.wikimedia.org/Ticket/Display.html?id=4563
https://rt.wikimedia.org/Ticket/Display.html?id=3989

singaporemaps wrote:

We did decide on this as one of the quickest and easiest ways to implement them on-wiki (for us at least), although given this roadblock we may look at other ways. What do you think Nicolas?

I think WikiMiniAtlas is instructive since it injects an iframe into the article, but we would prefer something more permanent and more obvious, since I didn't even know about the map features on Wikipedia and maps are undoubtedly even more important on Wikivoyage.

The tickets look like they need a separate login, so I can't access them, but do they look like the ones on WikiMiniAtlas?

(In reply to comment #4)

Simple source code, only 200 lines.
Uses the Smarty PHP library for templating.

All still needs reviewing though.

The tickets look like they need a separate login, so I can't access them, but
do they look like the ones on WikiMiniAtlas?

Yeah RT is secret. Only ops folks have access. (Something about they use it to track billing info as well or something like that.

Wouldn't it make more logical sense to install the maps extension ([[mw:Extension:Maps]]).

/me finds the widget extension a little scary, but that's just my personal pov, and its not up to me

As an aside, technically it is possible to already do this by dynamically inserting the iframe using js in MediaWiki:Common.js

(In reply to comment #9)

(In reply to comment #4)

Simple source code, only 200 lines.
Uses the Smarty PHP library for templating.

All still needs reviewing though.

What Reedy said, and more, to be more explicit: WMF Engineering just doesn't have the time to devote to reviewing/fixing this extension for deployment to our cluster.

(In reply to comment #10)

Wouldn't it make more logical sense to install the maps extension
([[mw:Extension:Maps]]).

/me finds the widget extension a little scary, but that's just my personal
pov,
and its not up to me

---

As an aside, technically it is possible to already do this by dynamically
inserting the iframe using js in MediaWiki:Common.js

What about these two suggestions from Brian? I'll note that it appears that the Maps extension would also need a review (security and performance) before going onto WMF production, but it might have a better chance.

Brian, Greg:

Thanks for taking the time to write an answer.

1. Extension:Maps can not be used as is. Our map server parses the whole article and inserts markers for each item of the article, which is very different from the way Extension:Maps works. It is not granted that they will accept to modify their extension to accommodate for our special needs.

2. Thanks for suggesting Common.js, it seems to work. So I guess this issue can be closed now.

Cheers!
Nicolas Raoul

I'm changing the resolution to resolved INVALID (which isn't quite right, but it was resolved in a way that didn't involve fixing the original request, so shouldn't be called FIXED)

Cheers

I'd even use "WORKSFORME" maybe, because a workaround was found. :)