The problem: IMG elements and relative SRC paths
Ever since I've known Drupal, I've remained dubitative about the proper way to insert and reference images in drupal posts (nodes). Sure, there are many modules like image, img, img_assist, and probably a few others, but none seem to answer this simple need for content creators: to be able to insert an img
element without a path, and have the CMS automagically fetch the image from its actual storage location, and generate the proper URL on the fly, so that it works in any context: on the page, within a teaser on a three-level-deep taxonomy page, or in a RSS feed.
A workaround is discussed in the handbook using the image
module, but it suffers from two drawbacks: dependence on the image
gallery, and the need to go through explicit URLs within the image
module, like , which prevent public downloads and require a drupal hit for every img
element.
Sure, these modules have a lot more features, like automatic thumbnails and such, but they don't really solve the problem: just relocate these images for public download.
A solution: img_relocator
After spending such a long time without a clean solution, and tired of typing absolute URLs when redacting content that would need to be updated everytime the site changed its base URL, I decided to build a module that would just define a content filter to patch image sources on the fly. Ladies and gentlemen, please welcome img_relocator.
Installing and configuring
A few words to describe the module use. It is designed for node authors and defines a content filter called "img_relocator" (how original !). To use it, install the module and enable it from admin/modules
, then go to admin/filters
and select the filter for which you want the service of img_relocator, say for instance 'Filtered HTML'
, then click on its "configure" link. On the filter configuration page, say admin/filters/1
, check the newly added IMG relocator filter
and save.
Using the module
Once the module is installed and configured, create a node of some sort, make sure the input format is set to a content filter for which you activated the IMG relocator filter, and add some images. Supposing your drupal site is installed on http://www.example.com/path/to/drupal/", the files directory is set to its default "files" value, and you've attached an image called image.png
to the node, you can now use these syntaxes:
- : the module won't touch your absolute URL. You could always do this and it still works.
- : the module won't touch your site-relative URL either. You could always do this and it still works too.
- : the module will notice your local URL and transform it to an absolute URL so that it works in all situations
/>
is required, though.
: the module even accepts such an incorrect syntax and will both fix it and make it use an absolute URL, generating attributes with proper case and quotes. The terminal - : additional attributes are not affected: "src" is the only attribute processed
An additional benefit of this format is resilience to site reorganization: should your site become http://www.example.com and the files directory /newfiles
, the
content in your nodes will still be working, without needing a rewrite.
In a sandbox ?
Why is this module in my sandbox instead of being made a normal drupal project ? Because I can't help thinking there has to be a better way, already built-in or being built into 4.8/5.0, I haven't found it, and this module is actually useless. If you do know about the better way, just let me know !
UPDATE : 2006-08-21 - Drupal.org does not host sandbox-related issues, so any issue/bug/feature/wish about this module should go to the audean wiki page for issues instead.
UPDATE : 2006-08-23 - There is a nasty interaction between codefile and img_relocator: any
appearing within a block will be processed by both filters, resulting in a mess. This will have to be fixed.
This is going to make people happy
great
IMCE
The best way I found for non-technical users (those who don't know what a tag means) for now is the new IMCE module. It has its limitations but is still the best solution for me.
TinyMCE requirement
Although I didn't look it, this could indeed be interesting for TinyMCE users. However, the TinyMCE requirement is a big no for me: it doesn't work well with Opera.
Also, this doesn't solve the problem at all: from its description, it makes it simpler for users to insert images, but it does not make them relocatable, which is the whole point of using image names without paths.
Why do I consider this relocation feature important ? because most of the time, when I create a site, it will first be located under a temporary (work) URL, and content will start to be entered, while the older site being replaced it still online. Then when the site is ready, in as short a delay as possible, the whole site is moved to the existing URLs to replace it. So every link in the work site must still work in the production site without having to rewrite them one after another, which is not practical for even small sites with a few hundred nodes.
Thanks : img_relocator works for 5.0
Thanks
img_relocator.info
. Maybe you want to take the module further and had its functionality added to drupal somehow, either in core or as a supported module ?Tweaking img_relocator for SEO
Hi,
Good module, thanks for that (time to open a project in drupal.org!).
I was thinking that you can extend this to an SEO tool, as many people neglect the "alt" tags that Google Images loves and relies on, this module will extend the img alt to include the photo information available (filename, post title, etc.).
I couldn't figure out if this is what happens now, but if it doesn't - I'm guessing it's a small tweak.
Moving to url_replace_filter ?
Hi fiLi,
Thanks for your comment. However, I don't think img_relocator should become a full-fledged project : another module, in the same vein although differently designed, has been started by David Lesieur as url_replace_filter.module, and I got in touch with David and suggested he merge
img_relocator
with his own module.This would be a win-win situation, IMHO. His module has an additional featurere: writing
<a href="
links in addition to rewriting<img src="
links likeimg_relocator
does, and will likely be better maintained since my module was mostly a proof of design, and I don't actively maintain it (actually, I didn't yet meet a problem with it).Now we just need to see how he sees things regarding such a merge...