im building a new side with movable type. And i want to remove the sidebar for a few pages, but not for all the pages.
Any idea?
Thanks.
In the archive template -> page
<mt:Var name="hide_sidebar" value="1">
Thanks
More in depth answer....
This code sets the variable hide_sidebar to 1:
<mt:Var name="hide_sidebar" value="1">
The sidebar in the classic blog template set is wrapped in the following conditional code which will have no output if hide_sidebar is set to 1:
<mt:Unless name="hide_sidebar">
<!-- sidebar code here -->
</mt:Unless>
This solution can be manually added to any template set, but this code can be found in the Classic Blog template set that ships with MT 4.x.
More about the MT If conditional and which is related to the unless conditional
(I can't link to any other resources as I need more reputation points.)
Related
I have a page template that has this line of code below:
<div id="<%= CurrentDocument.NodeAlias %>" class="lvl3">
Things work - the id value shows correctly. However, when using the Page Templates module Design tab, there's an error. In Event log, I saw the error message "Object reference not set to an instance of an object". Taking the id snippet out, the error is gone. I'm not sure what the error means and how to fix it. Could you help?
I do need some page-specific unique identifier in there (NodeAlias in this case) for other purposes.
The answer is pretty simple - if you open your page template in Kentico Page Templates application - your CurrentDocument is always null (because you are editing Template itself without specific document).
You could do absolutely the same thing in Pages application with the Design tab. It's also possible to edit all the template properties from there, including the Layout:
Using code blocks on page template layout is not supported. I assume you are using ASCX layout. Moreover your code looks more like a macro - so, maybe you are using HTML layout type? If yes, then the syntax should be {%CurrentDocument.NodeAlias%}
If you are using ASCX layout you may face also this issue: https://devnet.kentico.com/articles/the-controls-collection-cannot-be-modified-because-the-control-contains-code-blocks
Note that in portal engine the life cycle is bit modified, so we cannot ensure the code blocks will work every time - it may work sometimes. It mainly depends on what other web parts/controls and in what order are placed in the page template. I would rather recommend using the workaround from the article.
Or, you can give it a try, with no guarantee, this may work in certain cases, you need to specify the full namespace:
<%= CMS.MacroEngine.MacroResolver.Resolve("{%CurrentDocument.NodeAlias#%}") %>
I really hope I'm making sense with this one.
I'm trying to create a widget from a custom webpart that I created. It's nothing special at all as you can see:
<h3>Header</h3>
<p>Intro Copy</p>
<ul>
<li>List item one</li>
<li>List item two</li>
<li>List item three</li>
</ul>
I now want to be able to create a widget from this and create new fields that will be used to populate the above DOM. What do I need to do in order or do this.
In an example I saw for the demo site, they populated the bg image with:
style="background-image: url('{% ResolveUrl(PathToImage) %}');"
That was however done on the front facing part of the CMS and I'm trying to do it within the solution.
Any thoughts?
It's all in your layout or code behind. Your layout can have that code (but in ASCX format) and it will work just fine. OR you can add literal controls to the page based on the fields and what the user has entered.
Doing it in your layout is more restrictive and specific to that one application but allows you to use multiple new webpart layouts. Using the code approach allows you to be more dynamic but doesn't allow you to use the built-in layouts of the webpart/widget.
I would just use the Transformable Web Part in the Marketplace...it does exactly what you want it to do. Create a custom web part, and you use a Transformation to style the Web Part Properties into the DOM elements.
https://devnet.kentico.com/marketplace/web-parts/transformable-web-part
Reason why i built it!
I've done something similar in the past, using what I call generic web parts. I wrote a blog on it last year - it might help out with what I think you're trying to achieve:
http://www.mattnield.co.uk/Posts/Show/generic_web_parts_for_rapid_development
Why are you choosing to go with Widgets? If you want to access any field inside the transformation within the web part it's feasible by the same way as you define in inbuilt web parts.
If you want to perform any function like onload etc. then you need to use kentico API to access any data.
If you provide more insight on what is required, I can help further
I am using AEM 6.2 and trying to create a parsys component in crx, using the code below
However, the height of this parsys, in edit mode, comes as 0px.
Attached are the screenshots.
When I manually change the height to some values eg. 40px, it looks fine.
Note: I am not using any client library for the above page. (no css and js)
Futher, All sample sites like geomatrix etc have parsys showing correctly.
Could anyone guide me with what I am doing wrong?
I think that the problem is outside the component or any of the code shown here.
I think what's happening is that the css style for the div that gives the droptarget placeholder its dimensions is not loading.
That's loaded as part of the AEM authoring client libraries which you should be inheriting from the foundation page component.
Examine your page component's sling:resourceSuperType property. It should point to either wcm/foundation/components/page or wcm/foundation/components/page or inherit from a component that does.
If that is set then you have may have blocked one of the scripts within it, quite possibly head.html.
Include following code in the head section of the page component's rendering script.
<!--/* Include Adobe Dynamic Tag Management libraries for the header
<sly data-sly-include="/libs/cq/cloudserviceconfigs/components/servicelibs/servicelibs.jsp" data-sly-unwrap/>
*/-->
<!--/* Initializes the Experience Manager authoring UI */-->
<sly data-sly-include="/libs/wcm/core/components/init/init.jsp" data-sly-unwrap/>
For resolving your issue, you need to include init.jsp in the first before writing down the parsys code. I mean write like this.
<head>
<sly data-sly-include='/libs/wcm/core/components/init/init.jsp' />
</head>
<body>
<sly data-sly-resource="${'par' #resourceType='foundation/components/parsys'}" />
</body>
I think #l-klement pointed it out correctly that the problem is outside component. When I rename the landingpage.html file to body.html it starts working fine. I think this may be because of different files like head.html etc present at wcm/foundation/components/page which is required to provide proper styling and load certain required client libraries which assigns proper styling to parsys.
If the above is true, my next question would be, How can I have my own head.html, body.html, header.html, footer.html etc files without compromising with the parsys styling?
I need to make a footer in Liferay and use theme for it. What's the simpliest way to do it?
I have created new theme, filled _diffs folder with other folders, but it's empty and I couldn't find relevant docs about this. Should I copy all basic files there? What should I change to create footer?
In Liferay, theme's portal_normal.vm serves as the template to
construct HTML structure of the page. There you define your header,
body and footer includes.
When you will look at the portal_normal.vm of classic theme, you will observe following HTML snippet:
<footer id="footer" role="contentinfo">
<p class="powered-by">
#language ("powered-by")
Liferay
</p>
</footer>
This is the footer of the page. This is what you need to implement. However, it's not necessary to use footer tag at all, as you can simply use div or table based structure with bootstrap or customized CSS classes for your footer, it's upto your requirement.
Remember! Classic theme is just like a sample provided by Liferay, so, it's not good idea to directly customize it.
Everybody needs a whole customized view of the site, and for this the best idea is to create a custom theme (that's what you are doing!), that will give you full control over your look-n-feel.
To kick-start, you can initially copy required folders from classic theme to your customized theme's (_diffs folder) and start changing bit by bit.
This relates to an Xpages project using openNtf's Extension Library for Domino 9.0.1 V 16 (2016-01-28). There is a custom theme applied that extends extLib's Bootstrap3 theme.
Now I also applied Mark Leusink's debugToolbar Plugin (V 4.0.1, 2014-03-10).
Unfortunately all tables that are display inside the toolbar are partially "destroyed", as in this example:
Debugging the resulting html I see that the "label" cells of the debug table are assigned class="label" or class="label wide". Unfortunately bootstrap.css applies a display: inline style to a .label selector.
Currently I solved this by applying my own custom css file to reset toolbar styling; but I wonder whether there might be a more elegant way, maybe some kind of property that I simply missed out here. Or is this something that have to be done within the toolbar's source code?
Please add this as a defect on the project, so the contributor is aware and can resolve.
Alternatively, download the source code from https://github.com/OpenNTF/DebugToolbar, contribute the fix and make a pull request.
Hopefully Paul's and my entries at github and within the openntf.org project will help resolving this issue. Meanwhile my workaround seems to be the only option here;
As I mentioned above I created a custom styleSheet with just one line in it:
div.dBar table.grid td.label{display:table-cell;}
Then I created a cusom control as a container for the debug toolbar so that I could link my custom style sheet as a resource. The debug custom control finally is added to all the xpages where I want to have the toolbar.
Maybe this can help others, too.