Make ShURLy more use case non-specific: Add ability to edit, reactivate, and completely delete URLs

Also, super handy for spam, phishing, and bait-and-switch! Generate a popular URL/post on Twitter and then redirect it to something else. This is why ShURLy doesn't have this feature.

That being said, I'm sure that there are some valid use cases for this feature. When I see some valid use cases and there's enough demand and/or a patch, I'll consider adding this.

Hey frob and jjeff,

great module! But as frob said, there are some use cases that are not evil. I am continuously posting html sites, generated by a third party tool (an online learning prog). The tool generates its own frontpage that i don't want to use. The deep links are really ugly and change depending on the creation timestamp like module_learnviews_12712145.html

I want to make all those deep links accessible with a short url and be able to edit the original url after having generated a new version of the static site.

So please add this feature to the module. frob would you be so nice and post your patch?

Thanks,
McGo

jjeff,

Here's my use case example:

At A Small Orange (a hosting company), we registered aso.is for our own branded URL shortener. In addition to using the normal short urls for twitter feeds (via API), we plan to create custom URLs like "aso.is/awesome", which might point to our front page by default. Later, we'll want to change that to a different landing page for a particular promotional campaign.

Perhaps an implementation might include allowing only the admin the ability to edit a URL to prevent the bait'n'switch you described. Or at least make it a separate permission ("edit own URLS") so that the site owner can make it available only to admins, authenticated users or some other defined role. In our case, we have a "staff" role so that we can open it up to non-staff Authenticated Users later. This editing privilege could be extended to trusted staff, but not to untrusted, authenticated users. Of course, this doesn't prevent some other site owner from configuring this to allow anonymous users to change/edit URLs. If this feature is implemented, the documentation should include a warning of the possible consequences of allowing untrusted users to edit their short urls.

Currently, we also use the Path_redirect module, so we can create extended custom URLs like "http://aso.is/way/cooler/than/your/host" and those are editable. We may have to use ShURLy just for random short URLs for twitter/facebook/et al, but use the Path Redirect module for custom URLs to maintain the editing ability. My only beef with Path Redirect is that it isn't as nice as ShURLy (views, blocks, per-user URLs, etc).

I would also really like to see this feature added.

I just made a mistake so when I deleted URL (I misstyped a letter) I couldn't make new custom short URL as previous was there, just not active.

So I went to database and just plainly changed it. So much as for spam prevention: spammers are more capable than simple users and that is why there should be edit option. Edit is first of all user friendly.

Spammers would not bother with our little shorteners and even then, nothing can stop them from deploying there own sites or creating some stuff on less protected sites.

Site owner has that responsibility, but if you want you can put it as option that is disabled by default (thats *nix way).

Would love to see that module whenever you get a chance....

I'm using ShURLy for a higher ed website where we've been creating short URL's for various ad campaigns and departments. We ran into an issue where we used the wrong URL and deleted it, but now we can't reactivate it or reuse the previous short URL string (in this case, "discoverit"). I've read the issue thread and agree with many above - why not allow editing, reactivating or reuse? We aren't using it for spam, but need to make changes to properly run our ad campaigns.

ShURLy has been great for our usage so far, but it looks like it's not going to meet our needs going forward (between this and no D7 version).

My company only uses ShURLy for internal redirects. It is extremely frustrating if we miss-type the URL to be shortened and are not able to edit it, we can no longer use our preferred shortened-URL. At the very least, an Administrative option to delete links completely so the shortened URL can be reused again would be much appreciated.

