I'm trying to emit the current page's name within portal_normal.vm. The options I know of all include a bunch of XML garbage that it's important to be rid of.
Right now, I'm using $layout.getName(), which produces this:
<root default-locale="en_US" available-locales="en_US">
<name language-id="en_US">
Home
</name>
</root>
It's true that the page's name is "Home", but the rest of that garbage ruins it.
I've tried $layout.name as well, but it produces the same result.
How do I access the bare value?
Based on what I saw in this post (which appears to be about writing controller or servlet code), I was able to produce this code to get the bare name:
$layout.getName($themeDisplay.getLocale())
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've written a simple plugin that basically loops through a bunch of entries. The plugin is used to only display entries that contain a feature image, amongst some other minor logical conditions. The use of my tag looks something like this:
{exp:myentries:withimages channel="mychannel"}
<!-- This works fine -->
<h1>{title}</h1>
<!-- But nested exp:... tags don't seem to parse? -->
<p>{exp:ce_img:single src="feature_image"}</p>
{/exp:myentries:withimages}
I am calling
return $this->EE->TMPL->parse_variables($this->EE->TMPL->tagdata, $data);
from my custom EE plugin, the data is there, but only the nested {exp:... tags don't want to parse.
I've followed the online User Guide for creating plugins as close as I possibly could, but I need some help getting the other tags to parse? If I simply output {feature_image}, the field renders the src value for the image as expected.
Can anyone possibly shed some light on what I'm doing wrong?
You want to put parse="inward" parameter in your {exp:myentries:withimages tag, otherwise the template will try to parse the exp:ce_img call before {feature_image} is set.
{exp:myentries:withimages parse="inward" channel="mychannel"}
The parse="inward" will tell EE to run this tag first before parsing any other tags within the tag pair.
There are two important typos in your code.
{exp:ce_img:singe src="feature_image"}
Should read:
{exp:ce_img:single src="{feature_image}"}
If those differences are actually present in your template, then that would be it I believe.
Requirement:
Adding javascript file for a given page (which uses templates).
Details:
After successful login, user is navigated to a page, where he can perform different actions.
I have used common template in all the pages (apart from login page).
The template contains head tag, code for including header, footer and body (in which dynamic content will be included).
I observed that contents of head tag of the template are not getting updated (i.e. title tag, script tag).
The contents of head tag remains same as that of login page and also the URL of my browser.
Can you please let me know the possible cause for above.
It is probably related to the fact partial updates require id of a tag to be updated and html head element does not support id. There is no address in the html to apply update to. Icefaces are using partial updates heavily. You can try to enforce full update upon interaction which triggers changes to head element.
In my application we use the struts URL tag in our freemarker templates like this:
<s.url action="struts-action-name"/>
The issue is that instead of appending the action url to the root url of the application it actually appends it to the current URL.
Say we hit www.example.com/community/examples/xss187ba"><ScRiPt>alert(1)</ScRiPt>506d1768713/career_development, and in the ftl for that page we have a form like this:
<form action="<s.url action="struts-action-name"/>">
The rendered ftl would look like this:
<form action="/community/examples/xss187ba"><ScRiPt>alert(1)</ScRiPt>506d1768713/career_development">
Which causes an alert to popup... has anyone dealt with this issue? Is this a bug in Struts or are we doing something wrong here?
The obvious fix is to use the URL tag like this:
<form action="<s.url value="/struts-action-name.jspa"/>">
On the other hand a quick search shows 2500 uses of that tag in the project and refactoring all those would not be a very fun/efficient job :(
Any help, comments or suggestions would be highly appreciated.
-Andre
The url tag doesn't "append" to anything--it creates a URL relative to the application, in this case based on a configured action name. Assuming an action named "f1" and a root deployment the only thing the tag would produce is an absolute URL /f1.action (or `/f1' with no extension).
Given:
<struts>
<constant name="struts.devMode" value="true"/>
<constant name="struts.action.extension" value=",,action"/>
<package name="default" namespace="/" extends="struts-default">
<action name="f1" class="radios.RadioAction" method="input">
<result name="input" type="freemarker">/WEB-INF/radios/input.ftl</result>
</action>
...
The FreeMarker fragment:
<#s.url action="f1"/>
will output:
/f1
You may need to provide more info: are you using specific plugins (like Convention), etc?
You could extend org.apache.struts2.views.jsp.URLTag and replace the exiting or add a new tag in struts-tags.tld.
I do find it weird that it does not automatically url-encode those parts of the URL, as that's what I would expect it to do.
So I would consider this a bug. Maybe contact the Struts developers about this one. Most of their other tags do automatic encoding, so it's weird that this one doesn't.
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 :)