A short background on categories

Categories are a built-in content relation in OpenCms and allow files in the VFS to be assigned one or more topics/keywords/whatever. They can often be used as a replacement feature for siblings which are mostly misunderstood by users without a technical background. For example consider the typical example of a news site. You have a folder structure for your articles which could be the following way:

/articles/2008/12-24-merry-christmas.html
/articles/2009/09-01-new-site.html
/articles/2009/10-02-a-great-article.html

You now want to categorize the articles into topics so you would create another folder structure:

/topic/must-read
/topic/technical

The sibling-way would be to create a sibling (put simply: an automatically updating copy) of the articles in the desired topic folder. While this is a working solution it’s counterintuitive to most users. OpenCms 7 introduced the long awaited Content Relation Engine (CRE) including a default relation called categories. Similar to the sibling solution a category is effectively a folder but instead of creating it anywhere in the filesystem it’s created in the root site (“/”) under /system/categories/. Users can now assign categories to VFS files using the context-menu entry Relations -> Assign Categories. This is a much easier approach although it has one caveat: Categories are globally defined in the /system/ folder and can therefore only be created by users with access to the root site and can not be specified on a per site or even per folder basis. This can cause problems in multisite environments.

Decentralization to the rescue

With OpenCms 7.5 this limitation is finally gone. You can now define categories on a per-site and even per-folder basis. Simply create a folder named _categories in the folder where you want the categories to be available. Then create new folders inside this folder to define categories. The categories are available in the parent folder of the _categories-folder and all subfolders. They also cascade down. Example:

/de/_categories/
/de/_categories/hot-topic
/de/_categories/support
/de/news/_categories/
/de/news/_categories/marketing
/de/news/_categories/development

Inside the /de/ folder the categories hot-topic and support are available. Inside /de/news/ the categories hot-topic, support, marketing and development are available.

This feature should easily help you to get your content structured more nicely. Speaking from experience it is crucial to create an evolveable content structure upfront so your editors as well as visitors and search engines get the most out of your site.

See also:

• Presentation from Michael Moossen about the CRE at OpenCms Days 2008
• A guide to good URI design

Updating the SME in general is pretty straighforward but if the customer made modifications to the yum configuration it can quickly turn into a nightmare. Luckily there is a tutorial available in the SME Wiki which can help you to get started. Unfortunately the yum installation was completly broken so I had to update the packages by hand. I pulled the packages from the SME repository at and installed them via

export SME_MIRROR_URL="http://mirror.jvsnet.ro/sme/releases/7/smeos/i386/SME/RPMS"

wget $SME_MIRROR_URL/dialog-1.0.20040731-3.i386.rpm
wget $SME_MIRROR_URL/python-sqlite-1.1.7-1.2.1.i386.rpm
wget $SME_MIRROR_URL/yum-metadata-parser-1.0-8.el4.centos.i386.rpm
wget $SME_MIRROR_URL/e-smith-formmagick-2.0.0-1.el4.sme.noarch.rpm
wget $SME_MIRROR_URL/smeserver-yum-2.0.0-4.el4.sme.noarch.rpm
wget $SME_MIRROR_URL/yum-plugin-fastestmirror-0.2.4-3.c4.noarch.rpm
wget $SME_MIRROR_URL/e-smith-lib-2.0.0-1.el4.sme.noarch.rpm
wget $SME_MIRROR_URL/sqlite-3.3.6-2.i386.rpm
wget $SME_MIRROR_URL/yum-plugin-installonlyn-0.91-1.el4.sme.noarch.rpm
wget $SME_MIRROR_URL/perl-CGI-FormMagick-0.92-16.el4.sme.noarch.rpm
wget $SME_MIRROR_URL/yum-2.4.3-4.el4.centos.noarch.rpm

rpm -Uvh --nodeps --force *.rpm

You maybe have to adjust this mirror url. This is why I factored it out into a seperate variable.

After this you should reset your yum repositories and clean the yum cache.

cd /home/e-smith/db/
mv yum_repositories yum_repositories.po
/etc/e-smith/events/actions/initialize-default-databases
signal-event yum-modify
yum clean all

After doing so, issue the following commands to let SME rewrite it’s config.

signal-event post-upgrade; signal-event reboot

Now you can update yum through yum itself (I know this sounds strange but this second update helps to get all the GPG keys for the repositories right).

yum update yum
signal-event post-upgrade; signal-event reboot

