how to set publish dcp for child or other publications to different location without overiding all other settings - tridion

I am trying to configure cd_storage and getting issue in setting up dynamic component presentation as they get over written by child and published to same folder from every publication.
I know we can define the publication level settings but once we define that then it expect us to define everything inside that publication tag. We do not want to define every thing 50 times in publication tag.
Could any one suggest the best practice for same.
this is for sdl tridion 2011 sp1
Thanks in advance...

Your problem is in how you defined your storage configuration for the storage which you use to store ComponentPresentations. There is a flag in the definition of a storage which sets exactly this type of behavior: defaultFilesystem. You probably have it set to false which causes all ComponentPresentations from all publications to be stored in the same location. By setting this flag to true you will get ComponentPresentations from different publications stored in different locations. I will give an example to show how this works in cd_storage_conf.xml:
<Storage Type="filesystem" Class="com.tridion.storage.filesystem.FSDAOFactory" Id="defaultCPs" defaultFilesystem="true">
<Root Path="c:\temp\cpRoot" />
</Storage>
....
<ItemTypes defaultStorageId="defaultFile" cached="true">
<Item typeMapping="ComponentPresentation" itemExtension=".jsp" storageId="defaultCPs"/>
....
This is really easy to maintain and will make the Broker to store ComponentPresentations to locations like: c:\temp\cpRoot\pub109\dcp\jsp\*** (here I have publicationId=109).
Hope this helps.

Related

Set Directory in WiX

I am trying to create a folder at a location different from the application installation location which happens to be C:\Program Files(x86). I am using the following fragment
<Fragment>
<DirectoryRef Id="TARGETDIR">
<Directory Id="PhotosDir" Name="Photos" />
</DirectoryRef>
<!--<SetDirectory Id="PhotosDir" Value="[TARGETDIR]Photos" Sequence="execute"></SetDirectory>-->
</Fragment>
I tried with a SetDirectory element as shown above and also with a CustomAction as shown below. (If I use both, I get an error saying Id is duplicated. Hence I commented it.)
<CustomAction Id="SetPhotosDir" Directory="PhotosDir" Value="[TARGETDIR]Photos"></CustomAction>
<InstallExecuteSequence>
<Custom Action="SetPhotosDir" Before="CreateFolders"/>
</InstallExecuteSequence>
I have a component also defined for this directory element as below.
<Component Id="cmpPhotosDir" Guid="{8F757344-CA0A-42BC-B292-A51CE86B19E2}" KeyPath="yes" Directory="PhotosDir"><CreateFolder/></Component>
But the directory called Photos is always getting created in D drive, even though it is nested inside of TARGETDIR. I actually want to control the location where this directory gets created, probably through UI. I googled for SetDirectory element example, but couldn't find a proper working sample. All I get to see is that I have to use a custom action type 35 or 51. But it is not clear what code should go inside of these custom actions. Also, I am not sure, if these custom actions are required in addition to the SetDirectory element or not. Can anyone please help me achieve this, with some working sample?
The problem is your directory identifier is not PUBLIC. Change its name to include no lower-case letters; use only upper-case letters, numbers, and underscores. (This came up in reverse pretty recently over here.)
I would also probably schedule the action to After="CostFinalize" , or just set the property of the same name Before="CostInitialize. Neither of those are likely to be relevant to your symptoms, however.

Remove custom type in Alfresco

In Alfresco, if a type name is removed/changed all nodes of that type will disappears but still exists.
Using alfresco 5.0.c I've added some custom types:
eg:
<type name="my:test">
<title>Test folder</title>
<parent>cm:folder</parent>
</type>
now i deploy it and create a folder of this type (a simple folder, then change type)
Now i edit the type like this:
<type name="my:test2"> <!-- from my:test to my:test2 -->
<title>Test folder</title>
<parent>cm:folder</parent>
</type>
Deploying this: any "my:test" folder will disappear, but, if I try to create another folder with the same name I get an error becouse the node still exists.
These nodes will not be not even listed within the folder child:
print(document.getChildren());
How can I recover (if possible using the the javascript console) all the "broken" nodes and be able to change the type?
A little preface: as widely stated by Alfresco, if you want to change your custom content model you should change it only incrementally.
This means that you can't remove any properties, types or aspect at definition level of the model, you only can add new definitions in the content model of Alfresco.
So it is a very bad practice to change types "on the fly".
A good practice is to always start with a model as small as you can and then add features as long as you need them.
In your case you should have deleted all nodes referencing my:test type BEFORE changing the model and then safely remove it and finally you should have performed a full reindex. This could be the reason why the repository tells you that the folder exists even if you cannot see it anymore.
As far as I know it is not possible to delete this inconsistent nodes through the console, so my advice is to perform a full reindex. If the issues come up again then you should consider to start again from scratch.
Another approach next time is to add the new type and programmatically hide the older one.

How to enable Content Delivery Loggin

