| Project: | Media |
| Version: | 7.x-2.x-dev |
| Component: | WYSIWYG integration |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
Hi
Perhaps I am doing something wrong but this has been an issue on 3 sites now.
When an image is interested via a wysiwyg editor the path is set absolutely. This is great when working out of the same domain name all the time. But in our development work flow this does not work.
When we develop a site the working out of http://dev.domainname.com
Then is goes to staging for client interaction which is: http://stage.domainname.com
Last when in production it's: http://domainname.com
When we move the site between these domain name the path doesn't match the uri. For example if an image was added to a peace of content (using ckeditor) when in dev.domainname.com. And we push the site to stage (using drush rsync and sql-sync) all the images placed by the editor still have the http://dev.domainname.com/path_to_image where as it should be http://stage.domainname.com/,..........
Is there a way to configure this?
At present I go back and reedit all the content and it's painful please help.
Comments
#1
I am having the same issue.
the image paths are fixed after clearing the cache
but after the cron runs the paths are again reset to http://domainname.com while the site i am working in is a sub domain http://dev.domainname.com
#2
I used pathologic to overcome this issue hopefully it will work for you to.
http://drupal.org/project/pathologic
#3
I do a find and replace on the database export before importing.
#4
my issue is somewhat different,
I am currently working on dev site,
the image appears in the wysiwyg editor in node edit page but appears broken in node view page.
when I inspect element,
in wysiwyg:
<img src="http://dev.mySiteName.com/sites/mySiteName.com/files/imageName.jpg" alt="" class="media-image attr__typeof__foaf:Image img__fid__52 img__view_mode__media_original" data-mce-src="http://dev.mySiteName.com/sites/mySiteName.com/files/imageName.jpg">in node view:
<img alt="" class="media-image" typeof="foaf:Image" src="http://mySiteName.com/sites/mySiteName.com/files/imageName.jpg">After I clear the cache, the image paths are corrected with path to dev site.
I found the culprit. it was this filter in my Text/input format "Convert URLs into links"
I disabled it and everything works good.
#5
This bug exists in 1.x as well. Is there any chance this will be assigned and worked on?
Installing and configuring pathologic made no change to the resulting URL.
Our site already has "Convert URLs into links" disabled.
#6
Marked #1548426: Store/display relative path in CKEditor images as a duplicate.
#7
Hi there, just wondering what the priority level of this is for the devs and if there's a solution on the horizon? Thanks!
#8
Marked #1660936: Media filter should not generate absolute URLs as a duplicate.
#9
there are certain instances when being able to force an absolute url would be useful ( like when forwarding nodes via email ). It would be great if this was configurable per content type. It's a thorny issue....
#10
I have a strange bug which seems related to this discussion. When an image is inserted into the body field via wysiwyg and the "add media" button the rendered page gives a path starting with
"http:///sites/default/files [etc]"
and the image is broken. This only happens in my production environment where everything is cached (though I fail to see why that would matter). I have the same database synched on my local devmachine and the path is
"http://productionurl.com/sites/default/files [etc]".
So the reference on my local machine is absolute to the production environment, which is fine for my workflow, but on the production environment the path is broken. It is neither relative nor absolute, it omits the domain. This seems to occur after a while (possibly after cron runs). If I edit the node and save it again the image paths are back to what they should be. Also if I edit the input filter. But then the problem comes back after a little while. My last bid is to disable "convert urls and email to links" in the input filter. But I have a bad feeling I will soon have the problem back again...
Has anyone experience something similar and been able to solve it? If the path was without the domain
src="sites/default/files ... " i would not have this problem. It is the "http:///sites..." that creates the problem.
#11
@leanderl How are you using the production url on the site? Are you aliasing with a sites.php array value or are you host hacking to use the production url on your local machine?
#12
hello @crimsondryad. On my local machine I have the correct path to the production server. So the images need to be on the production server for the local version to work, but that's fine for my workflow. I usually publish content "live" and then copy the database and files folder to my local machine. (So on my local version the images are actually loaded from the production server, while content is from local).
What is the media module supposed to do in it's default state? Create a img src of type "http://domain.com/sites/default/files [etc)" or is it supposed to create a img src of type "sites/default/files [etc]"? I'm considering trying to hack into the latter behaviour. I just can't understand why the production site gets "http:///sites/default/files [etc]". The domain name on the production site is somewhat unusual though it is in this pattern: vps-123455.serviceprovider.com, because it is not "released" yet and hasn't had it's future conventional domain name assigned to it. So the domain prefix is vps-12345. Perhaps that somehow screws something up? On my dev site I have prefix "loc": loc.domain.com
#13
I'm assuming that the issue here is that images are being inserted directly using WYSIWYG and the "Image" formatter (which creates an absolute URL).
I see two ways to fix this:
Opinions?
#14
Hi Devan, I'm not sure about this. I tried to understand what you wrote, but it seems to be about embedding other documents than images. I'm not sure what you mean by "Image" formatter. I use the media "add media" option for the wysiwyg (CKEditor).
What is embedded in the Wysiwyg field is the "fid"
[[{"type":"media","view_mode":"media_large","fid":"5597","attributes":{"alt":"","class":"media-image","height":"171","title":"","typeof":"foaf:Image","width":"176"}}]]And the output is always(!) correct on my local version and usually breaks within a few hours on my production site. I never experience this problem on my local install of the site. The only difference between the two is that the production site uses caching for blocks. And the the url begins with "vps-1234" instead of a more traditional prefix such as www or dev or loc. The result as stated above is "http:///sites/default/files..." vs "http://loc.domain.com/sites/default/files..."
If I could skip the "http://" the problem would go away I guess...
#15
So i temporary sorted it out by doing this jQuery filtering, but it is an unsatisfactory feeling.
$('.view-name img').each(function() {
var img_src = $(this).attr("src");
var starts_with = img_src.substr(0,8);
//If the src starts with http:/// something is wrong, remove http://
if (starts_with == "http:///") {
img_src = img_src.substr(7);
}
$(this).attr('src', img_src);
});
It will be interesting to see if there is any difference once the site runs on a more conventional domain prefix...
#16
I'll try the patch for the first option in #13. I'm thinking that is a slightly better option.
#17
There are multiple different issues here:
garethhallnz: Media transforms the media tags into markup (an image with an absolute URL) when you first view the page with the media on it. If you have caching enabled, Drupal will cache the page contents, including the image and its URL. So if you view the page on development and then move the development database to production, including the cache table, anonymous users will still get the cached copy of the image which uses the URL that points to development. Clearing the cache and then visiting the page again should fix this.
crimsondryad: I believe that all core URL generation functions, including the ones used by the Generic file and Image formatters use absolute URLs. This is because some files cannot have a relative URL. For example, how could you get a relative URL to a YouTube video? In order to do this, custom formatters would need to be written (as I mentioned in #13) which only work with certain URI schemes.
leanderl: It seems like you have a configuration problem, you should never get a URL like "http:///sites/default/files". Since Media uses the core formatters, I don't believe that this is a Media issue (and switching to relative URLs probably won't solve the problem). You'll also want to see my response to garethhallnz on caching to make sure that is not your issue.
#18
I am also getting "http:///sites/default/files/myimage.jpg". An additional caching problem we have is that admins and editors can only log in under https, but our normal vistors use http. So after saving the src is saved using https.
#19
Here's some threads that may be vaguely related, at least in the sense that they regard images being output with src "http:///sites..."
http://drupal.org/node/1559716
http://drupal.org/node/1786952
http://drupal.org/node/1783686
@Devin you may very well be right that the problem does not reside within Media, but in my case somehow occurs when Views is rendering a "full content" node display. What I find so strange is that the problem occurs after a while and not at once. It is not there to begin with, but emerges after a few hours, so it seems like something with a cron job or some other "task" that is run after a while changes the cached content. And yet again, I have the exact same database and files on both machines. It's the machine with cache turned on that breaks the image src.
#20
@Devin Wasn't that the purpose of having stream wrappers though? It seems to be that if the media was stored in the database with the streamwrapper, when it cached and/or rendered it should be getting the actual path the site is on. In many cases absolute urls make sense ( like if you're emailing a node ), but not always.
Using the stream wrapper may take a bit more processing time after a cache clear to generate the correct absolute url, but otherwise it shouldn't be too bad. And it would be really nice to be able to specify on a specific content type or asset type if the urls should be relative or absolute. If the default is absolute, that's ok...so long as if we really need them to be relative they can be.
#21
I'm seeing this issue when using an 'admin.clientdomain.com' url for site administration. Media urls uploaded via the WYSIWYG are prefixed with 'admin.' and not available to the public. I'm experimenting with the attached patch against the 1.2 branch - not sure if it applies but you get the idea - set :
$conf['media_browser_relative_url'] = TRUE;
in settings.php
Not sure if there is a more appropriate way to fix the problem, but hopefully this helps the discussion...
#22
@aaron there's also the http://drupal.org/project/pathologic module to help with that. It will allow you to define specific sites as being local and will use the appropriate url.
#23
My two cents...
Hey all! Can't say it enough, I love Media and have it installed on every site I develop!
I wanted to pipe in to mention that I agree with crimsondryad in comment no. #20. I sorta thought that having a stream wrapper would do all the magic of correcting URLs.
In line with crimsondryad's last comment #22, I too have implemented the work around of using Pathlogic. It's a good enough work around and I don't think it should cause major performance issues - but then, I'm a total NOOB when it comes to server performance. I recall reading that the number of modules active on the site drastically decreases performance and increases server CPU load on Drupal sites - which makes sense - so the less modules I can install/activate, the happier I am!
Once again, thanks to the maintainers, Media+Media-suite-of-modules rock!
#24
The problem I had with the pathologic solution (which just treats the symptoms and is not a cure) is that pathologic sends its paths through url(), which calls hook_url_outbound_alter(), which lets other modules (purl in my case) alter the path.
So for me, if a mobile device is used to edit the page, or is the first to hit a page after a cache clear all, then the path is saved as a mobile path for all devices, which is completely wrong.
I ended up just writing my own input filter to fix the media module's paths in the meantime.
#25
@crymsondryad - I backed my patch out and am now successfully using the pathologic module. I also agree with @awolfey that such a fix addresses the symptoms and is not a solution. I think stream wrappers should support this -- does it makes sense to move this to a core issue?
#26
I guess we could...this seems like kind of a mess the way it is and there doesn't appear to be a clear fix.
#27
this should fix this:
#1942688: Documents embedded in WYSIWYG get converted to HTML by the editor
#28
@rootatwc
Will this #1942688: Documents embedded in WYSIWYG get converted to HTML by the editor fix the issue even if we are not using a WYSIWYG ?
I found this issue from another issue #1660936: Media filter should not generate absolute URLs where the images are not showing because they are given absolute urls. The image is often given https URL which the security certificate prevents the image from showing.
#29
if you are not using wysiwyg how you insert the files in the wysiwyg?
#30
My situation is that I am using the media module with views slideshow, so that I can reuse featured images.
In my slideshow I started noticing that images where blank and then found these issues. So because the images have a "https" prefix the slideshows are blank.
#31
then you are using image fields? that should not happen, image fields store the file id not the path
#32
I had the same issue described by garethhallnz.
The solution #2, http://drupal.org/project/pathologic, works perfectly for me.
It solves my issue in minutes. Thanks garethhallnz.
#33
Related: #1984424: RFC: Disable caching for media filter
#34
#1942688: Documents embedded in WYSIWYG get converted to HTML by the editor
and
#1984424: RFC: Disable caching for media filter
will fix this