Jahia the Java Open Source Web Content Management Community

• Jahia The Open Source Community
• Jahiapedia
• How to use Jahia?
• Jahia for Administrators

Jahia comes with a web based back-end administration system that helps site administrators, server administrators or even power users manage various websites. This system is called the “Administration Center” (or Admin Center) in Jahia.
When you have the right privileges you can access the Admin Center through the standard Edition Toolbar.
 
By default the Jahia system is delivered with:

• a “Root” user: This user has all the permissions on the overall system. He can access all features on every sites hosted on the platform. Nobody can restrict his privileges. So even if he is not directly listed on a content object’s permissions, this user will be able to bypass all existing security settings.
• A “Site Administrators” group and a “SiteAdmin” user: When creating a new virtual site, Jahia will automatically create a new “Site Administrators” group dedicated to this new site and will also ask to the Site Creator if he wants to create a new “SiteAdmin” user (optional). Any existing LDAP or Jahia user could then be added afterwards as a member of this “Site Administrators” group. Once a user belongs to this group, he will be automatically turned into a “WebMaster” for the current virtual site only. All other restrictions or security settings on the current virtual site will not apply any more for all members of this group.
• Finally server or site administrators could delegate administration actions to specific “power editor”. For instance a site administrator may decide to let specific users be able to create or modify existing groups. Or to let them manage the overall categorization tree. Such “power users” will also be able to access the Administration Center but only to specific features and of course, as opposed to the aforementioned users, they will not inherit from any “WebMasters” or “Root” privileges on the underlying website(s).

This first section will focus on the tools available on a virtual site basis (for Site Administrators / WebMasters). The second chapter will explain other features usually only available to Root user and that are impacting all virtual sites hosted on a single Jahia environment.
 

When accessing to the Administration Center as a Site Administrator you will see the following User Interface:
This screen includes all administration tools to manage one given virtual site hosted on your Jahia platform.
If the current Site Administrator can access several virtual sites, he will see a drop-down list allowing him to easily switch between all virtual sites he manages.
The Site Administrator can access the “Server Settings” Panel but all or most of the options should be unavailable and will appear as being turned off (grayed-out).
When clicking on the “Exit from Administration” button, the Site Administrator will be redirected to the home page of the currently selected virtual site. This could be an option to switch from one virtual site to the other. A similar option is available directly in Edition Mode as part of the Edition Toolbar.
“Power User” who can access the Administration Center will only be able to access limited features. In the example illustrated below a power user is accessing the users and groups menus only. All other options are “grayed-out” and are unavailable to him.
 
Let’s now see the details of each sub-menu available as part of the Site Settings Panel.
 

This menu lets you switch from one theme to the other.
In Jahia 5 there was only one single notion of “Template” that was mixing both the page skeleton (aka content objects on the page) and the CSS theme.
This menu will then transition to a “Theme Switching” only sub-menu. For several reasons (orphan content objects; search indexes corruption ;…) the “Template Switching” option is now forbidden in Jahia 6.
 
Just choose the page you want to “skin” and select the theme you want to apply. Click on Save Changes to validate modifications.
The same option is also available directly in the Edition Toolbar as part of the Page Properties option. However such an option could sometimes be useful to revert from a theme producing errors on the page and preventing you to access the page settings any more (e.g: such a menu could be hidden behind a badly positioned CSS layer) to another known good CSS for a specific page of your site.
 

This interface allows site administrators to manage the Jahia users available on the current virtual site and their properties (e.g: default home page; other additional user properties and preferences).
 
By default Jahia is provided with its own custom directory of users (Jahia_db). However Jahia can easily plug in and access other LDAP or MS Active Directory Servers. In such a case a Site Administrator will be able to see a consolidation of all the different “user providers” being currently in use.
Please note that LDAP or Active Directory (AD) properties are only available in read-only mode throughout the Jahia system. Your System Administrator may then have decided to reuse user properties directly from the LDAP server (e.g: first name, last name, phone number, address, department…). Such metadata and the overall management of such users (creation, deletion…) could not be done through Jahia directly. Please rather use your standard LDAP/AD Management Utility.
Please also note that for performance reasons Jahia is “caching” details about users and groups. So you may need to manually flush such caches (cf: next chapter in the Cache menu) or use one of the existing back-end Jahia Web Service in order to automatically flush such caches once a while or upon specific user properties modifications.
Finally each user stored in a remote LDAP/AD server will still benefit from Jahia-only properties (e.g: default redirection home page for this user) and other kind of user preferences (e.g: position of portlets and mashups on his personalized portal page). These properties are directly created and added by Jahia on top of the other inherited LDAP/AD properties. Such properties are of course editable as they are custom to the Jahia platform.
You can create new user (only local Jahia_DB users), Register users from another virtual site, Edit the user properties or remove/delete a user (only local Jahia_DB users) from the operation bar.
 

Create New User

Creating a new user will display the following user interface:
 
Please note that the username could not be changed afterwards and should be unique on the overall server. So you cannot have two distinct users called “John” available on two different virtual sites as users could be shared among site (cf: below).
Except for the standard fields, you can also:

• Disable email notifications for this end-user. In that case this user will not receive any workflow message (or any other kind of email notification issued by the system).
• Choose the preferred language: this language will be used for instance to send the notifications in the right language.
• Select a default redirect home page on login: you can also select a default homepage for the current user. When this user will log in and if he selects “Jump to personal home page”, he will automatically be redirected to the page defined in this menu. Simply click on the Select Button to add a new default home page to the current user.

 
This user interface could be customized to every company’s needs as each user could have different sets of properties. Most of these user options are initialized at creation time by a Site Administrators (or programmatically if users could automatically create new account on a site). However these properties could also be modified afterwards directly by the end-user itself through the “MySetting” panel.
 

Register a user from another virtual site
 

By default local Jahia users are created as part of one single virtual site and are available for this site only. However it makes sense sometimes to reuse one or several users among several web sites. You can then use this option to reuse an existing user profile among several virtual sites.
Simply select the source site and the name of the user to include it in current site. You will then be able to use this user account (assign rights and permissions) as if it is a current local site user.
Please note that this is not the case for LDAP/AD users. Such users are automatically shared and are available among all virtual sites.
 

Edit/View selected user properties

This option lets you update the properties of an existing user. Select a user and click on this option to edit his profile.
Please note that double clicking on a user will lead to the same result.

Remove selected user

The remove option will turn off the current user instance. This only works for the local Jahia_db user and not for LDAP/AD users. Note that the user and its preferences still exist in the database. So the username could not be assigned to a new user any more.
Warning: if a user name is reused on several virtual sites, this will only delete the current instance of this user on the current site. The user will still be able to login throughout the other sites he still belongs to. You will have to manually remove this user from all the other sites if you want to permanently delete it.