Now you can proceed with a normal update to get the whole system up to 7.4. I had to do this following process twice because the updates seem to have pulled in some new dependencies which in turn have to get updated.

yum update yum
signal-event post-upgrade; signal-event reboot

That’s it. I’m sure there might be an easier way but at least these are the steps the helped me get the system up to date. If you have questions just leave me a comment.

Preparation

To make the approach more modular we will use an environment variable pointing to our htdocs directory. I will call this variable $HTDOCS.

export HTDOCS=/kunden/homepages/.../htdocs

We can check if everything is correct by changing into the htdocs directory.

cd $HTDOCS

We will now create two directories:

• $HTDOCS/linux-src: To hold all the data we need to compile the extensionn
• $HTDOCS/linux: To hold all the compiled data

This setup allows us to delete the linux-src directory after we finished compiling the extension and save some diskspace.

mkdir -p $HTDOCS/linux-src
mkdir -p $HTDOCS/linux

Now we will download the required sourcecode into our working directory:

mkdir -p $HTDOCS/linux-src/download
cd $HTDOCS/linux-src/download
wget ftp://ftp.imagemagick.org/pub/ImageMagick/ImageMagick.tar.gz
wget http://pecl.php.net/get/imagick-2.3.0.tgz
wget ftp://ftp.remotesensing.org/pub/libtiff/tiff-3.8.2.tar.gz
wget http://us3.php.net/get/php-5.2.10.tar.gz/from/us.php.net/mirror

Note: The URLs to the latest versions may change over time. You will have to adjust them and also watch for changed file names in the following steps. Also be sure to use the PHP version currently active on your managed server.

Extracting the sourcecode

Now create a folder for the extracted sourcecode and extract the source archives:

mkdir -p $HTDOCS/linux-src/extracted/imagick
mkdir -p $HTDOCS/linux-src/extracted/php-imagick
mkdir -p $HTDOCS/linux-src/extracted/libtiff
mkdir -p $HTDOCS/linux-src/extracted/php5

cd $HTDOCS/linux-src/extracted/imagick && tar xfz $HTDOCS/linux-src/download/ImageMagick.tar.gz
cd $HTDOCS/linux-src/extracted/php-imagick && tar xfz $HTDOCS/linux-src/download/imagick-2.3.0.tgz
cd $HTDOCS/linux-src/extracted/libtiff && tar xfz $HTDOCS/linux-src/download/tiff-3.8.2.tar.gz
cd $HTDOCS/linux-src/extracted/php5 && tar xfz $HTDOCS/linux-src/download/php-5.2.10.tar.gz

Building delegate libraries

ImageMagick uses different delegate libraries for certain formats. We have to build these first so they can be incorporated into our ImageMagick build. In this case we will only use libtiff to allow the usage of the TIFF image format.

Building libtiff from source

Building libtiff is pretty straightforward. Simply use the following commands inside the extracted source archive:

./configure --prefix=$HTDOCS/linux/
make
make install

Building ImageMagick from source

Change into the extracted source directory and type in the following:

./configure --without-perl --prefix=$HTDOCS/linux \
  CPPFLAGS="-I$HTDOCS/linux/include" LDFLAGS="-L$HTDOCS/linux/lib/"
make
make install

You can type the following command to test the compiled ImageMagick.

make check

After ImageMagick is built we can now go on and create the PHP extension.

Building the ImageMagick PHP extenstion

To compile the extension we have to have a PHP development environment in place. To create one we’ll simply compile and install PHP (this sounds more scary than it is).

Building PHP from source

Change into the extracted PHP archive and type in the following:

./configure --prefix=$HTDOCS/linux
make
make test
make install

The make test target will run the PHP test suite. You can expect some tests to fail but if the number of failing tests is overwhelming you should get suspicious.

Building the ImageMagick PECL extension

Change into the extracted source archive and type in the following:

phpize --clean
phpize
./configure --prefix=$HTDOCS/linux --with-php-config=/usr/bin/php-config5 --with-imagick=$HTDOCS/linux

The configure script should go through. Unfortunately it seems that the prefix and paths will not be set correctly in the Makefile. We will have to adjust this and replace the /usr/local paths with the path to our $HTDOCS/linux

echo "$HTDOCS/linux" | sed -e 's/\//\\\//g' > htdocs_pattern && \
  export HTDOCS_PATTERN=`cat htdocs_pattern` && rm htdocs_pattern
