Closed (won't fix)
Project:
ShURLy
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
8 Nov 2010 at 20:51 UTC
Updated:
22 May 2014 at 09:00 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
jjeff commentedYes. I've thought about this. I was thinking about support for something like
hook_shurly_validate($long, $short)which would allow other modules to do validation on both long and short (a.k.a. custom) URLs entered either into the form or through the API. This way you could do things like limit the domain of the long URLs and/or add a "bad words" filter to custom short URLs.Sound like that would work for you? I'd be happy to look at patches for this if anyone is up for it. The next few weeks are going to be very busy for me, so I don't think that I'd be able to get to this sort of thing myself 'til the end of the month. But if anyone else wants to take a shot at it, be my guest!
Comment #2
jjeff commentedChanging title of this issue to more accurately reflect the proposed fix.
Comment #3
shawn dearmond commentedThanks. Yes, that would be awesome. I haven't had time to work on it yet.
Comment #4
joe-b commentedI have an easy fix to make this happen. No need for a new hook for shurly.module. Drupal already has enough facilities to do this. Here's how I did it …
I created a custom module that does several things. With hook_form_alter() I added a custom submit validator, e.g.
$form['#validate'][] = 'custom_library_shurly_create_form_validate';
That function can then run any sort of validation that you want and return any errors through form API. Sweet.
My custom module also has a configuration form that allows users with appropriate permissions (I recycled ShURLy's permissions so users who can 'Administer short URLs' can administer the config) can create a list of valid domains in a text field, separated by newlines. My validator then grabs this list, checks that the domain of the $long_url being shortened is in the list by calling a function like the following …
Easy peasy, lemon squeezy.
Mildly more involved is implementing this through the shurly_services module. For this I needed a small addition to shurly_shorten() (in shurly.module, but ironically only gets called from shurly_services.module) to create a new hook, hook_shurly_validate(), and then create an implementation in shurly.module to do the existing $long_url format check. Patch attached.
With this hook in place, of course, the domain validation can go on in the same/similar code in the custom module.
Hope you like.
Comment #5
rjbrown99 commented#4 - I think this is a good approach, but why not expand the hook_shurly_validate() to also perform the form validation? Then you can create a single function in your custom module to handle both use cases. From what I can see shurly_shorten() is only called via the API/service module.
Comment #6
joe-b commentedYes, with you 100% @rjbrown99 (and I did mention what you've pointed out in my post at #4) - just didn't have time to go back over the form validation to insert the hook. Exactly the thing to do, though. Hopefully I'll get time this week to do it, if no-one else gets there first.
Comment #7
rjbrown99 commentedThanks @joe-b. I figure this could be just as easy as inserting something in the existing validation function shurly_create_form_validate() to call the API hook? That's basically what I did with a custom form validator.
Comment #8
rjbrown99 commentedThere's a patch here, changing status.
I am using the patch in #4, and at least for me it works quite well. I have built an extensive validation routine with this.
Comment #9
dqdI would rather discuss if this is really a good practise. Corner cases make modules too heavy and should be separated. This is not only a matter of what is Drupals way, it is more the meaning of building sites with frameworks and "modules" = modular.
I would rather suggest to use combination with the field_validation module for such approach, which offers much more validation options and can't be maintained better for validation options, than to put this additionally on the list of the shurly module maintainer, even if this function already exist. This is double code.
I would rather suggest to leave the patch as is for others who may want to have it this fixed now and build in and apart from that, I would rather discuss a feature request to make shurly data entries to
. Then it would be possible to manage the urls in /admin area with edit buttons, revisions and to combine it with field_validation module.
Comment #10
jibus commentedAgree with Digidog, field validation module can handle this need.
Closing issue.