ted serbinski – a blog about drupal, macs, productivity, health, and bmws
a blog about drupal, macs, productivity, health, and bmws
New external links filter for Drupal
Update: version 2 has been released that fixes some bugs and adds new features.
More than a year ago, I released an outgoing links filter (OLF) for Drupal. This module worked well and added a CSS class to outgoing links.
However, I didn’t touch the module for more than a year (it only worked in Drupal 4.7!) and it kind of faded away… until, today!
In keeping current with more widely used lingo, I decided to create an external links filter (ELF) that worked in Drupal 5, had nifty icons, and was all around more robust.
So why is this better than other modules that do this?
Well there are a couple reasons. Other modules, like External links rely on Javascript to find external links. This is not the best choice because:
- It will find all external links on a page, what about ones that appear in main menus, images, and more? Might produce some odd results.
- The page has to be loaded and the DOM parseable before it can find links. Therefore, a user could notice a delay on a page with tons of links, and worse, the page could look jittery as CSS is applied as links are found in realtime.
- Depending on how the site is loaded (Google cache, iframe) you could end up with weird results since the Javascript doesn’t know the correct URL anymore.
- Parsing can’t be cached.
While there are many valid reasons to use this module (it is still written very well), it is in my opinion that a more optimal approach would be to rely on Drupal’s filtering system.
This way you can find external links on only the content you want (e.g., switch filters, configure them differently) and the page loads with the CSS class already applied to all links, so that your CSS and JS can take affect right away, with no lag, and doesn’t eat up a user’s browser resources parsing links.
And with that, I announce the new elf module for Drupal. If anything, it should get bonus points for the name :-)
4 comments
Subscribe to updates
Latest posts
Tags
Recent comments
- Okay I figured out the path
3 days 1 hour ago - Where do I set the path? As
3 days 1 hour ago - Where do I set the directory
3 days 1 hour ago - I think we don’t need to
2 weeks 3 days ago - That’s really a great idea
2 weeks 6 days ago - See
3 weeks 1 day ago - Well, testing further, it
3 weeks 1 day ago - Thanks for this hint, which
3 weeks 1 day ago - OK, worked it out now –
3 weeks 6 days ago - I’m using Views2 and do
4 weeks 13 hours ago
Nice Ted! +1 for the name :). Is this for the wine site?
I like your logic to start a new module and think it makes a lot of sense. You obviously did the research on what is out there and saw that it will be more efficient to build your own based on the needs you have. Taking the extra time to blog about new modules like this and explaining the difference is great for people new and old in the community – this is a huge help that better allows folks to compare a lot of modules that might looks similar at first glance but have their own special details. I think building like this (ie at times just building a new modules even thought there are a lot of other modules that kind of do what you need but not quite) is what is allowing good open source communities to development better ideas faster.
Obviously at a certain point when modules get bigger and the problems they are trying to address need more recourses, there becomes a benifit for consolidation to help better channel community energy, like with with aggregation modules. But the user stories still call the shots in the end of the day, which is why it makes sense to have both simple feed and feedapi continue to be actively supported even thought they ‘both handle aggregation.’
Again, nice work, I look forward to using the module on an op coming project, it is going to be great for an intranet wiki :)
Not used on the wine site yet but coming soon for sure :)
Indeed, very well said Eric. Speaking of consolidation, 2 modules, URL Class and URL icon are slated to be merged into ELF module per this issue.
I think this supports your point greatly—start a new module from scratch, with a clean architecture and then slowly roll other modules into it that help support it, rewriting those implementations to be faster and cleaner too.
I eagerly await releasing version 3 of this module this spring with some of those great features in other modules in it, creating a standard module to work with external links :)
Looks good Ted! I didn’t know you had a module that did this way back in 4.7 days! The javascript External Links module was mostly a proof of concept when it started (a jjeff experiment). But now I’ve grown to like it so much that I use it all the time. It gets points for ease of use, but it’s good to see there’s an efficient alternative for a site serious about it’s external linking.
Nate, indeed! I certainly think there are viable times when Extlink with a full JS solution is better than a filter system approach. Good to see people have 2 solid options depending on their needs and what they are trying to accomplish :)
Add your comment