Using the main Users Panel

You can also browse, search and sort users from different all the mounted sources directly from the main Users panel.
In case you have several hundred users, you can use the search field to retrieve specific users. Wildcards can be used for example to search all users whose name begins with “s”. Just enter “s*” in the search field and click on search. You can also sort in ascending or descending order the list of users by provider or by username just by clicking on the arrows icon above the users list.
Please note that the Root user as well as the guest (anonymous) user cannot be deleted. In fact the Root user does not appear in the list of users as it automatically has full permissions on all the virtual sites. The SiteAdmin user is optional and could then be deleted.
 

This menu is very similar to the previous one but lets you manage groups.
 
Similar to Users, Groups can either be local to Jahia or inherited from a LDAP/AD connection. Mounted LDAP/AD groups are automatically available throughout all the virtual sites.
However Jahia groups are specific to each virtual site. So you can perfectly have two distinct “Authors” groups for two different virtual sites.
Jahia groups could also include LDAP/AD users. This is then perfectly possible to either create new Jahia-centric groups that do not exist in the main LDAP/AD server but that regroup LDAP/AD users or even to mix LDAP/AD users with other Jahia-only users (e.g: external users subscribed to websites but not part of your centralized LDAP server for Employees only).
  Note that you cannot create groups of groups for the time being.

Three groups exist by default in Jahia and cannot be removed:

• Administrator: all users that have complete administration rights on the current virtual site.
• User: all logged users (Jahia or LDAP/AD users) are automatically registered as member of this group by default.
• Guest: this group represents all the possible anonymous or logged users (= the Users group + the anonymous user). As the anonymous user (the “guest” user in Jahia) is considered in Jahia as a standard automatically logged user, if you only grant access to a page to the guest user, other logged users will not have access to this page. Then, you will need to grant access to the full “guest” group that includes both logged and anonymous users.

Add users to a group

To add or remove users from one of these group, select a group and click on “Edit selected group” (or simply double click on the group).
 
All users are displayed by default, there is a search button to filter the list.
If you want to add new users to the group, click on “Add members” in the main Operation Toolbar.
 
Select users and click on Add to add them to the current group. You can also double click on a user to directly add it to the underlying group being edited. So you can easily keep this user selection pop-up opened, double click on the users you want to add to the current group, refine or redo another user search and add additional users without ever leaving this user selection window. When you are done picking the users that will belong to your group, close this pop-up window by clicking on the “Add” button (if you still have users to add) or the Cancel button (if all users were already added thanks to double clicks operations).

Delete users from a group

Select one user (or press the Ctrl key to choose multiple users) and click on the “Remove members” operation button.

Duplicate an existing group

You can also copy groups and keep in the new group all users from the source group. For example, select group “Authors” and click on the “Copy selected group” operation. Give to the new group a name, i.e. “Authors_Copy” and click on OK. You now have a second group containing the same members as the “Authors” group.

Other Advanced Options

A first option lets the Site Administrators enforce a password security policy only for one given group of users. Usually you may want to enforce the password security policy at a site level (cf: Virtual Site Management) so that all users have to comply with the same policy. However it could make sense sometimes to only enforce a security policy for one given group (ex: “Employees” group) and not for others (e.g: “UGC Community Members”).

This setting does not apply to LDAP/AD users as they are only available in read-only mode. So Password Policy rules will only apply to local Jahia users.

A second advanced option allows the site administrator to enforce a home page for a given group. All members of this group will automatically be redirected, upon login and if they choose this option, to that specific page. This option does not override personal end-users home page preferences and is only available for users that do not have setup their own home page. This is a default value for site administrators when adding new users to groups. New users can then automatically benefit from such a redirection (e.g: there is a new employee in the Marketing team. The Marketing group includes a home page redirection to the main page of the Marketing Department. When adding this new user to the Marketing group she will automatically benefit from this redirection).
 

This administration module allows you to manage the templates available for editors of your site.
In Jahia 6 template sets can now be shared across several virtual sites. When creating a new virtual site (cf: next chapter) the webmaster will have to decide what template set to use. Once defined, all sites using this template set will share the same templates.
However in order to better define, on a per virtual site basis, what template is available for which user, a site administrator can manage permissions on a per template basis.
For example you may decide that the “MyPortal” template, which is part of your generic template set, is only available as part of your “Intranet” virtual site but not for the “Public Web Site”. Similarly, you may decide that only some editors could add a template, let’s say, type “NewsLetter” on the public web site but that all editors could add such a template anywhere they want on the Intranet website.
In such a case you will limit permissions on the instance of a template and define more granular permissions on a per virtual site basis.
 

  To add and deploy additional template or remove a template from a template set, please check the Template Development Guide of Jahia.

To edit a template instance, simply double click on it or select it and use the “Edit” operation.
This will open an edition pop-up similar to the one available for content objects. Only two sub-menus are present: “Edit” and “Rights”.
The first menu (“Edit”) only displays read-only information about the deployed template. You can find information such as the template title, its path on disk or if the current template is the default one (aka it is selected by default when adding a new page).
 

The second menu is the most important one and lets you manage permissions on your template instance. As mentioned previously ACL on template are available on a per virtual site basis. So you can precisely decide which editor can add what kind of template on which site even if distinct sites share the same template set.
 

By default every user has access to all templates, provided that he has sufficient rights to manage content and add pages on a section of the site (the guest group is the default one).
To remove access on the current template instance for a user or a group, you can restrict some users –or groups- permissions. In that case, click on “Add new users/groups to the ACL”. Then choose all users/groups that should not have access to the current template and click on OK. Then select these users/groups and unclick the checkbox of the read column. Now the selected users/groups will not be able to add pages based on this template.
Or you can do the opposite and remove the generic “Guest” group and only add the users/groups that need to be able to use such a template.
  The “Write” and “Administration” radio button may be used in the future but have currently no effects.
If you click on the Tools tab, you will see administrative audit log about previous action made to that template.
 

