I have a site package that I need to include in Static Templates.
It has been added as the last template under Includes > Selected Items, but if I then go to the Template Analyzer it is not listed.
In another offline installation of TYPO3 I use to test on, the static template is added and working perfectly. What could be going wrong here?
For Includes > Selected Items you are registering a label-value-pair for the select field only. To be shown, it is only necessary that your extension is installed/active. The content of this registration is not checked.
In contrast to this, the specified file is read during parsing. I.e. errors in the pathname take effect here. So here it is crucial that the registered path matches the actual path of the file - if necessary, including the consideration of the upper and lower case (or camelCase).
Related
I have requirement where, in template we will have some list of components by default. But the requirement is, author can delete,move these components in the page.
We are using sightly and I have used
<div sly data-sly-resource="${'sample' # resourceType='sampleapp/components/content/sample'}" />
This is working fine. But I am not sure how do to delete and move this component.
Any help is appreciated.
If you have a template/component in which you include a specific component then it cannot be moved or deleted. It will show the delete option but after refresh it will be there again (not configured). The things that can be moved are components placed within parsyses.
To create template which has predefined components that can be then moved around you need to base your structure on parsyses. Place your predefined components within the templates parsyses - within the templates jcr:content. Remember that template is nothing else then a predefined content node.
See the example in which the survey-template has predefined content:
I have a test web page that contains one component, a carousel.
That component was copied from /libs/foundation/components/carousel and what i have modified from the copied component was the property:
sling:resourceSuperType from foundation/components/list to foundation/components/carousel.
My next step was to remove a property from the touch dialog (the property Controls Style).
My problem is that in my web page i keep seeing this property even when it was deleted.
Is this because the resourceSuperType is foundation/components/carousel and because this component stills have the property i'm seeing in the dialog?
This behavior was not like this in AEM 5.
My intention was to copy the component, keep the inheritance (resourceSuperType) and modify the copied component.
What i'm doing wrong?
EDIT: Making some tests i figure out that in AEM 6.0 if i delete a property of the carousel (my copied carousel), the property doesn't appear. BUT in AEM 6.1 the property appears. Where can i found this change between the two versions? or is something else?
When creating an overlay, you're going to find all properties from the original component even if they don't exist in the overlay.
You'll have to explicitly remove the property by adding the sling:hideProperties property of type String[] to your overlay. This will allow you to hide the values otherwise inherited from the node from /libs that you're trying to overlay.
I think you'll find the descriptions of various use cases for the sling:hideProperties property in the documentation quite useful.
As part of of it's resource resolution process, the Sling Resource Resolver has search paths that it looks in to locate a resource.
The two most common search paths are /apps and /libs. With the /apps path taking precedence. The most common usage of this in sling:resourceType where the value is defined as the path below one of these search paths. In your case having a sling:resourceType of foundation/components/carousel would originally return the OOTB components under /libs and when you copied it to the /apps directory it would return the component you put under /apps.
This concept of replacing the existing component with your own component is called an overlay another method is called extending an component where you define a sling:resourceSuperType which, if a resource is not found in the existing path, will pass the request to the superType to see if the resource can be found there.
Before 6.0 this concept of overlay applied only to resource. Which is a node that contains properties (simplistically speaking.) And in most common usage you have to reflect the majority of the component into the new search path to get what you are trying to do.
Starting in 6.0 there was a new concept of a merged resource. That would combine the values of a resource located in multiple search paths. This allowed you to modify or alter the functionality of a component without replicating everything else. You could just change a property at a particular level.
None of this happens automatically. To get this functionality the component needs to be aware of the ResourceMergerApi and use that API when attempting to resolve resources for it to use.
That's why the documentation mentions granite. Granite refers to the new components being written by Adobe that uses the TouchUI and is aware of this new API. With each new release more and more older components are being replaced by the new TouchUI based ones that supports resource merging. Including the carousel.
Is there a possibility to change the typoscript template hierarchy via an extension-template? Currently i have defined everything including all typoscript in my extension. This works fine with real_url configuration etc. But everything regarding indexed_search is overwritten by the original extension itself.
Is there a possibility to define the loading/parsing order of extensions?
Thanks!
You need to define a dependency to all extensions that should load before your extension.
If you do not have a hard dependency, then make sure to list the extension as suggested, because this will make that it is loaded before your extension too.
Open the TypoScript record, switch to the tab "Includes", at the bottom you will find the field Static Template Files from TYPO3 Extensions:. Select the value Include before all static templates if root flag is set.
Question is a duplicate of Manage hierarchy / enforce priority of TS-templates
I have an TYPO3 installation with two domains. Each domain has its own provider extension and static template file.
Example:
domain1.com -> providerextension1
domain2.com -> providerextension2
Is it possible to hide the fluidcontent FCEs from providerextension1 in domain2.com?
Example from Bootstrappackage (https://github.com/Ecodev/bootstrap_package)
As soon as an extension has included fluidcontent FCEs (like the fluidcontent_bootstrap) it will add these to all domains, also when the TypoScript Configuration is not included.
If I understand the question completely, the answer is no: you cannot in TYPO3 make your TypoScript that is available in the backend, depend on the domain name being used. There is a way to make TypoScript conditions for the frontend output (for example a condition to only add template paths for your provider A when domain is X), but the same is not possible in the backend.
You are of course welcome to add a feature request on our issue tracker - I don't see any immediate problem with a feature to toggle on and off particular provider extensions based on for example a TypoScript setting. But you should keep in mind the limitation mentioned above since it implies that in order to achieve your desired goal you must place each domain record on a page tree of its own and closely manage the TypoScript that controls the available Provider Extensions on each page tree.
Put shortly: even if you get this feature request filled, it may not be the solution you want and you may have to restructure your pages and domains to get where you need to be.
The problem is, that the FCE are defined in the "ext_tables.php" and "ext_localconf.php" and these files are always loaded when the extension is enabled.
You can alter "ext_tables/ext_localconf" with a simple condition like
if($_SERVER['server_name'] == "www.yourdomain.com") {
//init FCEs here
}
You can try to override the template paths for one domain with an empty value or at least a path to an empty directory. Maybe flux is smart enough to ignore empty template paths.
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.