@Bugreporter to clarify, you want something like the table below (but with a better appearance)

Yes, but in reverse order.

Okay. Seems like a good idea for a special page, but it could also be implemented with a user script if there was a way to retrieve the target of a short url from the api. Could that / should that be added as a feature?

It seems we does not have an API to get the target yet.

The list may probably be orderable by any column. Better display may be needed for long original URLs. There may be also a search feature (of target) similar to Special:LinkSearch (this may be out of the scope of this task).

In T228779#5358365, @Bugreporter wrote:

It seems we does not have an API to get the target yet.

Would it be okay to add such an API module?

Yes.

After this we should still have some method to get recently created short URLs.

This will make oversight easier.

Could you elaborate?

When someone create a short URL to an inappropriate URL such as en.wikipedia.org/wiki/Example_is_a_loser, it's easy to detect the creation.

I came here to open a task to create this feature request, but saw it already exists. Can we retriage this request to medium priority? Creating a special page to list all short URLs on a wiki or by namespace would be very helpful for managing unnecessarily created short URLs.

In T228779#6249253, @dmehus wrote:

I came here to open a task to create this feature request, but saw it already exists. Can we retriage this request to medium priority? Creating a special page to list all short URLs on a wiki or by namespace would be very helpful for managing unnecessarily created short URLs.

"or by namespace" isn't possible. The database only stores the id and the url basically

This task isn't particularly difficult, just needs pagination etc implementing for performance reasons. And if we want url sorting.. potentially another database index

Resetting the priority in all honesty will make almost no difference, as no one is actively working on it/maintaining it AIUI.

Proposing a patch is probably much more fruitful

Thanks for the quick reply and update, @Reedy. I appreciate that the "or by namespace" isn't possible due to the way in which the short URLs are stored in the database. That idea isn't really necessary anyway.

I'm also tagging @RhinosF1 onto this task, so can monitor it, per our discussion on the Miraheze Discord server.

User-RhinosF1

In T228779#6249269, @Reedy wrote:

In T228779#6249253, @dmehus wrote:

I came here to open a task to create this feature request, but saw it already exists. Can we retriage this request to medium priority? Creating a special page to list all short URLs on a wiki or by namespace would be very helpful for managing unnecessarily created short URLs.

"or by namespace" isn't possible. The database only stores the id and the url basically

This task isn't particularly difficult, just needs pagination etc implementing for performance reasons. And if we want url sorting.. potentially another database index

Resetting the priority in all honesty will make almost no difference, as no one is actively working on it/maintaining it AIUI.

Proposing a patch is probably much more fruitful

This would probably be easier once T228781: Create API to retrieve list of short urls provides a similar view via the api; that task has a patch just waiting for review

The patch doesn't create any common code for reuse though, and I doubt we're necessarily going to implement this as a special page that just calls the API?

So it's on our radars

In T228779#6249292, @Reedy wrote:

The patch doesn't create any common code for reuse though, and I doubt we're necessarily going to implement this as a special page that just calls the API?

True, but it shows what the query would be if someone wasn't familiar with the extension. Anyway, if that can be reviewed I'd be happy to take this one on

I'm going to look into this.

In T228779#6249253, @dmehus wrote:

... managing unnecessarily created short URLs.

Do you mean like deleting unnecessary URLs? would that short URL then get repurposed? if not, why the need for deletion?