Just when I think I understand how Tridion resolves links ....
According to the docs about Component links -
If you unpublish a Component, any Components that link to that
Component are not unpublished.
Does this only relate to DCPs?
We have components used in DCPs and within component links. When I unpublish the component e.g. C5, in the "items to unpublish" list, I see pages that are only connected to C5 through component links - I've opened several pages from the list and none use the component directly in a CP, but it is linked to from another component on the same page:
Page P1
CP1
C1 + CT1
CP2
C2 + CT2
(C2 links to C3 below)
Page P2
CP1
C3 + CT3
CP2
C4 + CT4
(C4 links to C5 below)
Page P3
CP1
C5 + CT5
When I unpublish the component C5, Page P1 is in the unpublish list - that's correct behaviour right?
EDIT
Apologies, this is Tridion 2011 SP1.
I would think that is indeed the wrong behavior. Unpublishing of a component should not unpublish all the pages containing components with component links to the component we are unpublishing.
EDIT
#Neil, the only things I can think of that could trigger the behavior you describe are the following:
2009 or older. TBB, Workflow or EventSystem with code to publish/unpublish
components according to your description.
2011 GA or newer. TBB, Workflow, EventSystem or resolver extension with code to trigger the behavior you explain in your post.
Unlikely but is still possible, a bug :)
Unpublishing C5, as a DCP used by a page and static content, should:
Leave P3 alone, since it includes C5 as a dynamic Component Presentations
Unpublish C4 and as a (non-dynamic) component embedded on a page, this will also...
Unpublish P2 (if already published)
The question is if unpublishing P2 should unpublish C3 and therefore C2 and the P1 page it's embedded on (statically). Unpublishing a page with a non-dynamic embedded CP doesn't unpublish other pages at least for my SDL Tridion 2011 SP1-1 setup.
But, because the dynamic component is linked to by a "static" component, I'm thinking the best case here is to remove and publish the page. Otherwise you'll have other pages like P2 removed if you really just meant the DCP.
Related
I relatively simple question regarding XPM this time. It's about creating Page Type which editors could use to base their new website page on. When defining a Page Type, you can use an exisiting page to enable this as an example page, including its components. You can copy these components to enable editors to edit these freely without tampering with existing pages using these components as well.
On the SDL Live content docs they explain the following:
Change the setting from Include this Component Presentation to
Include a Component Presentation that contains a copy of this
Component. If you use this Component in multiple Component
Presentations on this Page, then saving the Page causes all of those
Component Presentations to have the setting you configured last for
any of those Component Presentations. A number of new controls appear.
This means that whenever an editor clicks 'new page' within XPM, this page type is available and the components that are defined inside it are copied with user-specific prefixes. You can define this inside the page defined as a Page Type itself, by clicking on the component presentations tab, then clicking on a component and selecting Page Type settings. note the following:
As you can see, the copy of the content is being created in 050 - Web - Global, which is, in our blueprint, the wrong publication. However, in the popup you cannot select the correct content location, only the one where the page type is residing.
I've tested this, also with the UI -specific blueprint context settings, where you should define where content and pages are created. However, when creating a new page, the components are copied inside 050 - web - global; the wrong publication. As we're moving to a training, I'd imagine that dynamically created components like this might clog the CMS with content in the wrong location, making it unusable for other publications. Is there a reason for this behaviour, and if so, a way to make this work properly?
If you set the BluePrint Context for Components to the Publication where you want them to be created, it should work as you expect.
I need help with following scenario:
I have page template PT1 , which contains 2 TBBs and I have component template CT1, which contains 1 TBB.
I created a page using the Page Template(PT1) and added a component and selected the component template (CT1).
The TBBs pushing some text value to package and all three TBB are part of a single dotnet assembly and implemented in three different class, which is implementing "Itemplate" interface and implement "transform" method.
Problem:
In the published file i am able to see the content pushing by TBB used in Page Template PT1, but not able to see content which is pushing by TBB of Component Template CT1.
Typically, to output from a template you need to create a DWT TBB unless you are directly sending Output from C# TBB.
In your case, looks like you have all C# TBBs and are they outputting anything to the package. If not then I even doubt your PT will output any html.
You could use the Template Builder tool to debug your out of the template as in my comments the doc portal link will provide you guidance.
In Dreamweaver Templating we can access the fields of a component in two ways.
1.##Component.Field.FieldName##
2.##RenderComponentField("FieldName",0)##
similarly to access the Component Presentation
1.RenderComponentPresentation()
Is there way to access it in another way.
You should really consider editing your question and clarifying it a
bit to make it more clear of what you are asking. Reading all the
answers you dismiss and their comments, I think what you are trying to
accomplish is to have some Component Presentations on the Page editable
and others not.
Depending on the version of SiteEdit you are using there are two solutions:
SiteEdit 2009 SP3 - You should remove the inline editing TBB from the Component Template which you do not want editable, the Page will still generate a hover-over the Component Presentation so it can be moved.
UI 2012 (the new UI or Experience Manager) - You can disable inline editing per Component Template, through the checkbox in the Component Template.
If you also need to have the hover-over on the Component Presentations removed, then I think the only solution is to remove the Inline Editing features of the Page Template (for SE 2009 SP3, remove the TBB and for UI 2012 disable it on the Page Template) and generate all the required SiteEdit marking yourself in the Page Template.
An interesting question to all this would be "why?", what is your requirement exactly to have the need for only enabling inline editing on some of the content on the Page. Since you could also accomplish that through (editing) permissions for certain user groups.
The default TBBs that ship with Tridion, SiteEdit 2009 and the new UI/Experience Manager all insist on generating markup around Component Presentations and Component Fields. You can control the markup elements they generate, but there is currently no way to turn them off.
To gain such full control, I created a simple extension function for use in DWT templates. You can find it here: http://code.google.com/p/tridion-practice/wiki/TridionUI2012FunctionsForUseInHtmlTemplates
RenderComponentPresentation would be from the Page Template, and the first examples are from the Component Template, or within e.g. a repeating region:
<!-- TemplateBeginRepeat name="Components" -->
Fields.*FieldName*
<!-- TemplateEndRepeat -->
But either way, why are you asking?
You can also call RenderComponentPresentation from within another Component Template, using this code:
##RenderComponentPresentation(Component.ID, ComponentTemplate.ID)##
Where the arguments are the tcm ids of the component you wish to render, and the template to render it with.
For dynamic component presentations you can use the following in a page template:
<tcdl:ComponentPresentation type="Dynamic" componentURI="${ComponentID}" templateURI="${DynamicComponentTemplateID}" />
But in this case these dynamic component presentations won't be published during the publishing page. So, you should publish them before publishing page.
I have a Plone (4.0.1) site which requires changes in layout depending on the folder. Imagine a structure like:
University > Faculty A > Institute A1 > Person A11
> Person A12
> Institute A2 > Person A21
...
Now if I put all needed resources (custom css file, images, etc.) into the ZODB, pages for person A11 would automatically pick up a fac-image.gif located in the Faculty A folder.
However, to avoid confusion, I do not want to expose fac-image.gif to the users. (This is all part of the framework which they're not supposed to touch anyway.)
If I register a resource, I can access stuff with ++resource++theme.images/path, but no acquisition from parents is taking place, so ++resource++theme.images/facultyA/instituteA1/fac-image.gif won't find the image. Even worse, I have a separate directory structure to maintain now.
What I'm currently doing is hand-rolling a "best effort" traversal process through a file system directory view that will try to go down the path, just stay where it is if the subdirectory doesn't exist (i.e. the resource tree doesn't have a subdirectory for person A11; instead of yelling 404 I stay at institute A1), and then try to acquire back up. Some trickery is involved for portal_factory and views, and I'm pretty sure I've missed more.
So: that surely isn't the way one is supposed to do it, but what is?
Use CSS.
Simply tag your tag with classes based on the current section / faculty / aspect of your choice and alter your images based on those classes. Keep visual design separate from your content!
You can inspirate you from collective.phantasy that implements this use case for plone3 (change l&f for a folder container).
It seems to be so. I ended up registering a helper view that examines and mangles the context path and points it somewhere else into a file system directory view.
When installing an Umbraco site, I changed my umbraco admin url from '/umbraco/' to '/myadminurl/', even before I went through the install process.
Just like it's documented, I changed in the web.config the keys 'umbracoReservedPaths' and 'umbracoPath' to match my new admin url.
Installed and everything is working fine, except for one thing:
All the nodes in the trees in all sections aren't showing any thumbnails. There used to be a win folder thumb before each tree node, but now it's just empty, except for the 'packages' node in the developer section, and for the recycle bin thumb.
Am I missing anything else I should had changed?
Thanks!
Lee Kelleher answered my question in the Umbraco forum here.
The answer is that it looks like the image reference for the tree icons are hard-coded to use the "/umbraco" path.
2 options:
Manually create the path to the image? The CSS is specifically looking for...
/umbraco/images/umbraco/sprites.png
Change the reference in the CSS, (rule for ".tree.tree-umbraco li a") ...
/umbraco_client/Tree/Themes/umbraco/style.css
Cheers!