How to enable content delivery logging in Tridion 2011 sp1. We have .net version of content delivery. After installation of content delivery we changed logback file present in our application folder (D:\Inetpub\MyPortal\bin\config), below is the setting in logback xml
<property name="log.history" value="7"/>
<property name="log.folder" value="D:\tridion\log"/>
<property name="log.level" value="DEBUG"/>
After doing the change we reset the IIS. But we don't see any log file at above location.
Reason why we want to check log file is.
We have implemented content filter mechanism. In which we are using various Query Criteria like ItemSchemaCriteria, CustomMetaKeyCriteria, KeywordCriteria.
Somehow for some filters results are not displayed, though we have component present in broker database. How to check exactly what query is getting fired when filter mechanism is executed on page.
Note : At location d:\Tridion\log\ We can see files like cd_core.2012-10-25,cd_monitor.2012-10-25, cd_deployer.2012-10-25,cd_transport.2012-10-25 but these files are old we need today's log. (04-11-2012)
More inputs on issue :
We found that when we add cirteria for Category that time results are not coming.
KeywordCriteria FilterCategory5303Criteria0= new KeywordCriteria("FilterCategory","Administrative");
Criteria[] filterCatCriteria5303 = {FilterCategory5303Criteria0};
Criteria filterCatOrCriteria5303 = CriteriaFactory.Or(filterCatCriteria5303);
mainCriteria5303 =CriteriaFactory.And(mainCriteria5303, filterCatOrCriteria5303);
In CUSTOM_META table in broker db we have entry for 2 component.
KEY_NAME = "FilterCategory" and KEY_STRING_VALUE="Administrative"
If you're using:
<property name="log.folder" value="D:\tridion\log"/>
then it's expected that you'll get no logging. Logback expects either double backslashes or simple (fwd)slashes. Example:
<property name="log.folder" value="D:\\tridion\\log"/>
or
<property name="log.folder" value="D:/tridion/log"/>
Further more, if you want to see what (JPQL) query Tridion creates for you from your Broker query then you need to set the logging to TRACE and to search in your logs for the following:
TRACE JPAQueryDAO - Broker Query generated:
This will give you an impression about the final SQL query generated in the end.
My last remark is about the KeywordCriteria and how you're using it. You should know that KeywordCriteria does not relate in any way to the CUSTOM_META table. For queries related to that table you should use the criterias called "CustomMeta***Criteria"
Probably, in your case you need to use:
new CustomMetaValueCriteria(new CustomMetaKeyCriteria("FilterCategory"), "Administrative");
Hope this helps.
Cheers,
Daniel.
Whenever a Broker Query doesn't give me the results I expect, I head towards the MSSQL Query Profiler to see what actually happens on the database level.
I documented this process in an article on the Tridion practice wiki: http://code.google.com/p/tridion-practice/wiki/TroubleshootBrokerQueryGeneration .
A quick summary of the steps:
start the MSSQL Query Profiler
start a new Trace
filter the trace on database name
reload your page, so the query fires
find the query in the Profiler
copy the query into a better tool and reformat it
Once you reach step 6, it is often somewhat clear why there are no results. I often end up then modifying the SQL to give the results that I'm looking for. And from that I modify the Criteria to generate that SQL, which can at times be a challenge.

How are keywords in metadata stored?

I'm researching options to synchronize external data to a Category and Keyword list.
I have a metadata field with a states field that uses a category called US States.
When I preview my component with a simple XSLT component template (<xsl:copy-of select="." />), I can see:
<tcm:Content>
...
</tcm:Content>
<tcm:Metadata><Metadata xmlns="http://createandbreak.net/schema/generic">
<states>California</states>
<states>New York</states>
</Metadata></tcm:Metadata>
When I update the keyword and preview, I can see updated values.
<tcm:Content>
...
</tcm:Content>
<tcm:Metadata><Metadata xmlns="http://createandbreak.net/schema/generic">
<states>Californias</states>
<states>New York</states>
</Metadata></tcm:Metadata>
Which is great. It looks like we do not need to synchronize components (open, edit, and save) to use updated keywords. Is that a safe assumption?
If I update a keyword, do I need to update components that use it in order to publish component presentations with the updated values?
Do I need to also be careful when moving components with content porter?
No, you don't need to do anything manually for those Keyword fields to be "Content Porter"-safe. Tridion stores the link from your Keyword field to the Keyword definition (in the category) as a so-called managed link (a TCM URI).
The reason you don't see this value in your XSLT has to do with the way Tridion traditionally exposes the Keywords in WebDAV: it hides the TCM URIs there and instead just exposes the value of the selected keyword. Since Keyword values must be unique within their category, this will always allow you to look up the correct TCM URI if needed.
But when exporting (and in general when you're using the API to access content) you should retrieve the Component XML with the TCM URIs in place. Check the API documentation for your programming language to see which Filter/ReadOption you need to specify for that.

Saving Configuration Section Error - Elements are merged as attributes

I have created a configuration section designer project to represent nodes of a custom section necessary to read and save from my web application. I am able to successfully create instances of the configuration elements and collections, however when I save the configuration using the referenced System.Configuration.Configuration object and issuing save, the elements get merged into their parents as attributes. An example of the issue is outlined below:
After calling the referenced Configuration.save, the output is as follows:
<savedReports xmlns="SavedReportSchema.xsd">
<resultsSets dataViewId="1" id="4203bb88-b0c4-4d57-8708-18e48f0a1d2d">
<selects keyId="1" sortOrder="1" />
</resultsSets>
</savedReports>
As defined in my configuration section designer project (confirmed by the resulting xsd as well) the output should match the following:
<savedReports xmlns="SavedReportSchema.xsd">
<resultsSets>
<savedReport id="1">
<selects>
<select keyId="1" sortOrder="1"/>
</selects>
</savedReport>
</resultsSets>
</savedReports>
Any ideas? The element collection types are set to BasicMapAlternate however when I set them to AddRemoveClearMapAlternate they are not merged but they are prefixed by "add" rather than "select" or "savedReport" causing the validation to be off.
Turns out AddRemoveClearMapAlternate was the option I needed to correct my problem referenced in the question.

Resources