i'm trying to add <script> ... </script> to HTML element in Neos CMS, could you please tell me how to do it, because HTML element in Neos CMS doesn't accept js. Is there any alternative how to do it please. Thanks for any recommendations.
There is a package available with wich the editor can add source code like that. But be careful with this feature as with great power (of the editor) comes great responsibility!
Depending on what your use case is, it may be more secure to provide a custom NodeType for the editor which then adds this JS code via fusion.
One thing you may want to think about is loading things from external sources might be problematic for GDPR compliance.
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.
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.
I am working with the Hybris CMS Cockpit (only as a user, not an admin) and I have built a page with the content slots.
However I am trying to insert some JavaScript into the page. I cannot see where I am mean't to add the JavaScript and I tried in-line <script> tags but they just get stripped out and turned to plain text.
Does anyone know if this is possible or will I have to ask an admin of the system to enable something?
You can add javascript but you will have to have a developer make some overrides to the configuration files (local.properties) of the environments you want to add javascript in.
The settings are:
xss.filter.rule.script_fragments=
xss.filter.rule.lonely_script_tags=
xss.filter.rule.lonely_script_tags2=
xss.filter.rule.javascript=
By doing this, the system will no longer strip those tags :)
Typhoid Marty is correct, however to expand on his answer:
The Hybris Cross Site Scripting (XSS) filter is stripping out your script tags.
You will probably want to simply disable it for the extensions where your users will be editing the site, specifically the CMSCockpit, HMC and HAC:
hac.xss.filter.enabled=false
hmc.xss.filter.enabled=false
cmscockpit.xss.filter.enabled=false
You can find more configuration options for the XSS filter in the documentation here:
https://wiki.hybris.com/display/release5/Web+Security+XSS+Filter
Answers suggested by #Typhoid Marty and #kabadisha will fix the issue. Adding another workaround here. script can be added into content of component even if xss filter is configured as xss.filter.enabled=true.
This can be achieved by creating an impex for component and importing it via hac as a script with 'Enable code execution' check as true.
Here's an example :
<script type="text/javascript">
function myFunction()
{
document.body.style.backgroundColor="lavender";
<!-- document.write(Date()); -->
alert(document.getElementById("hai"));
}
</script>
In fact, Hybris cockpit use ZK framework, views are ".zul" files.
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### -->
Up to now, I used to use template auto-parser. I like the fact I can modify any element of the template using typoscript, without altering the initial HTML file. I also like the fact that I can render the html template directly in a web browser, filling it with dummy elements to see examples of menus and content elements. Finally, with the new backend templates, i now can place content elements anywhere on a grid, in a way that mimics the real aspect of the website.
I know there is also TemplaVoila. I never took the time to learn it. My feeling is that it is less compatible with some extensions, but maybe I am wrong.
Now, there is fluid, that will be used in the next version of Typo3. While it is clear that it is better using it that using template markers, I don't really understand why I should be better using Fluid than using template auto-parser or TemplaVoila. What I dislike is the fact it requires to modify the html template with special tags, meaning that either the web designer has to know Fluid, or the Typo3 integrator has to modify templates from the designer each time a modification is performed.
My question is: should I migrate form template auto-parser to Fluid for my website template? What are the benefits of using Fluid? Why should it be better? What template system should I use with Typo3?
As long as TypoScript does not support objects, the benefits of FLUIDTEMPLATE over template auto-parser are only a few. So there is no need to migrate.
But IMHO there are some arguments to switch to fluid:
more and more extensions will use fluid, so it will help you to learn fluid
you can use an ide with code-completion for fluid (it is just XML!)
fluid is really powerfull, you can have f.e. if statements which checks for empty content
some day TypoScript will support objects as well
But for extension developement, it is totally different. In an Extension, i would allways prefere using FLUID. You do not have to deal with template things inside your extension anymore. Just pass the data to fluid and things which concern the view will be done in your template.
Whever you choose, it should be something based on Fluid - this will allow you to be extremely versatile and it makes the implementation less important than the template, which is quite good.
I myself am the creator of the "Fluid Powered TYPO3" framework (formerly known as FED) and would of course recommend that you take a look at what this framework can do for you - it's capable of great things, not the least of which is saving you a lot of time while at the same time allowing you to create even more consistent templating for pages and content - and even backend modules.
And we're always happy to help new users. We are currently in the process of improving our documentation, but you can already find many fully up-to-date guides on our Github page - https://github.com/FluidTYPO3 - the repository called "documentation" is the place we will store all the documentation.
You may want to have a look at http://fedext.net http://fluidtypo3.org - especially the "Tour of features" which tries to explain the point of Fluid Powered TYPO3 in as few words as possible. After that, the examples from the documentation will give you a much clearer picture of what Fluid Powered TYPO3 can do for you.
We focus on efficiency always - we've tried to do all the heavy lifting so that you really can just sit down and begin creating page templates. We took a lot of inspiration from TemplaVoila but there is no more re-mapping of content and things like this: when you change your templates, that change is immediately reflected, which makes it very nice to work with in iterations and do things like continuous delivery and -integration.
Hopefully this helps!
Cheers,
Claus aka. NamelessCoder
You could also argue, that adding special tags like
<f:section name="typo-content">
<div id="content">This is where the designer intended content to go</<div>
</f:section>
Could assist your designer while doing a redesign to know where you "mapped" your content elements to. This is neither the case with autoparser nor with TemplaVoila. So if the designer moves stuff around you probably get your templates back and they still work without any modifications.