To avoid strongly connecting multimedia metadata I've seen "image metadata" components that have fields such:
image (multimedia component link)
alt text
title
width
height
This allows us to separate context-specific information. For example a banner component could serve this role and might link to a multimedia image. Since alt text also depends on context, it doesn't make sense to set these fields in the multimedia metadata. We can also localize text for media separate from the multimedia.
In SDL Tridion 2011 I have advanced image options for richtext fields. When adding an image, I can set:
(alt) text
alignment
width
height
proportion
This affect the attributes in the source. For example:
<img src="tcm:5-274" title="buddy" alt="buddy" style="vertical-align: top; width: 70px; height: 70px;"/>
When were these in-RTF options introduced and are they configurable?
I think the reason of having separate metadata components is because not all the scenarios of use of an image happen in an RTF, where you can add the additional attributes for the specific rtf you are editing.
In some scenarios you want to use an image but with different metadata depending on where is used.
Scenario A:
The Metadata of the image strongly depends on the final content which is consuming the image and will be used only in that context, you can do an embedded schema that is constructed by a multimedia link + the metadata fields.
In the content that will consume the image, add that metadata schema as a field
Scenario B:
The Metadata of the image doesn't depends on the final content which is consuming the image and there are some variations of different metadata, same image.
In this case should be a regular schema for store metadata with a binary link pointing to the binary.
This schema can be referenced as component link by other schemas.
Scenario C:
The Metadata of the image will be the same always regardless of where is consumed.
In this case you add the metadata in the metadata of the Multimedia Schema.
You can extend the UI for apply those values automatically to the RTF when the user chooses that image, but still give them the flexibility of change those
I can't tell you exactly which version they were introduced, but they are not recent. I have seen them in Tridion 2009, 5.3 and even 5.2 IIRC.
If by configurable you mean to change (add/remove) these attributes -- no, they cannot be configured.
Related
I have a Plone 4 site where I currently use the following method to embed objects (e.g. images, videos, tables …) in user-editable HTML content:
I have a custom transform browser which takes HTML text and transforms all a and img elements which refer to an element by UID (i.e., which have an href="…/resolveuid/abc123…" or src="…/resolveuid/abc123…").
My view templates read the text field and let that browser transform it;
the browser has a Python dict TYPE2TEMPLATE which has portal_type keys and template_id values;
for each a or img which refers to an object by UID,
the object is fetched by o = brain._unrestrictedGetObject()
the template id t_id is taken from the TYPE2TEMPLATE dict
the "embed" method is fetched by method = o.unrestrictedTraverse(t_id)
that method is called (in some cases with some keyword arguments), and the result - which is contained in one top HTML element - replaces the "raw" a or img element.
Now that I'm developing an additional customization package (which contains new object types, now using Dexterity), I wonder whether there is some more "plonish" way. Is there, for example, some embed action?
i don't know of a package that does the same and what you're doing sounds sane to me ;-)
i just would use https://pypi.python.org/pypi/plone.outputfilters instead of your transform BrowserView.
if it's possible to explicitly mark links that should not be auto-embedded (eg via span.noEmbed a.internal-link selector) this could become a useful addon.
i guess for portal_type=='File' you'll need to check the mimetype too in order to decide if you're embedding a video file or something else...
other products i know of embed content outside of your plone site (eg. collective.embedly)
another approach would be a to use a tinymce plugin to genereate the proper embed html when editing the html-body of your page (i personally would not go this route because there are different tiny versions to support for 4.3 and 5.0 and we're not sure if tiny woun't be replaced as default editor in the future)
icon_expr is gone.
There is an related issue https://github.com/plone/Products.CMFPlone/issues/1236
concerning the problem but only for control-panel icons.
What is the appropriate way to add a icon to a dexterity content type in plone 5?
Any pointer welcome
Volker
Unluckily the Plone 5 way is only through CSS (with a background image for example) and register it in the new resource registry.
One way I tested is to re-use Fontello, like Barceloneta is doing but is not really simple because you must manually modify the generated CSS to prevent you new CSS to destroy other global rules.
An example is here: https://github.com/RedTurtle/TurtledGazette/tree/master/Products/PloneGazette/browser/static (it's not even Dexterity or Archetypes, but this is not important).
Note. I don't really understand this run to CSS and iconfont. It's a kind of over-optimization:
old school images can still be cached
background images are not really accessible as real images provided also an "alt" for blind people, that warn about the content type.
I don't like current situation too much... it's OK while you are developing a theme but is a nightmare for add-ons developers.
Beneath the update of an actual fontello font, you can limit yourself to enhance the icon configuration.
From the Products.CMFPlone package you can get the current icon font config file "config.json"
/Products/CMFPlone/static/fonts/config.json
To review the content of the file visually, go to the fontello.com website and visit the menu under the "wrench" icon.
Reset all icon selections and settings you may have done before.
Unselect glyphs
Reset all changes
Use Import to load the config.json file from CMFPlone.
Review the icons, names, codes and shapes
Look at the source code of config.json and locate icons not referencing a font but containing plain svg path information.
You will figure out that even glyphs can contain multiple path elements and holes as well.
Try to overload just the config.json file in your package by appending your custom icon as plain svg in the json and choose a non conflicting unicode char code. I am still working on documenting this in detail.
Source: I found a hint to this by Victor Fernandez de Alba mentioning this method in his talk [2] (see transscript [1]) during Plone Conf Bucharest:
http://maurits.vanrees.org/weblog/archive/2015/10/victor-fernandez-de-alba-plone-5-theming
http://www.slideshare.net/sneridagh/plone-5-theming-53980481 Slide 12
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.
I have a Dynamic Component Template which publishes XML to the Broker database which is then dynamically loaded using the Component Presentation factory.
This Xml contains URLs to Images. I need a thumbnail and a full image to be available. I have managed to use the Image Resizer TBB to produce the thumbnails however, I was hoping that this would add separate package items and binaries that could be referenced, but it seems to overwrite the full size images.
Is there a way I can get both into my Xml and the Package without writing my own custom TBB?
Tridion Content Delivery can store multiple variants of the same Multimedia Component. Each such variant has an ID that identifies it and the variant with no ID (of in newer versions #def# as its ID) is known as the default variant.
When you reference an image from a DWT, it is automatically added as an item to package when the render engine executes your DWT. This item is then later processed by the default "Publish Binaries in Package" TBB that is part of the Default Finish Actions. The Publish Binaries in Package TBB publishes binaries by calling AddBinary on them - you can verify this by looking at the original code for most default TBBs that was published on the Tridion forum here (login required).
appliedTemplateUri = new TcmUri(item.Properties[Item.ItemPropertyTemplateUri]);
...
engine.AddBinary(itemUri, appliedTemplateUri, targetStructureGroup,
data, fileName);
The AddBinary method that is called is defined in the TOM.NET CHM as:
public abstract string AddBinary(
TcmUri componentUri,
TcmUri templateUri,
TcmUri targetLocation,
byte[] data,
string fileName
)
componentUri
The multimedia component this item refers to
templateUri
The template in whose context this AddBinary call is executed (used as variant id)
targetLocation
The location to publish the binary to (if null, publish to standard path)
data
The binary data to publish
fileName
The filename to publish the file under
So as you can see in that last call to AddBinary, the Publish Binaries in Package TBB uses a property (look here if you've never heard of Item.Properties) to determine which variant to publish (and publishes the binary as the default variant if the property is not present).
With all this knowledge in hand, the task becomes quite simple: you have to ensure that there are two binary Items in the package for your MMC, each with a different value of the Item.ItemPropertyTemplateUri property.
The default Image Resizer TBB replaces the binary content of the Item it resizes and does not set this property. So the least code you'll have to write is either a pre-processor TBB that duplicates the item or a post-processor TBB that re-adds the item. In both cases the TBB will have to set the "magic" property too.
Useful links:
the original C# source code of the default template building blocks
a page describing Item.Properties and how to see what they do in your compound template
a recent post on the SDL Tridion forum about the same topic (login required)
Basically all the Image Resizer TBB does is resize the image already in package, so the Default Finish Actions TBBcan publish it (using an AddBinary() call).
So what you require is a slight change in the logic of the Resizer TBB (you need to do something yourself here), so that it does not resize the original item in the package, but publishes a variant of it. Then you have two images available on the delivery side (you can distinguish them by sending the resized image to a different structure group for instance).
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.