Media assets should have relative paths for wysiwyg editors

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

I do a find and replace on the database export before importing.

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.

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.

Marked #1548426: Store/display relative path in CKEditor images as a duplicate.

Hi there, just wondering what the priority level of this is for the devs and if there's a solution on the horizon? Thanks!

Marked #1660936: Media filter should not generate absolute URLs as a duplicate.

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....

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.

@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?

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

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:

• Implement #1792738: Allow custom file view modes for WYSIWYG display. This makes Media only display a preview with WYSIWYG. Since the actual display of a file is generated on page load, no paths are stored, the URL to the file will be built using the current domain.
• Write custom "Media" versions of existing formatters that generate relative URLs (this is what the Insert module does, see http://drupalcode.org/project/insert.git/blob/refs/heads/7.x-1.x:/insert... for an example).

Opinions?

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...

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...

I'll try the patch for the first option in #13. I'm thinking that is a slightly better option.

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.

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.

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.

@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.

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...

@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.

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!

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.

@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?

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.

this should fix this:
#1942688: Documents embedded in WYSIWYG get converted to HTML by the editor

@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.

if you are not using wysiwyg how you insert the files in the wysiwyg?

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.

then you are using image fields? that should not happen, image fields store the file id not the path

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.

Related: #1984424: RFC: Disable caching for media filter

#1942688: Documents embedded in WYSIWYG get converted to HTML by the editor
and
#1984424: RFC: Disable caching for media filter
will fix this

I had some weird issues with pathologic where it didn't seem to be working. I resolved the issue with a custom filter that replaces all links with relative links (/sites/default...).

Use Custom Filter

Use this template REGEX as a guide,
/https{0,1}:\/\/(dev|www)\.mysite\.com\//i

You can replace (dev|www) with all the sub-domains and mysite with the name of your site.

Set the replacement as "/" (no quotes, just the slash).

Perhaps if others have any issue with pathologic and media, etc, this is another quick fix that patches a hole.

Nice, after you went live, you are forced to do some search and replace in mysql dumps.
That's incredible. But you should not expect anything.

Pathologic solution doesnt work for me.

Patch in comment #21 works like a charm! Makes possible relative url to work with Media module.

closed duplicate? where is the real thread then?
this bug will kill every images inserted with media via wysiwyg if site is used from dev to live.
pathologic doesnt work here neither. 10 sites are broken as is see now.
for pathologic to work you must input the currently WRONG URL like http://www.dev.localhost/

The bugs linked in #34 don't appear to address the issue of absolute URLs being generated instead of relative URLs.

is anyone still looking at this thread?

I can't see what's wrong with the patch in #21 (maybe add a field in UI to choose relative or absolute?)

But it's definitely vital to be able to use relative paths. Otherwise, there's no clean way for moving between local, dev, staging and live servers!

#21 Worked for me but I had to clear Page and Else cache.

patch #21 looks good but we should also check to see if base_url is set before using it.

*EDIT* actually I had another closer look, patch#21 is still not the ideal solution, why use the base_url , we can use parse_url to get it, see my next comment

something of a variant of #35 and #21 combined using parse_url()

ok, if you modify patch #21 with this:

  // Support absolute / relative urls.
  if (variable_get('media_browser_relative_url', FALSE)) {
    $tmp_scheme;
    $tmp_host;
    $tmp_port;
    $tmp_base_url;
    $parse_tmp = parse_url($file->url);
    $tmp_scheme = $parse_tmp['scheme'];
    $tmp_host = $parse_tmp['host'];
    if(isset($parse_tmp['port'])) {
      $tmp_port = $parse_tmp['port'];
      $tmp_base_url = $tmp_scheme . '://' . $tmp_host . ':' . $tmp_port;
    }
    else {
      $tmp_base_url = $tmp_scheme . '://' . $tmp_host;
    }
    $file->url = substr($file->url, strlen($tmp_base_url));
  } 

then the output of $file-url will be the relative URL, however in my case this doesn't seem to be the full solution. There is obviously other areas where the base_url is used

$file should be passed in by reference to the media_browser_build_media_item function should it not? passing by value and then not returning anything won't actually do anything other than run code that doesn't store any result.

I'm wondering if this patch is related :
https://www.drupal.org/files/issues/dont_use_absolute_url-2212553-2.patch

@joseph.olstad are you successfully using the code in #43?

I don't understand the question about #45 - I assume you've found an answer by now.

Would be nice to get this fixed for 7.x-2.0-rc13

mgifford , that was a while back, I recall it was a problem when we were using deployment from a different url to another url without the base_url being set. I haven't had to deal with this since.

If you can clean up the code in #43 and put together a patch, by all means, do so and then lets try to get it reviewed and added provided that the solution works for you and hopefully will work for everyone else as well.

Thanks

Still a bug in Media 7.x-2.9 ...

Why has this been open and never fixed for 6 years!

Bumping priority to Major, as having to do a "find and replace on the database export before importing" is both insane and the only valid solution after, again, 6 years...

Joseph, I think you came late to Media, but with the amount of outright broken parts of Media, why don’t you just mark the whole project as obsolete and be done with it.

Yeah, Media is a nice concept, but it causes so much wasted time trying to fix what should be simple things and creates incessant client complaints.

PS:
No! Base URL should not be used. For the most part, Base URL was a kludge fix for D6.

Patch?

Patch 21 looks like it should do the trick.

new patch, I haven't yet tested this though.

Yet a newer patch based on my own suggestion in comment #43

+ // Start off with relative urls supported.

Like that.

And, always hate to give estimates on D.O ;) But... I should have time Sat morning to apply and test this.