perl -pi -e "s/\/usr\/local/$HTDOCS_PATTERN/g" Makefile

Note: The above command looks a bit freaky and is a bit of a quick hack. What it basically does it is escaping the slashes (/) in the $HTDOCS path and writing this to a file. Then exporting the content of the file to an environment variable and deleting the file. After this PERL is used to replace all /usr/local paths in the Makefile to $HTDOCS/linux

After that we are good to go and can build the extension:

./configure --prefix=$HTDOCS/linux
make
make install

Now the extension should be build successfully and is placed in the directory $HTDOCS/linux/somepath (the make install will tell you the extact path) . The last thing we have to do is activating the extension.

Activating the extension

To activate the extension for a certain folder, create a file named php.ini (for example in the $HTDOCS directory) with the following content inside the folder:

extension_dir=$HTDOCS/linux/somepath
extension=imagick.so

Also don’t forget to activate PHP 5 with using a .htaccess file:

AddType x-mapp-php5 .php
AddHandler x-mapp-php5 .php

That’s all. If you have any questions feel free to comment. I hope this helps some of you.

Create the webapp directory

Since the configuration files have to be modified an exploded WAR has to be used. The webapp directory has to be created and the WAR will be extracted inside of it.

mkdir xwiki && cd xwiki
unzip ../xwiki.war
rm ../xwiki.war

Create and configure a database

Create a database including a dedicated database user. Open the file WEB-INF/hibernate.cfg.xml and uncomment the MySQL block. Modify the following properties:

• connection.username
• connection.password
• connection.url

Important: Don’t forget to add the MySQL JDBC driver to your classpath (e.g. WEB-INF/lib).

Note: It is of course also possible to use a container managed DataSource via JNDI.

Configure Logfile

Since the security manager restricts file IO to the webapp directory the logging has to be reconfigured. To do so the log4.properties file has to be copied from xwiki-core-2.0-milestone-4.jar to the WEB-INF/classes directory. After this the property log4j.appender.file.File has to be modified to point to a writeable path.

Add the context file to Tomcat

Add a file name ${context}.xml to the /conf/Catalina/localhost” directory of $CATALINA_HOME (the Tomcat instance) and put the following content into it:

<Context path="${contextPath}" docBase="${pathToWebapp}" ></Context>

Eventually put in references to resources like DataSource’s etc.

Create the proxy settings in Apache HTTPD

You can use any proxy settings. I’m currently using a very simple setup:

<Proxy ajp://localhost:10709*>
  Allow from all
</Proxy>

RewriteEngine On
RewriteRule ^/$ /xwiki/ [R=301,L]

ProxyPass        /      ajp://localhost:10709/
ProxyPassReverse /      ajp://localhost:10709/

Note: xwiki is the contextPath

Test the installation

Surf to http://www.yourdomain.com/. An empty XWiki page should be displayed. The first step should always be to register a user so the administration area is accessible. The default content can be imported by using the page /${contextPath}/bin/import/XWiki/XWikiPreferences.

I’ll probably blog more about XWiki and how to customize it in the future.

By usage of the property folders.available (you might have to define it first) on a template you can specify a list of comma seperated folders in which the template is available (in the dropdown).

Unfortunately this property works only on file level and can not be inherited via the folder hierarchy. Also it does not provide a secure solution since the template can always be set via the advanced property dialog.

But you never know when a feature could come in handy.

The Problem

One problem with the current Plesk version (as with most Plesk versions :/) is that it has some nasty bugs. For example mod_rewrite doesn’t work with the FastCGI configuration. The problem is that the generated virtual host configuration has a small but important problem. The generated host looks something like this:

<VirtualHost 88.198.164.10:80>
  ServerName   playground.himberger.de:80
  ServerAlias  www.playground.himberger.de

  <IfModule mod_fcgid.c>
    <Files ~ (\.php)>
      SetHandler fcgid-script
      FCGIWrapper /usr/bin/php5-cgi .php
      Options ExecCGI
      allow from all
    </Files>
  </IfModule>
</VirtualHost>

The issue with this configuration is the line “Options ExecCGI“. This line enables the execution of CGI scripts for this particular directory but overrides all the Options set earlier. These are in parts needed for mod_rewrite. To fix this the line should be “Options +ExecCGI“. Sadly changing the configuration doesn’t help because at the next opportunity Plesk will regenerate the config file and your change is gone.

