Each content block can be further customized with different content, personalized to the current site visitor. When this feature is enabled, the content editor includes an additional drop down menu to select which personalized version of the content to edit. This version of the content will be displayed to the user if their visit matches the predefined user persona for that personalized content block.
If a personalized version of the content is not set, the default content will be displayed. Even if the user matches a given persona criteria.
In the environment configuration file in
~/humblee/configuration set the
use_p13n flag to
CMS users with the "designer" or "developer" role can then use the "Personalization Personas" tool to add and edit the individual persona criteria to be used. Humblee comes pre-configured with just a few personalization options pre-defined, including "time of day," "required role" and "i18n URL segments" (see below.) To add you own personalization criteria edit the
testCriteria() method in
While general personalization criteria can test against numerous factors, such as preset $_SESSION variables, authorization roles, or even the time of day, you may wish to implement a more global URL based method for filtering specific demographics. Commonly this method is used for offering multiple language translations of content by prefixing the URI slug with a language or country abbreviation, such as "EN" for English or "ES" for Spanish.
To implement this functionality with Humblee, update your environment configuration file in
~/humblee/configuration and set the
i18n_segments variable to an array of the allowed URL segments you would like to use.
'use_p13n' => true, 'i18n_segments' => array('es','de','en'),
With the above setting enabled, any page, such as my-site.tld/hello-world, can also be accessed like
To customize the content for these pseudo pages, create a personalization persona (see below) that checks for the URL segment, then update the content through the content editor as normal.
CMS users with the designer or developer roles have access to the "personalization Personas" tool. The form on this tool has a few parts. The first section allows you to create the friendly name of the persona and give it a description. You can also check or uncheck the "active" checkbox to suppress the persona criteria from being considered on page load.
The guts of the persona are the "criteria" that are checked to see if a given user's visit matches the personalization persona. These criteria are stored in the database as a JSON object but the tool includes a handy "criteria builder" to manage the rules via a relatively simple UI.
Criteria rules are grouped by programmatic "And" and "Or" conditional operators. In order for a criteria to be met, all of the "and" rules in an "or" block must be true.
Also on the "Personalization Personas" tool page is the ability to drag and drop the order of the personas to be matched. When loading a page, a given user will be assigned the first persona they match. If they match more than one persona, only the first one on the priority list is used. It is important to make sure that personas with more specific criteria have a higher priority than similar personas with a more general set of rules.
For example, if you have one persona that checks that i18n segment and another that checks for both the i18n segment and also requires a given user role, than the latter should have a higher priority. Otherwise, a user who does match both criteria would only be assigned the simpler i18n persona. With the more complex criteria listed first, a user that only matches a portion of the criteria (such as just the i18n) will not meet that persona, but will still be caught by the more appropriate personalization further down the list.