Provide UI option for using relative urls for the inserted images

I'd suggest using Pathologic if you need to manage URLs across multiple sites, since even if Insert is using relative URLs, you'll still have problems with other URLs that your users copy/paste. I'd prefer not to burden the settings form with settings that will not be needed (or possibly understood) by 90% of administrators.

+1 to this behavior. It was the first thing I wanted as soon as I installed the module. I think it's totally relevant to the module at hand, and you can circumvent confusion by newbie administrators by adding to the field description something like this:

If you don't understand this behavior, leave this checked.

I'm not planning on adding this option.

Seriously? It's so useful and relevant to this module and the task its accomplishing, and it has no harmful side effects. The only way this module is useful to our development workflow is if we are using the portion of URL following the domain name.

Please reconsider... I'll do all the patch work and testing, if needed.

EDIT: Also consider that other related modules do this as a standard practice, such as IMCE.

I, too, am a huge fan of this patch getting in - I haven't used absolute paths on any of my sites since the early 00's, as doing so always requires a bit of strong-arming the database if you move sites, change subdomains, go from dev to live (and back), etc.

This is a rather common occurrence on my end, and the more times I find modules using absolute URLs, the more times I have to go in and do more database work to simply change a domain name. Is there any harm in using relative URLs, or at least having a setting for it?

Another consideration is that if a fully-resolved URL is saved as HTTP, and then the page is viewed over HTTPS, then the user will see an error that some of the content is not secure. Why not just add this checkbox and let the site administrators choose how it should behave, depending on the scope of their website?

Is there any harm in using relative URLs, or at least having a setting for it?

Relative URLs do not aggregate well, in such situations where you provide any sort of RSS feed for example. As for a setting... I still think Pathologic is the way to go. There's no way you can prevent your end-users from copy/pasting complete URLs, which I think is much more likely than them using relative ones. Regarding running multiple sites, it's absolutely impossible to have consistent URLs in your database based purely on what Insert module puts into the textareas for you. If you want to have consistent URLs (relative or absolute) you need another mechanism to ensure that behavior.

Regarding running multiple sites, it's absolutely impossible to have consistent URLs in your database based purely on what Insert module puts into the textareas for you.

You're right—there needs to be a mechanism that fires after the content is saved to enforce relative or absolute URLs. That's been my experience, too, as users inevitably format URLs any number of ways.

I would choose Pathologic, except that it forces absolute (fully-resolved) URLs. I want something which allows me to force relative URLs / absolute paths (/node/5, or /sites/default/files/picture.gif). For what it's worth, Path Filter does this pretty well, by saving an "internal" URL in the database, but giving you the actual path in the textarea, and again when it's rendered. As far as integration with Insert goes, I submitted a patch which helps force that same behavior for files: #634744: Absolute paths for files

I'll set it back to "won't fix," and humbly accept defeat. :)

I looked at pathologic, but it seems a bit like overkill. Can't I just search and replace the two paths in node_revisions, substituting:

2lkj3lk32j4h3k2j4hk23j4h2k3h4j.tempurl.org
with
live-url.com

...when going from temporary URL to live URL?

Or are there any pitfalls doing it this way?

I looked at pathologic, but it seems a bit like overkill. Can't I just search and replace the two paths in node_revisions, substituting:

Yes that will work well for anything inserted into the body field. Note that you'll need to do the same thing for any additional textareas you've added to your node form through CCK.

After getting yet more requests for this feature, I've decided to make an option (but not a UI) for relative URLs. As I've stated above, counting on Insert to manage all your URLs will not work, since some users will inevitably use a different format or type out the HTML or paths manually.

So for the time being I'd like to make a variable_get() call to determine if we should use relative or absolute. We can consider adding the UI to change the option later.

I've committed the attached patch that provides this functionality.

To make Insert use relative URLs, insert this into your settings.php file:

$conf['insert_absolute_paths'] = FALSE;

Woah! Great timing! I just spent the last day trying to figure out which module (filefield, imagecache, wysiwyg, tinymce or insert) was creating 'domain absolute' urls in the nodes. I guess I've finally found the culprit, which was actually my least suspected.

My search stems from a certain issue you may not be aware of:

If I access my site using http://mydomain.com this is the root that is used for the images inserted.
If I access it using http://www.mydomain.com then this becomes the root used.
For some as yet unknown reason (to me at least), imagecache does not work with 'www' in the paths.

I don't even understand the url issue here. IMO every single internal link should be 'root relative'. I really don't care if other technologies have to deal with that; site portability should always come first. There is no way that I'd sacrifice that over the ability for some bozo to get images in his feed reader, for instance.