Luckily there is a way around this…

Enable mod_rewrite (the solution)

Luckily Plesk allows you to append a custom configuration to the virtual host by creating a file vhost.conf in the ${yourvhost}/conf directory. By putting the following config in your vhost.conf you can take back the overwritten Options (don’t forget to restart the Apache HTTPD).

<Directory "/var/www/vhosts/${yourvhost}/httpdocs">
  <Files ~ (\.php)>
    Options All
  </Files>
</Directory>

You have to be very specific (using the enclosing Directory directive) to cause the current setting to be overridden.

With this knowledge at hand we can do some other nice tricks.

Using a custom php.ini with fastcgi

Since we are now able to override the Plesk generated configuration we can also alter the fastcgi command and for example specify a custom php.ini:

<Directory "/var/www/vhosts/${yourvhost}/httpdocs">
  <Files ~ (\.php)>
    FCGIWrapper "/usr/bin/php5-cgi -c /etc/phpconfigs/${yourvhost}"  .php
    Options All
  </Files>
</Directory>

The FCGIWrapper command will use the directory specified with the -c parameter for it’s php configuration. Simply put your php.ini in this directory and it will automatically be picked up. This way you can easily use a per customer PHP configuration with fastcgi and Plesk.

Since 1und1 puts every server behind a dedicated firewall the setup is not as easy as you think. I’ll document it here because It may be useful for other people and certainly for myself after a couple of months.

Configure a static IP address

Open the file /etc/sysconfig/network-scripts/ifcfg-eth0 and edit it to look like the following:

DEVICE=eth0
BOOTPROTO=none
TYPE=Ethernet
ONBOOT=yes
HWADDR=$YOURMACADDRESS
NETMASK=255.255.255.255
IPADDR=$YOURIP
GATEWAY=10.255.255.1

Save the file.

Configure static routes

This is the tricky part. Configuring a default gateway using the GATEWAY= setting is not enough. You have to setup the routes yourself. To do so create a new file /etc/sysconfig/network-scripts/route-eth0 with the following contents:

10.255.255.1 dev eth0
default via 10.255.255.1 dev eth0

Now you only have to reload the networking configuration via

service network reload

and you are done!

This post helped me a lot with the solution.

Prerequisites

• OpenCms 7 (already installed)
• Apache HTTPD 2.2 with mod_proxy_ajp
• Apache Tomcat 5.5+

Goal of the setup

• Dynamic content served from http://www.yourdomain.com/
• Static content served from http://www.yourdomain.com/opencms/export/

Steps to perform

Configure Tomcat

As described in the Howto you have to add the emptySessionPath=”true” attribute to the Tomcat AJP Connector in the server.xml:

<Connector emptySessionPath="true" port="8009" protocol="AJP/1.3" />

Configure OpenCms

You have to modify the opencms-importexport.xml configuration file. But beware the <rfs-prefix> doesn’t need changing anymore. In fact: Things won’t work if you change it the old way. These are the settings you want.

       <rfs-prefix>${CONTEXT_NAME}/export</rfs-prefix>
       <vfs-prefix></vfs-prefix>

Don’t forget to restart OpenCms.

Configure Apache HTTPD

Since the AJP Connector is now integrated in mod_proxy you don’t need the (stupid) rewrite rules anymore. I also got rid of the fact that static content is served from Apache. This has several reasons:

1. The new Tomcat is fast enough to serve static content itself. Espcecially with the NIO / APR Connector.
2. If you ever want to move the Tomcat to a different machine and use Apache HTTPD as a simple load balancer things get a lot easier if Apache doesn’t need access to the web application files.

Here’s an example virtual host:

<VirtualHost *:80>

  ServerName yourdomain.com
  DocumentRoot /some/directory

  <Proxy ajp://localhost:8009*>
     Allow from all
  </Proxy>

  ProxyPass        /opencms/   ajp://localhost:8009/opencms/
  ProxyPassReverse /opencms/   ajp://localhost:8009/opencms/

  ProxyPass /          ajp://localhost:8009/opencms/opencms/
  ProxyPassReverse /   ajp://localhost:8009/opencms/opencms/

</VirtualHost>

This is it. Don’t hesitate to ask questions.

<cms:include file="/system/modules/com.example.ocms.commons/elements/pager">
  <cms:param name="currentPage">
    <c:out value="${model.currentPage}"/>
  </cms:param>
  <cms:param name="pageCount">
    <c:out value="${model.pageCount}"/>
  </cms:param>
