How to add custom layout to page fragment in Liferay 7.3 - liferay-7

I have followed this tutorial https://help.liferay.com/hc/en-us/articles/360018167031-Creating-Layout-Templates to create custom layout for Liferay 7.3. After deploy the layout to the Liferay manually using app manager, I'm not able to find the custom layout in Fragment and Widget option.
When I check in Global Menu > Control Menu > Components > Layout Templates. I'm able to see my custom layout.
Did I missed anything or is there any other way to add custom layout to Fragment and Widget options?
Thanks

You missed one crucial info: "Layout Templates" are only applicable to pages of the type "Widget Page" (the default and pretty much only page layouting method in Liferay 6 and earlier). "Page Fragments", on the other hand, are only applicable to pages of type "Content Page" (which came up somewhere between 7.0 and 7.3). You set the type of a page at the moment you create them, by selecting one of the corresponding page templates.
So, if you want to create a certain row/column layout as a template for your "Content Page", you may want to look into the page fragment type "section". Basically, you'll be creating a Page Fragment that incorporates some <lfr-drop-zone id="invent-your-own-id"></lfr-drop-zone> tags in its HTML. Documentation on dropzones is very sparse at the moment (best source I found is Liferay's issue tracker plus experimenting yourself), but as this tag currently does not allow more attributes than id, you can simply experiment with it.
(Side notes: Due to some arcana in some standard documents, you cannot use the self-closing form of the <lfr-...> tags, so <lfr-drop-zone id="abc" /> will fail silently. Also, remember that the HTML part of a page fragment actually will be interpreted as an FTL template using Freemarkers alternative syntax before the <lfr-...> tags are interpreted., which gives you the option of placing a configurable amount of dropzones using a loop.)
But: take a moment to check whether you really need a custom "dropzone layout", as Liferay already provides you with a configurable "row section" in the content page editor; and anything more complex will give you headaches when making it responsive.