So, thanks for making this patch. Another +1.
I hope this feature gets a UI in future, and actually becomes the default behaviour.

By the way, thanks so much for this module. It is one of the most important.
If you don't use IMCE, there is no other easy way to get images into the editor inline.

Having said that, it's insane that getting an inline image into a node takes six modules. Seven if you include the resize module. Eight if you include the teaserthumbnail module. That's what I hate about drupal; it takes 20 modules all knitting together in a carefully crafted way just to get what I would call basic functionality.

Cheers.

That's what I hate about drupal; it takes 20 modules all knitting together in a carefully crafted way just to get what I would call basic functionality.

You'll be happy to know that ImageCache, ImageAPI, Image, and ImageField have been merged in Drupal 7 and are part of core. Upload module is now replaced with File module (the D7 version of FileField). Since Image and File modules are enabled by default on all new sites, you won't have to add anything for "basic" functionality, but Insert will definitely still be around. Drupal has been going through a tough transition between the "classic" node-based modules and the new field-based ones. Fortunately with CCK in core in D7 we've finally unified our approaches so that there's only one (much better) way of doing things instead of two or more.

Well that certainly sounds great.
Almost as if drupal might be pleasant to use!

Cheers.

This module is so great it should be included in Drupal 7 core! We have already CCK and Imagecache in D7 core and I vote to include Insert to complete powerful image handling! Thanks.

Since we Drupal architects know what we do when enabling this feature it would be great to have this as UI option. Please.

Thanks, Ronald ;-)

Subscribing...waiting for that UI! :)

I'm using this for a dev site which is in a sub-folder on my web domain. Thing is, it's still putting "/drupal in front of the relative path (which is no fault of this module - it's where drupal lives...for the moment!), any ideas how I can strip that out when I go live and I move the site from "/drupal" to root?

Is there a clever way to do this?

Many thanks!

I used this in phpmyadmin to update the dev path to the live version(example.com):

UPDATE `node_revisions` SET `body` = REPLACE(`body`,"2lkj3lk32j4h3k2j4hk23j4h2k3h4j.tempurl.org","example.com")
UPDATE `node_revisions` SET `teaser` = REPLACE(`teaser`,"2lkj3lk32j4h3k2j4hk23j4h2k3h4j.tempurl.org","example.com")

So that paths will change from 2lkj3lk32j4h3k2j4hk23j4h2k3h4j.tempurl.org to example.com

jonthomas83: You might consider Pathologic.

thanks joelstein, I'll take a look! :)

I vote for relative URL's by default. After my client signed off on the production launch of their site, they were sent scrambling to reinsert every image after I turned off the development server. I can see there are good solutions in this issue thread, but relative URL's would be much more convenient, and appropriate.

My question is, don't images in imagefields not work as relative URLs? It seems so as I have no problem going from development server to live. Why is that a problem here?

Maybe insert can be accompanied with its own input filter?

Open a new issue for your questions.

UI would be great - Default should be "relative".
So all Server-Changes are no problem.
And you can choose "direct" in case of adding pics to a newsletter.

And yes - this small module should be in core !

Hey quicksketch, sorry for reopening this again.

I'm using Aegir and have no control of my site's settings.php file.

I believe that UI for the relative path option is absolutely necessary.

And i also vote for relative path to be default.

I'm not interested in adding this as an option in the UI. I don't think relative should be the default.

Not wishing to question you or stir trouble, but if someone were to develop this functionality (the UI stuff I mean, the default behaviour is a different matter), wouldn't it benefit the community for you to include that in the module? Especially if people are asking for this?

Sorry if that sounds naive, it's just I'm not sure why you're objecting to this.

Many thanks.

I explained myself in #1:

I'd suggest using Pathologic if you need to manage URLs across multiple sites, since even if Insert is using relative URLs, you'll still have problems with other URLs that your users copy/paste. I'd prefer not to burden the settings form with settings that will not be needed (or possibly understood) by 90% of administrators.

So moving a site from dev to production breaks all inserted images with this module. If I'm working in WAMP or something localhost, my absolute for that is localhost/sitename. So going to prod, localhost/sitename no longer exist. Having to manually set each image path AGAIN is not exactly worth my time.

Reference #22. This has kept me from using this module on a couple sites where users would love to have control over inserting images, but it'll stop me from going to production due to this absolute URL issue.

@narcissus921: You can always make this module use relative URLs by the approach described in #11.

#11 is great, but only if I have access to the settings.php file. For some users, like site admins without permissions to change mission-critical files, it would be a nice option.

So, if I have this right - I'll have to follow #11, then clean up all 4000 nodes since they're already input as absolute?