</cms:include>

Became:

<wt:pager model="${model}"/>

Not does it only look cleaner and is much more focused, it also decouples your view more from the underlying CMS solution. Of course you could also develop a custom tag library using Java (which I have done a few times) but using a JSP the advantage that code can be changed on the fly and even from a web designer. You can always refactor your JSP taglib into a Java one if you need to do it. There are some limitations of JSP tag files (like you can’t use scriptlets in the body) but they are easy to get around.

But as always: This is no silver bullet. There are problems with tag files which may not be obvious at the first glance.

How to create a tag

Creating a tag is easy. I will show you the necessary steps while developing a tag which allows the user to loop over the contents of an OpenCms VFS directory.

Preparing your module

As normal Java libraries too, JSP tags need to be exported into the filesystem to be read by the Servlet-Container. Normally the tag files reside under a directory like ${yourwebapp}/WEB-INF/tags/mylibrary. So what we will do is adding a new export point to the module containing our tag files.

First we create a new directory called tags inside the module we want to contain our tags (normally I create a module for each site). The resulting structure will look something like this

The tags folder inside the module directory

Then we open the module administration and add an export point to our module (Administration -> Module Management -> Edit Your module -> Module exportpoints -> New exportpoint).

Adding the tags exportpoint

After pressing OK we are well prepared to add custom tags to our OpenCms module.

Creating the tag file

We now create a directory for our taglib. This will be located inside our newly created tags folder. Because we want to create a tag which interacts with the OpenCms VFS we will simply call the folder vfs. Inside this directory we create a new JSP resource called directoryLoop.tag. The result should look something like this:

The created tag file in the VFS

Now it’s time to write some code .

Writing the tag file

I don’t want to go into the details of developing tag files in general. This topic has been covered by dozens of books and online tutorials. I have collected some links in this blog post which explain the development of tag files in detail. Have a look at the section Further reading if you want to find out.

I will assume you’ve already developed JSP files inside OpenCms so I won’t explain the steps in detail. If you have questions regarding the sourcecode simply post a comment.

Here’s the commented sourcecode for our tag file.

<%@ tag body-content="scriptless" %>
<%@ tag import="org.opencms.jsp.*,
                org.opencms.file.*,
                java.util.*" %>
<%@ attribute name="folder" required="true" %>
<%@ variable name-given="resource" scope="NESTED" %>
<%@ variable name-given="status" scope="NESTED" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %><%

// First we get the pageContext variable.
// Tag files only have an explicit JspContext but in this case
// it is a PageContext which is a subclass of JspContext.
PageContext pageContext = (PageContext)jspContext;

// Instantiate the usual CmsObject to access OpenCms data
CmsJspActionElement cmsa = new CmsJspActionElement(pageContext ,request,response);
CmsObject cmso = cmsa.getCmsObject();

// Read the resources, note that we can access the tag
// parameters using the pageContext.
String folder = (String) pageContext.getAttribute("folder");
folder = cmso.getRequestContext().removeSiteRoot(folder);
List resources = cmso.readResources(folder,CmsResourceFilter.DEFAULT,false);

// We store the list of resources in the pageContext for usage with JSTL
pageContext.setAttribute("resources",resources);

%>

<c:forEach var="resource" items="${resources}" varStatus="status">
  <jsp:doBody/>
</c:forEach>

As you can see the tag file looks like a usual JSP file with only a few differences.

The tag exports two variables: The current resource and the iteration status. These can be accessed from the invoking JSP. We will make use of this in the next example.

To use the tag you have to publish the file so it gets written to the file system. After you’re finished writing/modifying the tag: Don’t forget to publish it!

You can’t preview tags, even though they are JSP files. You also won’t get compiler warnings. You always need a JSP file to test your tag files.

Using the created tag

We will use the created tag to implement a simple file browser. The file browser displays the contents of a folder and allows the user to navigate into subfolders recursively. Please note that this is definately no production ready code.

<%@ taglib prefix="vfs" tagdir="/WEB-INF/tags/vfs" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

<%-- Determine the current folder, set to "/" if no parameter given --%>
<c:set var="folder" value="${param.folder}"/>
<c:if test="${folder eq '' or folder == null}">
  <c:set var="folder" value="/"/>
</c:if>
<html>
<head>
  <style type="text/css">

   .row-1 {
     background-color: #ECECEC;
   }

  </style>
