I - like most other Tridion implementers, I'm sure - have also been confronted with this very important decision, and my conclusion has always been that
It doesn't matter as long as it is consistent
Often the challenges I've seen are more around semantics than actual grammar - making sure your "displayHeadline" field is always called "displayHeadline" on ...
This is happening because you have 2 embedded schemas in the same schema, and did not change the Root Element name for either.
More detail on this is available on this answer.
The short story is that you can fix this by changing the Root Element Name of your embeddable schemas to something else than "Content". You may have to change the schema type to ...
To hide schema from specific users or groups, place them in a folder and apply security which reduces the read permissions to specific groups. When the drop down is generated in the create component view, only schema to which the user has read permissions will be displayed.
I typically have a few folders for schema (e.g. System Schema, Content Schema and ...
It appears that having a keyword field in the metadata of a component causes this problem after HR1.
Hotfix CME_2013.1.1.88649 available https://www.sdltridionworld.com/downloads/hotfixes/SDL_Tridion_2013_SP1_HR1/index.aspx fixes the issue.
If you set a linked schema on folder and call GetDefaultData from Coreservice it will return a new component with the schema set and appropriate component type set multimedia or normal. Mandatory has no effect on returned default data. However, it has impact on saving the component as described below.
From API docs
If the linked Schema is not ...
I think it's something you agree as a team. At Building Blocks we tend to use underscored names for XML names e.g some_field.
I don't think there's a "right" way of naming, as long as it's consistent throughout the implementation (and valid XML!)
In your screenshot, notice how the "Content" attribute is null. For each component, you need to call:
ComponentData component = (ComponentData)coreServiceClient.Read(
componentTcmId, new ReadOptions());
Now you can parse the component.Content to read the field values.
By the way, if you happen to have metadata fields as ...
The first thing that strikes me about your question is that there is already a tool to do most if not all of those things - The Content Manager Explorer! "Don't re-invent the wheel!" (just playing Devil's advocate here).
The API you will most likely want to use is the Core Service. This is a WCF web service that you can use to communicate with Tridion. The ...
In SDL Tridion 2013 (SP1), the same error persists when you try to send the same structured content via the Translation Plugin.
To fix (in Translation Manager) we used the hotfix TT87682 part of the TM package here.
We successfully content port our content, with this same scenario - our versions are: from SDL Tridion SP1 HR1 to SDL Tridion SP1 using ...
The nearest to an out of the box solution you have available is described by Alvin in the comments - and as Alvin indicates - it's not a good solution.
You could interact with the Event System and stop saving on non-permitted schemas. There are a few implementation patterns you could consider such as:
folder metadata with, say, a category of 'locked ...
var list = ClientAdmin.GetList("tcm:1-1-8", new UsingItemsFilterData());
var listXml = ClientAdmin.GetListXml("tcm:1-1-8", new UsingItemsFilterData());
I agreed completely with Nuno's answer above, but wanted to add my two cents.
The rule of:
It doesn't matter as long as it is consistent
Is really important to me as I use it when writing my templates. I'm able to know the naming rules of the schema field so that I can really pump out dwt without having to keep checking the names of the schema / ...
When you are talking about best practice in the WCM space it is very vague as this entirely depends on the Business Context and End User experience. Also, above what you are saying may be correct depending on the actual requirements or it may be an overkill.
You need to consider following points:
Do you have schema which are common to all or majority of ...
To elaborate on Rob's answer, the code to add to yours would be something like:
SchemaFieldsData schemaFieldsData = Client.ReadSchemaFields(txtSchTCMURI, true, null);
foreach (var schemaField in schemaFieldsData.Fields)
bool isMandatory = schemaField.MinOccurs > 0;
// Do something with isMandatory
var mandatoryFields = ...
There are a number of reasons why you can't delete a Component, for example: it could be used by some other items, it is published, checked-out, the deletion is not attempted from the owning publication etc.
But... the grayed out appearance leads me to believe that the Component has entered a Worflow. Did you attach a Workflow to the Schema?
We were able to find the schema that caused issues by using the powershell modules provided by Peter Kjaer (https://github.com/pkjaer/tridion-powershell-modules).
With this module, we were able to write and execute the following command (the function was also provided by Peter in one of the samples)
function Get-TridionChildItem([string]$Id, [int]$...
The only way to build such a Schema would be with a GUI Extension and complex metadata against each field.
It would be much easier to have a "Green Schema", "Red Schema" etc... and a shared Embedded Schema to hold common fields between them.
This also give you more use of SDL Tridion features, like where used, limiting Component Templates, Easier Template ...
I think you need to look at the MinOccurs and MaxOccurs on each field. MinOccurs will be 1 for mandatory fields. Remember the Schema is an XSD.
There's probably a simpler way but I've never done this before.
See here for example of creating the fields:
I am in agreement with Nuno and also with Dominic.
Generally if you go with naming conventions, Pascal cases are generally specified for methods and camel cases for local variables in a programming methodology (Microsoft).
In XML there is no such specified naming convention, though most of the professional recommend using lower case or camel case.
In my ...
I'm seeing this pattern again with the popular "slide out" type navigation (from the hamburger menu) and can offer two follow-up considerations.
The nested items are editorial (manually curated), not based on structure, but are (likely) related to existing content. So rather than just links of Components to other Components, also add these links to existing ...
One solution could be to use event system to parse out the component links entered into the field and check if the links are created using an allowed schema, here would be the steps:
1) on save - check rtf field for component links
2) for each component link check the schema used
3) custom logic - check the rule of schema / link is allowed
4) warn / or ...
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;
"Simple Schemas" don't support attributes, only elements.
You can modify the Source tab of the Schema to add the attribute, but be aware that it will change it to a "Complex Schema" - meaning you will not be able to use the form-based UI to edit Components based on said Schema. You will only be able to edit it in the Source tab or through the API.
SDL Tridion Schemas can be divided in two categories, a Tridion Web Schema and a W3C Schema.
The first variant (also known as a Simple Schema) does not allow attributes and only accepts certain data types. The second variant (also known as Complex Schema) will allow you anything supported by http://www.w3.org/2001/XMLSchema. But W3C Schemas don't have a ...
In addition to Chris' answer, you could also set the Linked Schema on the Folder, and set this as Mandatory.
This will force all Components created in that Folder to use that Schema, and will not display the Schema dropdown at all.
If you have flexibility to switch the field types, you might consider changing the dropdown to a radio button since it also only allows one value to be selected, as in a dropdown, but isn't prepopulated by Tridion when you create a new component.
You don't have to use Search for this. A where used query will also work, and might be the better choice. Here's a powershell snippet to illustrate how you might do this:
$core = Get-TridionCoreServiceClient
$filter = new-object Tridion.ContentManager.CoreService.Client.UsingItemsFilterData
$filter.ItemTypes = "Component"
$components = $core.GetList("tcm:...