You can get version history on the following items:
Template Building Block
Organizational items don't have a versioned history. To keep a history on this type of information, consider placing it in a "configuration" component or using the Event System to record the details in Application Data or a non-...
@Kris, I am assuming you have custom meta value as a comma separated string. You can use SQL like pattern %% to match the value. So your custom meta value criteria should be like:
CustomMetaValueCriteria customMetaValueCriteria = new CustomMetaValueCriteria(metaField, "%keywordValue%", Criteria.Like);
You can fit this code in your application code.
It looks like the content you are migrating is not in sync with the Schema it is based on. I would do a where used in the Schema the component is based on and check-out/check-in all the components to sync them up with the latest version of the schema. If you have event system or workflow, I recommend you disable them before going through this process.
There is a purpose property in SchemaData class, to define purpose(type) of schema.
By default it's set to the value SchemaPurpose.Component. That's why, if you are creating with the root element 'Metadata' its throwing the error.
try like this:
SchemaData scm = new SchemaData();
scm.Purpose = SchemaPurpose.Metadata;
On Tridion 2009 you should use the TOM Interop APIs (COM) which are provided under Tridion\bin\Client\PIA. You'll need to use the Tridion.Interop.TDS.dll and Tridion.Interop.TDSDefines.dll.
Create a new Tridion session with code like this:
TDSE tdse = new TDSE();
If the current Windows user is a valid Tridion user, then it will just work. If it's not it's ...
Dd4t has some functionality in the tbbs to merge page metadata with metadata from parent items (structuregroups).
In the templates, you can add a tbb called ad inherited metadata to page, and set a parameter called mergeaction.
If you want to see what it does, you can see the code here
Without running the code, I think the problem is your initial for loop. If you look at the XML source of a Component with categories in the metadata (one of ours for example) :
<region>United Arab Emirates (Middle East)</region>
This is a bug with DXA 2.0 release - see https://github.com/sdl/dxa-content-management/issues/14. The issue has been closed, as there has been a fix made, but this is post 2.0. You will either have to upgrade your TBBs to DXA 2.1, or bake your own TBBs containing the (simple) code fix: https://github.com/sdl/dxa-content-management/pull/15
We found an answer, but it's very much a workaround.
We determined that all of the field values are saved when you select a value from a single value metadata field that is linked to a category with multiple keywords. We tried multiple iterations of this, just to confirm that this condition made it publish and that not doing this condition made it not ...
Looks like the Metadata of "OriginalComponentData" is invalid. It's likely that someone changed the Schema after it was created. The Components do not automatically get updated when a Schema is changed (hence the giant warning about editing existing Schemas :)).
So it is possible for a Component to return invalid content or metadata, which would mean that ...
Inline editing of (pure) Page Metadata is not a feature that is available in XPM at this time, so you have two options:
Use the Metadata in the properties and edit it there (not inline)
Make the Metadata of the Page a Component link, and store all its Metadata in a Component
When using option #2, you can write out the Metadata on the Page using @@...
You need to properly configure the cd_storage_conf.xml configuration file of the deployer web application (assuming you use the web application deployer and not the windows service).
This file is normally located in the bin/config folder of your web application. Could you post the contents of this file (leave out the comments and change the username/...
Since you are on version 2009 your options are a bit limited, you would either use the Business Connector (SOAP) API, or the TOM API directly on the server.
For the TOM API you could write a ASP Page, or you can do an ASPX Page (with C#), but then you have to use the TOM Interop, and run it from the Custom Pages. I don't think I have any direct examples of ...
Basically main difference is that Simple schema is to define the properties of component where as metadata schema is also similar to simple schema but if you use metadata schema then this kind of component is get stored in broker so that you can use these component for querying the data from broker that why we are using this schema with publication , folder ,...
It seems that the reason you want a WebDAV URL on the delivery side is so you can query for this component without having to hardcode the Tcm Id into your CD code. However as user978511 pointed out you'll run into issues.
The typical way to handle the scenario you describe is to keep the environment-specific attributes in a config file, just like db ...
In 2013 in your deployer extension you could get this with the following syntax:
String renderAddedMeta = page.getRenderAddedMetaData();
This example is for a PageDeploy. You have access to the page object in the processPage method. Similarly you can do the same for component presentations.
I am unable to verify at the moment, but Web8 must have ...
The pageModel.meta is defined for the HTML meta tags, it is actually not supposed to map to the CMS Page metadata.
For mapping CMS Page metadata, you should extend the default Page Model and add these fields yourself, just like you do in Entity Models.
Not sure if you’re talking about .NET or Java, but ComponentMetaFactory still exists. See, for example, its usage in DXA 1.8: https://github.com/sdl/dxa-web-application-dotnet/blob/release/1.8/Sdl.Web.Tridion/Statics/BinaryFileManager.cs
Your approach is not entirely correct. It's true that you will not get the proper WebDAV url until component is saved, but you also can't be sure that url you have in metadata is correct at the time of publishing, let's say component is moved, in this scenario it will not be updated.
Better approach will be to do something during publishing.
Raj's answer will work if you have a single keywords text field in your Page Metadata, if you want that to be a multi value text field (each having a single keyword), you can use something like this in your DWT Template Building Block:
<meta name="keywords" content="<!-- TemplateBeginRepeat name="Page.Metadata.keyword" --><!-- TemplateBeginIf ...
You have to read this metadata in your Page template's DWT and generate Meta tag on fly.
<!-- TemplateBeginIf name="Page.Metadata.keywords" -->
<meta name=“keywords” content=“@@Field@@”>
<!-- TemplateEndIf -->
Have you changed the original component's schema's fieldname at some point after it was created?
Components are not updated field name changes, mandatory data etc. when you change their schema. The CME does this for you when you open the component (you should see an information message stating this) but you must also then save it again to save the changes.
You may also want to consider modifying the publish path using a Custom Renderer.
A Custom Renderer can be used to manipulate the output produced by the template process.
More information can be found in the online doc's here:
So now you got the metadata xml of the component, the Tridion core service role is over; it's all about compiling the xml and get the desired things out of it using .net.
So assuming you want to get the values of metadata fields, you can follow the below example code, I haven't run it though so you may need some adjustments as well.
doc = XDocument.Parse(...
The correct course of action, of course, will be to first install SP1 HR1 so environments are consistent - this will likely be the instructions from Support without having to add further hotfixes to complicate the setup (remembering that hotfixes are not supported in the context of being used with other hotfixes etc. but are provided on an 'as is' basis.
Images do not have a URL until they are published, as mentioned by @Nuno.
In your code you'll need to publish the binaries to get a URL you can use either the AddBinary or the PublishBinary method to publish binaries. I'd recommend AddBinary, as shown below:
ItemFields metadataFields = new ItemFields(objSG.Metadata, objSG.MetadataSchema);
My suggestion would be do to this change during publish at templating level before the package is created from publisher. Depending upon the publish target, you can take action on the page object as needed. The advantage of doing this at the templating level are a couple:
You can reuse the same template if you need for any other publishing target by adding ...
The problem was that the component hadn't been saved back after schema changes, as the pre-populated default values in the data were not saved back prior to publishing. Hence, publishing out the component only published out the old version of the component.
You can create (and register) a custom Page Model class and use semantic mapping to map the metadata fields to properties of the View Model.
For semantic mapping to work, the metadata fields must be defined in the (semantic) Schema of the Page. So, you may have to add those fields to your Page’s Metadata Schema.