When an editor uploads a new version of a PDF-document (or any media) I instruct him/her them to manually edit the links on each page that has a link to the particular media. It's a bit cumbersome (and not that impressive).
if you enter your mediaitem links using the media picker in the content editor, don't the links get updated automatically like they are for content pages?
where are the links? in content area of a richtext editor, seperate page properties, in page templates or other ?
Thanks for your input, made me think a bit on what I recommend for PDF-links in the first place. For links to PDF documents in media within a Rich text editor the url's need manual edits. But for Xslt-produced links they are updated as they should thanks to the node id (if the new PDF is uploaded to the existing node in media tree). I will talk with the editors about using a related links (xslt-powered) box instead of using the Rich text editor links.
If all media links in RTE should be changed automatically after media change, I guess there could be problems both with SEO and keeping a consistent document review-publish routine. ?
I wasn't even aware of this issue, this is a serious shortcoming of umbraco from my point of view.
If you upload a document to the media section, and want to change it to a new version with even a slightly different name, you have to update the link to the document in every page (richtext editor) where you link to it?
surely this can't be intentional? I might as wel dump all media files in a folder on filesystem then ?
Also, the old document stays present and working, instead of being overwritten. So all links throughout the website that link to this mediaitem remain linked to the old version of the document, and the new one only appears there where you manually insert it ?
A simple test (umbraco 4.0.2) shows that the link is not changed automatically. A changed image will change after a document open-publish tho.
Steps:
On one document with a rich text editor, I add a image "family-picture.jpg" (node 1010) from the media section plus a link to the same file.
I publish and check its ok.
Then I go to media section and open node 1010. Choose to upload "family-picture-new.jpg" and save the media node.
The published page stays the same with both old image and old link. A right-click publish changes nothing either.
But if I open the content page the RTE shows family-picture-new.jpg, and do a publish there - it makes the changed image appear ("family-picture-new.jpg") on the site. However the link stays unchanged ("family-picture.jpg").
Yes, it would be conveniant if Umbraco could help out more here.
Any more thoughts on this. We have a PDF of prices thoughout our site that needs to update when the Media Item (PDF) updates. Its hard to remeber all the pages to update. We could use a Macro but thats a bit hard when the link needs to be in the middle of a text block.
I'm using 4.7.2 and have the same issue.. I was floored when I discovered this issue..
one guy in the office said to just instruct the users to keep the same file name of the uploaded files, and technically that works, but it's really not ideal..
Dennis, I'm with you.. Why wasn't it implemented in a similar way to the way that internal site page links are using "{locallink}"...
I'm very disappointed that Umbraco has, what I'd call, such a big flaw...
We've just had a discussion in the office and decided to do away with using the media in our case.
We're still fleshing this out, but here's what we're going to do; create 2 new doc types: 1) DocumentFolder 2) DocumentItem
DocumentFolder will hold only DocumentItems.
DocumentItems will have an "upload" property and whenever our users want to link to a document from a content page, they link to the relevant DocumentItem node in the content tree, effectively the same way that you would with a media item.
The template for the DocumentItem will have a .net usercontrol on it to pump out the linked file to the resonse stream... then it will either display in the browser or be downloaded.
If anyone has any good reason not to do it this way, let me know..
The issues here is, that while it's entirely possible to implement af {localmedia} solution in tinyMce, it would be an absolute performance hog. To transform {locallink} values to real links Umbraco has to parse the tinymce content and replace the {locallink} with the corresponding link for the content item based on the provided local link id.
Now, as far as I know, this parsing is quite fast since Umbraco can use the XML cache to do lookups. However, that is not the case with media. Media aren't stored in the XML cache, thus, media items will by default be loaded from the database. This means, that for every time the Umbraco parser would hit a {localmedia} link it would have to do a database lookup to get the media item and from there get the correct file path. Imagine a page with just 10 {localmedia} links. It would be a huge performance hit.
So, what to do? For {localmedia} to work, we need a way to get access to media items as fast as regular content items. There are a few ways to do this, but with the current backend architecture of Umbraco, none of them are super-easy.
At the company I work for, we base most of our new Umbraco projects on a custom lucene implementation, where we store both content- and media items. This means, that we have ultra fast access to media items. So a few weeks ago, with the database bottleneck out of the way, I implemented a solution that inserts {localmedia} links in tinyMce and parse them on page rendering.
It's a tiny bit complex, and I will post something about it as soon as I get around to it, but the important thing to note is, that for {localmedia} to work, we need fast access to media items. Examine would be really suited here or perhaps the Digibiz Advanced Media Picker which will (I think) let media items be a part of the XML cache.
Thoughts.. if you think 10 IO actions on the database is excessive then try actually turning off the xml caching and running the entire front end with database lookups, which we have to do as our clustered host infrastructure doesn't allow for the distributed calling mechanism.. actually the site runs fine and we've had very few complaints on speed issues from our 130+ umbraco sites ;-)
For this specifc instance, you don't have to do a single IO for each medialink, you could do single IO to fetch all media links in one go?
I guess the root of the problem is that a locallink doesn't need to be intelligent at all in tinymce, as there is no visual cue... with media you wouldn't just want to insert a medialink and not see the visual representation of that media.
on a tangent... perhaps a different approach to media items would be to drop the filename? eg /media/1234/1234.jpg would suffice so that chaging any media asset wouldn't change the url to the media item? May be issues with the file extension.. If you are doing your bit with accessibility and alt tags that should cover the seo implications.. and you have the media name in the admin to sort HCI?
Rather than databse lookups could we use urlrewrites on intelligently constructed media urls?
Yet, you do get complains? :P I really can't comment on the performance on your sites and your setup, but I certainly wouldn't like my entire site running off the db. But if it works for you, that is just great, but though slightly besides the point :)
AFAIK, the media api only allows one way to retrieve a media item from an id. You could of course ditch the official api and make your own sql query, but imho that is not the way to go.
You talk about a visual clue, which leads me to think, that I might have caused some confusion in my last post. What I implemented was the use of {localmedia} only when inserting a link to a media item from the regular link function. Inserting images is a similar issue, but the solution is more complex here I reckon, since, as you said yourself, we would like a visual presentation of the media, not just a {localmedia} text.
The thought of dropping names for media items and just use their id's is good, but I'm guessing that when a user downloads a file/image, the user (and the client for that matter) would most likely want the file/image to be named correctly. Also, there might still be an issue with the folder naming. I'm not sure how it works internally, but I'm pretty sure, that Umbraco has a habit of sometimes changing the folder names when updating a media item with a new file/image.
I'm not sure how you would solve this issue by using url rewrites, but the thought is interesting.
In the end, however one decides to fix the media limitation at this point, fixing the problem in the core would of course be preferable. I think it would require a lot of core rewriting though.. I know it's in the planning, but it's probably some time away still.
The speed complaints are down to the actually hosting infrastrucutre speeds.. and actually our previous cms was a asp.net to mssql with all aspects run with databse IO and that perfomed much better (speed wise) than the umbraco cms that we've embraced. But obv the power of umbraco outweighs the slight performance hit.
I think the discussion around chached xml interogation vs constant db access, isn't as cut and dried as db io is bad in memory xslt is good
Maybe becasue out cms was a tailored solution using stored proceedures in sql and hence can take advantage of cached proceedure plans etc... whereas the on the fly creation of queries in umbraco to allow multiple db support simply doesn't levearage all the power of the database...
One of the biggest slow downs we see is trying to sort data on the fly on xslt scenarios...Muenchian grouping technique to allow a designer to sort content via xslt comapared against sorting the actuall dataset in the query on the db, just isn't comparable!
But that's a little off topic ;-)
With regards urlrewriting for media items... you could change the insert media item in the tinymce to be say /media/1234... and then url rewite /media/{digit} to /media/getMedia.aspx?id=digit and that could then lookup and return your image... not necisarly hitting the DB.. as it could simply interogate the filesystem to give the image that is in the corresponding media folder. (I know that you can end up with multiple images in media folders... but that's just something to work around;-)
Another approach we considered with existing functionality, was to have a macro that you passed a media id to...that you could use in the tinymce editor, but that has the issues with rendering macros in the editor being at best flakey and worst "aw snap" in chrome!
You can't really turn to the filesystem for help here, as Umbraco won't necessarily name the folder the same as the media item id. I guess it would make a lot a sense if the naming was consistent with the id's, alas it is not.
Im pretty sure, that the short term solution for vanilla Umbraco will be to use either Examine or the xml cache.
This might be a old thread but it's still up to date. I had the problem with a client with a download center kind of page. They had to update pdfs and files every months without loosing the links.
So I have created a custom application for them that I just shared for anyone with the same kind of problem.
It's an Umbraco application that helps you update multiple media items in a simple way.
Keeping media links intact with a new file
When an editor uploads a new version of a PDF-document (or any media) I instruct him/her them to manually edit the links on each page that has a link to the particular media. It's a bit cumbersome (and not that impressive).
Does anyone have a better solution? I just found Media Link Checker by theFarm http://our.umbraco.org/projects/backoffice-extensions/thefarm-media-link-checker which seems like a good help, but still it requires a bit of manual work.
Regards
Jonas Eriksson
if you enter your mediaitem links using the media picker in the content editor, don't the links get updated automatically like they are for content pages?
where are the links? in content area of a richtext editor, seperate page properties, in page templates or other ?
Hi Rik,
Thanks for your input, made me think a bit on what I recommend for PDF-links in the first place. For links to PDF documents in media within a Rich text editor the url's need manual edits. But for Xslt-produced links they are updated as they should thanks to the node id (if the new PDF is uploaded to the existing node in media tree). I will talk with the editors about using a related links (xslt-powered) box instead of using the Rich text editor links.
If all media links in RTE should be changed automatically after media change, I guess there could be problems both with SEO and keeping a consistent document review-publish routine. ?
Regards
I wasn't even aware of this issue, this is a serious shortcoming of umbraco from my point of view.
If you upload a document to the media section, and want to change it to a new version with even a slightly different name, you have to update the link to the document in every page (richtext editor) where you link to it?
surely this can't be intentional? I might as wel dump all media files in a folder on filesystem then ?
Also, the old document stays present and working, instead of being overwritten. So all links throughout the website that link to this mediaitem remain linked to the old version of the document, and the new one only appears there where you manually insert it ?
A simple test (umbraco 4.0.2) shows that the link is not changed automatically. A changed image will change after a document open-publish tho.
Steps:
On one document with a rich text editor, I add a image "family-picture.jpg" (node 1010) from the media section plus a link to the same file.
I publish and check its ok.
Then I go to media section and open node 1010. Choose to upload "family-picture-new.jpg" and save the media node.
The published page stays the same with both old image and old link. A right-click publish changes nothing either.
But if I open the content page the RTE shows family-picture-new.jpg, and do a publish there - it makes the changed image appear ("family-picture-new.jpg") on the site. However the link stays unchanged ("family-picture.jpg").
Yes, it would be conveniant if Umbraco could help out more here.
Regards
Jonas
I tested this on 4.5.2 and encountered the same issue
Any more thoughts on this. We have a PDF of prices thoughout our site that needs to update when the Media Item (PDF) updates. Its hard to remeber all the pages to update. We could use a Macro but thats a bit hard when the link needs to be in the middle of a text block.
Is there a reason links to media isn't implemented as {locallink} the same way as content-links?
I'm using 4.7.2 and have the same issue.. I was floored when I discovered this issue..
one guy in the office said to just instruct the users to keep the same file name of the uploaded files, and technically that works, but it's really not ideal..
Dennis, I'm with you.. Why wasn't it implemented in a similar way to the way that internal site page links are using "{locallink}"...
I'm very disappointed that Umbraco has, what I'd call, such a big flaw...
http://umbraco.codeplex.com/workitem/29071
We've just had a discussion in the office and decided to do away with using the media in our case.
We're still fleshing this out, but here's what we're going to do; create 2 new doc types:
1) DocumentFolder
2) DocumentItem
DocumentFolder will hold only DocumentItems.
DocumentItems will have an "upload" property and whenever our users want to link to a document from a content page, they link to the relevant DocumentItem node in the content tree, effectively the same way that you would with a media item.
The template for the DocumentItem will have a .net usercontrol on it to pump out the linked file to the resonse stream... then it will either display in the browser or be downloaded.
If anyone has any good reason not to do it this way, let me know..
Thanks
The issues here is, that while it's entirely possible to implement af {localmedia} solution in tinyMce, it would be an absolute performance hog. To transform {locallink} values to real links Umbraco has to parse the tinymce content and replace the {locallink} with the corresponding link for the content item based on the provided local link id.
Now, as far as I know, this parsing is quite fast since Umbraco can use the XML cache to do lookups. However, that is not the case with media. Media aren't stored in the XML cache, thus, media items will by default be loaded from the database. This means, that for every time the Umbraco parser would hit a {localmedia} link it would have to do a database lookup to get the media item and from there get the correct file path. Imagine a page with just 10 {localmedia} links. It would be a huge performance hit.
So, what to do? For {localmedia} to work, we need a way to get access to media items as fast as regular content items. There are a few ways to do this, but with the current backend architecture of Umbraco, none of them are super-easy.
At the company I work for, we base most of our new Umbraco projects on a custom lucene implementation, where we store both content- and media items. This means, that we have ultra fast access to media items. So a few weeks ago, with the database bottleneck out of the way, I implemented a solution that inserts {localmedia} links in tinyMce and parse them on page rendering.
It's a tiny bit complex, and I will post something about it as soon as I get around to it, but the important thing to note is, that for {localmedia} to work, we need fast access to media items. Examine would be really suited here or perhaps the Digibiz Advanced Media Picker which will (I think) let media items be a part of the XML cache.
More to come ... :)
Thoughts.. if you think 10 IO actions on the database is excessive then try actually turning off the xml caching and running the entire front end with database lookups, which we have to do as our clustered host infrastructure doesn't allow for the distributed calling mechanism.. actually the site runs fine and we've had very few complaints on speed issues from our 130+ umbraco sites ;-)
For this specifc instance, you don't have to do a single IO for each medialink, you could do single IO to fetch all media links in one go?
I guess the root of the problem is that a locallink doesn't need to be intelligent at all in tinymce, as there is no visual cue... with media you wouldn't just want to insert a medialink and not see the visual representation of that media.
on a tangent... perhaps a different approach to media items would be to drop the filename? eg /media/1234/1234.jpg would suffice so that chaging any media asset wouldn't change the url to the media item? May be issues with the file extension.. If you are doing your bit with accessibility and alt tags that should cover the seo implications.. and you have the media name in the admin to sort HCI?
Rather than databse lookups could we use urlrewrites on intelligently constructed media urls?
Just a few ruminations.... ;-)
Yet, you do get complains? :P I really can't comment on the performance on your sites and your setup, but I certainly wouldn't like my entire site running off the db. But if it works for you, that is just great, but though slightly besides the point :)
AFAIK, the media api only allows one way to retrieve a media item from an id. You could of course ditch the official api and make your own sql query, but imho that is not the way to go.
You talk about a visual clue, which leads me to think, that I might have caused some confusion in my last post. What I implemented was the use of {localmedia} only when inserting a link to a media item from the regular link function. Inserting images is a similar issue, but the solution is more complex here I reckon, since, as you said yourself, we would like a visual presentation of the media, not just a {localmedia} text.
The thought of dropping names for media items and just use their id's is good, but I'm guessing that when a user downloads a file/image, the user (and the client for that matter) would most likely want the file/image to be named correctly. Also, there might still be an issue with the folder naming. I'm not sure how it works internally, but I'm pretty sure, that Umbraco has a habit of sometimes changing the folder names when updating a media item with a new file/image.
I'm not sure how you would solve this issue by using url rewrites, but the thought is interesting.
In the end, however one decides to fix the media limitation at this point, fixing the problem in the core would of course be preferable. I think it would require a lot of core rewriting though.. I know it's in the planning, but it's probably some time away still.
The speed complaints are down to the actually hosting infrastrucutre speeds.. and actually our previous cms was a asp.net to mssql with all aspects run with databse IO and that perfomed much better (speed wise) than the umbraco cms that we've embraced. But obv the power of umbraco outweighs the slight performance hit.
I think the discussion around chached xml interogation vs constant db access, isn't as cut and dried as db io is bad in memory xslt is good
Maybe becasue out cms was a tailored solution using stored proceedures in sql and hence can take advantage of cached proceedure plans etc... whereas the on the fly creation of queries in umbraco to allow multiple db support simply doesn't levearage all the power of the database...
One of the biggest slow downs we see is trying to sort data on the fly on xslt scenarios...Muenchian grouping technique to allow a designer to sort content via xslt comapared against sorting the actuall dataset in the query on the db, just isn't comparable!
But that's a little off topic ;-)
With regards urlrewriting for media items... you could change the insert media item in the tinymce to be say /media/1234... and then url rewite /media/{digit} to /media/getMedia.aspx?id=digit and that could then lookup and return your image... not necisarly hitting the DB.. as it could simply interogate the filesystem to give the image that is in the corresponding media folder. (I know that you can end up with multiple images in media folders... but that's just something to work around;-)
Another approach we considered with existing functionality, was to have a macro that you passed a media id to...that you could use in the tinymce editor, but that has the issues with rendering macros in the editor being at best flakey and worst "aw snap" in chrome!
You can't really turn to the filesystem for help here, as Umbraco won't necessarily name the folder the same as the media item id. I guess it would make a lot a sense if the naming was consistent with the id's, alas it is not.
Im pretty sure, that the short term solution for vanilla Umbraco will be to use either Examine or the xml cache.
ok, but food for thought examine/lucerne isn't supported in medium trust... there's some work going on to correct this in 4.8 I think ;-)
Ok, just did a code write-up on the way I approached {localmedia} here, hope it helps :)
Hello,
This might be a old thread but it's still up to date. I had the problem with a client with a download center kind of page. They had to update pdfs and files every months without loosing the links. So I have created a custom application for them that I just shared for anyone with the same kind of problem. It's an Umbraco application that helps you update multiple media items in a simple way.
You can check it here and let me know your feedback : https://our.umbraco.org/projects/backoffice-extensions/media-editor/
Cheers,
MrFlo
is working on a reply...