While I can agree with your frustration here, there is a very logical explanation for this… permalinks. If you did not have permalinks turned on, relative urls would work just fine everywhere a post can be displayed.
On my blog, I use the “Day and name” based permalinks.
This means that a post can be displayed at anyone of the following urls:
http://example.com/
http://example.com/2009/06/13/sample-post/
http://example.com/category/tacos/
http://example.com/tags/tacos/
There is no relative path that satisfies all of these combination.
Hope this helps!
mfields, a relative path from root would work in all those cases, wouldn’t it?
/path/someimage.jpg
The problem, as I see it is that there uploads are just files and are not associated with any object in the database.
If they had DB entries, registering them, it would have been possible to access the files in different ways. The permalink would have been calculated in real time, based on the permalink structure.
As it is now, the only thing that identifies files is their path on the hard drive, so there’s not much to do about it.
mfields, a relative path from root would work in all those cases, wouldn’t it?
/path/someimage.jpg
Definitely not on my development machine 🙂
A relative path, while a nice idea, is as problematic as an absolute URL. At least with an absolute, you can search/replace in the database fairly easily.
And as anyone who’s moved their content folder knows, it’s a pain in the ass!
Relative paths are perfectly doable even in an environment such as wordpress. ASP.NET has had a solution for this problem for years: the tilde. The tilde represents the base URL of the application, and converts any URL (that is generated by the server) to a absolute url.
Analogue to wordpress, when an image (or other object) is inserted in a post/page, do not include the full path. Instead, include something like “%siteurl%/path/to/image.jpg” and UPON DISPLAY convert to it whatever is neccesary for the browser to find it. This way a url is totally independent of permalinks and domain names.
Problem solved. Now to implement it.
Interestingly enough, in WP 3.0 running multisite, it puts my images in domain.com/wordpress/files/2010/02/22/file.jpg
Looks like an absolute, right?
Yeah, the files are ACTUALLY in domain.com/wordpress/wp-content/blogs.dir/1/2010/02/22/file.jpg
There’s a rewrite rule in my haccess:
RewriteRule ^(.*/)?files/(.*) wp-includes/ms-files.php?file=$2 [L]
So it’s not quite what thanatica had in mind, but it could probably be taken as a baseline to make a similarish plugin?
Members of this post. I completely agree with the original post person. I actually came to this forum thread to post my own complaint to find ITS ALREADY HERE!
MFields is ask “why wouldn’t the relative link work for you?” That doesn’t make sense to me. Its storing “http://domiain.com/location/of/file/name.ext” in the GUID of the media library. Why would you want that to be static?
Ipstenu, yes WPMU rewrites the location of the file to help keep your actual file location private and secure, but this has nothing to do with the URL its using to link to this file in the HTML Source.
Plain and simple, question “Why in gods name is the source URL of file attachments stored in the GUID?” We already ALSO store this exact same information in the _meta table. For some reason everything else on the site uses %site_url%/%meta_info% to create HTML. Why has this not been implimented on the media library, and better yet, why IF THIS IS STORED in the GUID field, can we not modify this information from the “media library -> edit file” page where we modify everything else… for some reason they have it blocked.
I was forced first to manually change the database from phpmyadmin, then found “search and replace” plugin that fixed a majority of my problems. Thankfully, all my problems as they related to the Media Library.
oh I wanted to write about the cause of the issue that generated my hate for media library static GUID URL.
I am using wordpress MU, and in order to “move” websites that used to be in regular wordpress you must
1. create a subdomain ie. sethcarstens.smwpmu.com
2. you export your wordpress from the original site, in my case sethcarsten.com (pre MU).
3. You import this into the subdomain mu site
4. (unfortunately) you fix about 10 other things that go wrong with the conversion.
5. You point the A Record to the MU host.
6. change the primary URL of domain mapper from sethcarstens.smwpmu.com to sethcarstens.com
7. You change all the settings on the blog to remove sethcarstens.smwpmu.com and replace with sethcarstens.com.
8. You get hundreds of broken images since the GUID stores the old file url (ie sethcarstens.smwpmu.com/files/uploade.ext)
if the “File URL” from the media library was created dymanically, like its supposed to be useing the domain stored in the options tables, everything would be fine. Instead we have static information thats caused me a few hours of headache and worry.
Phew, glad I got that off my chest.
MFields is ask “why wouldn’t the relative link work for you?” That doesn’t make sense to me. Its storing “http://domiain.com/location/of/file/name.ext” in the GUID of the media library. Why would you want that to be static?
Although it may store something like “http://domiain.com/location/of/file/name.ext” in the guid column of the posts table, I have never seen WordPress core actually use this value for anything. All media links that I have ever seen generated use wp_upload_dir() to generate a string to the uploads directory. Then, a path relative to this directory is concatenated.
The value of this relative path is stored in the postmeta table under the meta_key of _wp_attached_file (originally uploaded file) or under _wp_attachment_metadata for intermediate image sizes.
On another note: When you talk about importing and exporting, are you referring to sql or WordPress XML? I have experienced much success using WordPress’ built in importer/exporter. As for links in the post content, you might want to try a plugin such as:
http://wordpress.org/extend/plugins/search-and-replace/
Never used it before but it might help ease the pain of migration.
Having offloaded and then returned my images, that plugin is great for the nonSQL comfortable.
The best ‘fix’ for relative links, since it’s not the media info that does it but the actual post, would be to manually change the URL to relative, and then use the base href tag.
<base href="http://example.com/" />
Another gotcha in this is RSS readers, which run from a different ‘base’ than your posts. There are just SO many possibilities for setups, that absolute paths are the … er point of least resistance? The common denominator.
Maybe try this? http://plugins.trac.wordpress.org/wiki/RelativeLinks