It seems to me that supplying this feature poses the most risk when using shURLy for a public shortener service like lb.cm. When using it internally as a business tool for authenticated users it seems like a basic need. Perhaps the thing to do is to create a couple of separate permissions (as below) for editing existing URLs with a comment about the pitfalls of opening the ability up to the public. That way it can be a business decision made by those with knowledge of the application rather than an assumption enforced from afar. (That just sounds more Drupally, doesn't it? :)

• Edit any short URL
• Edit own short URLs

For further example of legitimate business cases, my company uses short URLs in printed and digital marketing materials. Circulation can instantly be tens of thousands. If a broken link slips through, they can't afford to wait for a developer to edit the database. Directly modifying the database on a production system is somewhat frowned upon, anyway. But most importantly, our users shouldn't be dependent on development resources to make trivial business changes.

And again, we reuse short URLs for seasonal and rotating content. For example we may have /christmas or /shareholder-report, which will be reused annually, quarterly, or more, but which need to go different places each time.

Thanks for the great module. :)

Allow me to broaden the scope a bit here. This discussion really amounts to answering the same question of ShURLy we've been asking of Drupal: "Is it a product or a framework?" So long as it is treated as a product, issues such as this one will naturally seem to dilute its potency and introduce bloat and risk. If, however, a framework mentality is adopted, the reverse will be true, and attention can be devoted to creating possibilities instead of mitigating risk. As that decision properly belongs to the maintainers and contributors, I would like to make explicit the question and direct it to them: Can ShURLy be made a more generic, use case non-specific tool? As I see it, several pieces of functionality (with corresponding permissions) would need to be added in order to accomplish this:

I have posted a patch for editing existing shortened URLs that works with 6.x-1.0 http://drupal.org/node/1352010. It only allows editing via the API using API key authentication, but may be a start in the right direction.

I have another use-case. I created vets.to as a public URL Shortener for the veteran community, planning to also use it for my company, a veteran social network. So for the most part I'm using the module as a product, as intended.

My company created a short URL that points at a Google Map of our office, so that we can give out a quick and easy to remember URL to partners and clients, and to use on our own smartphones as a starting point for getting directions to and from the office.

But if we move offices next year, we're not going to be able to use that custom URL anymore. Well, actually, we will -- I'll go in and manually change it in the database. But I like trying to avoid ugly hacks.

I give 100% support to implementing permissions like the proposal in comment #13. I use ShURLy as a product, but part of my case requires some slightly different features.

I'm going to add a definite +1 on this feature request. From my initial exploration, shURLy is everything that I need, save this one feature. My favourite thing about bit.ly is the ability to create a custom URL but I can't count the amount of times i've done it wrong and had to create an entirely new shorted URL to correct the problem!

The company I work for has many of the same use cases already mentioned here; #15, #12, #5, etc.

I think TravisCarden has pretty much hit the nail on the head in #13, although I would settle for the ability to simply edit an exisiting custom URL as a stop gap.

There's not a lot of coding in these fingers, but I'd be happy to help testing if anyone can come up with the goods.

Great module, Thank You. However, I'm also missing the possibility to edit. In my case it's about "forgotten" urls which lead to error 404. In addition to the possibility to edit, it would be nice to have a default "ShURLy-404" -page, where non existed will redirect.

I need the ability to link to specific article, even if author decides to edit it's title and target site changes URL. So I have to +1 this.
These should be a configuration options, all blank if one wants ShURLy as it is now, all checked to get what OP wanted.

Sounds like your use case is the exact same as mine. Here's the patch I used http://drupal.org/node/1352010

Is there a D7 version of this patch ?

I would agree with the proposal outlined in #13.

Here's my case study: we use the ShURLy module as an internal tool as we create digital campaigns such as Facebook apps and e-mail campaigns. We've had a few specific reasons for needing the ability to edit and delete URLs:

1. Facebook app with links to a photo gallery that won't go live until a couple days after the app is created. It would be nice to be able to create the short links and implement them within the app framework and then allow one of our digital guys go and change the link destination as soon as the photos are live. We need to be able to track each click area separately and not being able to edit the destination after the short url is created is forcing a programmer to have to generate the short link and code it into the app manually versus an easy web interface to just change the destination.