</head>
<body>
<h1>Resources of folder "${folder}"</h1>
<table>
  <tr>
    <th></th>
    <th>Name</th>
    <th>Size</th>
    <th>Date created</th>
  </tr>
  <vfs:directoryLoop folder="${folder}">
  <%-- We use the status for alternating row classes, useful for css --%>
  <tr class="row-${status.count % 2}">
    <td>
      <%-- Display D for directory or F for file --%>
      <c:choose>
        <c:when test="${resource.folder}" >D</c:when>
        <c:otherwise>F</c:otherwise>
      </c:choose>
    </td>
    <td>
      <%-- If the current resource is a folder, display a link --%>
      <c:choose>
        <c:when test="${resource.folder}" >
          <a href="?folder=${resource.rootPath}">${resource.name}</a>
        </c:when>
        <c:otherwise>${resource.name}</c:otherwise>
      </c:choose>
    </td>
    <td>
      <%-- If the current resource is a file, display size --%>
      <c:if test="${!resource.folder}">${resource.length}</c:if>
    </td>
    <td>${resource.dateCreated}</td>
  <tr>
  </vfs:directoryLoop>
</table>
</body>
</html>

As you can see the tags are included with the directive.

<%@ taglib prefix="vfs" tagdir="/WEB-INF/tags/vfs" %>

The usage of the tags is similar to normal tags with the exception that you can’t use scriptlets in the tag bodies. If the example is working you should see something like the following.

The output of the created JSP

If you have trouble reading the above code. Here is a more condensed version of a file using the tag:

<%@ taglib prefix="vfs" tagdir="/WEB-INF/tags/vfs" %>
<ul>
<vfs:directoryLoop folder="/system/modules">
  <li>${resource.name}</li>
</vfs:directoryLoop>
</ul>

Things to keep in mind

JSP tag files and OpenCms really are a nice fit, but before you start working on converting all your custom includes to tag files keep in mind some of the disadvantages of tag files in respect to using <cms:include>.

• Tag files are not seperated by online/offline. Since the tag files only get exported during publishing there is no way of developing the tags in the offline project. You always have to publish the tag file to see your changes (It’s like a normal, Java based, tag library). This means if you have an error in your code the live system will be affected by it. In my opinion this problem is not as big as it sounds. Tags are normally developed in a staged environment or on a developer machine and then deployed on the live server. Additionally they are no replacement for templates and therefore shouldn’t be changed often.
• Tag files are not cached. The output of a <cms:include> may be cached by the OpenCms FlexCache. This can speed up the rendering enormously, tag files are always processed. In my opinion this no big problem. Tag files will mostly always be used in JSP templates which in turn will be cached by the FlexCache. I would suggtest that tag files are used as the building blocks for JSP templates and therefore are one a finer granular level. The chunks you want to cache are normally much more coarse grained.

Finishing thoughts

In my opinion JSP tag files are a great thing. They can help you clean up messy JSP templates and nicely decouple your JSPs from OpenCms (although I used a pretty OpenCms heavy example in this post). I hope this post was useful and helped you adding another tool to your toolbox. If you have further questions or need help regarding a specific project, please leave a comment or contact me directly.

Further Reading

These tutorials can help you developing your own tag files or looking up classes used in this tutorial.

• The JEE 5 tutorial on creating tag files
• An online tutorial on JSP tag files by Oracle
• A java.net article on tag files, short and good
• The OpenCms JavaDoc, always handy

If you put an external link into the OpenCms navigation the resulting link will target the external link file which then in turns redirects the surfer to the external page. This is bad if you really want to optimize your navigation for search engines, because search engines won’t see the real link inside the navigation.

The solution

You can use the following JSP snippet to get the real URL from a CmsJspNavElement.

// We assume that the variable "link" holds an CmsJspNavElement and
// "cmsa" holds an CmsJspActionElement.

// Prevent external links from beeing a redirect
// therefore extract the real URL out of the file
String fileUri = link.getResourceName();
CmsResource navResource = cmsa.getCmsObject().readResource(fileUri);
if (navResource.getTypeId() == CmsResourceTypePointer.getStaticTypeId()) {
    CmsFile navFile = CmsFile.upgrade(navResource,cmsa.getCmsObject());
    String externalLink = new String(navFile.getContents());
    externalLink = externalLink.trim();
}

Further reading

• The OpenCms JavaDoc