We are going through this exact same situation. Up until 7.1, we used Layout Templates on Widget Pages to enforce a consistent design over our Org's Intranet, while still having per-Department Authors (see Herding Cats).
New requirements, including the Users overall desire to have more control over page layout and simplified editing, as well as personalization (using Segments), are forcing us to implement the features of Widget Pages (and Layout Templates) in Content Pages. So far, Page Fragment Sections (as #orithena suggested) are giving us a path forward.
Now, we're developing for 7.2. 7.3 seems to be taking this concept even further, with the afformentioned drop zones, nested row layouts, and Master Pages.

Related

What is the relation between extensions and the backend of TYPO3?

I am new to TYPO3 and have trouble understanding the general relation between extensions and the backend of TYPO3.
For example, is it true that the goal of making an extension is to be able add edited/new content elements to your page that cannot be found in TYPO3 out of the box?
For example if I wanted to add a carousel to my page, would I make an extension and design it in such a way that I can add it from my backend to the desired page? Or would it make more sense to, for example, put it as a partial and import it to the desired page using fluid (all of this without using the backend and just using code).
Or are both approaches possible and when would you go for the first or the second (or seek out a third approach)?
Sorry if this question is too general/vague. I feel like I do not understand how the backend and the files in my TYPO3 folder communicate to generate the website and that I am using content elements in the backend one time and typing out the elements in HTML the next time without a good reason for it.
I try to bring some light into the dark areas.
Backend This is the admin area of the CMS where in most cases the content is created by editors.
Frontend: How the website looks to a regular visitor
Extension: An extension is custom code, either your own code or by others which extend TYPO3 in one or more ways. The benefit is that you don't change the code of TYPO3 core itself and therefore it can be always updated.
An extension can be used for a lot of things:
- Shipping a site template with all the assets like CSS, JavaScript, HTML template, ..
- Providing custom content elements
- Providing new record types like news or forms
- Improve user experience
So yes, if you want to have a new kind of content elements you need to use an extension:
Search on https://extensions.typo3.org to check if there is already something which fits your needs
Use https://extensions.typo3.org/extension/mask/ (best in combination with https://extensions.typo3.org/extension/mask_export/) or https://extensions.typo3.org/extension/dce/ to make it a lot faster to create content elements
If experienced you can also create a custom content elements without any additional extension but for start I don't recommend that.
One approach to look at this question in a different way might be to differentiate between content created and maintained by editors (the backend users which typically add and maintain content) and parts of the visible webpages created in other ways. For example, the header, footer, menu of a site may be created by a sitepackage extension - this is something the editor (backend user without admin access) typically has no permission to access and that is one of the points of a CMS - the content is editable by someone without technical background. Of course this improves the stability as well because you don't have people fiddling around with things they should not be able to have access to and thus cannot break.
If you want your editors to be able to add (remove, change) content - do it in a way they have access to (typically using content elements).
You are right, the core provides content elements (such as "textmedia"), extensions can extend this by adding other content elements.
For your example with "carousel" you might want to look at the (official) Introduction Package which uses the bootstrap_package which offers a carousel content element. The Installation Guide explains how to setup a TYPO3 installation with "Introduction Package" so you may already be using that.
For example, is it true that the goal of making an extension is to be able to add edited/new content elements to your page that cannot be found in TYPO3 out of the box?
That is one of many, many other possible purposes of an extension. For example, look at the extension "min". It does not provide any content element and there is no visible change for the editor. An extension is just a way to extend the TYPO3 core (while the core itself also consists of extensions).
Introduction of Extensions in TYPO3 Explained
Sitepackage Tutorial

How to change the website look and feel by changing the design location under page properties

I have a requirement where I have 2 clientlibs having different CSS files for my website. The business author should be capable of switching the website look and feel by just changing the path of the design under page properties. While I am able to achieve that requirement by changing the clientlib categories name referred in my JSP of base template of my site, can the same thing be achieved by the business author without actually performing a code level change? Basically, he should be able to select the design path present under the page properties section, and selecting a different design should change the look and feel of the website. Please let me know how this can be achieved.
Note: I have placed my clientlibs under /etc/design/proj-name/ path
The foundation page component is designed to include css link in the head if a file called static.css is present under the design. It's done through the design object.
If you have different css in the static.css file under different designs then the look and feel will change with the design. However you will be stuck with one file and cannot leverage the utility of client libs.
This adobe doc suggest's doing something like this for css and related images
<%= currentDesign.getPath() + "/static/img/icon.gif %>
Data from design dialogs is stored under the design , swapping designs to change look and feel will cause data inconsistencies too.
Why not add a selection widget to the page and use it's value to selectively include different client lib categories instead of relying on the design.

Adobe CQ - CQ5 - Limit a component to only being usable on a given page template

I am developing components for CQ5 and wish to control them so that component A is only displayed in the sidekick if the page is of template T_A, and components B and C are only visible if the page is of type template T_B, however I have so far not been able to find a set of properties to allow this.
Does anyone know of any way to achieve this functionality?
I am also able to retrieve the page template in code via the use of
currentPage.getProperties().get("cq:template", "").equals(MyTemplate) however, once I have not been able to find a way to control sidekick component visibility.
I have also attempted variation on Disabling The Components Tab, however this too has met with no success (even at the level of disabling the entire components tab).
This feature is baked into CQ5 and requires no special coding. The general way of controlling what components are visible in the side kick (specially what components are allowed for a given parsys) is controlled via a design. The remainder of my answer is based on the assumption that you have no special requirement other than controlling what components are allowed for a parsys (i.e no run time requirements).
The components (or component groups) allowed for a parsys are stored in the design of the site . You can control this behavior by editing the design dialog of the parsys.
The steps for achieving this are as follows
Go to design mode by clicking on the ruler icon at the bottom of the side kick
Click on edit button of the required parsys
Check the components required from the allowed component list
The allowed components are stored on per template basis. Since this data is stored in a design , all the pages must have the same design. The design must be exported too, for this to work across instances [ref : https://stackoverflow.com/questions/17049259/limiting-allowed-components-in-a-template-in-cq5
]

Creating a responsive design using CQ5 templates

I'm investigating Adobe CQ5 and would like any advice on how to integrate its drag-and-drop UI to create a responsive website. It seems as if it works on a concept of fairly bland templates with components that can be dropped in pretty much anywhere, including things like "three-column control" - which would make designing a responsive grid structure very hard (as it would be hard to prevent users from dropping in a control that could ruin the layout).
Does anyone have any experience or advice on this? I'm really looking for deep technical details on the structure of templates vs components (paragraphs), and where/how to manage to the CSS.
CQ5 offers ways to control what can be done within a template, so thinking that components "can be dropped in pretty much anywhere" may be misleading. Page templates are designed and configured so that you control which components can be added to a certain area of a page. This allows you to only make those components available that will work with the template layout, excluding components that would wreck the layout. Then authors are only allowed to use things that will work. If they attempt to drag a component onto a paragraph (parsys) where that component has not been configured as available, the UI will not allow them to use it there. So CQ actually makes it easy to prevent users from dropping a control somewhere that would ruin the layout.
This is outlined a bit here:
http://dev.day.com/docs/en/cq/current/howto/components_develop.html#Adding%20a%20new%20component%20to%20the%20paragraph%20system%20%28design%20%20%20%20%20mode%29 which states that
"The components can be activated (or deactivated) to determine which
are offered to the author when editing a page."
When it comes to CSS and JavaScript, you can create a client library and then include the relevant client library on the page. Backend CQ functionality will take care of combining multiple CSS (or JavaScript) files into a single minified file to allow for a single HTTP request of an optimized file. This it outlined a bit here:
http://dev.day.com/docs/en/cq/current/developing/widgets.html#Including%20the%20Client-Sided%20Code%20in%20a%20Page as well as
http://dev.day.com/docs/en/cq/current/howto/taglib.html#%3Ccq:includeClientLib%3E
So you might develop several components that share a client library, then when any of the components is added to a paragraph the client library will be included on the page. You may also want a CSS library that applies to all the templates to give a common look and feel, yet allow components to add their own when they are used.
These guidelines for using templates and components outline how you provide control, yet flexibility:
http://dev.day.com/docs/en/cq/5-5/developing/developing_guidelines_bestpractices.html#Guidelines%20for%20Using%20Templates%20and%20Components
I'll document our successful WIP experience with RWD and CQ5
Assumptions:
A well documented style guide.
Our First Steps:
Modified existing column control component css to utilize twitter bootstrap grid css.
Create a base page property allowing two different classes on the grid container to be set and inherited by child pages. (container||container-fluid).
Leverage out-of-the-box components where ever possible.
All component widths inherit the width of their parent container allowing for components to be dropped into any location within a template.
Issues:
The out-of-the-box column control component can not be nested.
We are looking into building a custom column control component.
Takeaways: this is an evolutionary project and we are constantly iterating.
With the recent launch of AEM 6.0, they have an example website called as Geomatrixx Media. This website is responsive.
You can take this example as reference and start building on top of it.

Teamsite component or template

I was wondering if page templates can be built instead of individual components in Teamsite 7? I've seen other cMS systems where it is just a page template that has lots of functionality built I and you can "switch" on and off elements that you want to display instead of having to drag components onto a page? Is this possible?
Old question, but since I just came across it:
Yes, TeamSite supports templates (.template) files which can be partial or full page templates. The default location is iwadmin/main/livesite/template.
I recommend downloading the developer guides from Autonomy's web site for detailed information.
Templates in teamsite/livesite is like a bag that can contain components. But in order for a functionality to be developed in teamsite/livesite we need to create components. certainly we can avoid dragging and dropping components in each page by creating templates and dropping components within it for once. Keep in mind templates are bound to layouts. for each type of layout we need to create a template. Please have a look at TS_7.3_SiteDeveloper_rev1, Chapter 5.
Yes, you can create templates instead of dragging components.
Since, TeamSite supports templates (.template) files which can be partial or full page templates and resides at location : iwadmin/main/livesite/template.
So, whenever you try to create a new page everytime the HTML code required for that page gets automatically added with the template and layouts you selected.
But, again this is not good since you can have any number of templates you need but this could create confusions at times when you try to create a new page since you will need to remember every template name and contents that you will need for a particular page so it's better to have small lists of templates and layouts since then we can say that there is reusability in our application/website which we are going to develop using Teamsite and Livesite.
Please vote the solution if its helpful.
Thanks!