Page MenuHomePhabricator

Code Stewardship Review: ShortUrl Extension
Open, NormalPublic

Description

Original task description by @Reedy

After T108557 is actually finished... We should probably EOL Extension:ShortUrl in some form or another

Code stewardship reviews started by @Ladsgroup


Intro

ShortUrl (not to be confused with UrlShortener, the recently deployed feature) is an extension that helps create shortened URLs for wiki pages, using their base36 encoded IDs. Adds a 'Short URL' link to the Toolbox. Primarily developed for use in the Indic Language Wikipedias (while deployed on wikis like eswikibooks as well)

Issues

It doesn't have any maintainer

Yuvi originally wrote this and since he left, there's no active maintainer.

It writes on master on page view in deployed Wikis

T122708: ShortUrl must not write to master db on page views (DBPerformance warning)
This is a problem for active/active

Having two extensions doing the same thing is confusing and redundant

It won't be long until bugs would be made against wrong extension or people look at the wrong documentation.

Rubric

  • Current maintainer

None.

  • Number, severity and age of known and confirmed security issues

None.

  • Was it a cause of production outages or incidents. List them

None

  • Does it have sufficient hardware resources for now and the near future (to take into account expected usage growth)?

It depends on which communities want this, if a large wiki wants it, probably not

  • Is it a frequent cause of monitoring alerts that need action, and are they addressed timely and appropriately?

Yes, T122708: ShortUrl must not write to master db on page views (DBPerformance warning) is an issue for active/active

  • When it was first deployed to Wikimedia production

Based on T3450: Enable Extension:ShortUrl on or.wikipedia, ta.wikipedia... it was 2012 (probably it was a rainy day)

  • Usage statistics based on audiences served
  • Changes commited in the last 1, 3, 6 and 12 months

(Based on github)
Last month: 1
Last three months: 6
Last 6 months: 8
Last year: 23
(All small fixes, library upgrade, removing obselete parts)

  • Reliance on outdated platforms (e.g. operating systems)

None

  • Number of developers who committed code in the last 1, 3, 6, and 12 months

(Based on github)
Last month: 1
Last three months: 2
Last 6 months: 2
Last year: 5

  • Number and age of open patches

One patch, open for five and half years now

  • Number and age of open bugs

11 open bugs.

  • Number of known dependencies
  • Is there a replacement/alternative for the feature? Is there plan for replacement

Extension:UrlShortener which provides the same functionality is deployed and usable now. There is no migration plan so far and would be tricky due to differences on the backend

  • Submitter's recommendation (what do you propose be done?)

Phase out this extension in favor of the cool new feature. The way to phase this out (either make it read-only to completely undeploy it) needs to be determined though. There's some discussion in T107188

Event Timeline

Reedy created this task.Feb 12 2018, 10:37 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 12 2018, 10:37 AM

pinging @Jayprakash12345 as somewhat per its documentation: Primarily developed for use in the Indic Language Wikipedias. (In your opinion, what's the expected future of those Shortting-URLs extensions?)

See T107188: Add support to UrlShortener to support ShortUrl redirects - we do need to ensure no matter what that the ShortUrl URL's keep working.

Reedy added a comment.Feb 13 2018, 3:48 PM

We should probably also have a look at how widely used this actually is in production

Elitre added a subscriber: Elitre.

pinging @Jayprakash12345 as somewhat per its documentation: Primarily developed for use in the Indic Language Wikipedias. (In your opinion, what's the expected future of those Shortting-URLs extensions?)

Thanks Sir Pinging me, I will look at this.

Can we just deprecate ShortUrl in favor of UrlShotener?

Sounds good to me, but what do we do about Cool URIs don't change?

Ideally we'd end up with an outcome where the maintenance cost is near-zero for ShortUrl-compat, which a read-only extension is not (there's lots of churn through unmaintained repos, and lots of hard-to-measure cost during development from isolating issues, log spam, on-going performance issues, etc.)

Some ideas:

  • We could add read-only decoding support to the UrlShortener extension, as @Legoktm proposed at T107188.
  • We could add a basic "this to that" config option to the UrlShortener extension. E.g. wgUrlShortenerMapFile which could be set to a static array file containing the one-time export of the ShortUrl database. This would mean we only have to maintain the data on disk (e.g. wmf-config) and the redirection. With no database tables or complex PHP code remaining.
  • We could export the existing redirects and load into a separate light-weight redirect service, or as Apache rewrite-redirects.

Can we just deprecate ShortUrl in favor of UrlShotener?

Sounds good to me, but what do we do about Cool URIs don't change?

To be clear, any proposal that does not support /s/ style short URLs forever is not acceptable.

Jrbranaa renamed this task from Decide on future of Extension:ShortUrl on Wikimedia Wikis to Code Stewardship Review:ShortUrl Extension.Jun 4 2019, 11:15 PM
Krinkle renamed this task from Code Stewardship Review:ShortUrl Extension to Code Stewardship Review: ShortUrl Extension.Jun 26 2019, 1:00 AM
greg triaged this task as Normal priority.Jul 16 2019, 9:25 PM