Edit (Note to self):
https://api.drupal.org/comment/14134#comment-14134
$file_uri = file_create_url(file_build_uri('images/example.jpeg'));

putting this in 7.x-3.x rather than 2.x, it can be merged back to 2.x once successful uptake in 3.x

Fixed

pending merge to 7.x-2.x

fixed in 7.x-3.x , released in 7.x-3.0-beta5
however it was not included in 7.x-2.10
if you want this functionality in the future yet to be determined 2.11 release then please try it/use it in 7.x-3.0-beta5 first and report back to us here to say if it works well enough for you to give it the thumbs up for 2.11.

Huh, guess I wrote it up, but didn't add the Comment :(

tl;dr
I can guess, but where, and what variable name, does Media set for ‘src=’ and I’ll go fix it.

# # #

No go on 7.x-2.10

Testing Steps

Install patch:

# cd sites/all/modules/media
# wget https://www.drupal.org/files/issues/1352182-media-browser-relative-urls-54.patch
# patch -p1 < 1352182-media-browser-relative-urls-54.patch
patching file includes/media.admin.inc
patching file includes/media.browser.inc
patching file media.install

Update Media Configuration:

admin/config/media/browser
Check: Support relative / absolute urls 

# drush vget media_browser_relative_url
media_browser_relative_url: 1

Clear Cache:

# drush cc all && drush cc all

Add image with link to WYSIWYG body field using Media Browser button.

Resultant page source (re-formatted):

<div class="content node-content">  <!-- Node content -->
  <div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items">
    <div class="field-item even">
      <p>some beging teext (top)</p>
      <div class="media media-element-container media-teaser media-wysiwyg-align-left">
        <div id="file-392" class="file file-image file-image-jpeg">
          <h2 class="element-invisible">
            <a href="/file/market-hoursjpg">market-hours.jpg</a>
          </h2>
          <div class="content">
          <a href="/sites/default/files/public/market-hours.jpg">
            <img alt="overlapping markets" title="overlapping markets" class="media-element file-teaser" data-delta="1" src="http://d7pat.srv04-inet-design.com/sites/default/files/public/styles/medium/public/market-hours.jpg?itok=WbYmPQ5A" width="220" height="132" />
          </a>
        </div>
      </div>
    </div>
    <p>right text</p>
    <p>more text</p>
{snip}

admin/config/media/browser
Un-Check: Support relative / absolute urls 

# drush vget media_browser_relative_url
media_browser_relative_url: 0