I noticed with CKEditor that it was pathing ../../sites/(pathtofile), which works fine in the edit, but not displaying the image on the node display. Is that CKEditor related, or something you've come across?

Your module is used on TopNotchThemes' PowerSites, through WebEnabled. Perhaps mentioning this (Pathologic) module to use as well would be a good idea, or the settings.php edit.

So, if I have this right - I'll have to follow #11, then clean up all 4000 nodes since they're already input as absolute?

That's right, and having to "clean up" 4000 nodes is exactly the reason why this setting shouldn't matter anyway, since you're never going to be able to prevent users from using absolute URLs anyway when they copy/paste or create links in their content. Insert module is a tool for inserting HTML, it's not a tool for enforcing certain markup or ensuring paths are consistent across servers.

I dunno. It just seemed to me that if CCK images are being used, and Insert inputs image into the body of a node, it should just insert it relative to the actual Drupal install, and not absolute. This is my real issue. I'm not inserting anything with CKEditor on one site, Insert throws in absolute paths for images.

I mean, I guess I could go into the database and add your #11 to the variable table (btw, worked), but what if I don't have access to that? Or the settings.php file?

I'm not trying to enforce markup or anything like that, just trying to keep my PowerSite running after I pull it down.

My point being, not everyone has access to the solutions you provide. And even then, they'd have to be a little bit smart about what they're altering and where, as it could potentially break their site.

If you want to hammer on something or someone, the "inline" module should be your target. The huge vacuum on this issue is caused by that module.

Anyways, you're definitely barking up the wrong tree to attack quicksketch for this. The best you could do is beg him to do his own take on inline and get it out there.

+1 to have an UI option for this behavoir.

A lot of us works in the same way: a development site to be moved after to a production site. Its usual to create nodes with images while the site is in development.

So the Pathologic module as a solution is kind of weird. We create a problem with this module and solve it with Pathologic, would not be more logical and clean if we don't create a problem in first place?

I tried the solution in #11 and it didn't work for me, it looks like when the node has a path alias the url is build with the alias.

I added the code in #11 to settings.php and it is still adding absolute paths when I click the button. Is there anything else I need to do?

You also have to apply the attached patch (insert_relative.patch - 3.74 KB), from the handbook: Applying patches

I agree with #36 and just wanted to mention that – while Pathologic works fine and is utilized by me anyway – inserted images still show up broken when editing the node because filters only process field output.

So every time I move a site from local- to test- to live server or change redirects, the editor sees broken images in all edit node pages. In my opinion, this is not a rare occurance and should be foreseen by the Insert module as a standard behaviour.

As far as I know, there are filter modules (even Pathologic?) that process relative to absolute paths via output filters which seems to be a more elegant solution to the problem mentioned in #7.

P.S.: I also recall a CKEditor Bug resulting in relative path problems in Firefox – does anyone know if the use of relative paths with Insert bypasses this problem?

Subscribing--this is something I'm in a desperate need of.

Although it's not a UI option, the solution is posted over here: #887442: Add information about using relative paths to README.txt, putting $conf['insert_absolute_paths'] = FALSE; in your settings.php.

Updating title, since the topic is now more for enabling a UI option. The settings.php solution seems to be amply stated now.

I think in most cases relative paths make more sense than absolutes. Like often mentioned moving a site from Dev to Live with absolute image paths is just a pain. Adding a variable to the settings.php is more like a secret workaround but not a user friendly solution, especially for new user module of this module. Not to mention, that not all admins have access this file.
Please provide an UI option for relative paths, it would make so many people happy! :)

Thanks for your work and this great module!

Is the patch in #11 also for D7 or only for D6?
I also would love the have the option of the relative path. For me it's almost a no go without, because the changes taking to much time if i move the project from development MAMP to the live server.

Is the patch in #11 also for D7 or only for D6?

D7 is a significantly more challenging beast because the new file API makes "relative URLs" pretty much impossible. Because of the new "stream wrappers" like public://whatever.png or flickr://whatever.png, it's not possible for all mechanisms to have a relative URL (since some assets might be on on external service). Since not all stream wrappers can have relative URLs, all URLs are always absolute for all files.

It was a big surprise when I moved my site with the new added module Insert to my production site and al my pictures were gone. I also work with MAMP and without the relative path I cannot use this module.

I hope there will be a relative path option soon.

Use the module in drupal 7

Pathologic and absolute urls is really the only answer at this point.

Relative URLs should be the default and a UI Option would be nice. I have a site that uses https for authenticated users and editing, but is accessable via http, too. Getting all images via https is anoying and gives warnings. Some users don't see the pictures at all. What harm is done using relative URLs as an Option?

