TinyMCE adding image puts full path? Work around?

Topics: Core, General, Troubleshooting
Jan 26, 2012 at 1:49 AM

Hi everyone.  I've noticed that when TinyMCE adds images through the media picker, it seems to add the full URL with the domain attached.  That is problematic given that my domain name changes by environment (DEV -> UAT -> PROD) its hard to migrate content between the environments.

http://mydomain.com/Media/Default/myimage.png

If I try to remove all the paths

/Media/Default/myimage.png

It works great on the page itself but the editor shows the image as broken.

I've also tried ~/Media/Default and Media/Default without any impact.

 

Any thoughts?

Coordinator
Jan 26, 2012 at 4:16 AM

File a bug.

Jan 27, 2012 at 3:03 AM

Will do, I know how to fix it even, just not sure how to route the correct data to it:

 

Go to Orchard.Web\Modules\TinyMce\Scripts\orchard-tinymce.js

Edit the file

Add document_base_url : "http://www.site.com/path1/",

Where the document_base_url is set to the root URL of the site

obviously hard coding my root url into the file of a module isn't good but it would seem the correct action is to have this pull from the dashboard settings.

Feb 16, 2012 at 1:05 AM
Edited Feb 16, 2012 at 1:06 AM

Hi bertrandleroy, I opened a defect and you closed it as unable to repeat.

http://orchard.codeplex.com/workitem/18390

Perhaps I can provide a better/easier example to repeat the issue better:

  1. Create a site at http://localhost/
  2. add a bunch of content with images using tinymce
  3. modify the site so that it's root URL is http://localhost/mysite
  4. result, all the images are broken.  
  5. If I add images, it adds mysite/media/folder/myimage.png to the path, if I move to a different subsite or back to localhost it's broken again.

I'm using 1.3.10.  The issue of course is that your dev and prod better match the exact same subsite and that is a poor assumption.  I would expect TinyMCE to use my General Settings BaseURL to help it append that to the image path.

Coordinator
Feb 16, 2012 at 1:17 AM
Edited Feb 16, 2012 at 1:18 AM

TinyMCE actually has little to do with this: once your content has been saved, and it contains the site-relative URL of images, if you change the structure of the site by moving it under a different virtual directory, yes, your images will be broken. To fix that, we'd have to save tokens representing the path instead of the path, and have post-processing of the output to replace those tokens at runtime with the actual path. It's doable but it's not implemented currently.

In the meantime, the workaround is to configure your dev environment to reflect the structure of prod.

Feb 16, 2012 at 1:42 AM
bertrandleroy wrote:

TinyMCE actually has little to do with this: once your content has been saved, and it contains the site-relative URL of images, if you change the structure of the site by moving it under a different virtual directory, yes, your images will be broken. To fix that, we'd have to save tokens representing the path instead of the path, and have post-processing of the output to replace those tokens at runtime with the actual path. It's doable but it's not implemented currently.

In the meantime, the workaround is to configure your dev environment to reflect the structure of prod.

Thanks bertrandleroy.  I'm still curious though why it couldn't use the Base URL property as is without the tokens.  The rest of the site already operates like this where ~/url is http://domain.com/url or http://domain.com/subsite/url based on the root of the application itself.  That includes images that are part of my theme, menu's links etc.  Why are images in content types any different?

So when you say "and it contains the site-relative URL of images," I would expect the concept of sit-relativity be from the base application URL as defined by IIS or BaseURL setting in the properties.  Perhaps you can help me better understand the value of the BaseURL property?

Sorry, not trying to be difficult, just trying to understand what is so unique about images and anything I could do to assist. 

Coordinator
Feb 16, 2012 at 1:45 AM

Because it's in the middle of a fragment of HTML that is saved as html. There is no such concept as site-relative in HTML: it's absolute, relative to the domain, or relative to the current resource (http://foo.com/bar, /bar or bar). The ~/ construct is something that only exists on the server side and needs to be processed before the client can use it. Makes sense?

Feb 16, 2012 at 1:48 AM
bertrandleroy wrote:

Because it's in the middle of a fragment of HTML that is saved as html. There is no such concept as site-relative in HTML: it's absolute, relative to the domain, or relative to the current resource (http://foo.com/bar, /bar or bar). The ~/ construct is something that only exists on the server side and needs to be processed before the client can use it. Makes sense?

ah, got it. That is what is meant by post processing.  Thanks for walking me through it.