<a href="/sites/default/files/public/market-hours.jpg">
  <img alt="overlapping markets" title="overlapping markets" class="media-element file-teaser" data-delta="2" src="http://d7pat.srv04-inet-design.com/sites/default/files/public/styles/medium/public/market-hours.jpg?itok=WbYmPQ5A" width="220" height="132" />
</a>

Michael, so I'm reading your test results and it appears confirmed that 7.x-2.10 fixes the issue right?

Ah, no, both with and without "Support relative / absolute urls" checked the full server name still ends up in the img src=

***EDIT***
see next comment
***EDIT***
ok, so it doesn't yet work.

Setting this issue back to 7.x-3.x and from needs review to 'needs work'.

TODO: back off the 7.x-3.x commit and continue working on the patch

AH!, Michael, when you were testing, did you forget to remove/disable the base_url from your settings php?

Please confirm... suspect you might need to retest this. Please confirm

Hey guys!
I am happy to know that I am not the only one with this problem.
I appreciate your interest.
I have been trying to use the patch without success, and looking for some alternatives but I can not find a way to do it.
In my case it would be enough to be able to cut the path and remove the domain but it is being impossible to me.
Is there any alternative solution, even if it is not the right one?
I understand that at some point the image src is receiving the domain, it would be impossible to modify the src and fill it without the domain?
Thanks to all!

Sorry Joseph,

Client did a 'surprise lets launch this yesterday’ Even though they hadn’t even QA’ed payment processing… [1]

In answer to your question, no I don’t use base_url (e.g. for D7 I always leave it un-set) as it’s an ugly hack that was introduced for D6 (D5?). No decently built D7 site should ever need it.

I don’t mind fixing this, just give me a pointer, so I don’t send several hours code tracing, to where, and what variable name, does Media set for ‘src=’, or I guess better where does Media browser do it’s return to WYSIWYG?

Best!, spend 5 minutes giving me a flow rundown of the Media browser button, and I’ll do all your MBB work in the future :)

Best,
Michael

[1] Ah, yeah, btw, (and yes I’ll add a ticket for this), Media browser truncates link URLs at around 130 chars, which was fun to track down ;)

Are you testing with 7.x-3.x? It has the 'fix'.
As for the other 130 character truncate, interesting.

patched (#54) 7.x-2.10

I've been using a copy of the clients latest build to test on, but can't really install 7.3 on on the client prod site until 7.3 hits a 'production ready' status.

I can do that on my local copy, but I don't expect to have any time at all this week with the number of outstanding issues they have from a rushed push to production.

You can hit me up in email if you don't want to keep adding posts here.

Best,
Michael

Holding off putting this patch into 7.x-2.x until some more reviews of it in 7.x-3.x comes in.
Michael-IDA, a full cache clear would be required after patching, and also before cache clear you'd have to go to the settings and enable this option, as this patch brings in a new optional setting for relative paths.

I haven't had a lot of time to test this myself, that is why it's not committed to 7.x-2.x, it is in 7.x-3.x though.

Other configuration that might prevent this from working:
base_url settings in settings.php
and
rewriteBase settings in .htaccess

cache clear required after the relative path option is selected (provided settings.php and .htaccess are correct)

Ah, yeah, did all that, standard stuff there.

Only question is on 'rewriteBase settings in .htaccess. [1]' As I'm not clear on how that's going to (or could) change how the data is stored in the DB?

Well and a philosophical question, since this is basically our own private thread, why the addition of the 3x branch instead of the standard use of 2x-dev? That really does seem to reduce the number of people who can patch, test, and review for you. Well, at least me, but maybe I’m missing the big picture?

Best,
Michael

[1] I’m fairly sure it was not set when I did the testing, but it is now as they needed redirects from old URL patterns to new URL patterns.

7.x-3.x allows us to commit changes faster than what we would put into 7.x-2.x. There's not much difference between the two right now. Basically it's helped push the development of the 7.x-2.x branch along.

I've been purposely delaying certain patches from getting into 7.x-2.x , preferring to put them in 7.x-3.x first.

The current difference between 7.x-3.x is these two commits:
#1352182-57: Media assets should have relative paths for wysiwyg editors
and:
#1343022-98: Adding alt and title attributes from fields to image markup

Otherwise the branches are identical except for the logs and one drupal_set_message.

Patch in #54 isn't working for me either. It seems to be doing it's job, I can see using XDebug the url property of $file being overriden, but when saving the content and displaying the page the full URL it's shown.

It may have something to do with the filter ran in the method media_wysiwyg_token_to_markup, when rendering the file it generates a full link to the image instead of the relative one. If I find a way to fix it I'll add a patch here.

It did not work on the 3.x either, for the same reasons I guess.

ok, well , if you can, write a patch for the 3.x branch to fix whatever the remaining issue is and share it here.

I'm considering upgrading my various sites to 3.x but the comments about the use of base_url in settings.php gives me cause to pause.

I note that @Michael-IDA does not use base_url so wandering what is for the best, with respect to relative urls for inline media.

Not sure whether this is normal practice, but when hosting with Cloudways it is necessary to set the base_url to htttps://www.domain.com

Like others I have found absolute urls to be a big problem with media module, when moving a site from staging to production.

Confirmed patch #54 applies and works just fine in Media 7.x-2.x (I did it on 7.x-2.19).

patch 54 was committed a long time ago to the 7.x-3.x branch with very little feedback (although no complaints), can anyone confirm if this is working for them in 3.x and/or 4.x?

I've just applied #54 patch to 7.x-2.21. Variable media_browser_relative_url set, caches cleared etc, but still inserts inline images with a full path (that's for images uploaded locally and web images that are copied in the Drupal filesystem). The code looks as though it should work... but doesn't for me.

