If the user wants to print the shortURL onto business cards or poster he will also generate a QR-code. This could happen automatically.
I suggest following acceptance criteria:
| Project | Branch | Lines +/- | Subject | |
|---|---|---|---|---|
| mediawiki/extensions/UrlShortener | master | +79 -1 | [WIP] Add QR Code to Special:UrlShortener |
For the records, MediaWiki-extensions-ShortUrl might get superseded by MediaWiki-extensions-UrlShortener . Maybe you want to adjust project tags?
You can use some other QR code generator to do this, UrlShortener isn't going to provide it.
We're investigating options for T329973, and just out of interest would you mind elaborating on the objections to including QR Code rendering in the UrlShortener extension? Thanks!
Re-opening, as it seems like it's worth looking into adding QR Codes to UrlShortener, per the designs that are being developed for the above wishlist proposal.
As (digital sustainability concerned) I am mostly for doing essential based on need, it would be good to generate just .svg and smallest (really just for business card) .png for shortURL requests that are pages, not diffs, media or queries...no?
Change 923156 had a related patch set uploaded (by Samwilson; author: Samwilson):
[mediawiki/extensions/UrlShortener@master] [WIP] Add QR Code to Special:UrlShortener
Above is a bare-bones draft of a patch for this. It hard-codes lots of things, but is a starting point for discussion.
I've also requested that UrlShortener be added to Patchdemo, so this can be previewed: https://github.com/MatmaRex/patchdemo/issues/566
Patchdemo working now: https://patchdemo.wmflabs.org/wikis/1800f12d4e/wiki/Special:UrlShortener?url=https://patchdemo.wmflabs.org/foobar
It's still WIP, there's more to be done for the first draft, but do share any thoughts!
Largely scope creep. UrlShortener was implemented because 3rd party shorteners have numerous issues including: reliability (if they die, links are broken) and tracking/analytics. But those aren't issues with 3rd party QR code generators? (Ignoring the sketchy ones that hijack your URL)
It's a weird fit too, UrlShortener is based around having a separate short domain but the QR code generator uses the full URL anyways, so it's independently useful from short URLs. Would you expect a toolbox entry labeled "Get shortened URL" to also be where you get a QR code from?
@Samwilson thank you for providing the patch. I leave here some things we should fix to match with the design:
Update on this, thanks @Zblace for the concern for digital sustainability, this is a really valuable concern to us, we have down-scoped this feature recently to be able to simplify it, which would allow the user to download the QR code rather than providing functionality to customise it.
As for where the code will live I also want to share some updates with you:
We were looking for related code that we might group this work with and UrlShortener was the closest match, we had identified three options:
As @Legoktm mentioned that might extend the scope if the UrlShortener in a way so that it's concern isn't clearly defined anymore. We sure want to avoid that so we considered renaming the UrlShortener extension to be able to contain both URL shortening and URL sharing through QR.
Currently, this seems to be the best solution.
FWIW, renaming extensions that are deployed to production is basically impossible. We tried for Flow -> StructuredDiscussions. You sorta can rename it in docs and pages and extension.json and classes/namespaces but actual rename is not really possible.
FTR, I support having QRs in Urlshortener extension and sorta calling it "sharing extension" or whatever you like.
@Ladsgroup What is it exactly makes it impossible to change the naming of the extension? "Sharing extension" sounds good to but I also think there is already something similar that offers social media share functionality but that's not in production yet so it would be hard to add to this.
branching, mw-config updates, and many of this changes can't happen without actually bringing down the production. The only possible solution is to undeploy url shortener making all of w.wiki to fail and then rename it and then deploy it under a new name.
You sorta can rename it in user-facing parts (that's what's done to Flow) but repo name and such has to stay as is.
That's great, thanks a lot, any other objections anyone? We want to take the final decision this week.