I have done the below steps to layout.html of my custom theme.
the default layout is :
<parameter name="com.ibm.portal.layout.template.href" type="string" update="set"><![CDATA[dav:fs-type1/themes/customTheme/layout-templates/2ColumnEqual/]]></parameter>
Then i from webDav I tried to edited that particular layout.html file. I just added a class ass follow:
<div class="component-container wpthemeCol wpthemePrimaryContainer ibmDndColumn wpthemeLeft wpthemeCol6of12 wpthemeMedium lhs" name="ibmMainContainer"></div>
<div class="component-container wpthemeCol wpthemeSecondaryContainer ibmDndColumn wpthemeLeft wpthemeCol6of12 wpthemeMedium rhs" name="right"></div>
lhs & rhs are my css class which are present in theme.
Now I wont see the change when i refresh page and cross checked with firebug too.
What is see is:
<div class="component-container wpthemeCol wpthemePrimaryContainer ibmDndColumn wpthemeLeft wpthemeCol6of12 wpthemeMedium" name="ibmMainContainer"></div>
<div class="component-container wpthemeCol wpthemeSecondaryContainer ibmDndColumn wpthemeLeft wpthemeCol6of12 wpthemeMedium" name="right"></div>
I even restarted the server. Some one please point out what is wrong.
Thanks & Regards
Adeeb
I would have expected the server restart to clear any cached layout data. Just to make sure though, try running the refresh-page-layout task from the ConfigEngine.
same issue both with Portal 8 and Portal 8.5 .
Even if I restart server, Portal doesn't feel the changing of any layout.html file.
The only way I've found to force Portal to feel the changing is to manually re-assign the layout (assign a different layout, than assign back the correct layout) to each page I need with that layout.
I believe there should be another way (it would be absurd if it were forced to do so for big amount of pages), but I didn't find any solution at the moment.
Hope it can help you
Related
I need to create a footer in a Liferay-project, that can be modified from the instance. I've been trying various things in my footer-code and instance, but haven't figured out how to do it.
Any content inside the footer can't be touched and in page edit mode, Liferay says "This area is defined by the theme. You can change the theme settings by clicking more in the Page Design Options panel on the sidebar". I didn't get any help from Page Design Options either. Is there a way to do this?
I found the answer after hours of work and searching and want to share it with everyone here. The working solution was found here, in one of the comments.
You need to write some code (I use Freemarker/ftl) and then configure the site pages a bit, but here's how it works:
Put a new setting inside liferay-look-and-feel.xml:
<settings>
<setting key="footer-article-id" value="" configurable="true" type="text"/>
</settings>
This will create a new configurable option in page options, allowing you to input the ID of the web content.
NOTE: <theme> might get underlined red "The content of element type "theme" must match". This still prints everything correctly, but the tags are given in a wrong order. Inside my <theme>, I have <template-extension>, <settings> and <portlet-decorator> in that order, which removes the error.
Assign a variable in init_custom.ftl (cleans up the footer-code):
<#assign footer_article_id = getterUtil.getString(themeDisplay.getThemeSetting("footer-article-id"))/>
And then add this to the footer-code, to create the spot, where the content is visible:
<#liferay_journal["journal-article"]
articleId=footer_article_id
groupId=page_group.groupId
/>
After this, everything should be ready code-wise.
Create a Web Content for your footer. In the creation screen, there's an ID on the panel on the right. Publish your content and grab the ID.
Finally, go to Site Builder --> Pages and click on configuration from the top bar (behind three dots). You should see the input field like in the first picture: That's where you add the ID.
Save the settings and your web content should now be in the footer.
Hope this helps!
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#%}") %>
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.
Please, someone tell me if there is a replacement for the rubbish Solpart menu, the menu with the small arrow to administer a module in DotNetNuke?
I have been using DNN for some time now and I would love to know if there is not a better way to get this menu working. I cannot believe DNN would let something as buggy as that out!
Thanks
You can use any menu for that drop down. You'd just swap out the solpartmenu for the one you want in the container you create. Here is a blog post outlining some of the menu options available. I'd suggest taking a look into each one of these and see which would be a good fit for you.
New Navigation Options in DotNetNuke 5.x Designers Should Know
Below is one (slightly updated) example from How to use RadMenu instead of the default solpartactions menu
Open an existing container for edit (a Default DNN container will work fine).
Register the RADMENUACTIONS tag by adding the following line of code: <%# Register TagPrefix="dnn" TagName="RADMENUACTIONS" Src="~/DesktopModules/RadMenu/RadMenuActions.ascx" %>
Replace <dnn:ACTIONS ... /> with <dnn:RADMENUACTIONS ... />
Set additional properties for RadMenu if desired. For example you can set the Skin property: <dnn:RADMENUACTIONS runat="server" id="dnnRADMENUACTIONS" Skin="CssGreen" />
I'm creating some pages using a SiteDefinition, the markup looks something like this:
<File Url="Page.aspx" Name="$Resources:SiteDefinitions,PageName;" Type="GhostableInLibrary">
<Property Name="Title" Value="$Resources:SiteDefinitions,PageTitle;" />
<Property Name="PublishingPageLayout" Value="~SiteCollection/_catalogs/masterpage/Somepage.aspx"></Property>
<AllUsersWebPart WebPartZoneID="WebPartZone1" WebPartOrder="1">
-- webpart data here
</AllUsersWebPart>
</File>
The page is created as expected, but it's somewhat faulty. If for instance I click Edit Page and then click Publish (without actually editing anything) I will get this error:
"This Page has been modified since you opened it. You must open the page again."
I will get this error approx. every second time I try an editing action.
If I manually create a page using the same page layout everything works as expected and this error does not show up.
Does anybody have an idea what could be wrong?
I too create a Page using the above method only thing I found missing in your code is that I used to have a title in the PageLayout as
<Property Name="PublishingPageLayout" Value="~SiteCollection/_catalogs/masterpage/Somepage.aspx, Your title"></Property>
This should not be the cause, but you can try it, Also refer the articles this or this
I think you're right with using PublishingLayoutPage. I came across this article today while searching for this error caused by something else. It describes your same issue although the person in the article was not inheriting from PublishingLayoutPage and had not specified the PublishingPageLayout property. When they fixed this it worked.
This doesn't directly help you, although I did notice in their article that they are specifying the ContentType property. Have you tried specifying this? As you can see your complete code, are there any other differences you see from the article or additional information from the comments?
Okay, I (kinda) got this working now.
The guy who had made the ONET.xml had put a reference to the page layout in the Url attribute of the element.
Like I wrote in a comment earlier I tried making the page layouts inherit from TemplateRedirectionPage. Instead I now made an empty default.aspx file that inherits from TemplateRedirectionPage and changed all my page layout files back to deriving from the PublishingLayoutPage. And then I added the PublishingPageLayout element below every element.
Funny, or oddly, having a refence to the page layout in the Url attribute and not having the PublishingPageLayout element at all is actually valid. It doesn't make sense, because it will produce these faulty pages, but SharePoint actually accepts it and spits out all the pages defined in the ONET.xml
Only thing left now is that since I made the above changes, when I manually create a new page based on a page layout every default webpart (as defined with AllUsersWebPart) is instantiated 5 times. Really don't know where this behaviour is coming from, but at least it's not as serious as not being able to edit/publish my pages :)