Jahia uses the Lucene technology from the Apache Foundation (http://lucene.apache.org/) to index all content, metadata or other digital assets. Lucene is a high-performance, state of the art, full-featured text search engine that relies on an index file and so minimize RAM usage.
This menu helps you re-index your whole site in case of problems.
 
Before being able to use the search engine in your site, you need to create the index file. Normally this file is automatically created when you create a new virtual site. So you do not normally have to take care about.
You may also need to re-index the site after restoring a site backup or an extraction if you do not have backup the Lucene indexes.
In all the other cases, the search index will be updated in real time when content is modified or added in the system.
Reindexing a site could take a lot of time according to the size of your site and the volume. This task is done as a background job and will not impact end-users or editors. The search feature will also continue to work while being reindexed and optimized (if the index exists on disk of course and is not recreated from scratch).
 

From this menu you can manage all parameters related to language for the current virtual site. The upper part of the panel displays all the languages currently configured.
For each language, you can select turn it on or off:

• Active: if checked, this language will be available on the site and in the edition windows. Users will be able to switch to this language and Editors to start translating existing content. At least one language must always be activated.

The order of language is important, as this is the one that will be used to display the default Home page on first login. The Jahia system will first try to identify the default language that the end-user is currently using as part of his personal browser settings. If this language exists in the system, Jahia will automatically try to display the home page in this language. However if the end-user is using an unknown language (e.g: a Spanish user and you do not have setup any Spanish on your site), the ranking of language in the menu will prevail. So you may want to add the English in first.

Mix language mode

For intranet or extranet purposes, you may often want to be able to display content to the user whatever the language he is browsing. For example, if you do not wish to have empty pages or missing content for languages where content is not entirely translated and available yet, you can activate the “mix languages when navigating site” option.
If a content object does not exist in the current language, Jahia will try to display content that exists in another language to fill in the blanks.
So you may finally have areas with English content in the French part of a virtual site if this content is not yet available in the French language.
Most often you do not want to have sites mixing languages on the same page. This is especially true for public brochure-ware type of website. But sometimes, mainly for intranet or extranet projects, it could be convenient to display as much content as possible whatever the language rather than to let the users have to guess that new content is only available as part of the page in the other language.

Adding a new language

To add a new language to the virtual site, select it from the list of available languages and click on the   icon to add the language to the list of already available languages.
You may notice that many languages are listed several times. In fact the list is based on “locale” or language for a region, so it does not only specify a language, but a combination of languages and region.
Jahia could identify these “locale” from the settings of browsers and can then behave differently whether it identifies a Canadian user (“fr_CA”)  from a French user (fr_FR). For example you may have two distinct sites with different content and texts for Canadian or French people.
If you rather wish to add the “generic” French language, just choose the “French (FR)” option.
So unless you plan to have content specific to a country or region (like fr_CA or fr_FR), you should normally always use the generic locale (fr) for a given language.
  The list of available language and locales comes directly from the underlying JVM. Each JVM supports different languages.Official ISO language may be missing depending on the JVM being used. In such a case, as a workaround, you may use another language that you plan to never use and replace the “language flag” icon on disk (or in the template). Jahia will not be able to automatically recognize such a language in order to redirect new users but such users will still be able to switch from the home page to this language.

Turn off a language

If you want to remove a language from a virtual site, just unselect the “Active” checkbox and click on “Save changes”.
  Currently, you cannot delete a language that you have already added. Jahia often uses “shared language” content items or properties. Deleting (= purging) a language from  the database may then lead to severe consequences for other languages. Please rather use the Active checkbox to temporarily desactivate the language.  All the content in that language will disappear on your website. If you turn on this language again, your old content will appear again and could be reused.

Language mappings

The “language mappings” option is useful when you have created a site with two different locales for the same language but you still want to redirect generic language-only user. For example you may have both German-Germany (de_DE) and German-Switzerland (de_CH) locales configured on your site. You may want to specify what language will be displayed when a user with a generic German (de) locale accesses your site.
Click on “edit language mappings” once you have added both de_DE and de_CH to choose which locale will be mapped to the (de) locale.
To summarize, here is the normal behavior if you have the following configured languages and mapping:

And you can choose which locale a generic (de) user will be redirected:
 

Site administrators need to separate the intranet environment from the Internet server outside the firewall, very often. However authors are most of the time employees and publish content from within the intranet zone for security concerns.
Most of the time the protected Jahia environment is also hosting the company’s intranet, which is storing confidential data.
Thanks to this option, you can create an authoring environment of your public website within the boundaries of your firewalls and replicate it on a distant Jahia Publishing server (de-coupled environments).
As this option works on a per site basis, only the data of the virtual site to be replicated will be exported on the distant server. If you want to unsure that no confidential data at all will be exported you can even decide to limit content export to only content objects or documents that are visible for example by the “guest (anonymous) user. The remote database will then only include such content objects and even if your publishing server is being hacked no confidential data will be available on disk or in the database.
Technically speaking Jahia uses its XML import/export capabilities to replicate content. An XML diff file with only the latest content modifications is generated on every replication cron job (cf: below) and this file is then pushed on the remote publishing server through a WebDAV connection (be sure to have your WebDAV ports open in your firewall) and imported on the publishing server.
This feature is a one-way replication. It does not support bi-directional synchronization. It globally means that Jahia will push data from the Authoring Environement  to the “publishing environement”. In case UGC (User Generated Content) is available as part of the Publishing Environement, this content will be only available on this server and will not be synchronized back in the Authoring Environement.


Find the details of the various options below:
Target Server url:     The URL of your destination site.
Target site key:    The site key of your destination site.
Alias name of your Job:     This field is currently not used any more.
User of target site:     A user, on the distant Jahia server, that has enough permission on the distant site to add and validate content (usually the root user of the distant site).
User password on the target site: The password of the user that will import content. This serves as an authentication and security mechanism to restrict access to the remote publishing feature.
User to export on source site: In order to avoid confidential and restricted information to be published on a separate public website, only information available for this chosen user will be exported (usually the guest user).
Export metadata:     Include the date of creation, author, etc. in the export file so that metadata is identical on both environments. Sometimes it is not useful to export such data and replicating them could slow down operations.
Export workflow settings:     Include the workflow in the export file.  If unchecked, the default workflow setup on the distant Jahia server will be used. All other custom workflows on the source site will not be imported.
Export ACLs:     Include the access rights in the export file (if you are using the guest user to export on source site, you usually do not need to export additional permissions as restricted content is not present).
Auto-Publish at the end:     At the end of the replication, new imported content is automatically validated and published. You may want to have an additional moderator on the distant site in order to ensure that everything is fine. In such a case do not turn on this option. Imported content will only appear in staging mode on the destination site and you will be able to manually re-validate it twice.
“Cron” expression for scheduling: Enter the “cron” expression to select the frequency of your site replications such as: "At 8:00am every Monday through Friday" or "At 1:30am every last Friday of the month". Thanks to this powerful mechanism you can decide to update your distant site once a week, once a day or once an hour.

A "Cron-Expression" is a string comprised of 6 or 7 fields separated by white space. Here are some examples:
    0 0 12 * * ? = Fire a new replication at 12pm (noon) every day
    0 15 10 15 * ? = Fire a new replication at 10:15am on the 15th day of every month
    More on the “cron” command on this URL : http://en.wikipedia.org/wiki/Cron

 

In this menu you will be able to setup the various roles for the current virtual site. Role is an additional mechanism beside standard permissions (ACL) and will let Site Administrator better define who can perform what actions.
 
So roles are cumulated to ACL and you need a combination of both to be able to perform any action within Jahia. For example you need to be a content manager (or content owner) with Read, Write and Admin permissions on a content object to modify existing ACL or to change the type of workflow. However you may decide that only a sub-restricted group of user could modify the types of workflow and that content owners cannot access this menu. You can then bypass such default permission schema through the existing roles and forbid the access to this edition interface to some users.
You may also want to avoid the Import/Export features access to editors that you do not want to support as part of your environment. You can then totally switch off this feature from this menu.
On the opposite you may want to let some power editors access the Administration Center (by default only available to the “Administrators” group or to the Root user). You can then grant additional roles to these users and allow them to see the “Administration” button in the main Edition Toolbar and grant access or all the administration sub-menus detailed in this chapter.
All Jahia operations, edition interfaces or action menus could benefit from extended or more restricted permissions from this menu.
Roles are by default regrouped according to various categories.
 

The current categories are:

Administration Center:	Who can access the Administration Center and which sub-menus. This only covers the options available to the current virtual site. Other Roles are available for the Administration Center Server part but are of course only available in that section for the Admin Center.
Edit:	Who can access the Edit Section in the Edition pop-up windows. For example you may decide not to use the “Time Based Publishing” feature on your site and to limit the access to all editors to this menu.
Tools:	Who can access the Tools Section in the Edition pop-up windows. For example you may decide that editors cannot have access to the Import or Export sub-menus.
Actions Menus:	A way to restrict operations available from the action menus to specific editors.
Languages/Translations:	This category allows you to block the access to specific languages for specific editors. This is the way used by Jahia to manage the role of translators.
Toolbars:	This category regroups all limitations available on the Toolbars. You can either limit access to specific sub-menus (e.g: you do not want your users to access the Mashup Manager as you do not manage any portlets or mashups on your site) or to optional toolbars themselves (e.g: you want to restrict access to the “Cache Toolbar” to a limited number of power users only).
Integrity checks:	This last category regroups the (des)activation of all integrity and consistency checks. You can then decide on a per user basis, which users should comply with the consistency checks and which one could bypass them.

 

When editing a website, editors are most of the time using rich content areas (aka HTML zone). As editors could manually enter HTML tags or make automated copy/paste of HTML content this could quickly lead to consequences when generating a correct and global HTML at an aggregated page rendering level.
For example editors may forget to close some HTML tags. Others may copy/paste from MS Office, which will integrate hundreds of Microsoft-specific tags.
Jahia offers the ability to clean up the HTML source code stored in Jahia by turning on the integrated HTML parser.
Sometimes you may also want to prevent the usage of HTML tags within those rich texts areas. For instance you may decide that editors could not use the tag <B> but should rather use the tag <Strong>. With Jahia you can forbid the usage of such tags through this menu. Editors will still be able to enter tags in the WYSIWYG editor but when saving the data on the server, Jahia will automatically extract and purge those tags out of the rich text area.
In order to do that, you just have to provide a comma-separated list of HTML tags to remove. For example: h1,hr,strong.
These two options are the two first check boxes available in the General Options.

The second part of this menu will let you decide which authors will access what version of the integrated WYSIWYG HTML Editor. Indeed Jahia can dynamically load a customized version of this WYSIWYG HTML editor per user.
Three default customized version are prepackaged with the software. You can however edit such a customization in order to fit with your own needs. Please check with your Jahia developer to get more information about such a possible customization.

Jahia will help you keep the integrity of your website up-to-date or can also help you comply with additional and optional web standards (e.g: Accessibility standards such as WCAG).
 

The goal of the “URL Integrity Checks” feature is to warn editors about possibly bad and corrupted internal cross-references they are manually making in the Rich Text areas (all others links directly managed by Jahia – e.g: a page field or an internal link field - are automatically and dynamically managed by the system in order to avoid any possible bad links).
An Editor may then want to get notified when one of its hardcoded link done directly within its WYSIWYG Rich text editor could lead to a possible 403 or 404 kind of errors.
For instance, an editor may link the current published page to another page still being drafted. Such a link will then lead to a 404 page and will be automatically detected by the Jahia system.
The Editor may also make a cross-reference to another page on the site but only available to restricted users. Restricted users that are allowed to access the first page (e.g: anonymous) will see a shortcut to a page only available for another restricted group of users (e.g: Managers). This will then result into a 403 kind of page and this is also of course automatically detected by the Jahia system.
So when you check the URL Integrity checkbox, a warning will appear when an author will create a cross-reference to another page that will then lead to a possible 403 or 404 error page. If you do not turn on this option, such consistency checks will not be performed at edition time.
 

The WAI (Web Accessibility Initiative or WCAG) compliance option will help make your website accessible to everybody, including those with temporary or permanent disabilities: visual, physical, cognitive and neurological disabilities and hearing impairments.
For example, a warning will appear when you forget to include a text label when you insert an image in a rich text area.
This will then ensure that WCAG 1.0 Level 1 guidelines are applied when entering new raw unstructured HTML text areas or when copy/pasting from a third-party word-processing software.
This feature could be verbose as compliance with WCAG standards will require lots of extra-work especially on unstructured rich text areas. We then recommend to turn this option off excepted if you really have needs for WCAG support and that editors are trained accordingly.
 

Finally an author may also add images in his rich text area or add a link to an existing document (e.g: link to a PDF file) from the embedded Jahia Document Management System (DMS).
Jahia will automatically detect such internal cross-referenced documents and will automatically modify hardcoded references to such documents in case of file renaming or file moving.
A manager may also delete a whole directory, within the Jahia DMS, that could still contain cross-referenced documents used within a page.
In order to avoid such problems the Site Administrator may decide to lock all published documents (images or files) automatically. In such a case a “system lock” will be applied on each of this file and will block further editing or deletion until such a document is getting “unpublished”.
 

By default those consistency checks are only considered as non blocking warnings displayed at edition time (aka when editors access the edition pop-ups). However a Site Administrator may also want to enforce such consistency checks at validation time.
Additional roles available in the “Manage Site Permissions” menu allow you to select among users which will be denied publishing rights based on consistency (no page validation will be possible until all consistency errors are fixed on the page).
You can then perfectly decide that specific “managers” could bypass such consistency checks but not standard Editors.
 

By default Jahia is already offering pre-integrated support for Google Analytics. This option will of course work for public website and do not work for intranets as Google Analytics is not be able to access such pages.

The Jahia integration includes:

• An administration menu to turn on or off your Google Analytics (GA) account on a per virtual site basis
• The integration of the Google Analytics Javascript in your generated page
• An Edition Toolbar available to Editors in order to let them see Statistics on a page without having to live your Jahia site and have to connect first to Google Analytics.

This module in the Admin Center will help you configure Google Analytic (GA) for the current site. All you need to do is to already have a GA profile and configure it by clicking the Add button on the page.
Other analytic tools can of course also be used within Jahia such as WebTrends or Urchin. However, you will need to configure them manually (and to create a dedicated toolbar if you want further in-depth integration with such analytics tools).
 

Jahia Template (aka the skeleton of the future page) are separated from themes (look&feel of the generated page composed of CSS elements). A template set can then embed several sub-themes.
Themes could be used to change the look and feel of a site. For instance a template developer could develop a generic all-purpose template set that could be used across several sub-sites. However as each sub-site (= each department, each product, each community,…) wants its own CSS, the template developer developed a series of extra themes that could be used on top of the current template set.

Themes could be also used to quickly switch the look and feel of a site to another one. For instance you may decide to have one CSS per season (winter, spring, summer, fall) and to switch the display of you site from one season to the other. You can then instantly do this through this menu without loosing your content or pages.
Please go to the Template Development Guide to learn about how to create, add or remove a theme to an existing template set.

Let’s now see the options available from the Server Administration Panel and that are traditionally available for the Root/Super Administrator only.
Options available at this stage directly impact the physical server (e.g: Patch Management) or all the hosted virtual sites (e.g: Adding a Portlet adds it on every virtual site, same is true for Categories). This is also the default section where you can add, update or delete virtual sites.
Similar to the Site Settings modules, the Super Administratror can delegate access to one, some or all the modules to other users through the “Manage Server Permissions” menu.

 

You can create multiple virtual web sites within one physical Jahia server, with its own set of pages, content, files, etc….
The Jahia Virtual Site paradigm acts more as a notion of “Virtual Spaces” rather than being able to create true physically independent web sites.

Each sub-site is getting:

• its own domain and site name (e.g: you can have one website accessible through the url www.first_domain.com and another one through www.second_domain.com, both running on the same Jahia server)
• its own sitemap
• its own search index
• its own virtual space in the DMS or in the Mashup Manager
• its own set of groups (e.g: you can have an “Authors” group on site A different from the “Authors” group on site B)
• its own settings (cf: previous chapters)
• However each site is cross-sharing:
• the same database and API: you can programmatically access content hosted on other sites if you have to
• the same template set (for sites that are reusing the same template set). So a change in a template set will impact all sites using it.
• the same category tree
• the same portlets and mashups
• the same users (LDAP or Jahia users)

 

Creating a new virtual site is useful if you have to manage several web initiatives (web, intranets or extranets) that would share the same sets of categories, portlets, users or templates. This could be also useful in order to avoid having to manage one single major Intranet and to split it in more fractioned web initiatives. This could help to better delegate permissions, search only in the current site (even if you can also perform cross-sites queries) or manage different sitemaps, themes or groups per site.
However virtual sites should not be used to create independently hosted web sites as per the aforementioned definition.
You can access the list of all existing virtual sites from the main menu of this module.
The default site is listed with a green arrow. This site is available directly through the url without having to mention the site key (e.g: www.acme.com). For other sites you will have to indicate the site key in the url to be redirected to the right site (e.g: www.acme.com/cms/site/demo). You can of course map such an url to your DNS in order to avoid having such troubles.
Operations to update some site properties (you cannot change the site key once created), to delete a site, re-index a site or export a whole virtual site are available next to each available virtual site.
 
When deleting an existing virtual site you will see a “Purge Option”. If you turn it on, the deletion of the virtual site will not only delete all pages and web content attached to this site but also all binary documents stored in the dedicated document space available for this site (each virtual site has its own document wallet in the Jahia DMS). You may also want to keep such binary documents and only delete the web pages.

You have three ways of creating a new virtual site:

1. Use the “Add a new Site” action. This will create a new blank virtual site only with the home page being available.
2. Use one of the prepackaged demo sites. By default Jahia is provided with two prepackaged demo sites:
   
   1. The “Corporate Demo” is a trial brochureware-oriented website, mainly used for end-user training purposes
   2. The “TCK” website is mainly targeted for template developers and illustrates all the combination of use of the possible underlying Jahia API.
      You may of course replace these demo sites or add new ones in your local installation. These prepackaged sites could then serve as a basis for new “project spaces” creation, new “product satellite sub-site” or new “event-oriented occasional sites”. Please check with your Jahia developer in order to know how to insert a pre-packaged skeleton of a ready-to-use website.
3. Finally you can also use the “Import Archive” function. This option is mainly used by System Administrator in order to import a site from another server (e.g: exporting a site from a pre-production server and importing the content back into a production server). If you developed a web site skeleton as part of another available web site (just a couple of pre-populated pages corresponding to the usual default pages and content), you can also easily export it locally into a ZIP file and reuse such an archive as a new “site skeleton”.

The process of the two latter options is quite basic as you only have to select one of the pre-configured demo site or to upload an existing site archive.
So we will now see in more details the process of creating a new blank virtual site.
To add a new virtual site, click on Add a new site. A three steps wizard will be launched.


Step 1: Enter Details about your new site
 
First, enter a site title. The site title will appear in your user interface when having to choose one of the available virtual site.
Then enter a site server name. This indicates the name of the server on which Jahia runs. You can specify a URL for the site server name, for example www.mycompany.com, and if your DNS is correctly configured, you will be able to access this virtual site by directly typing this url:

http://www.mycompany.com/

If you do not want to map to any DNS, please enter: “localhost” or the IP address of your server.
You also need to enter a site key. This is a keyword that will be used in the url to access this specific virtual site. For example, if you use localhost address and want to access one the hosted virtual site called ACME, the url will look like:
 

http://localhost:8080/cms/site/ACME

Finally you can check the Enforce password policy checkbox to activate the ”Password policy” protection. This will enforce the pre-defined password policy for every new user created on this site. See the related section to learn more about the Password policy later one.
Select the second checkbox if you would like to make this virtual site become the default one. It means that if you type the base url of jahia (i.e  http://localhost:8080/cms), you will be immediately redirected to the home page of this particular site rather than on another one. You can of course only have one single default site per Jahia server. So turning on this option will certainly turn it off on another virtual site.
The description area lets you describe the current site.
Finally you will have to define who will be the default site administrator for this site under creation. The site administrator will be able to manage users, groups, templates and components for his/her site but will not be able to access the Server Settings (cf: previous chapter). Then, you have the choice of either creating a new user for this role or to select the administrator of another existing virtual site. In all cases a new “Administrators” group will be created. You may also decide to avoid the creation of a new generic administrator account and to assign some existing users to this “Administrators” group later on.
Then click on the Next step button.
If you selected New User, you will have to enter additional information in order to create the new site administrator account.  If you selected the second option, you will then have to choose the web site from which you want to select the administrator as the new “webmaster” for the site under creation.

Step 2: Select the template set
After this step, you will have to choose the default set of templates that will be used. Template Sets could be shared among several sites. This means that if the template developer modifies a template, this will impact all virtual sites relying on that template set.
Once the template chosen, you will not be able to modify it as content definitions are also currently bundled within the Template Set. So be sure to select it carefully.
 
The system will also require the selection of the default theme (if there are several themes pre-packaged within this template set). You will be able to change the theme later on if needed (cf: previous chapter).
Finally you will have to choose the default language for this site. This is the first language configured for the new site under creation. You will of course be able to add additional language later on. However you will not be able to delete this first selected language. So choose it carefully.

Step 3: Confirmation Screen
Finally, you will get a confirmation screen listing all your options. Approve this screen and your new virtual site will be then created.
The site will be then listed on the main user interface of this module and will be also available from the “Site Settings” Panel from within the administration center (or directly from the url if you remember it by heart).
So in order to quickly take a look to your new created site, simply switch the “Site Settings” panel, choose your new created site in the list of available sites and once the page reloaded click on Exit From Administration. You should be redirected to your new blank website.

 

Content inside Jahia can be categorized for easy retrieval. It means that you can create a series of categories and sub-categories and Jahia objects can be later on associated to one or many of them. Pages, lists and content objects can be categorized. You can then for example recover in a Jahia template all objects belonging to one category or all categories associated with a content object.
You could for instance recover on a departmental home page all news published throughout the site that have been also associated to the category of this department. You can even re-use content from other virtual site on the same jahia server through the category mechanism, as content categorized can be retrieved throughout all virtual sites.
 
Figure 3 7: List of already created categories
For each category, you can also define one or many associated properties. For instance, you can define as a property the home page associated to this category, a description of the category or any other associated properties. Such properties can of course be retrieved inside a Jahia template for further usage.
To add a new category, select where you want to create your new category in the category tree and click on the Add new category button.

Enter the category key (a unique identifier for each category throughout all the virtual sites), the category title for each language available on your Jahia server (if no title is entered in a language, the category key will be used as a title). If needed only enter a property name and a value and click on the Apply button. You can enter as many properties as needed.
Now when you update a page, a list or a content item on your web site, click on the “Metadata” section. You should see the list of categories you just created under the “Categories” field.
 

Please note that the template developer may only map a sub-view of the overall category tree in a Jahia Category field. This will let him ensure that the editor can only enter a sub-set of categories. You can also use this mechanism if you want to have a dedicated set of category per site. Simply add at the first level of your category tree the list of all your virtual site and only map such a category sub-tree on each of the virtual site.

You can access other standard operations to manage your existing category tree from the main view of this menu (delete, update, cut, paste, …).

You can also use an embedded Category Import and Export feature. This mechanism uses a standard XML file output/input. If your company is already using a large classification tree a developer could easily convert such a tree into the related XML file and automatically import such categories back into the Jahia system.
 

From this menu you can change the email settings that were initially defined during the Jahia Installation Wizard.

In case you want to use the e-mail notification feature, please enter your mail server address (SMTP server), as well as the Super Administrator e-mail address and the e-mail address from where the notification will be originated from.

Please see the details for each input field below:

 

1. The "Mail server": field contains the SMTP host name, optionally with some advanced options.

Advanced options are:
- port number: if it differs from the standard SMTP port 25
- user and password: in case the STMP server requires authentication
- additional settings: e.g. to enable TLS
The format of the "Mail server" field value is as follows:

<user>:<password>@<smtp-host>:<smtp-port>[parameterName1=parameterValue1,parameterName2=parameterValue2,...]

All parts except <smtp-host> are optional. See use cases below.
 

2. The "Mail administrator": field contains a single e-mail address or multiple addresses separated by comma of users who will receive system-level notifications (if this option is enabled)

- "Mail from": the default sender e-mail address for an e-mail message

Here are several use cases for "Mail server" field values:
1. SMTP server does not require authentication and uses standard port 25:
smtp.acme.com

2. SMTP server require authentication and uses non-standard port 11019:
myuser:secretpassword@smtp.acme.com:11019

3. GMail example: SMTP server requires authentication and TLS enabled:
acme@gmail.com:mypassword@smtp.gmail.com:587[mail.smtp.starttls.enable=true]

4. Enabling mail server debugging option to see the details of e-mail server communication:
smtp.acme.com:25[mail.debug=true]

The event notification level (from Disabled to Paranoid) is only used to send errors emails to the Super Administrator(s). These event notifications will usually help you solve problems when you are testing newly designed templates that are still containing errors. Event notification can also be used to detect sudden exceptions on the system on a system in production.
 

 

Jahia natively supports JSR168 or JSR286 Portlets. They can be easily deployed and used within Jahia.
A portlet is usually a generic application that can have several instances. For example the Site Administrator may decide to deploy a new “RSS Portlet”. Such a portlet usually serve as a generic web application skeleton to integrate various RSS feeds onto different pages or on different virtual sites. Each of these portlet instances will then be saved and listed as part of the Jahia Mashup Manager.
So the generic underlying JSR168/286 portlet is managed through the Administration Center. The Super Administrator will be able to define here which users will be entitled to create a new instance of this generic portlet.
However each instance of a portlet (= each RSS feed) will be directly managed through the Mashup Manager available in the default Edition Toolbar. Each of these portlet instances could of course also inherit from dedicated permissions. But, as opposed to generic portlets that are shared across all virtual sites, you can perfectly decide to restrict the usage of a portlet instance to one given site or to one single user.
Please refer to the Jahiapedia - Portlet Integration section available on the Jahia.org website to learn how to develop new applications or adapt your already existing Java applications to work within the Jahia context.

From a similar manner to the Virtual Site Management menu, you will find the list of all portlets installed on your server in the upper part of the main view. You can click on the action icons to get more details about the portlet, to manage its permission rights or to access the portlet’s audit trails.

By default Portlets are only available for the Super Administrator. This means that an Editor could not create and add a new instance of such a portlet while the Super Administrator did not grant to him some additional rights. So do not forget to modify the default permissions when deploying new portlets and to add the specific editors.

To deploy a portlet in the Tomcat application server with Jahia, there is one technical operation that you need to do in your war file. This manipulation is described when you click on the help button. This modification can be made automatically by clicking on the “Prepare and deploy war” or on the “Prepare war” commands.

Then the Deploy to the application server will deploy your portlet to the Tomcat application server.  If you are using another application server, you should use the web application deployment utility provided with your application server. Please rather use the “Open Server applications manager” button that will redirect you to your underlying application server.
Be sure to read the Deployment in Another Application Server paragraph in the help section before deploying any new portlet.
 

Jahia natively supports JSR168 or JSR286 Portlets. They can be easily deployed and used within Jahia.
A portlet is usually a generic application that can have several instances. For example the Site Administrator may decide to deploy a new “RSS Portlet.” Such a portlet usually serves as a generic web application skeleton to integrate various RSS feeds onto different pages or on different virtual sites. Each of these portlet instances will then be saved and listed as part of the Jahia Mashup Manager.
So the generic underlying JSR168/286 portlet is managed through the Administration Center, where the Super Administrator can define which users are entitled to create a new instance of this generic portlet.
However, each instance of a portlet (each RSS feed) will be directly managed through the Mashup Manager available in the default Edition Toolbar. Each of these portlet instances could also inherit from dedicated permissions. But, as opposed to generic portlets that are shared across all virtual sites, you can easily decide to restrict the use of a portlet instance to a given site or a single user.
In this section we will detail how to adapt, deploy and integrate portlets into your jahia web sites.
 

Preparation :

Your portlet has to be prepared, in order to be deployed into Jahia.
Please follow the following steps; the example provided is called “BookmarkPortlet”.

1-    First, uncompress the contents of the WAR file into a temporary directory, with commands such as:

mkdir bookmarkportlet
cd bookmarkportlet
jar xvf ../bookmarkportlet.war
 
2-    Looking at the WEB-INF/portlet.xml file we notice the following Portlet declaration:

<portlet>
<portlet-name>BookmarkPortlet</portlet-name>
<portlet-class>
...
</portlet>
 
Basically we need to add a special « communication » servlet for each portlet. As it is a servlet, we will need to add it to the WEB-INF/web.xml deployment descriptor file.

3-    The default WEB-INF/web.xml looks like this:
 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<display-name>Bookmark Portlet</display-name>
</web-app>

We will modify it to look like this:

<?xml version="1.0" encoding="UTF-8"?>

      <!DOCTYPE web-app

      PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"

      "http://java.sun.com/dtd/web-app_2_3.dtd">

      <web-app>
  
      <display-name>Bookmark Portlet</display-name>
      <servlet>
      
      <servlet-name>BookmarkPortlet</servlet-name>
      
      <servlet-class>
      org.apache.pluto.core.PortletServlet</servlet-class>
      
      <init-param>
          
      <param-name>portlet-name</param-name>

      <param-value>BookmarkPortlet</param-value>
      </init-param>
      
      <load-on-startup>1</load-on-startup>

      </servlet>
      <servlet-mapping>
      <servlet-name>BookmarkPortlet</servlet-name>

      <url-pattern>/PlutoInvoker/BookmarkPortlet</url-pattern>
      </servlet-mapping>

      </web-app>

 
4-    All that is now left to do is to repackage the portlet. You can do this with the following command, executed from the directory in which we uncompressed the portlet:
jar cvf ../bookmarkportlet-jahia.war
 

Configuration:

The parameter portletAJAXRenderingActivated in the WEB-INF/et/config/jahia.properties configuration file is set to true by default. But on some occasions, the parameter portletAJAXRenderingActivated in the WEB-INF/et/config/jahia.properties configuration file must be set to false to allow some portlets to display properly.
 

Here are step-by-step instructions to help you deploy your own portlets inside Jahia.

1. Log into Jahia as an administrator
2. Go to the Jahia administration panel
3. Click on the “Server settings” tab
4. Choose the “Manage portlets” menu, the list of applications deployed alongside Jahia is displayed:
   
   
   
   Depending on whether you have modified the web.xml file for the portlet (see chapter 2 of this document for detailed instruction), you will either “Prepare and deploy war” for the new portlet, or just “Deploy new portlet”.
    
5. If you have completed the preparation procedure detailed in chapter 2 of this document, click the  “Browse…” button in the “Deploy to the application server” section, select the portlet WAR to deploy, and then click the “Deploy new portlets” button.
    
6. If you have not completed the preparation procedure detailed in chapter 2 of this document, you can try clicking the  “Browse…” button in the “Prepare portlet for deployment” section, select the portlet WAR to deploy, and then click the “Prepare and deploy war” button. This will automatically perform the modifications to the portlet’s web.xml file detailed in chapter 2. If that fails (errors in the server log would point to a faulty web.xml file), it is then necessary to manually perform those modifications (see chapter 2).
    
7. Your portlet is now available on the application server, and should appear in the list on the “Manage portlets” administration screen, sometimes after a small delay requiring a reload of the page. Refer to the server log to check success or failure of the operation.

 

Before the portlet can be displayed in a page, it has to be declared in the Jahia Mash-up Manager. Please quit the administration panel and go to the next section of this documentation.

 

You now have to declare the portlet as a mash-up in Jahia. Logged in as an administrator, you will have the Mash-up Manager available in the Tools menu.

 

Click  “Mashup Manager” item in the “Tools” menu. A new window is opened:

 

By default, the manager is positioned on the root folder for the current virtual site. If you want the portlet to be available for all your web sites, you should declare it in the “Shared Mashups” section (on the left). In both cases, declarations is performed as follows:

1. Select a directory for your portlet. You can declare it at the root of your web site folder or create a sub folder. To create a sub folder click the folder icon.

 

2. Once you have selected the folder, click the “New mashup” icon.

3. A popup window is opened, allowing you to configure your mashup step by step through a wizard. Step 1 will display the list of available portlets, from the WAR files that were deployed on the server (see previous chapter). If the portlet you want to declare is not in the list, chances are an error occurred when deploying the WAR file in the administration; please check the server log to identify the problem. Then, select the portlet you want to declare, and click the “Next” button.

4. Step 2 of the wizard allows you to enter information about the mash-up. None of it is mandatory.

5. Depending on your portlet, you can map roles to users or groups declared in Jahia. In the following example, we’re declaring that members of the Jahia “webmasters” group have administrator’s access to the portlet.

6. At the step 4, you can specify which users or groups can access the different modes supported by the portlet (usually Edit or Help, but each portlet can declare its own specific modes).

7. The last step allows you to enter the name of your mashup (the name under which it will appear in the mash-ups list).

8. Your portlet is now declared as a mash-up in Jahia, and you will be able to insert it into a web page. Please see the next section to discover how to do it.
    

 

Your portlet is now available as a mash-up in Jahia. So please go on a page with a template where you can add a mashup. In the “Web templates” set provided with Jahia 6.0, both the “My portal” and the “Full page” templates allow that. Here’s how it would work with the “Full page” template:

 

Click the “Add to list” button in the Portlet section, and browse the repository to select your mashup:

 

Once you have selected the mash-up in the edit pop-up window, and clicked OK, the portlet is displayed in the “Portlet” section of the page.

 

Be sure to publish your page through the workflow if you want the portlet to be displayed in Live view.

 

Jahia keeps track of all events generated by the system (add, delete, update... type of operations) with the date, the time and the user who performed the action.
To display the audit logs, click on view logs.

The Jahia audit log can be filtered or directly exported in various different formats.
As the amount of logs can grow fairly rapidly, you may also choose to purge them from time to time or to only keep a selection.

As a Super Administrator, you can of course change your personal settings (name, password, e-mail address,...) at any time.

Just update the information and click on the OK button.
 

The server status informs you about the state of Jahia’s various cache systems, as well as memory used and other available system information.


Such a module could be very useful in order to diagnose some potential problems. You can also use this interface to manually force the flush of one or of several back-end Jahia caches.
Jahia integrates three different levels of caches:

• Database caches (or Hibernate ORM caches)
• Object caches (in order to boost the usage of the underlying Jahia data model)
• HTML cache fragments (in order to avoid useless computing when an HTML fragment was already generated before). From this menu a super administrator will be able to access the second level caches (object caches) and to the third level caches (HTML fragments). Database caches (or Hibernate caches) could only be setup from within your database or in other configuration files.

Usually you do not have to manage anything as caches are updated and flushed transparently by the Jahia system. However for debugging purposes you may sometimes want to flush all caches (or only some of them) in order to ensure that caches still not include some obsolete values.
  Please note that the HTML cache could also be flushed directly from the related Edition Toolbar directly from the authoring environment. This avoids having to connect to the Admin Center or to delegate some permission to this more complex cache management menu to some super-editors in order to flush some HTML fragments.

The integrated HTML cache proxy provided with Jahia will certainly be the most sensible one. By default Jahia automatically split each pages in different fragments (usually one per content object) and caches all of them in memory. Jahia then tries to regroup all these fragments on a per group of users basis in order to improve the response time for the next users and avoid useless and time-consuming access to the database or to the application server. Access to pages already available in the HTML cache proxy can be between 10 and 20 times faster than non-cached pages. Of course, each time the content of a page is updated, the copy of the pages in memory will be automatically flushed by the system.
The HTML cache could also be accessed programmatically from within the template. So for dynamic areas (e.g: a RSS feed box), the template developer may want to manually enforce the flush of such a fragment based on a time frequency (e.g: every hour) rather than letting the system managing it. An editor could then see some delay between the real content and the cache one. Power users (via the Cache Toolbar) or Super Administrator (via this module) can then force the flush of the HTML cache if needed.
To get more information about the cache systems, take a look to the Jahiapedia - Architecture Overview available on the Jahia.org website or read more about it in the Jahia Configuration and Fine Tuning Guide.

Finally you can also access a “Lock” sub-menu from within this module. This option allows you flush all the current edition locks. When an editor performs operation on content, the targetes items are temporarily locked (e.g: if you edit a content objet, this item is temporarily locked while the editor is editing it).
Such edition locks (Do not mix it with the Workflow locks that prevents editors to edit content while the page is being validated) could be sometimes not correctly flushed (e.g: if the editor crashes his browser, the edition lock will stay on the server). Edition locks usually have an expiration time fixed at 30 minutes (session time) and are automatically cancelled after such a period of time. But if, for any reasons, you want to force the flush of all edition locks before this timeframe, you can do it from this sub-menu.
 

Similar to the Manage Site Permissions at the Site Settings level, this section lets super administrators delegate the access to one, some or all the sub-modules listed in the Server Settings section to some power users.

This module is more simple as the related “Manage Site Permissions” one as it only concerns the grant of permissions to modules available as part of the “Server Settings” part of the Admin Center.
Usually the Root/Super Administrator user only delegates some access rights on the “Manage Categories” module or on the “Virtual Site Management” one.
 

Similar to the Manage Site Permissions at the Site Settings level, this section lets super administrators delegate the access to one, some or all the sub-modules listed in the Server Settings section to some power users.

This module is more simple as the related “Manage Site Permissions” one as it only concerns the grant of permissions to modules available as part of the “Server Settings” part of the Admin Center.
Usually the Root/Super Administrator user only delegates some access rights on the “Manage Categories” module or on the “Virtual Site Management” one.
 

The Password policy is a set of common settings and rules for validating the password syntax, expiration period and age, password history, administration rights and reset options of the users’ passwords.

For certain types of sites (e.g: some public extranets that requires authentication schema from logged end-users), the Super Administrator may decide to better protect access to such restricted data and avoid that logged users could use too simple password protection schema. The Super administrator may also require that such users have to modify their password every two or three months. He can then customize such a password policy from within this menu.
You can have one password policy schema for all your dedicated virtual sites. In order to turn this option on, you have to update a virtual site (cf: Virtual Site Management module) and activate it. The Super Administrator can then decide precisely which virtual sites and which local users should respect such a policy (e.g: only logged users on the public Extranets but not logged users on the private intranet).

It is important to mention that the password policy will not take effect on users that come from the “read-only” providers such as. LDAP or Active Directory servers. Such a policy only affects local Jahia users.
 

The Patch Management Module was developed in order to list some additional patches provided from time to time by the editor and that you can fire directly from this menu.

Please check the documentation delivered with each patch in order to know precisely how to use it.

This shortcut redirects you to the Jahia online bug tracking system.

Two bug tracking systems exist:

• the free community one available on the Jahia.org and available to everybody
• the commercial one available on the Jahia.com extranet and only available to commercial customers

The community bug tracking system is also used in order to list improvement ideas or possible functional enhancements. So do not hesitate to visit it and share your feedback about the software with the Jahia development community. These tickets are visible by everyone and are not private: please only contribute generic information not related to your custom Jahia environment, you custom template set or your private data.
The commercial bug tracking system is only available for paying customers. Each Jahia customer has its own dedicated bug issue tracking module only available with a login and password. All bug or assistance tickets entered in this system will only be available by customers and employees of Jahia. Tickets are not shared with other customers or other developers in the Jahia community. As this service is commercial it also includes a SLA (Service Level Agreement), that guarantees an answer from the Jahia team within a short period of time (please check on your contract). The commercial bug tracking system is mainly used for non-generic bugs or requests for assistance on your custom environements.

This page redirects you to the Jahia 6 documentation space.
Similar to the bug tracking systems, the documentation is split between the available community one (as part of the Jahiapedia section on the Jahia.org website) and the commercial one only available for Enterprise Edition customers.
Most of the documentation is available for free. However some modules or extensions of the product are only available to enterprise users (e.g: Connectors to other ECM systems).
 

Finally the About Jahia module summarizes the options available as part of your current license key. According to your type of license (community vs commercial editions and then standard vs enterprise editions) you might have access or not to certain extensions.

In this section you will also find your Jahia build and version number (that is also indicated in the footer of all edition windows or on the Admin Center). It is important to specify it when you report a bug in our bug tracking system.