We have a Tridion use case related to curated content where we are creating multimedia components for images associated with our content which are pointing to External resource types instead of uploaded resource types.
One of the issues we have run into with this use case is that despite explicitly setting the Multimedia Type for the resource, if the URL of the image has either a query string in it: http://cdn.hw.net/UploadService/1c8b7f28-bb12-4e02-b888-388fdff5836e.jpg?w=160&h=120&mode=crop&404=default or uses a ‘friendly url’: http://www.somewhere.com/images/myimage/ when we save the component, Tridion barfs with error messages similar to : ‘Invalid value for property 'Filename'. Unexpected file extension: jpg?w=160&h=120&mode=crop&404=default. Expecting: jpg,jpeg,jpe.’
So far, the only way we’ve been able to figure out to potentially get around this issue is to do something hacky like appending an extra query string parameter to the very end of the urls which end with the expected file extension: http://cdn.hw.net/UploadService/1c8b7f28-bb12-4e02-b888-388fdff5836e.jpg?w=160&h=120&mode=crop&404=default&ext=.jpg Obviously, this is not the best solution and in fact may not work for some images if the site they are being served from strictly validates the requested URL.
Does anyone have any ideas on how we can work around this issue?
Unfortunately I can't really think of an easy solution to this, since Tridion "detects" the Mime type by checking the file extension.
You could perhaps add it while saving and remove it when reading (via Event System)? Definitely a worthwhile enhancement request, to my knowledge this behavior has not been changed for the soon-coming Tridion 2013... See comment below, it has been changed for 2013.
+1 for Nuno's answer. Recognizing that the title of your question is specific to multimedia components, you may want to consider another approach which is to use normal Components, not Multimedia Components. You can create a normal component schema called something like "External Image" that has an External Url field to store your extentionless url.
Content authors will then include these images via regular component linking mechanisms in the Tridion GUI.
You will then need a custom link resolver TBB that will parse the Output item (via Regex) looking for any Tridion anchor tags <a tridion:href="tcm:x-y-z"> and for each one replace them with an <img src=...> tag where the src path would come from this linked component.
For an example of a similar approach, but with videos, and sample code for a custom link resolver TBB have a look at the code in the following post: http://www.tridiondeveloper.com/integration-sdl-tridion-jw-media-player.
Related
I'm trying to register a custom content type, similar to this question on MSDN forums: I want to register a custom extension that is essentially an HTML file, e.g.:
[Export]
[DisplayName("My Custom Markup")]
[Name("mycustom")
[BaseDefinition("html")]
internal static ContentTypeDefinition MyCustomContentType;
[Export]
[FileExtension(".mycustom")]
[ContentType("mycustom")]
internal static FileExtensionToContentTypeDefinition MyCustomFileExtensionDefinition;
So by specifying BaseDefinition as html, I am able to get HTML highlighting in .mycustom files, unfortunately I get nothing else, in particular, the HTML intellisense. From the above link it seems that the only way to have Visual Studio recognize custom extensions as a specific editor type, but I'd have to hack the registry (or more specifically, provide this via the ProvideEditorExtension attribute, but it's only applicable on a VSPackage).
So my question is, basically, is there an alternative way to register a custom extension to an editor programmatically, but without creating a custom VSPackage for it? Other than hacking the registry, of course?
(I could be totally wrong with the approach, in which case your help is very much appreciated!)
The easiest way is to use the technique demoed here:
http://blogs.msdn.com/b/noahric/archive/2010/03/01/new-extension-css-is-less.aspx
This is effectively "hacking the registry" but in a supported way. You're simply wrapping the needed keys in a .pkgdef file (essentially a .reg file) that can be contained in an editor extension.
I need to publish out a large XML file (~8MB = ~28,000 lines) from Tridion (2011 SP1 HR1) on to the web sever(s).
I have done this in the past with similar sized XML documents by uploading the XML file in to a Multimedia Component in Tridion and then having a simple Component Template to render the contents of the file at publish time. However, in the Tridion implementation in which I am working there is already a mechanism for publishing out content to the site using a very simple 'Code' Content (not Multimedia) Component which has a single plain text field for the 'code'.
The problem that I am having is that the browser becomes unresponsive/crashes when I try to paste such a large amount of content in to the 'Code' Component. Does anyone know of a way (either in the browser or in Tridion) to make this possible? I do have the option of adding a Component Template to process this as a Multimedia Component, but I would be reluctant to do this if I could get the existing mechanism working.
I have tried this in IE, Chrome and Firefox. I have also tried uploading this using WebDav without success too. We have already increased the HTTP Upload size on the server to 0.5GB to accommodate large binary files.
Thanks,
Jonathan
The first thing that comes to mind is the WCF size restrictions in the CoreService configuration.
These are set in the Web.Config of the CME, under (by default): C:\Program Files (x86)\Tridion\web\WebUI\WebRoot
In SDL Tridion, Dreamweaver template, I have to set a relative path to my image in Page Template.
Tridion produces output as below when I do have code like this in DWT.
DWT Markup
<img src="##Field##"/>
Template Renders
<img src="image.jpg"/>
However when I add a relative path like this, the template returns tcmid
DWT Markup
<img src="Folder/img/##Field##" type="text/css" rel="stylesheet"/
Template Renders
<img src="tcm:8-674"/>
And this causes images not being presented properly in website. I tried with Tridion type: multimedia etc, but nothing has worked so far.
Has anyone seen a similar issue before?
The behaviour you experience is that Tridion (the Dreamweaver mediator) will interpret your src image attribute as WebDAV path of an item in the Content Manager. So if it finds a Multimedia Component under Folder/img/##Field##, it will replace your path with the TCMURI of that Multimedia Component. That's expected behaviour.
However, I don't think that's what you are trying to do (it's not clear from your question). Is your image in Tridion as a Multimedia Component? Are you trying to show this image? Then you should use Multimedia Links (i.e. links to a Multimedia Component) in your DWT: <img src="##Compoennt.Fields.link_to_mmc##"/>, where field link_to_mmc is a Multimedia Link field defined in your Schema. Use then also the 'Resolve Links' Default TBB to convert the TCMURI into a relative image path.
If you are linking to an external image, then you need to specify the URL of that image in your DWT template. Something like this <img src="##Component.Fields.external_url##"/>, where external_url is a Text field in your Schema and it contains the actual URL of the external image you want to show.
It seems like you are almost there, only when you add the string as a relative path, the default TBBs don't recognize the uri held in the SRC attribute anymore. If you are trying to publish the binary to a different location, you will need to bind it to a different Structure Group, alternatively try changing the multimedia URL on your publication. that way the images will be published (and resolved) to you sub directory.
If your imagefields field is a link to a Multimedia Component, then all you need is <img src="##Field##"/>. With that Tridion will (in this order):
replace the ##Field## with the TCM URI of the image (e.g. tcm:6-874) when it executes the DWT
put the image item into the package as an implicit step after executing the DWT
publish the images (as one of the steps in the Default Finish Actions)
replace the TCM URI (tcm:6-874) with the path of the published image
Since you'll probably have custom TBBs between the DWT and the Default Finish Actions, you could use those to modify the image item and influence what gets published (and where, using item properties).
If you've set up your Tridion installation correctly, you'll typically store the base path to the images in the Publication properties and then step 3 just puts the the image in there and step 4 puts the full path (including what you specified in the Publication properties) into the HTML.
If you want more control over the relative path, the Publish Binaries in Package and Default Finish Actions TBBs have a parameter that allows you to specify to which Structure Group the images will be published. That way you can have different templates output their images to different Structure Groups/directories on disk.
For the ultimate in control you can also decide to publish the binaries yourself. In that case have a look at the source of the Publish Binaries in Package TBB (available from the forum on SDL Tridion World), modify it to suit your needs and replace the one in Default Finish Actions with your modified version.
Is there any way of finding the absolute URL for a published object in the SDL Tridion Interface?
For example when I published a page, how can I find the url where to access the page?
Though not finished, and not really very documented, the Tridion 2011 PowerTools includes 2 buttons to "Open in Staging" and "Open in Live".
If you're looking for the code in your c# tbb library you can use the PublishLocationUrl property for pages and structure groups:
StructureGroup.PublishLocationUrl or
Page.PublishLocationUrl
This will return the URL if the item is published or not, as Page and StructureGroup extend the ReposityObject class, I typically perform a check to see if the ReposityObject is published to the target that the Page is being published to for example:
if (PublishEngine.IsPublished(myReposityObject, myEngine.PublishingContext.PublicationTarget))
{
// page or sg is published!
}
Note: Where the myEngine is an instance of the Engine object.
If you're doing this in the core service, that's a little different, what you need to do is create a PublishLocationInfo object which is casted from your Page or StructureGroup object property LocationInfo, as shown below:
PublishLocationInfo pubInfo = (PublishLocationInfo)page.LocationInfo;
return pubInfo.PublishLocationUrl;
It is not very straightforward, mostly because Tridion allows you to publish a single page to multiple targets (= web sites). The page could in fact have a number of URLs.
However, the best option is to open the page and click on the Info tab. There you will find the File Path, which might look like this: \about\press\2011. Replace the backslashes with slashes, and add the page's filename and file extension (can be found on the General tab). Put the whole thing behind the root URL of your web site (e.g. http://www.mysite.com').
Tridion exposes the path of the URL in PublishLocationUrl property. You can access this either through the TOM.NET API or by viewing the raw XML of the item by entering the TCMURI in the address bar of Internet Explorer (e.g. tcm:4-264-64).
But in either case those will just return the path part of the URL. You'll have to prefix it with the correct base URL as Quirijn already mentioned earlier.
In the past, I have resorted to extending the protocol schemas for publication target destinations. Having added a baseURL property there, I could access this from events system code (the idea was to mail a link to a workflow approver).
These days, you could use application data to do the same thing.
Hey,
Since Google Fonts came out, I have had this question in mind. First see this below:
<link href='http://fonts.googleapis.com/css?family=Cantarell&subset=latin' rel='stylesheet' type='text/css'>
Here Google is linking to an external CSS file that doesn't have a file extension (.css)! Then Google also has another feature that if you want to inlude another font to this then just add the "|" sign and type the font name. How do you do this? Using Javascript, PHP or something?
Help is appreciated!
Thanks :)
The extension of a file does not have to mean anything at all about the contents of said file. It is merely a convention (one that Windows, for instance, uses to the point of making it seem like a requirement).
Any dynamic 'file' on a web site can return what ever kind of content it wants, any time it wants. The extension means nothing - aside from expected convention.
That URL could be a directory named css with a default 'document' that is a script, which handles the parameters to decide what content to give. Or, it could be a literal file named css which does the same thing. Or, it could not be a file or folder at all, instead merely part of a routing mechanism, which calls a controller based on the URL, and passes the parameters in.
Web servers return information in the response indicating what the MIME Type of the return value is, and the browser determines what to do with it based on that - not based on the extension of the file.
Yes, they have to be doing some sort of server-side processing when this URL is requested
http://fonts.googleapis.com/css
The querystring is parsed, and a text stream is returned with the CSS output. Allowing the user to add additional font families to the CSS is pretty trivial, as the server is just spitting back what you append to the query string.
You could do this in PHP or ASP.Net (and many others), but there is no indication of the underlying technology from Google's URL.
The easiest way to do this yourself would be to create a folder on your web server called "css", and then have a default script in there that does the processing. The URL could basically be almost identical to the Google url.