Hi, I have to tackle this for a project where we need to have access to the development site from multiple, different URLs and having absolute paths is causing havoc. For now, I just wanted to make a couple of points about the patch in #54:

1. The patch won't do anything at all because the media_browser_build_media_item() function is NOT receiving the $file argument as a reference, so whatever it does to the object is lost in the infinite. I guess that's a bug that has been unnoticed for a while.

2. After fixing that and seeing no results, I realized that the function is used only to format image thumbnails in the Media browser, it won't do anything at all for the file when it is inserted or when it is rendered in the page. That was my main and (I suspect) most people's source of confusion, since I expected the path changed when displaying images in the node page.

If I manage to find a way to achieve that I'll post it here.

Hi Proteo, thanks for your in depth analysis and report. Hopefully you can also solve this for us and provide a patch.

Hi Joseph. I did some research indeed and I think the whole thing may need a different approach (please take my words with caution, I'm not an expert in Media or File modules by any means). I followed the trail of the whole render process using xdebug and couldn't identify any spot where Media could alter the generated URL before serving the file, but we may be barking at the wrong tree. Let me explain.

Media hands over the file object (containing the URI, not the path) to the image render function which depending on a number of factors could be theme_image_formatter(), theme_image_style(), etc. These functions use a number of variations to generate the path for the file. For example, theme_image_style uses image_style_url(), etc. but one way or another, I think in most situations the URI eventually reaches core's file_create_url(), where can be modified via hook_file_url_alter(). In the code of file_create_url() you can see that if the scheme (presumably, public://) is not present in the URI, the function will return just the portion of the relative path, which (theoretically at least) would give us what we want.

So in short, if we reeeally want to do this I think we have two options:

a) Strip the scheme from the URI before passing the file to the render function.
b) Create the alter hook for file_url, (would be media_file_url_alter) and from there strip the scheme portion from the URI.

I think the second option would be like a grenade though, because all the info you have in the function is the URI and I can't see any way to discern where the file is coming from so the change would affect every file path generated in the site. The first option sounds more appealing, if it seems right to you I could give it a shot. I must confess that for now we had to resort to Pathologic as a solution, so right now I have nothing but the theory :)

ya it's complicated, but sounds about right from what I recall. Don't kill yourself over this, but if you do bake something up, I'll review it and test it myself using the media_dev distribution (media_dev is the easiest way to test a media setup with sane defaults btw). I have a few sites running based on the media_dev distribution.