The publisher instance has the following javascript files included:
/etc/clientlibs/granite/jquery.min.js
/etc/clientlibs/granite/utils.min.js
/etc/clientlibs/granite/jquery/granite.min.js
/etc/clientlibs/foundation/main.min.js
/etc/clientlibs/granite/jquery/granite/csrf.min.js
It would be best to exclude them for performance and also the fact that I am using jQuery 2.0 as my part of AEM site.
These scripts(not including the csrf.min.js) are part of the category cq.foundation-main. You can use this utility for checking this.
http://localhost:4502/libs/granite/ui/content/dumplibs.test.html?categories=cq.foundation-main
If you create your page template components by extending the OOTB wcm/foundation/components/page (assuming you use sightly), AEM will add these scripts in the head section. More specifically these are included in headlibs.html file present under the OOTB page component.
To overcome this, you can override this file in your component, and either comment this below line or include it conditionally only when wcmmode is edit.
<sly data-sly-test="${wcmmode.edit}" data-sly-call="${clientLib.all # categories='cq.foundation-main'}" />
For JSP based components (foundation/components/page), the same thing is done in headlibs.jsp.
By the way, you wouldn't want to remove the CSRF JS. It's AEM's solution to counter CSRF issues.
What you see is the clientcontext related js'es
The script that loads the given js'es is as below (or sth similiar)
<cq:include path="clientcontext" resourceType="cq/personalization/components/clientcontext"/>
either you exclude it completely for publish (wcmMode=disabled) which would probably break sth related to analytics on your publish, or change the include to some overwrite of the clientcontext component that you'd develop.
If you however don't use any native Adobe integration you should be safe just with excluding the thing.
Related
Is it possible to conditionally include different clientlibs based on the user agent of the browser?
IE
<sly data-sly-use.clientLib="/libs/granite/sightly/templates/clientlib.html"
data-sly-call="${clientlib.js # categories='a'}"/>
Modern Browsers
<sly data-sly-use.clientLib="/libs/granite/sightly/templates/clientlib.html"
data-sly-call="${clientlib.js # categories='b'}"/>
AEM version: 6.3
If not, what are the other alternatives to achieve the same?
Note: I tried to get this check done in a sling rewriter server side but the problem is, with the dispatcher on, it will only hit AEM for the furst time and cache the html, any subsequent hit will not invoke any server side logic to render it. Hence, it has to be done client side IMO
For this you have to write custom clientlibs templates as described here : https://github.com/nateyolles/aem-clientlib-async.
And then in the WCMUse class you can check user agent and include clientlibs accordingly.
First of all, as you already pointed out correctly, you need asolution that works with the dispatcher cache. So Sightly is not an option.
Then, regarding the fact, that most AEM templates have paragraph systems with multiple possible components to be added to a page on the one hand and AEM clientlibs are build on a template level (and not on page level) you end up with a clientlib holding lots of unused JS and CSS most of the time, since you have to cover all the possible options of components used in your page and paragraph system.
With that in mind, clientlibs might not be a good option to be used after all.
Having static CSS and JS files in your AEM repo and referencing them client side based on a JS snippet will do the trick and - in most cases - you will not buy any side effects with that approach.
You can either:
Wrap your clientlibs with conditional comments: https://stackoverflow.com/a/11703767
Create a Use-Object that check the User-Agent header and exposes a method isIE that you can use to conditionally include the clientlibs with data-sly-test. Alternatively your Use-Object could just return the proper categiers based on user agent so you can have only one clientlib call.
You could use the <script module> and <script nomodule> to achieve that. The first one is ignored by older browsers and the second one by the modern ones. Similar to Vue's Modern Mode. Check: https://cli.vuejs.org/guide/browser-compatibility.html#modern-mode
More likely you would need some back-end to create your custom clientlib template.
If we give cq:includeClientLib inside my component jsp and if we drag and drop the component twice on that page, will the clientlib gets loaded/included twice?
what will be the case if we do in Sightly way (data-sly-call="${clientlib.all # categories='somecategory'}") ?
And also what is the suggested method of including client libs, either create a clientlib specific to the component and load only for that component or include all the CSS and JS at a common clientlib and use it across?
No, the clientlib is only included once for a category.
This is by design as the HTL (and respective JSP tag) are evaluated during runtime and the processor keeps a map of categories that have already been included and does not include them again.
As #i.net mentioned, each category will only be included once. To answer your follow up question about the suggested method..
The best practice seems to be to define a client library for each component, which is then embedded into a "global" client library. That global client library will then be included within your page template.
/etc/designs/acme/clientlibs-all
categories=["acme-all"]
embed=[compA,compB]
/apps/acme/components/compA/clientlibs
categories=["compA"]
/apps/acme/components/compB/clientlibs
categories=["compB"]
The reason the global client library is located under /etc/designs is to prevent exposing /apps to the public. However, in AEM 6.3, you could make use of the allowProxy property to serve the code at /etc.designs/. This would then look like this:
/apps/acme/clientlibs/clientlibs-all
categories=["acme-all"]
embed=[compA,compB]
allowProxy=true
/apps/acme/components/compA/clientlibs
categories=["compA"]
/apps/acme/components/compB/clientlibs
categories=["compB"]
Adobe recently released a good tutorial of more recent best practices around client library structure: https://helpx.adobe.com/experience-manager/kt/sites/using/getting-started-wknd-tutorial-develop/part3.html
I was referring to adobe blog
and as per standard guidelines, we need to embed all component specific clientlibs in /etc/design/app/clientlibs. Once done, all clientlibs will be consolidated into one call.
I have a question if we do this way, will AEM not call all clientlibs on page load and will that not affect performance on first page load? Of course, subsequent calls will be lighter?
Also is there any way where i can load authoring specific clientlibs only when author is creating/editing content or only on author mode?
I have a question if we do this way, will AEM not call all clientlibs
on page load and will that not affect performance on first page load?
Of course, subsequent calls will be lighter?
The purpose is to avoid multiple network calls to each individual libraries/JS that you have included in your code. With effective compression/minification the size is optimized.
To answer your question, there is a trade off but in long term its beneficial. With dispatcher and CDNs in place in most of the cases the first loads is the only bottleneck.
Also is there any way where i can load authoring specific clientlibs
only when author is creating/editing content or only on author mode?
You can and should include authoring clientlibs on Authoring instances only, you can do this by placing an edit mode check prior to including authoring client libs.
Look at /libs/wcm/foundation/components/page/author.html it makes a check for edit mode for including edit/authoring libraries -
<sly data-sly-use.wcmInit="initwcm.js"
data-sly-use.clientLib="${'/libs/granite/sightly/templates/clientlib.html'}"
data-sly-test="${!wcmInit.wcmmode.disabled && wcmInit.isTouchAuthoring}" data-sly-call="${clientLib.all # categories='cq.authoring.page'}" />
<sly data-sly-test="${!wcmInit.wcmmode.disabled && !wcmInit.isTouchAuthoring}" data-sly-call="${clientLib.all # categories='cq.wcm.edit'}" />
I would like to implement an extensible templating mechanism in AEM, so as to permit component users to control markup for individual projects (designs) without modifying the components' pre-defined JSPs.
I have extended the <cq:include> tag to permit this, by passing a template name, which is then retrieved from the current design, falling back to the default markup when an override does not exist in the design:
<ct:template name="listNav/prev" />
This should load the jsp script from [1], unless the location does not exist, defaulting to [2]:
/etc/designs/projectName/component_templates/listNav/prev.jsp
/etc/designs/component_templates/listNav/prev.jsp
When using the extended tag, I'm receiving the exception (yes, the file exists):
Caused by: org.apache.sling.api.SlingException: javax.servlet.ServletException: javax.servlet.jsp.JspException: Could not find script /etc/designs/component_templates/listNav/prev.jsp
This all works when the component_templates is under /apps. Is there any way to make this work? Is there a better approach? I'd prefer to keep the component_templates with the designs, if possible.
I don't think it is a good idea to put application script to etc. They should be under /apps.
But I think it could work, if you add /etc path to the "Resource Search Path" of this service:
system/console/configMgr/org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl
you can choose between different "designs" within the advanced page properties tab! afaik you should use this mechanism to declare different designts i.e. stylesheets etc. to your pages and of cause you don't need to modify anything at the jsp's to switch between different styles if implemented properly.
Have a look at this:
Adobe AEM Designs
I am very new in TYPO3 (I came from Joomla and WordPress) and I am having difficulties in understanding how templates are handled in TYPO3 (it seems to me that the situation is more complex in TYPO3 than it is in Joomla and in WordPress).
I have installed and I am testing this version of TYPO3 introductionpackage-6.1.3.zip
In Joomla and in WordPress a template simply is an HTML structure (which are marked in the various areas of the page where the CMS modules will be placed) and the related CSS settings.
In TYPO3 it seems to me that the situation is very different or am I wrong?
At this moment I am reading this section of the official documentation that references the default template of the TYPO3 Introduction Package: http://docs.typo3.org/typo3cms/GettingStartedTutorial/Templates/Index.html
The difference between static content and dynamic content of a website created using a CMS is pretty clear to me (this is not different from any others CMS like Joomla or WP)
Dynamic content: is something that is dynamically created by the CMS (executing some queries) as a menu (it look into a DB table and then a script renders the menu on the page)
Static content: is something that is fixed as the title of the website or a background image
Until now I think that it is pretty clear for me but I have many doubts when the documentation speaks about the Template Record as a way to implement the previous principle.
Here: http://docs.typo3.org/typo3cms/GettingStartedTutorial/Templates/%28%28generated%29%29/Index.html
it says that:
This is a control element that instructs TYPO3 how to handle a certain
branch of the page tree.
In particular with this image it shows how to modify these template records for the Introduction Package Template (Introduction Package is also the name of the template provided with this package or what?):
Then on this section on the documentation it says:
If you edit the template "Introduction Package" you will see that most
fields are empty. For each website you need a TypoScript template on
the ROOT level, in this case that is the "Introduction Package"
template. The TypoScript configuration of a website can be quite long
therefore it is possible to make many small TypoScript templates that
get included in the main template. For better maintenance, all
TypoScript of the Introduction Package has been put into the folder
'Typoscript Templates'. The only thing the "Introduction Package"
template does is to include the "ROOT" template that in turn includes
other templates.
And this is totaly obscure for me: I have understood that TypoScript is a configuration language that can be used to configure the frontend (so I think that I can use it to configure how my page will appear) but I can't understand the following assertions:
What does this mean: For each website you need a TypoScript template on the ROOT level, in this case that is the "Introduction Package" template ? I have installed TYPO3 Introduction Package and I have only a web site !!! What is the ROOT level of the website? Is it the Welcome to TYPO3 node in the List section Tree? So in pracatice I am assigning a specific template to the root of a website and this is used in all subnodes (all the pages as Home, About TYPO3, Features, etc)?
What does it mean when it says: For better maintenance, all TypoScript of the Introduction Package has been put into the folder 'Typoscript Templates'. Where is this folder? I don't have it.
What does it mean when it says: The only thing the "Introduction Package" template does is to include the "ROOT" template that in turn includes other templates.?
Tnx so much
Andrea
The root level of your website is the page called Home. It also has the globe instead of a normal page icon, because the flag Use as root page is set in the page properties under behavior.
When you access a page in TYPO3 CMS, then it will walk up the rootline until it finds a root page with a template record. In this case, it is indeed a record called Introduction Package, but what is more important, is that this is a record of the type template.
OK, so far we have found a template for your request. Now TypoScript comes into play. On a normal request, the template engine will search for an object named page which is (usually) of the type PAGE. Thus the most simple template is:
page = PAGE
page.10 = TEXT
page.10.value = <h1>Hello World</h1>
Which just prints Hello World on your website.
What happens next depends on your template approach chosen (marker base, automaketemple+marker, templavoila, fluid, fedext, ...). That means that TYPO3 CMS does not just have one template approach (or one kind of template), but is extensible and very flexible, as you can combine them.
In the Introduction Package uses the automaketemplate+markers approach. This includes a ready HTML template, automatically creates blocks based on certain rules and then replaces those blocks with dynamic content.
OK, where do you find the configuration for this?
The actual template file is fileadmin/default/templates/introduction_package_site_structure_template.html.
The TypoScript configuration is in fileadmin/default/TypoScript. There you can find a file called setup.ts. It includes all other TypoScript files. There are various folders, e.g. menu for the menu definition, block for the dynamic blocks, etc.
The configuration of automaeketemplate is in Extension/AutomakeTemplate/setup.ts.
The sections defined with the help of automaketemplate are replaced in Page/setup.ts.
The full TypoScript defines a tree structure of objects with their configuration. You can view the full parsed template with either the Template Analyzer or the TypoScript Object Browser which you find in the template tools in the dropdown select box on top of the module.
The separation of the TypoScript into several files is done by the purpose of the configuration inside the files. This is meant for easy maintenance and not for easy learning. You can always use the Template Analyzer to see the full template that is generated out of the fragments and the TS Object Browser to see what kind of configuration tree this results in.
This might sound a bit difficult at first, especially compared to the primitive template systems of other products, however it gives you great possibilities that are yet easy to maintain, even if you do major updates.
It is great to see that people decide to use TYPO3. In my point of view the biggest difference to WordPress, Drupal...
is the strict separation between HTML and dynamic logic, witch can be TypoScript/userFunc or Fluid logic...
and even this makes TYPO3 so powerful. nothing against WordPress, Drupal... ect. but to use PHP in templates is especially for updates a dangerous thing to do.
I am always impressed whats possible with TYPO3. "I cant do it" is not valid for TYPO3. TYPO§ always has a way.
It is indeed a hard way through to learn all the corners of TYPO3 but it is worth.
Keep doing it and you will succeed
Ludwig
Great to hear you also wanna use TYPO3 as a CMS.
To understand the TYPO3 CMS better, i think you can better begin from scratch, meaning download the source + dummy package and install it on your server, or maby download a wamp package.
Currently I use Fluid to build my templates. For the part outside TYPO3 its much like Joomla, just create one or more HTML files, with some special markers.
The other parts, which are in TYPO3, may be some more difficult now, and it would take a lot of time to explain that here, so i'll refer to a tutorial made by Thomas Deuling:
http://thomas.deuling.org/2011/06/create-a-complete-typo3-website-by-using-the-fluid-template-engine/
You might wanna join the TYPO3 mailing list for italy, found at http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-ug-italy.
Furthermore, the TYPO3 website is filled with documentation, although sometimes out of date its still usefull. Also you might wanna take a look at the TYPO3 certified integrator program. There you can find all the basics to become a master at TYPO3.
Please feel welcome to the community, TYPO3 is inspiring people to share!
Kind regards,
Jeroen
Hi i wrote a little starter ts time ago.. maybe helps you
Remember in TYPO3 there are many ways to solve things!..
gl
Setup:
config {
baseURL = http://www.bla.com/
prefixLocalAnchors = all
meaningfulTempFilePrefix=1
doctype=xhtml_trans
htmlTag_langKey=de
remove_defaultJS=external
inlineStyle2TempFile=1
disablePrefixComment = 1
linkVars=L
sys_language_uid=0
language=en
locale_all = en_EN.UTF-8
xmlprologue = none
}
page = PAGE
page.typeNum = 0
page.bodyTag=<body>
page.10=TEMPLATE
page.10 {
template = FILE
template.file = fileadmin/templates/template.html
workOnSubpart = DOCUMENT
subparts {
CONTENT=COA
CONTENT.10<styles.content.get
}
}
File: template.html
<!-- ###DOCUMENT### -->
<!-- ###CONTENT### -->CONTENT<!-- ###CONTENT### -->
<!-- ###DOCUMENT### -->