2. E-mail newsletter with links to content that aren't yet live. This happens quite a bit for us. There is a long process between the e-mail newsletter creation and coding before it is actually blasted out. As a result, sometimes content isn't posted live until a day or two before the newsletter goes out. But at this point it's too late to modify code in the newsletter. It would be extremely helpful to generate a short URL that we can use in the production of the newsletter and then change the destination once the content is live.

Neither of these are nefarious in purpose and with the appropriate permission settings could be sufficiently safe to use on any public facing site.

I just post to prevent automatic closing due to inactivity.

So long time and no reply to our use cases from original developers? Why?
Seems sooner or later one of us will have to write this from ground up or simply make a fork.

By the way, how is it phishing-handy for anyone if only change I make is to allow my trusted users to correct their typos instead of updating database directly? They can edit drupal's full URLs anyway. And they are owners of the database (in the literal, legal way) so they can have the change done by simply anyone who can send UPDATE to MySQL.

I definitely would like this feature as well. Using the Redirect module in order to allow administrators to redirect urls is already available, but mashing the functionality of the two modules together is a hassle. It would be great to see this feature enabled!

From git activity here it looks like it's mostly abandoned anyway. I guess if we want this solved, and Drupal 8 supprt, one of us needs to make a fork. Not the good old "Drupal way", but ignoring legitimate use-cases hardly is a Drupal way either.

Before forking, I would encourage submitting a patch. The maintainers may just be stretched too thin to develop against this project. But if someone provides a patch, folks can have the functionality they need, and if everyone tests and RTBC's the patch, the maintainers may be willing to commit it. And if they're not able to spare that much commitment, maybe they'd accept a co-maintainer.

In comment #3 frob states he already have the code developed, so it is not the question of "who should write it".

I can make a patch implementing #13, I have it pretty much hacked already (gosh I hate cleaning my own quick'n'dirty code), but why would I? There is a link to partial (but workable) patch in #14 and absolutely no response from developers, and I can't see it commited.

All I want now, honestly, is one sentence from maintainer: "make it happen and I'll not oppose due to ethical reasons". Given that, all right, why not. Of course seeing code mentioned from #3 might make it faster, I don't really care to reinvent the wheel here.

So be it - I'll try to get my code clean and patch ready. It was d6 too, but well, we need to start somewhere.

Thanks for the attention frob, Molot. I may be able to provide some testing and some additional support in updating the patch to D7 if a D6 patch is posted.

Well, I'm at the point now where this has become necessary for me to custom code. I'll post any patch that I can here after getting into the work a bit.

Has anyone else made any headway?

Here is a patch for my implementation. I did not implement this as I think it should be implemented for the community, but this is to help people get this functional if they need it right away, as I did.

What this does is updates the short url to have an appended Year-Month-Date-Hour-Minutes-Second at the end of the url so that you are free to create a new URL with the same original shorturl. You trigger this update by deleting the URL, my customization just allows for the appended timestamp to be added before deactivating the URL.

This is functional for my client as we needed something where they'd be able to rack the # of clicks for different parts of the marketing campaign.

Cheers

I have been working on an implementation to solve for my needs. The simplest thing for me to do here was to simply extend the existing Redirect module to allow for generating a randomized shorturl. This automatically adds the ability to go back in the admin interface and change the destination URL as well as maintaining the stats on how many visitors have accessed the forwarder. I feel this is also super lightweight and flexible since we're taking advantage of existing functionality core to this module.

The basic idea is implemented and functional, although I'm working on adding a few more features to mature this a bit more. It's definitely not as fully blown out as the ShURLy module, but for basic shortening needs it has more than sufficed on several of my live production sites. I have a dev branch that I'll be actively maintaining here if anyone is interested.

It is important for several valid use cases to be able to edit.

I'm working on ShURLy Auto, a module used for create ShURLy short URL automatically on node creation and update.

