I have created a website structure in CQ5 WCM. I have created one template and defined few parsys and iparsys into its page level component. After this i have created one page and several more pages under it. Now my question is if make changes to the iparsys component and activate it, would all the pages inheriting it will also get activated or i need to activate all the pages individually?
Yes, all the nested pages would pick-up the change. Look at it as a "computed" reference - your page containing the original content gets replicated to the publish instance's repository, and all other pages compute their HTML based on that indirectly-referred content.
Dispatcher's cache however is another beast - make sure you're invalidating whole site's cache, rather than just the page you activated.
Related
I'm new to CQ5 and working on a project that deals with refactoring code that uses design dialogs.
Currently, I have a property declared as part of design dialog of my component. It creates a folder in /etc/designs/ for each template my component is used on. Is there a way we can make sure that those property values are stored at one particular configuration in /etc/design(as opposed to multiple)? I need to make sure only one set of configurations is used for all pages that use my component.
Thanks in advance!
Pallavi
The designs are linked to the template and not the whole site.
Hence whenever you configure the component in design mode, the values are stored within the corresponding template under the jcr:content of the configured design page or under /etc/designs/default/jcr:content in case no design is configured.
As far as I know, there is no way to tell AEM to store all the design configurations under one single path, unless you are using absolute paths in your dialog / page configurations.
If you are using multiple templates in your site, there must be one master template (which render global components eg. header/logo/navigation & footer), and all other templates should extend master template to get these global components and change pagelayout for content section.
Saying so, if templates are structured & inherited properly, you should be able to set design dialog property on home page (created using master template) and all internal pages will be able to access those design property OOB. Though child pages (created using other template) can override those design property (if needed for that template) to break inheritance.
I have a query regarding CQ. Your reply will really make the difference to my understanding.
In other CMS like Vignette, content authors create the contents separately (not directly on the page) for ex. products details and then those contents are iterated / processed to display on the page. But in CQ, the scenario is other way round. Authors directly create the content on the page. Now if same content is needed on other page, how will that be re-used ?
Regards,
Ronak
Content can be reused across pages via Reference components. From the docs:
The Reference component lets you reference text in another part of a
CQ based website (within the current instance). The referenced
paragraph will then appear as if it was on the current page. Instead
of referencing a specific paragraph, the path can also be modified to
specify an entire [paragraph-system]...
There are some other techniques for sharing content and reference data across pages, including inheritance and "data components," described in this SO Q&A.
Why exactly do we need templates when all a template does is to have a resourceType property attached to a content-page component.
At the time of creating new page, shouldn't authors directly select that component instead?
The template nodes define the metadata for the page that will be created, one aspect of which is the underlying resource type (i.e. the Page component that will be used to render out the content).
Some example of other things configured at a template level include:
The default content that is included when the page is created. This
is stored under the template node itself, i.e. in /apps/[your-site]/templates/homepage.
For example, you could add a carouselnode underneath the homepage node, to ensure that any page created with the homepage template will have a carousel node added by default.
The allowed parents & children of the template — e.g. configuring the homepage template so that it can't be placed beneath other templates.
The allowed components in each parsys — In /etc/designs/[your-design]/jcr:content, you can defined what components can be added to a particular parsys, which applies to any page using that template.
By having a separation between templates & page components it allows us to re-use the same renderers (e.g. JSP scripts), but have aspects like these configured differently for different templates.
When I create a live copy of a blueprint website, and rollout pages using standard rollout config, links in the pages are updated to reflect the live copy version.
ex. /content/myblueprintwebsite/home.html -> /content/mylivecopywebsite/home.html
But when those paths are buried inside properties of the page content nodes, they are not updated, and still points to the blueprint pages.
... is this the intended behavior? If so I guess I would have to write my own rollout config? Or is there another solution to this problem?
Thanks for your answers.
As per: https://docs.adobe.com/docs/en/aem/6-1/administer/sites/msm/msm-livecopy.html
"
When the blueprint source contains links and references that target a paragraph in a different chapter, the targets are not updated in the live copy pages. For example, a live copy is created from the Geometrixx Demo Site blueprint. Links in the Toolbar chapter that target the Services chapter are not updated in the live copy, and continue to target the original pages in the Geometrixx Demo Site.
"
My interpretation of the above:
- If the link to the target is created on a page that is in the ancestral line, the change will reflect in live copies.
I tested this by configuring a link to bp/en/parent/child-page on the bp/en/parent page and also on the bp/en page.
In both cases, the corresponding live-copy/... pages reflect changed paths to the live copy specific child page.
Moreover, the change is happening for links no matter what widget is used - OotB List, a customized link widget, or hyperlink configured in the text widget.
Further question:
Editors may want to create links from pages that is not in the ancestor line. What then? Is there a configuration that can be set to allow the change to happen ? Or are we required to write custom rollout action?
When ever a page rollout is done it updates all the individual content references for ex:
paths in property nodes, if it is stored individually i.e., not concatenated with any other text like: hello /content/test/master/en.
It doesnt update if the path is in the mid of other text.
And
Creating custom roll out doesn't server your purpose.If u really want to create custom roll out to meet this requirement then you have to create following custom live actions and write logic to find paths and then modify them.
1.ContentCopyActionFactoryCustom
2.ContentDeleteActionFactoryCustom
3.ContentUpdateActionFactoryCustom
Creating custom roll out is a risky option as roll out is called from many places like while creating live copy,from blue print section , roll outing a page and its sub pages and background execution etc.,We have to handle any exception caused in this explicitly.If u start changing one file then u end up changing all related files has roll out implementation on many java classes.
Ideal Solution : Save all the paths in a individual property and AEM will take care of updating there references
Cheers !!
It seems to be quite basic problem, but I still cannot find a nice solution.
I made a component that uses a dialog property.
How could I avoid setting this property for every single page if this component is used also in template?
What I already have tried:
I set name attribute in dialog.xml to absolute path - Component stops working as standalone (dropped into parsys).
Move it to design_dialog.xml - First of all it's conceptually content, so I do not like such move, and again it doeas not make much sense for standalone versions.
Change resource path to absolute, while including in template:
<cq:include path="/content/site/somepage" resourceType="/apps/portal/components/myComponent" />
For the first look it was almost it. Instances included via parsys has it's own path, and Content for template is fetched from single resource... But where to store it, to make template code independent from pages tree structure?
Is there any other nice way to do so? or at least way to improve 3.?
To the original poster, the functionality you are looking for is now supported by Shared Component Properties in ACS AEM Commons (http://adobe-consulting-services.github.io/acs-aem-commons/features/shared-component-properties.html)
Compared to your suggested solutions:
No need for absolute property path required for SCP
Agreed these are "content" properties, so they should be stored as "content" instead of "design". SCP stores these values under the homepage node of a site, making them as genuine of content as any other piece of content.
Agreed that it is bad to have a template hard-coded to a content path of a single site, especially since this makes a multi-site implementation impossible without creating a bunch of templates. SCP does not have this problem, because each site has its own homepage under which the properties are stored.
If I understand correctly, you have a component which may work in two modes:
it may be included statically in the main page renderer via <cq:include>
it may be also dropped into some parsys.
In the first mode component should have some common configuration for all pages and in the second mode it should be configured separately per-instance. The problem is how to create such common configuration.
I think your 3rd solution is perfectly fine assuming that the component configuration is shared by all sites in your CQ instance. At some point it may be too strong assumption, eg. you may have a 3 language branches under /content/site-en, /content/site-fr and /content/site-de and you'd like to make a separate configuration for each branch.
I'd suggest following improvement to the 3rd solution: you may create the shared component under some relative path which will be the same for all pages, like /content/.../configuration/shared-component (where ... may be site1, site2 or site3). Then take first two parts of the current page path, add the /configuration/shared-component suffix and use <cq:include> to include path created in such way.
You may also take a different approach and create a common configuration page referenced by all statically included components. These components may try to find their configuration automatically (via the relative path as above) or they may have a single pathfield that references configuration page.
If you don't like these options (as they assume some site structure or they need some minimal configuration for each component), consider using HierarchyNodeInheritanceValueMap. It allows you to get property from the current resource and if there is no such property, it'll look into the same resource on ancestor pages. Using this you could configure your component just once, in the site root page and inherit configuration across the whole site.