A good article on implementing friendly URLs in IBM WebSphere Portal 8-based WCM rendering
Let's discuss and capture real time use cases and problems in WebSphere Portal world
Showing posts with label Customization. Show all posts
Showing posts with label Customization. Show all posts
Implementing friendly URLs in IBM WebSphere Portal 8-based WCM rendering
Retrieving the rendering context within a WCM .jsp component
1. For the preview to work, place the code in the following directory:
\ibm\WebSphere1\profiles\wp_profile\installedApps\<cellName>\wcm.ear\ilwwcm.war\jsp\html>
2. Access via a .jsp component configured with the following path: /jsp/html/render.jsp.
\ibm\WebSphere1\profiles\wp_profile\installedApps\<cellName>\wcm.ear\ilwwcm.war\jsp\html>
2. Access via a .jsp component configured with the following path: /jsp/html/render.jsp.
- Note that this .jsp will not work if accessed directly using a URL in a browser such as xxxx/wps/wcm/jsp/html/render.jsp. The .jsp must be accessed via Preview or a rendering portlet.
If you are accessing the content via the Web Content Viewer local rendering portlet, you must also place the .jsp in the war/jsp/html directory for the local rendering portlet. Here is a sample location:
\websphere\PortalServer\installedApps\WCM_Local_ng_Portlet_zkj5916.ear\zkj5916.war\jsp\html\
- If you use the Remote Rendering Portlet, you must place it there as well.
- <%@ taglib uri="/WEB-INF/tld/wcm.tld" prefix="wcm" %>
<%@ page language="java" contentType="text/html; charset=ISO-8859-1" %>
<%@ page import="com.ibm.workplace.wcm.api.*" %>
<wcm:initworkspace user="<%= (java.security.Principal)request.getUserPrincipal()%>">Cannot get Workspace</wcm:initworkspace>
<%
RenderingContext currentRenderingContext = (RenderingContext) pageContext.getRequest().getAttribute(Workspace.WCM_RENDERINGCONTEXT_KEY);
out.println("APP PATH: " +currentRenderingContext.getWcmWebAppPath() + "<br>");
out.println("Servlet PATH: " +currentRenderingContext.getWcmServletPath() + "<br>");
out.println("Rendering Context " +currentRenderingContext.getPath());
%>
<%--
Note: if the rendering context is returning %2F instead of "/", you may want to use the string replaceAll method to modify. For example:
String myContext = currentRenderingContext.getPath() ;
String myModifiedContext = myContext.replaceAll("%2F", "/");
--%>
Different ways of Handling CSS and JavaScript in WCM
We can handle CSS and JavaScript in WCM in following three different approaches.
Approach 1: Storing the CSS as Style Sheet Component and JavaScript as File Resource Components
Note: You can upload the JavaScript file into WCM as the File Resource Component and refer that in presentation template as below
<script language="javascript" src="<Component name="library/test-javascript-cmpnt" format="url"/>" />
Pros:
1. Out of box component
Cons:
1. Authors can't modify the CSS in the authoring interface when they have to make changes.
2. You can not refer the File Resource components(like images) stored in WCM like below
table{
background-image: url(<Component name="bckImage" format="url"/>);
}
3. Need to place CSS and JavaScript on somewhere for future changes(outside of WCM).
Approach 2: Storing CSS and Javascript as HTML Components
Store CSS styles as HTML components and then embedded those components in presentation templates inside of <style> blocks. (Same for the javascript also)
Pros:
1.Authors can modify CSS classes inside the WCM authoring.
2.Additional request to load the CSS files is not required (fewer HTTP requests generates from page)
Cons:
1. Here CSS files are rendering from WCM, Can't take the advantage of browser caching
2. Response size and time may increase as Styles are coming from the JCR.
Approach 3: Storing CSS and Javascript as Content Item under some SiteArea
Steps to implementing CSS as a content item -
a). Create a authoring template with a single Body HTML element,
b). Create a presentation template that just refer Body element (you may not use Ephox RTE element because it includes <P> tags , causing CSS Styles failed )
c). Name ContentItem as *.css ("test.css").
d). You can add the above contentItem from other presentation templates as CSS or Javascript . Make sure to append "?subtype=css" to path of content item while referring in other Presentation templates to force WCM content to be rendered with text/css as MIME type instead of text/html (default MIME type for WCM content is text/html or text/plain).
Ex: <link rel="StyleSheet" href="/wps/wcm/myconnect/library/Site/SiteArea/test.css?subtype=css" type="text/css"/>
Following are the advantages if you naming the ContentItem as *.css
a) When site is pre rendered for delivering content, content items stored as *.css will generate files valid CSS file to pre render
b) Even when content served through the WCM servlet , this allows the browser to cache the CSS file
Pros:
1.Authors can modify CSS classes inside the WCM authoring portlet with normal workflow process
2.Additional request to load the CSS files is not required (fewer HTTP requests generates from page)
Cons
1. Make sure this content item (css) doesn't pick up by some navigators or menu components as it is content item
Note:
a). In Second and Third approach approach , your CSS styles or javascript can refer File Resource Components(like for background images) that stored in WCM repository as components by simply using the Component Tag as below
body{
background-image: url(<Component name="bckImage" format="url"/>);
}
b). "subtype" query string parameter only applies to the default content renderer and will not work on URLs which is used to invoke the component renderer (i.e. which contain srv=cmpnt in the query string parameter).
c). You may need to add an extension mapping for CSS to WcmConfigService.properties in older versions. Following are steps to do this.
Approach 1: Storing the CSS as Style Sheet Component and JavaScript as File Resource Components
Note: You can upload the JavaScript file into WCM as the File Resource Component and refer that in presentation template as below
<script language="javascript" src="<Component name="library/test-javascript-cmpnt" format="url"/>" />
Pros:
1. Out of box component
Cons:
1. Authors can't modify the CSS in the authoring interface when they have to make changes.
2. You can not refer the File Resource components(like images) stored in WCM like below
table{
background-image: url(<Component name="bckImage" format="url"/>);
}
3. Need to place CSS and JavaScript on somewhere for future changes(outside of WCM).
Approach 2: Storing CSS and Javascript as HTML Components
Store CSS styles as HTML components and then embedded those components in presentation templates inside of <style> blocks. (Same for the javascript also)
Pros:
1.Authors can modify CSS classes inside the WCM authoring.
2.Additional request to load the CSS files is not required (fewer HTTP requests generates from page)
Cons:
1. Here CSS files are rendering from WCM, Can't take the advantage of browser caching
2. Response size and time may increase as Styles are coming from the JCR.
Approach 3: Storing CSS and Javascript as Content Item under some SiteArea
Steps to implementing CSS as a content item -
a). Create a authoring template with a single Body HTML element,
b). Create a presentation template that just refer Body element (you may not use Ephox RTE element because it includes <P> tags , causing CSS Styles failed )
c). Name ContentItem as *.css ("test.css").
d). You can add the above contentItem from other presentation templates as CSS or Javascript . Make sure to append "?subtype=css" to path of content item while referring in other Presentation templates to force WCM content to be rendered with text/css as MIME type instead of text/html (default MIME type for WCM content is text/html or text/plain).
Ex: <link rel="StyleSheet" href="/wps/wcm/myconnect/library/Site/SiteArea/test.css?subtype=css" type="text/css"/>
Following are the advantages if you naming the ContentItem as *.css
a) When site is pre rendered for delivering content, content items stored as *.css will generate files valid CSS file to pre render
b) Even when content served through the WCM servlet , this allows the browser to cache the CSS file
Pros:
1.Authors can modify CSS classes inside the WCM authoring portlet with normal workflow process
2.Additional request to load the CSS files is not required (fewer HTTP requests generates from page)
Cons
1. Make sure this content item (css) doesn't pick up by some navigators or menu components as it is content item
Note:
a). In Second and Third approach approach , your CSS styles or javascript can refer File Resource Components(like for background images) that stored in WCM repository as components by simply using the Component Tag as below
body{
background-image: url(<Component name="bckImage" format="url"/>);
}
b). "subtype" query string parameter only applies to the default content renderer and will not work on URLs which is used to invoke the component renderer (i.e. which contain srv=cmpnt in the query string parameter).
c). You may need to add an extension mapping for CSS to WcmConfigService.properties in older versions. Following are steps to do this.
- Search for the line "#mapping of mimetypes to extensions" in wcmconfigservices.properties file located under <Portal_root>\wcm\shared\app\config\wcmservices\ directory.
- There is an attribute named "mimetype.list=extensiontype.gif". Add ",extensiontype.css" (no spaces, include the dot ( . ) character at the front of the string) at the end of the line.
- Add a new line "extensiontype.css=text/css" (no spaces) after the "extensiontype.lzh=application/octet-stream"
- Save the file.
- Restart WebSphere Portal Server (WPS).
Rendering WCM Library components in non rendering portlets
// Get the workspaceWorkspace workspace = Repository.getWorkspace("admin user id", "admin user id Password");// set current working library
workspace.setCurrentDocumentLibrary(workspace.getDocumentLibrary("name of the library where you have your components"));
// retrieve library component
DocumentIdIterator docIds=workspace.findByName(DocumentTypes.LibraryComponent,"component name");
if (docIds.hasNext()){
DocumentId did = (DocumentId)docIds.next();
LibraryComponent libComp = (LibraryComponent)workspace.getById(did);
if (docIds.hasNext()){
DocumentId did = (DocumentId)docIds.next();
LibraryComponent libComp = (LibraryComponent)workspace.getById(did);
// Create the rendering contextRenderingContext context = workspace.createRenderingContext(portletRequest, portletResponse, new HashMap(), "connect");
// Set the path to the content to be renderedcontext.setRenderedContent("/Library1/SiteA/SiteArea1/SiteArea1-1/myContent(refer some default content)");// Get the rendered stringString renderedContent = workspace.render(context,libComp );How to modify the text which is displayed in the banner of your Portal page?
The text that is displayed in the banner of the portal page is defined in the file calledengine.properties. This file is is located in the JAR file named wp.ui.jar in the directory,
For multilingual sites, the file can have a language suffix corresponding to the locale, for example,engine_es.properties for Spanish etc. If Portal cannot determine the client locale, the banner text is defined in engine.properties. Follow the below steps to change the banner text for each language that is supported by your portal site.
1. Extract the file engine.properties to the /PortalServer_root/ui/wp.ui/shared/app/nls directory.
2. Edit the file engine.properties and change the title parameter to the name that you want to be displayed in the portal banner.
3. Save and close engine.properties.
4. Restart the server to view the changes.
/PortalServer_root/ui/wp.ui/shared/app
For multilingual sites, the file can have a language suffix corresponding to the locale, for example,engine_es.properties for Spanish etc. If Portal cannot determine the client locale, the banner text is defined in engine.properties. Follow the below steps to change the banner text for each language that is supported by your portal site.
1. Extract the file engine.properties to the /PortalServer_root/ui/wp.ui/shared/app/nls directory.
2. Edit the file engine.properties and change the title parameter to the name that you want to be displayed in the portal banner.
3. Save and close engine.properties.
4. Restart the server to view the changes.
How to enable and disable versioning of diferrent artifacts in WCM?
Here is a quick tip to enable / disable the versioning of different artifacts used in WCM.
Search WCMConfigService.properties for "versioningStrategy". You can set the below properties to always (enable) or never (disable)
Search WCMConfigService.properties for "versioningStrategy". You can set the below properties to always (enable) or never (disable)
# enable version control for the following types.
# options are always | never
versioningStrategy.AuthoringTemplate = always
versioningStrategy.Component = always
versioningStrategy.Content = always
versioningStrategy.PresentationTemplate = always
versioningStrategy.Site = always
versioningStrategy.Taxonomy = always
versioningStrategy.Workflow = always
How to Enable and Disable Managed pages feature in WebSpshere Portal Server 8.0?
By default, managed pages is enabled in WebSphere Portal Server 8.0. In order to disable the managed pages, one can use the following config engine task.
Note: Do not attempt to enable managed pages on a server where managed pages are already enabled. If you previously disabled managed pages and want to re-enable the feature, you must ensure that the "Portal Site" library is empty first. If you fail to remove page artifacts from the previous configuration, the resulting portal might not work properly.
Disabling managed pages has the following effects:
By default, each virtual portal has its own specific workspace where content is stored. When you disable managed pages, only a single workspace for the default virtual portal is available. The workspaces of other virtual portals are still there, but you can no longer access them. Any system associations between pages in those virtual portals and their respective Portal Site libraries also no longer work.
Note: To preserve content in the other virtual portals, you must import or syndicate the libraries into the default virtual portal before disabling managed pages.
You can still access the Portal Site library for the default virtual portal, but the library is no longer automatically synchronized with the page structure.
Pages are no longer managed in IBM Web Content Manager, with the following implications:
ConfigEngine.bat disable-managed-pages -DPortalAdminPwd=wpsadmin -DWasPassword=wasadmin
Note: Do not attempt to enable managed pages on a server where managed pages are already enabled. If you previously disabled managed pages and want to re-enable the feature, you must ensure that the "Portal Site" library is empty first. If you fail to remove page artifacts from the previous configuration, the resulting portal might not work properly.
Disabling managed pages has the following effects:
By default, each virtual portal has its own specific workspace where content is stored. When you disable managed pages, only a single workspace for the default virtual portal is available. The workspaces of other virtual portals are still there, but you can no longer access them. Any system associations between pages in those virtual portals and their respective Portal Site libraries also no longer work.
Note: To preserve content in the other virtual portals, you must import or syndicate the libraries into the default virtual portal before disabling managed pages.
You can still access the Portal Site library for the default virtual portal, but the library is no longer automatically synchronized with the page structure.
Pages are no longer managed in IBM Web Content Manager, with the following implications:
- No page drafts can be created.
- No new versions of pages can be created.
- Pages are no longer syndicated.
- Access control changes that you perform in the portal interface are no longer applied to the portal page site area.
- If you delete a page from the portal interface, the corresponding portal page site area is not deleted.
Try to delete the content in "Portal Site" library and then ran the following commands
ConfigEngine.bat enable-managed-pages -DPortalAdminPwd=wpsadmin -DWasPassword=wpsadmin
ConfigEngine.bat create-page-nodes -DPortalAdminPwd=wpsadmin -DWasPassword=wpsadmin
It will create lost-found and Content Root folders under Portal Site library as shown below.
Labels:
Administration,
Customization,
Managed Pages,
WCM,
WP 8
Subscribe to:
Posts (Atom)