http://drupal.org/project/imagepicker offers a good experience and an UI-option for relative and absolute URLs. This might be the more userfriendly way to go.

At this moment with this status,

A BIG +1 for http://drupal.org/project/imagepicker
-single module to enable
-all options have a UI

OK, let's stir up this a bit (eg. to 7.x).

Attached patch tries to solve the issue by providing webroot-relative URLs if absolute ones are turned off _AND_ the actual stream wrapper supports relative paths. Don't know if this approach satisfies everybody, though.

I have just tested this patch. It seems good, thank you Boobaa!

+1 for this in D6. This is a very needed option! Cheers!

#51 works for me

@Kars-T is already in D6 read the README....

This patch is in the wrong place. Please submit it over in #1149910: drupal7 insert relative paths. The current patch doesn't "Provide a UI option", which is what this issue is intended to address. The current patch provides a similar API-only option for D7.

@gargarine
I am talking about the UI option. imho it is very needed to be able to choose if you want a absolute or relative path. Hope this will be added at last.

subscribe.
I need ui option

Yup. Should be relative by default IMHO.

My team of editors are all clogging my node bodies with absolute paths that I'll have to potentially clean up later.
But at least they can post images easily :)

"Relative Path" should not be added in UI because when someone reading from RSS, the relative path will be broken.

For those moving from Staging to Production, you can do a Search and Replace for path in the database. Another option is use the Pathologic module.

Does this make any sense or it's trolling?

I think someone need put note about this absolute and relative URL on the project page.

@jessicakoh definitely not trolling. But I'd say it is easier to change root relative URLs to absolute URLs than change the domain name. So I still vote for an UI option for this fantastic module.

Agreed.
My opinion on the best approach is to store relative URLs. You can always turn them absolute on the way out.
There are lots of situations with: subdomains, multiple domains, movement and migration proof, etc.

I've created a patch for the 7.x version that allows relative path linking for public:// stream wrappers.
http://drupal.org/node/640352#comment-4950506

@lolmaus and anyone else using Aegir. You can just add this setting to the database by enabling Devel module, navigating to /devel/php on your site, and running the following code:

variable_set('insert_absolute_paths', FALSE);

This problem seems to be larger than just the insert module.

Take colorbox for example.
It adds functionality to the insert module that the above "solutions" fail to solve.

As an example, I attached a rather brute-force/hackish patch that makes colorbox+insert use relative paths.
You can compare that when colorbox is enabled, only the "Automatic" image insert works from this module and those functions end up taking over their respective "colorbox insert" options.

It seems that whenever file_create_url() and image_style_url() are called, they always produce absolute url paths. As far as I can tell drupal core does not provide a way to get relative URI paths from those functions.

The solution might be to provide some way, be it custom module or patch, to the drupal core url functions such that we can selectively choose relative paths when appropriate and absolute otherwise.