This issue similiar to Ability to edit an existing shortened URL and the use case very important when we use Pathauto then title changed.

Now, I'm working to add the ability to:
- Update Short URL when Long URL changed, so user will not receive "page not found"!

@drupalisme

Sounds good. Can't the ShURLy Auto module always create a link to URLs of the form /node/nid (so that your module is path-independent?) That way, the links would never be broken, apart from deleted content.

This is the way the menu module works in Drupal, and it seems to work very well. In practice, this would be seemlessly resolved to the currently active alias, provided something like Global Redirect is installed.

@JamesOakley
Using node/nid is not good for SEO. But, basically ShURLy Auto save nid in its table, here are complete fields recorded:
- sid, nid, longurl, shorturl, uid, ip, created

In the next version ShURLy Auto will support Views, so user can access above fields using Views/

Using node/nid is not good for SEO

That's why I said to use the Global Redirect module. You can then store only the nid, and no other aliases, but people will always get sent to the correct node alias.

We needed functionality along these lines for a site we are working on. I understand why this is not part of the main module (due to concerns over disreputable sites) but this can be very useful, especially in cases such as when you are shortlinking to a commerce product which changes on an annual basis.

I have attached a patch file in case it is of use to anyone. We will likely do the work with hooks etc. as it sounds as though this will never make it into contrib, but wanted to share nonetheless to help others that stumble across this post.

I understand that in specifics cases, having the ability to edit the URL is required.

Since, it requires permissions, i think we can look into it.

Maybe we need to keep the history of changed urls ?

How much detail are you thinking we would want to store? It's just to get revisions, we could change it all to entities, but such an overhaul seems overkill for this. So if we are thinking this wont be a regular thing, could the history be stored in a blob in the DB maybe? Just showing who/when/olddest/newdest, maybe only the last 5 too. Just throwing this out there.

We can add a new table. This will contain old URLs and the count (we need to reset the count to 0 when upgrading the destination).

Okay, I wont have time to make the update today, but so the plan is logged:

• extend the patch we already have
• create a DB table (using update hook) called 'shurly_history' with the columns: source, destination, closed_date, count
• when we edit an item, we will add the old items data to the new table
• we will also reset the main shurly table so the source we are editing has the count set to 0
• we will have a confirmation screen explaining the risk in editing an item too (eg. reset count field)

Does this sound about right?

That sounds brilliant, yes.

One enhancement that might mitigate the security / link-spam risks - but I don't know how much work it would add: Make sure that there are separate permissions for "Create short URLs" and "Edit own short URLs". That way, the feature can be added without everyone who had permission to create short URLs automatically acquiring the permission to edit them. (It may be, say in a forum site, that the site administrators want to give out permission to create, but for exactly the reasons highlighted in #1 above don't want people to be able to edit. If the module is changing to allow edits, individual site admins need to decide which of their users will have this new feature)

@JamesOakley I think the patch I posted pretty much does this, but may be too specific. It allows a permission marked as 'edit own URLs', but I wonder if this is poor naming, and should be changed to just 'edit URLs' instead.

They're not the same, and both are needed, IMO.

You, the site owner, may wish to give me permission to edit my own URLs.
You may also have moderators that you want to be able to edit anyone's URLs, not just their own, but you don't want them to be full site (or full ShURLy module) administrators in order for them to do that.

Had a little free time today, so have reworked the patch so it allows for a history as discussed earlier. At present it doesn't do anything with this data, but it is storing it so it can be used/read if need be.

I have rerolled this against the latest dev version and also added the edit link to both views not just the "my shortlinks" one.

Thanks for the work and for all the comments.

Two comments :

- I removed the test view field. I don't see the benefit since we have already the link on the long url column. Maybe I am missing something ?
- I added a table on the edit field which shows the history of the modification.

In the futur, we can add a view dedicated for the history. But for now, I think it's pretty good.

Thanks again ! Committed against 7.x-1.x