@thekevinday: You're right that this problem is much wider than Insert, which is why I've been trying to encourage other solutions (as I said in #1, #30, and #33). In any case, I suggest posting your Colorbox concern to the Colorbox queue, as it provides its integration with Insert directly.

quicksketch,

The relative url patches have been priceless for 3 free community sites i run and maintain. I would really be very interested in seeing some form of solution in the insert module until the "larger" issue stopping complete support of relative urls can be worked out (no idea when that will happen and looking at the problem not soon is my betting).

I know it isn't a simple problem but consider using Insert with the Deployment module in D7.

Client looks at staging.yourdrupal.com and approves changes.
All images and files would be for example :
http://staging.yourdrupal.com/sites/default/files/images/image.png
Developer clicks deploy to www.yourdrupal.com.
http://www.yourdrupal.com/sites/default/files/images/image.png

Oh... none of the images or files work across all content.... shame all the urls weren't relative...

Path Filtering modules really aren't a good solution for the above situation. And i don't think you should rule out support for relative URLs just because they don't work with RSS agg.

None of the three sites i mantain use RSS and aren't planning to, so RSS isn't an issue for me (and by the looks of all the issue threads alot of others).

Overall relative URLs would be a very nice option even if some notes need to be displayed next to the configuration options.

Please consider it yet again!

I thought I really wanted this relative URL. I was wrong. Search and replace the URL was really easy. Only 2 queries.

UPDATE field_data_body SET body_value = REPLACE(body_value, 'localsite:8888', 'example.com');
UPDATE field_revision_body SET body_value = REPLACE(body_value, 'localsite:8888', 'example.com');

I stand by quicksketch.

Not really an acceptable solution when deploying to a live enviroment from a development / UAT enviroment. I will stand by the relative url solution. I feel it should just have a UI option with a warning description.

In a professional staged enviroment absolute urls are not a fesable solution.

Hey guys, yeah I've finally come around on this issue. If someone writes the patch for making this an option at the widget level, I'll include it. I don't want to keep it as a global-only option because there isn't anywhere to put the setting, so making it a per-widget setting (maybe using the existing variable as a default value) seems like the way to go.

Also regarding relative paths in D7, this is still an issue: #1149910: drupal7 insert relative paths. A review and RTBC on that issue could also help bring this to completion, since there's no way we can add a UI option until relative paths work at all.

quicksketch,

I might be able to include reviewing and testing of #1149910 for D7 as part of a current working project. I'll see if this is an option. If i have time this sprint then i'll include it as a task. If this isn't an option then i'll stay late tonight and do the testing etc in my own time.

There is a definate need for this functionality though the stream wrappers really don't make this easy! I've no idea if i'd be able to do the extra development but i might give that a go as well...

quicksketch,

How easy would it be to add the logic behind a checkbox next to the "Insert" button, labeled, "Strip Domain?"*

Would have to add a statement in the readme that it only removes the domain portion of the URL (e.g. installed in a directory will still have problems upon migration), but it would seem to provide an acceptable solution to 90+% of the use cases for Insert.

Best,
Sam

* Strip Base Path, Strip ...,

How easy would it be to add the logic behind a checkbox next to the "Insert" button, labeled, "Strip Domain?"*

It would be easy. That's what the original patch did way back in 2009, but it needs to be updated. As you can see it's actually a fairly simple thing to do technically, we were just hung up on philosophy.

Relative URI should be the default. An option isn't required.

@js please read the whole thread. What you say is not true if we need the URL for newsletters and such. So an option is the best way. I hope for a patch soon.

@quicksketch regarding #45:

Maybe issue #1451320: Evaluate Symfony2's Finder Component to simplify file handling could be the beginning of the solution to this problem in D8?

@js: you are right: Relative URI should be the default. But not a must. Thats the sense of an "option".
Oh so much time only for discussion is thrown away...
*sigh*

Another reason not to put relative URL is when you shared in social media, relative URL would be a problem. i.e. Facebook share.

@quicksketch, you absolutely want to maintain the current design.

We are talking about adding an option to choose what we desire not changing the design.

@jessicakoh: See #69.

I finally fixed up #640352: Linking with relative paths (and its duplicate #1149910: drupal7 insert relative paths), so we have relative URLs at least possible in D7.

This pair of patches (finally) adds the UI for relative links to the module. It's roughly the same as the original patch, only it adds a parameter to insert_create_url() instead of adding a new function that strips the domain separately.

Based on people's feedback here, I've set the *relative option as default*, and you have to check a box to enable absolute URLs. Anyone who sets the old 'insert_absolute_path' variable, that will be used as the default for all new fields (and any existing fields that existed before the 1.2 version).

Perfect that relative become the default. When will sou commit it?

@quicksketch, I am sad that you gave in to whiners.

Relative path should not be default. Relative path should be in in the first place. I don't understand why people find it hard to use a mysql query in their production server to convert local's absolute to server's absolute.

What next? iPhone will have two buttons because 500 people complain.

@hass, it will be perfect if you can chip in and submit the patch.

Relative paths are correct, they work with every protocol (http/https). This has nothing to do with whiners. Only maintainers can commit.

I don't think any more patches are necessary. The current ones work fine, afaik.

I held out on this for almost 3 years because I didn't think relative paths were the right thing either. However an overwhelming number of people have expressed in the issue queue, in person, and over IRC that the absolute paths were causing them confusion or more trouble than relative paths would. I think I got the default wrong and if I were dead-set on keeping it simple, I'd just flip the $absolute variable and make relative the default and force users who wanted absolute to set the variable.

But honestly, seems like there are people in both camps, having the option keeps everyone happy.

I already committed these to the Git branch. Though I forgot to remove the documentation from README.txt. Seems like it's probably irrelevant if there's just a UI option now.

Cleaned up the README.txt by removing the related section.

http://drupalcode.org/project/insert.git/commitdiff/08d07f3d9035fff6f2b9...

I already discussed this with pathologic maintainer who had absolute paths forced in past #516294: Can pathologic alter img src paths to be HTTPS if the page is served out HTTPS? and no way to turn relative on. I have the position that Core need to get fixed to set/optionally allow absolute paths in RSS feeds only (if there is a problem with rss readers). All other urls/paths should better be an internal drupal path (fixed with pathologic) or relative path. I guess this was never done because of the hard rules not to change D6 core APIs.