Assistance with Open Source adoption

Open Source News

Customize Elastic Search and Search by Synonyms in Liferay

Liferay - Sat, 02/24/2018 - 08:52

Q-Have you ever wondered if you can customize your Elastic Search, so that on your searches in Liferay, not only the words you're searching for come up in the results but also synonyms of these words?

A-Yes, you can!

Below, I'll show you an example of how I did it (by customizing my indexes and mappings settings).

Let's say that I have a web content article containing the word "small" and I search for the word "tiny".

  1. Navigate to Control Panel → Configuration → System Settings → Foundation
  2. Search for the system setting.
  3. Go to "Aditional index configurations" and add your own.

    You can start by copying the contents of your index-settings.json file there. Your index-settings.json file is packed in the Elastic Search module of your Liferay bundle.

    Now, modify it as this document describes: .

    It should look like the image below (note the "synonyms" part of the json, where we wrote our list of synonyms):
  4. Now go to "Override type mappings" and copy into the text area input the contents of the file "liferay-type-mappings.json", also packed in the Elastic Search module (a jar that you will find in your Liferay bundle) into it.

    Modify it, also following the steps this document describes: (as in the previous step).

    For example, you could add something like this:
      "content": {      "index": "analyzed",      "store": "yes",                "search_analyzer" : "my_synonym_analyzer",                "analyzer" : "my_synonym_analyzer",                "term_vector": "with_positions_offsets",                "type": "string"   },
    and something like this:
     "title": { "index": "analyzed", "store": "yes",                "search_analyzer" : "my_synonym_analyzer",                "analyzer" : "my_synonym_analyzer", "term_vector": "with_positions_offsets", "type": "string" },
    to it:

  5. Save your changes
  6. Navigate to Control Panel → Configuration → Server Administration and execute "Reindex all search indexes" under the section "Index Actions"

  7. Perform a search and... Voila!, the magic happens:

    Easy, right?

    If Elastic Search can do it, Liferay will do it too (since it leverages on Elastic Search for indexing its documents). You just need to know it can be done, and where in the control panel you can configure it.
Carlos Hernandez 2018-02-24T13:52:38Z
Categories: CMS, ECM

How to Upgrade to Liferay 7.0+

Liferay - Fri, 02/23/2018 - 15:35

So the question comes up how to do Liferay upgrades.

I'm not talking here about the technical details of how you upgrade one particular plugin to another type of plugin, what kinds of API changes have to be made, etc.

Instead, I'm thinking more about the general process of how to upgrade, what choices you're presented with and what the ramifications are for making certain choices.

Upgrades Are Projects

The first thing to remember is that upgrades are projects. You should totally build them out as projects, you should have a project plan, you should have a project team, ... Having a full project plan forces you to define scope for the upgrade and time box all activities so you will know how the project is proceeding.

As a project, you also should have a risk assessment/mitigation plan. Know in advance what you will do if the project runs long or runs into issues. Will you just stretch the timeline? Will you seek help from Liferay GS or a Liferay Partner? Are you sending your development team to Liferay training in advance or only if they seem to struggle? Will you rely on LESA tickets, Liferay documentation, community support via the forums or slack?

Liferay GS offers an Upgrade Assessment package where an experienced Liferay GS consultant will come onsite to review your environment and build a customized report outlining what your upgrade effort will be. This assessment can become the foundation of your project planning and can help set your upgrade in the right direction.

Upgrades Have Scopes

Upgrading from Liferay 6.2 to Liferay DXP 7.1, there will be scope to this project and the project is susceptible to scope creep.

For example, you might decide going in that your project is simply to get what you currently have migrated and running under DXP. During the upgrade project, though, you might decide to add some backlogged features or refactor your codebase or rework legacy portlet wars into OSGi portlet modules. Each of these things would be considered scope creep. Each change like these that the team takes on will negatively impact your project plan and schedule.

Upgrades Expose Bad Practices

The one thing I've found is that upgrades tend to expose bad practices. This could be bad practices such as using an ORM package instead of Service Builder for data access. It could be a non-standard way of decoupling code such as making all service calls via remote web services where a local service implementation would have been an easier path. It can expose when standard design practices such as design by interface were not fully leveraged. It could be as simple as having used an EXT plugin to do something that should have been handled by a JSP hook or a separate custom implementation.

Exposing bad practices may not seem very important, but upgrading bad practices will always add to a project plan. Something done initially as a shortcut or a hack, these things get difficult to carry forward in an upgrade.

The one thing I've found in 10+ years of experience with Liferay, it is often better to do things "The Liferay Way". It is not always easy and may not seem like the right way, but it usually ends up being the better way generally to develop for the platform.

Upgrade Project Recommendations

To facilitate your upgrade project, I offer the following recommendations:

  • Limit scope. As far as the upgrade is concerned, limit the project scope to getting what you currently have running under the later version. Do not consider refactoring code, do not consider reworking portlet wars as OSGi modules, etc. Limit the scope to just get on the new version. If you want to refactor or rework wars as OSGi modules, save that for a later project or phase.


  • Leave portlet wars as portlet wars. I can't say this strongly enough. It is absolutely not necessary for your legacy portlet wars to be refactored as OSGi modules. Your legacy portlet wars can be deployed to DXP (after necessary API changes) and they will automagically be converted into an OSGi WAB for you. Do not spend your upgrade cycles reworking these into OSGi bundles yourself, it is a complete waste of your time and effort.


  • Only rework what you have to rework. You'll have to touch legacy hooks and EXT plugins, there is no way around that. But that is where your upgrade cycles need to be spent. So spend them there.


  • Rethink upgrading bad practices. I know, I said limit scope and migrate what you have. The one exception I make to this rule is if you have exposed some really bad practices. In the long run, it can often be a smaller level of effort to rework the code to eliminate the bad practice first or as part of the upgrade. Cleaner code is easier than spaghetti to upgrade.


  • Use Liferay IDE tooling. The Liferay IDE comes with a built-in upgrade assistant tool. While the tool is not perfect, it can help you upgrade your Maven and Plugin SDK projects to be compatible with the later version, including suggesting and making necessary API changes for you. If you do not use the upgrade assistant, you are willfullly missing out on an automated way to start your upgrade.


  • Have a Backup Plan. Know in advance if you are going to leverage Liferay GS or a Liferay Partner to help complete your upgrade in case you are seeing delays. If you wait until you are behind the eight-ball before mitigating your risk, you will be less prepared to get the project back on track if it is going off the rails.


  • Get a Liferay Upgrade Assessment Package. Even if you are going to do all of the work in house, an upgrade assessment can highlight all of the aspects you and your team will need to consider.

That's pretty much it.  Have any horror stories or suggestions you'd like to share? Please add them below...

David H Nebinger 2018-02-23T20:35:41Z
Categories: CMS, ECM

Deploying Liferay 7.0 on to Tomcat 8.5

Liferay - Fri, 02/23/2018 - 13:21

Tomcat 8.5 is an in-between version of Apache Tomcam 8.0 and 9.0. According to the Apache site, it contains some features in 9.0 that have been backported to 8.0. This version of Tomcat is currently in the "Supported" matrix of the Liferay DXP Compatibility Matrix, and of course, the question is: How do I set up Liferay CE/DE 7.0 with Tomcat 8.5?

The short answer is: Exactly like you would on Tomcat 8.0, which can be found here. Much of this entry will be a reproduction of those steps. The order of the steps will be a little different.

This blog post will cover the bare minimum to get Liferay CE/DE 7.0 working on Tomcat 8.5, skipping some of the extraneous steps or providing alternate steps. These steps were run on a Windows 10 machine, but should be generally applicable to Linux environments as well. Differences will be noted. Despite having been done in Windows, "forward" slashes aka "/" will be used, as that is how Tomcat wants directories to be marked.


$TOMCAT_HOME - location of the Tomcat 8.5 directory, usually inside $LIFERAY_HOME

$LIFERAY_HOME - location of the Liferay directory that will contain Tomcat, and all the usual Liferay directories, like data, deploy, logs, osgi, etc... This directory can be located anywhere.

Step 0 - Prerequisites
- Install Java JDK 8, and configure the JAVA_HOME variable if not done already.
- Test the validity of the path by using the command "java -version" in the command prompt/terminal
- If there is a JRE_HOME variable set, remove it.

Step 1 - Acquire all the necessary files
- There are 3 required files provided by Liferay: the Liferay WAR, the Liferay dependencies, and Liferay OSGI dependencies.
- These steps were performed using Liferay DE 7.0 SP6, the portal portion of Liferay DXP. If you have a Liferay subscription and wish to also do the same, the files are available from Customer Portal, here. The files for Liferay CE 7.0 GA 5 can be found here. The individual files can be found down at the bottom of the page.
- There are a number of JAR files that are not included in default Tomcat that need to be acquired. They can either be copied over from a Liferay Tomcat bundle, or downloaded individually.

  • activation.jar
  • ccpp.jar
  • com.liferay.osgi.service.tracker.collections.jar
  • jms.jar
  • jta.jar
  • jutf7.jar
  • mail.jar
  • persistence.jar

Locations on where to get these files can be found in the regular Tomcat 8.0 steps.

REMINDER: Don't forget the database driver JAR file.

Step 2 - Extract dependency files
- Extract the Liferay dependency JARs to $TOMCAT_HOME/lib/ext. It will be necessary to create the "ext" directory.
- Extract the "osgi" directory from the OSGI dependency ZIP into $LIFERAY_HOME

Step 3 - Configure
- In $TOMCAT_HOME/conf/, find the "common.loader" property.
- Add the following to the end:



Replace the whole property


- This tells Tomcat that there are extra JAR files that it needs to recognize.

Step 4 - Configure catalina.policy
- Delete the contents of catalina.policy and replace it with:

grant { permission; };   - Yes, delete the contents of the file and replace it with the above 3 lines.

Step 5 - Configure server.xml
- In $TOMCAT_HOME/conf/server.xml, the URIEncoding needs to be set te UTF-8 for Tomcat. Add the property URIEncoding="UTF-8" into the 2 <Connector> sections. In the default server.xml, it will be on line 69 and 116. 

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8"/> AND <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" URIEncoding="UTF-8"/>

Step 6 - Configure ROOT.xml
- In $TOMCAT_HOME/conf, create Catalina/localhost/ROOT.xml
- Add the following to ROOT.xml

<Context path="" crossContext="true"> </Context>

- Note that in the original Tomcat 8.0 steps, there is a significant chunk of commented out settings. They are not used in this basic, minimal setup. If you are using JAAS, then yes, the commented out section is necessary.

Step 7 - Extract Liferay WAR
- Delete all the directories in $TOMCAT_HOME/webapps except for ROOT. These are just sample applications.
- Delete the contents of the ROOT directory. Alternatively, ROOT can be deleted along with the other sample directories and remade as empty.
- Unzip the contents of the Liferay WAR file into the now-empty ROOT directory.

Step 8 - Configure JVM
- This is where Windows and Linux diverge.
- In $TOMCAT_HOME/bin, create setenv.bat or, depending on OS.
- In setenv.bat, paste the following:

set "CATALINA_OPTS=%CATALINA_OPTS% -Dfile.encoding=UTF8 -Dorg.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES=false -Duser.timezone=GMT -Xmx2048m -XX:MaxMetaspaceSize=1024m"

- In, paste the following:

CATALINA_OPTS="$CATALINA_OPTS -Dfile.encoding=UTF8 -Dorg.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES=false -Duser.timezone=GMT -Xmx2048m -XX:MaxMetaspaceSize=1024m"

Note the following properties:
"-Xmx2048m" - Liferay 7.0 CAN be run with the default 1024m of JVM space, but it's not fun. I would suggest at least 2048m (2 GB) or higher for development work.

"-XX:MaxMetaspaceSize=1024m" - In Java 8, the property -XX:MaxPermSize was deprecated and is ignored. PermGen was replaced with Metaspace, which by default is unlimited. Setting it to 1024m is fine for development work.

Step 9 - (optional)
- In $LIFERAY_HOME, create or copy over a file. In the file, you can set various configurations like the database connection, and disabling of the setup-wizard.

Step 10 - Start it up
- There are 2 ways to start Tomcat from a command line/terminal.
- Executing or startup.bat will have the process run in the background and will not output log into the current window.
- Executing run or catalina.bat run will have the process run in the current command line and will output log into the window. If the window is closed, or the terminal session disconnected, then the process will stop.

Skipped Steps
- In comparison to the original Tomcat 8.0 setup steps, the following sections were skipped:
JNDI database configuration
Mail configuration

- The database and mail configuration can also be done via, in Step 9 above.

There are no specific steps that differ between Tomcat 8.0 and Tomcat 8.5. Essentially, steps are the same for a basic configuration of Tomcat 8.5 with Liferay 7.0 CE/DE. PACL and Mojarra may have some differences, but I've never used them. I believe Tomcat 8.5 is just a hair faster than Tomcat 8.0, but that's a subjective topic.

Jonas Choi 2018-02-23T18:21:43Z
Categories: CMS, ECM

Seis tendências de Experiência do Cliente para 2018

Liferay - Thu, 02/22/2018 - 14:46

O que define uma boa experiência do cliente está em constante transformação devido às constantes mudanças de comportamento do público e o uso de novas tecnologias. Entretanto, embora CX mude com o passar do tempo, sua importância para potenciais clientes e o sucesso dos negócios cresce a cada dia.

De acordo com um estudo feito pela Spigit, 75% das empresas pesquisadas em 2016 tinham como seu principal objetivo a melhoria da experiência do cliente. No entanto, a resposta para tornar isso possível encontra-se na continuidade. As seis tendências seguintes ajudarão você e seu negócio a criarem estratégias eficientes para atender às expectativas do seu público e atingir o sucesso com o passar do tempo.

1. Os Maiores Desafios Internos de uma Organização São Enfrentados na Experiência do Cliente

De acordo com uma pesquisa feita pela Forrester, os três maiores desafios na implementação de uma estratégia para a experiência do cliente são: a cultura da empresa (54%), sua estrutura organizacional (45%) e seus processos internos (41%). Todos esses obstáculos são, na maioria das vezes, associados ao CEO do negócio. Deste modo, 2018 pode ser um grande ano para empresas e CEOs principalmente, tomando decisões que poderiam permitir seus times a obter grandes ganhos em relação aos seus esforços de CX. CEOs e os departamentos deveriam focar na colaboração e comunicação efetivas para progredir substancialmente.

2. O Poder das Experiências sem Interrupções

Serviços como o Amazon Go lideram na criação de experiências de consumidores sem interrupções ao possibilitar compras online, até então realizadas apenas em supermercados, removendo o processo de checkout através de cobranças instantâneas. Como demonstrado pelo Customer Think, o público espera que as experiências avancem de maneira consistente e uma organização importante, como a Amazon, geralmente define os padrões para outros negócios. Neste caso, fazer compras sem obstáculos torna, o simples ato de comprar, fluido e mais rápido do que nunca.

3. Melhorando Experiências Baseadas na Localização

A tecnologia beacon tem sido usada por muitos anos, mas a sua adoção agora pode ser feita para deixar a experiência do cliente mais integrada e rápida. De acordo com a Dimension Data, os negócios estão trabalhando para fazer com que os pontos de contato físicos com o usuário sejam tão simples e eficientes como experiências onlines. Por exemplo, hotéis estão utilizando beacons para substituir chaves de quarto e empresas estão permitindo o acesso de colaboradores à locais seguros e informações sigilosas baseada na localização através dos beacons. A lacuna entre interações interpessoais e experiências online está cada vez menor. Clientes podem integrar todos os aspectos das suas atividades cotidianas às empresas.

4. Crescimento e Aperfeiçoamento da I.A. nas Operações de Negócios

A Inteligência Artificial terá papel importante em vários aspectos da experiência do cliente, mas garantir que isso aconteça depende da capacidade de reconhecer o discurso da sua audiência. A Customer Think detalhou como os sistemas de reconhecimento de voz podem ajudar os assistentes de voz a aprender rapidamente o modo como cada usuário fala, incluindo seus padrões, dialetos e sotaques únicos a fim de evitar a frustração e tornar seus papéis, nas empresas e em casa, essenciais no futuro. O Gartner prevê que 85% das interações dos clientes serão gerenciadas sem uma figura humana até o ano 2020, o que significa que sistemas automatizados e inteligência artificial gerenciarão a grande maioria dos processos. Com um uso cada vez maior de I.A. nas operações das empresas através de chatbots, agrupamento de dados, ferramentas de análise e muitos outros programas, espera-se que, em 2018, encontremos muitas outras empresas usando esta tecnologia de diversas maneiras.

5. Impulsionando o Gerenciamento de Identidade do Consumidor (CIAM)

Dados continuarão a ter importante função no modo como as organizações interagem com seus clientes. Por sua vez, empresas estão adotando o gerenciamento de identidade do consumidor (customer identity and access management - CIAM), que usa caraterísticas como o registro de clientes, autenticação “multi-fatores”, auto-gerenciamento de conta e administração do acesso a dados para escalar e personalizar canais para cada usuário e seus objetivos pessoais. Como discutido por Janrain, CIAM cria interações personalizadas elaborando estratégias de engajamento baseadas em insights de dados e na eliminação de obstáculos que podem afetar as experiências dos clientes. As empresas irão buscar este tipo de solução que seja robusta no gerenciamento e segurança de dados.

6. O Tempo se Torna um Produto

Enquanto ótimas experiências continuarem a ser uma prioridade, o The Economic Times destaca que o tempo de um cliente é um fator que se torna cada vez mais importante em cada interação. Desde realizar o processo de checkout o mais rápido possível a solucionar problemas de um item online obtendo respostas rapidamente através de chatbots, as empresas devem se esforçar para diminuir o tempo necessário dos clientes para receber os produtos ou serviços que eles desejam. Isso pode evitar que sua audiência se frustre e que potenciais clientes não abandonem sua jornada antes de concluí-la.

Mudanças para os Negócios Digitais em 2018

O modo como organizações realizam negócios e como elas são impactados pelas mudanças no marketing digital, irão, novamente, mudar em 2018. Leia mais sobre isso em negócios digitais.

  Transforme Sua Experiência do Cliente em 2018

Acompanhar as expectativas sobre experiência do cliente requer um software que está pronto para atender uma série de demandas. Leia mais sobre as estratégias possíveis com Liferay.

Leia Quatro Estratégias para Transformação Digital do Negócio   Isabella Rocha 2018-02-22T19:46:52Z
Categories: CMS, ECM

Drupal 8.5.0-rc1 is available for testing

Drupal - Thu, 02/22/2018 - 13:28

The first release candidate for the upcoming Drupal 8.5.0 release is now available for testing. Drupal 8.5.0 is expected to be released March 7.

Download Drupal-8.5.0-rc1

8.5.x makes the Media module available for all, improves migrations significantly, stabilizes the Content Moderation and Settings Tray modules, serves dynamic pages faster with BigPipe enabled by default, and introduces the new experimental Layout Builder module. The release includes several very important fixes for workflows of content translations and supports PHP 7.2. Finally, 8.5.0-rc1 also includes the same security updates that are provided in 8.4.5.

What does this mean to me? For Drupal 8 site owners

Drupal 8.4.5, a security update and the final release of the 8.4.x series, has also been released this week. 8.4.x sites should update immediately to 8.4.5, but going forward, 8.4.x will receive no further releases following 8.5.0's release date, and sites should prepare to update from 8.4.x to 8.5.x in order to continue getting bug and security fixes. Use update.php to update your 8.4.x sites to the 8.5.x series, just as you would to update from (e.g.) 8.4.2 to 8.4.3. You can use this release candidate to test the update. (Always back up your data before updating sites, and do not test updates in production.)

If you're an early tester who is already running 8.5.0-alpha1 or 8.5.0-beta1, you should update to 8.5.0-rc1 immediately. 8.5.0-rc1 includes security fixes (the same fixes that were released in Drupal 8.4.5).

Site owners should also take note of the fact that Drupal 8's support for PHP 5 will end in one year, in March 2019. PHP 7.2 is now the best recommended PHP version to use with Drupal 8.

For module and theme authors

Drupal 8.5.x is backwards-compatible with 8.4.x. However, it does include internal API changes and API changes to experimental modules, so some minor updates may be required. Review the change records for 8.5.x, and test modules and themes with the release candidate now.

For translators

Some text changes were made since Drupal 8.4.0. automatically offers these new and modified strings for translation. Strings are frozen with the release candidate, so translators can now update translations.

For core developers

All outstanding issues filed against 8.4.x were automatically migrated to 8.5.x. Future bug reports should be targeted against the 8.5.x branch. 8.6.x will remain open for new development during the 8.5.x release candidate phase. The 8.5.x branch will be subject to release candidate restrictions, with only critical fixes and certain other limited changes allowed.

Your bug reports help make Drupal better!

Release candidates are a chance to identify bugs for the upcoming release, so help us by searching the issue queue for any bugs you find, and filing a new issue if your bug has not been reported yet.

Categories: CMS

Drupal core - Critical - Multiple Vulnerabilities - SA-CORE-2018-001

Drupal - Wed, 02/21/2018 - 12:10
Project: Drupal coreVersion: 8.4.x-dev7.x-devDate: 2018-February-21Security risk: Critical 16∕25 AC:Basic/A:User/CI:Some/II:Some/E:Exploit/TD:DefaultVulnerability: Multiple Vulnerabilities Description: 

This security advisory fixes multiple vulnerabilities in both Drupal 7 and Drupal 8. See below for a list.

Comment reply form allows access to restricted content - Critical - Drupal 8 - CVE-2017-6926

Users with permission to post comments are able to view content and comments they do not have access to, and are also able to add comments to this content.

This vulnerability is mitigated by the fact that the comment system must be enabled and the attacker must have permission to post comments.

JavaScript cross-site scripting prevention is incomplete - Critical - Drupal 7 and Drupal 8 - CVE-2017-6927

Drupal has a Drupal.checkPlain() JavaScript function which is used to escape potentially dangerous text before outputting it to HTML (as JavaScript output does not typically go through Twig autoescaping). This function does not correctly handle all methods of injecting malicious HTML, leading to a cross-site scripting vulnerability under certain circumstances.

The PHP functions which Drupal provides for HTML escaping are not affected.

Private file access bypass - Moderately Critical - Drupal 7 - CVE-2017-6928

When using Drupal's private file system, Drupal will check to make sure a user has access to a file before allowing the user to view or download it. This check fails under certain conditions in which one module is trying to grant access to the file and another is trying to deny it, leading to an access bypass vulnerability.

This vulnerability is mitigated by the fact that it only occurs for unusual site configurations.

jQuery vulnerability with untrusted domains - Moderately Critical - Drupal 7 - CVE-2017-6929

A jQuery cross site scripting vulnerability is present when making Ajax requests to untrusted domains. This vulnerability is mitigated by the fact that it requires contributed or custom modules in order to exploit.

For Drupal 8, this vulnerability was already fixed in Drupal 8.4.0 in the Drupal core upgrade to jQuery 3. For Drupal 7, it is fixed in the current release (Drupal 7.57) for jQuery 1.4.4 (the version that ships with Drupal 7 core) as well as for other newer versions of jQuery that might be used on the site, for example using the jQuery Update module.

Language fallback can be incorrect on multilingual sites with node access restrictions - Moderately Critical - Drupal 8 - CVE-2017-6930

When using node access controls with a multilingual site, Drupal marks the untranslated version of a node as the default fallback for access queries. This fallback is used for languages that do not yet have a translated version of the created node. This can result in an access bypass vulnerability.

This issue is mitigated by the fact that it only applies to sites that a) use the Content Translation module; and b) use a node access module such as Domain Access which implement hook_node_access_records().

Note that the update will mark the node access tables as needing a rebuild, which will take a long time on sites with a large number of nodes.

Settings Tray access bypass - Moderately Critical - Drupal 8 - CVE-2017-6931

The Settings Tray module has a vulnerability that allows users to update certain data that they do not have the permissions for.

If you have implemented a Settings Tray form in contrib or a custom module, the correct access checks should be added. This release fixes the only two implementations in core, but does not harden against other such bypasses.

This vulnerability can be mitigated by disabling the Settings Tray module.

External link injection on 404 pages when linking to the current page - Less Critical - Drupal 7 - CVE-2017-6932

Drupal core has an external link injection vulnerability when the language switcher block is used. A similar vulnerability exists in various custom and contributed modules. This vulnerability could allow an attacker to trick users into unwillingly navigating to an external site.


Install the latest version:

Reported By: 
  • Comment reply form allows access to restricted content - Critical - Drupal 8
  • JavaScript cross-site scripting prevention is incomplete - Critical - Drupal 7 and Drupal 8)
  • Private file access bypass - Moderately Critical - Drupal 7
  • jQuery vulnerability with untrusted domains - Moderately Critical - Drupal 7
  • Language fallback can be incorrect on multilingual sites with node access restrictions - Moderately Critical - Drupal 8
  • Settings Tray access bypass - Moderately Critical - Drupal 8
  • External link injection on 404 pages when linking to the current page - Less Critical - Drupal 7
Fixed By: 
Categories: CMS

4 Ways to Build a Lasting Relationship with Your Customers

PrestaShop - Wed, 02/21/2018 - 04:19
Whether you’re a marketing rookie or a master, you already have one powerful tool at your disposal: your brain.
Categories: E-commerce

Why You Should Join the 7.1 Community Beta Program

Liferay - Tue, 02/20/2018 - 23:32

So Jamie just announced the new Liferay 7.1 Community Beta Program here:

I recommend everyone who has working code in Liferay 7.0 or Liferay DXP should join the 7.1 beta sooner rather than later.

Why? Well, mostly because Liferay's engineering team is focused on the 7.1 release, so anything that you find in beta, well that will be something that they will want to fix before release. Without those bug reports, some incompatibility that you encounter later on falls under the regular release process and that will only work against your release schedule.

Let's say, for example, that you have spent time building out a comprehensive audit solution for your Liferay 7.0/DXP environment where you have a slew of model listeners and a custom output mechanism to route the audit details to an ElasticSearch instance that you report on using Kibana. You've got a decent investment in your auditing solution, one that you plan on leveraging in 7.1 on.

You're basically looking at two choices.  Choice #1 is to do nothing; wait for the official 7.1 GA to come out and for your organization to decide it is time to consider an update to 7.1. Now I can't predict what might be part of 7.1, but let's argue that it has one or more bugs related to the audit mechanisms.  Perhaps the model listeners registration has changed or the audit messages are broken or the output mechanism isn't invoked consistently, ... I don't know, some sort of bug that maybe could have been caught sooner but ended up getting by. But now that you're looking at the upgrade, you've found the bug and want to report it. That's fine, Liferay wants you to report bugs, but at the time you've found it 7.1 is out and fixing the bug ends up becoming part of the release process.

Choice #2 is to join the Beta program. Now you dedicate a little bit of time to test your code under 7.1 before it goes out and you find and report the issue. Now Liferay has this list of things that they want to knock out for the first GA, so your report becomes one of many that Liferay really wants to deal with for a solid initial release. Your bug gets dealt with before it can impact your own upgrade schedule, and this actually helps you from the early reporting.

So please, please, please sign up for the 7.1 beta program.

Get the 7.1 beta and beat on it as much as you can.

Run the DB upgrade against your current database. Update and deploy your custom modules, make sure features, functionality and APIs are still there that you depend on. Point your load test tool at your instance and see if you have a measurable difference in performance or capacity vs your current environment.

Just bring it. Find and report the problems.

Together we can make the next release one of the best ever, all that's missing is you.

David H Nebinger 2018-02-21T04:32:04Z
Categories: CMS, ECM

User Guide documentation sprint to happen remotely, March 22nd/23rd/24th

CiviCRM - Tue, 02/20/2018 - 17:35

The Documentation Working Group is planning a remote sprint to improve content in the User Guide. Everyone is invited to participate! Experience editing our docs will be helpful but not required.

Sign up to join this sprint

Categories: CRM

Creating Consistent User Experiences with Liferay Adaptive Media

Liferay - Tue, 02/20/2018 - 11:53

The average web page is far larger in size and more complex in its programming than it has ever been before. Today, businesses across all industries are using images, video and interactive capabilities more and more to help create better user experiences. In addition, there are countless types of devices being used to access the internet, creating a complex interface that changes the user experience from person to person.

Beyond the complexity of websites, individual web pages are steadily growing in size thanks to the many elements commonly used in each. These elements have increased the average total web page size from 702 KB in November 2010 to 3.3 MB in September 2017, according to HTTP Archive. This means that the average size has multiplied by approximately five times in seven years.

It isn’t just web pages increasing in size and devices multiplying in number that can cause such a wide disparity in user experience. More countries than ever have a large portion of their populations accessing the internet. However, the average bandwidth in each country can vary greatly, leading to even more variations in user experience. Differences in devices mean that navigation menus, text size, image placement, white space and more will change to suit the specific dimensions of various screens. In addition, the increasing size of web pages and large differences in bandwidth can cause sites to load slowly and frustrate visitors, or even fail to load various elements at all. Without great UX strategies that take these factors into account and plan for them through detailed programming, it can be difficult for companies to properly reach their target audiences.

As such, Liferay Adaptive Media has been created to address these needs and improve a company’s omnichannel strategy and behind-the-scenes performance.

Optimizing for Great User Experience

Video has made the largest gains in accounting for the size of web pages during the last seven years, with images still accounting for the majority of data, as seen in the charts below.

However, while video is taking up a great portion of data, images are accounting for more data than ever. As seen below, while the average number of images has stayed relatively the same across the years, the average image size is steadily increasing.

According to statistics from Kissmetrics, nearly half of web users expect a website to load in two seconds or less. Should the site not load in three seconds, then they are likely to abandon it. In addition, 79% of those polled said that they would not return again to a site with performance issues. These online factors influence the bottom line of every company and illustrate the importance of creating an online experience that performs well for a wide variety of users under many different circumstances.

As page data continues to grow, businesses must take steps to prevent complications from negatively affecting their user experience due to device specification, bandwidth and more, while still providing a pleasing modern user experience.

Taking Control of User Experience

A well-constructed user experience that conforms to the unique circumstances of users can benefit many different audiences. Liferay Adaptive Media can help:

  • Portal Administrators: Define media resolutions that will be used to process and serve uploaded images according to the characteristics of the accessing device (screen size, bandwidth and processing capacity).
  • Content Creators: Upload media and create new pages of content without needing to worry about their appearance being negatively impacted by varying screen sizes and devices, with Adaptive Media transparently working in the background.
  • End Users: Enjoy an improved experience by consuming images that best fit to their devices and Internet connection.
  • Developers: Easily integrate Adaptive Media in their apps to support different media qualities.
Improve Your UX with Liferay Adaptive Media

The Liferay Adaptive Media app help programmers combat the complications caused by large page sizes and variations in device layouts, with features including:

  • Core integration with documents and media
  • Optional integration with blogs and web content
  • Compatibility layer removing the need to modify old content
  • Resizing images stored in Liferay to certain image resolutions
  • Reducing page size and improving loading speed based on device and bandwidth
  • Applying these changes automatically to end users without individual programming

Adaptive Media helps Liferay DXP users create experiences that are tailored to their customers, wherever they are, regardless of device.

Improve User Experience with Liferay Adaptive Media

Find out if Liferay Adaptive Media is right for you and see how you can tailor image quality in order to provide the best user experience possible.

Learn More About Liferay Adaptive Media   Matthew Draper 2018-02-20T16:53:28Z
Categories: CMS, ECM

Meet Jimmy, Ambassador of the month | February 2018

PrestaShop - Tue, 02/20/2018 - 11:33
Jimmy joined the Ambassador Program in August 2017 and he is our first Ambassador in Hong Kong. We are happy to have him among us, and we thank him for his dedication to PrestaShop.
Categories: E-commerce

Liferay 7.1 Community Beta Program

Liferay - Mon, 02/19/2018 - 19:12
Welcome to the Liferay 7.1 Community Beta Program!     During the Liferay 7.0 development cycle we launched the Community Expedition program.  With over 600 participants this was one of our largest and most successful community programs to date.  It is in large thanks to our awesome community who was instrumental in the success of Liferay Portal 7.0.     It is with great pleasure that I announce our next community initiative: Liferay 7.1 Community Beta Program.  The main goal for this program is to ensure that Liferay 7.1 meets your expectations by giving you the opportunity to provide vital feedback and bug reports during the duration of the 7.1 testing cycle.  The program will once again be hosted on the Liferay Developer Network and is scheduled to begin in early March.   Why participate? Besides the gratitude you’ll receive from the Liferay Community (and the Liferay QA, Engineering, and Release teams), other reasons to join include:
  • Get a heads up on new features in Liferay 7.1.
  • Help test your upgrade to make sure everything works as smooth as possible.
  • Engage other members of the community (including Liferay staffers).
  • Gain credit towards the Liferay Top Contributor award.
  • Receive a small token of our appreciation for your efforts.
Joining the Community Beta Program The Liferay 7.1 testing cycle will begin with the first Alpha release of Liferay 7.1 and will conclude when GA1 is released.  This will be a shorter testing cycle then we have had previously so timing is of the essence.  What you will need to do is to download a new pre-release when it becomes available, try out the new features highlighted on the beta program site (more details soon) and provide your feedback and report bugs to Liferay.  Here’s how to sign up:  
  1. Sign up for the program.  This let’s us know more about you and what your interests and environment are.  Once we are ready to launch the program we will send a follow-up email with more instructions.
  2. When a new pre-release (Alpha, Beta, RC) is released, we will provide an announcement on the beta program site with any important details for the release.  Be sure to download the pre-release and provide feedback and bug reports in the Forum on the beta program site.
  3. If you run into any problems or just have questions in general about the release, feel free to post in the Forum on the beta program site.
We look forward to your involvement with our community and hope that you will learn a lot about the release and meet some new faces along the way! Jamie Sammons 2018-02-20T00:12:34Z
Categories: CMS, ECM

DrupalCamp London 2-4 Mar'18

Drupal - Mon, 02/19/2018 - 14:45

The following blog was written by Drupal Association Premium Supporting Partner, DrupalCamp London.

The people surrounding Drupal have always been one of its strongest selling points; hence the motto “Come for the code, stay for the community”. We bring individuals from a multitude of backgrounds and skill sets together to push forward towards a common goal whilst supporting and helping each other. Within the community, there are a number of ways to connect to each other; both online and in person. A good way to meet in person is by attending DrupalCons and DrupalCamps.


A DrupalCamp can be similar to a DrupalCon but is on a much smaller scale. Where a ‘Con has 1,600+ attendees a ‘Camp ranges anywhere from 50-600 people. In Europe alone there were over 50 camps in 2017, including DrupalCamp London.

DrupalCamp London

DrupalCamp London brings together hundreds of people from across the globe who use, develop, design, and support the Drupal platform. It’s a chance for Drupalers from all backgrounds to meet, discuss, and engage in the Drupal community and project. DrupalCamp London is the biggest camp in Europe (followed very closely by Kiev), at ~600 people over three days. Due to its size and location, we’re able to run a wide range of sessions, keynotes, BoFs, Sprints, and activities to take part in.

What happens over the three days? Friday (CxO day)

Friday (CxO day) is primarily aimed at business leaders who provide or make use of Drupal services (i.e web development agencies, training companies, clients etc), but naturally, everyone is welcome. Throughout the day we'll have speakers talking about their experiences working with Drupal and Open Source technologies in their sector(s) or personal life. With a hot food buffet for lunch and a free drinks reception at the end of the day, you'll also have ample time to network with the other attendees.

Benefits of attending 

Benefits for CTOs, CMOs, COOs, CEOs, Technical Directors, Marketing Directors and Senior Decision Makers: 

  • Understand how leading organisations leverage the many benefits of Drupal
  • Network with similar organisations in your sector
  • Learn directly from thought leaders via specific case studies
Saturday/Sunday (Weekend event)

Over the weekend, we have 3 Keynote speakers, a choice of over 40 sessions to attend, BoF (Birds of a Feather) talks, Sprints, great lunch provided (both days) and a Saturday social. With all the activity there is something for everyone to get involved in.

Benefits of attending 


Over 500 people attended the weekend event last year and we are expecting it to grow even more this year. Not all attendees are devs either, with a fair share of managers, designers, C-Level, and UX leads there's a great opportunity for all skill sets to interact with each other. Big brands use Drupal (MTV, Visit England,, Guardian, Twitter, Disney) and this is a chance to meet with people from those companies to compare notes, and learn from each other. 


As above, the chance to meet so many people from various skill sets is a great way to line up potential interviews and hires for any aspect of your business. At the very least you'll be able to meet interesting people for any future potential hires. 

Marketing & Raising company profile 

Attending an event with a huge turnout is a great way to meet people and talk to them about what you and your company do. Embedding your name within the tight-knit Drupal community can attract the attention of other companies. Sponsoring the camp means that your logo and additional information can be seen around the camp, in tote bags given to attendees, and online. The social and sponsors stands are the perfect chance to talk to other companies and people attending DrupalCamp, to find out how they use Drupal for their benefit. 


DrupalCamp isn't just for Devs, over the weekend there are sessions on a broad range of topics including community & business, UX, and general site building/using Drupal. The technical topics aren’t just Drupal specific either, this gives developers (and others) the ability to learn more about general core coding concepts and methodologies. The methods and techniques learnt help with day to day development and long-term work. In addition to the planned sessions, BoF (birds of a feather) sessions, there are ad-hoc get-togethers where people can talk on any topic, allowing a free discussion to share ideas. 

Warm fuzzy feeling/giving back 

Drupal (like any open source software) wouldn't survive without the community. Camps and other events allow the members to come together and see ‘first hand’ that they’re giving back to a community that helps power their tech, maintains their interests, and enables them to make a living.

How to get involved?

It’s easy to get involved with DrupalCamp London, check us out on Twitter for updates and you can find out more about the event and buy tickets on our website.

Categories: CMS

CiviCamps in the UK, 2018!

CiviCRM - Mon, 02/19/2018 - 06:47


This year we will have two CiviCamps in the UK to choose from!

  • May 15th in London

  • October 5th in Manchester

Categories: CRM

¿Por qué tu customer journey map no está reflejando la realidad de tus clientes?

Liferay - Fri, 02/16/2018 - 07:58

Las empresas diseñan buenas experiencias de clientes con el objetivo de satisfacer o superar las expectativas de su público objetivo; y lo hacen a través de la predicción de sus acciones e intereses. Sin embargo, las compañías necesitarán crear una descripción detallada y precisa de estas experiencias potenciales en forma de customer journey map, en el que estén representados todos los pasos que estos dan durante la interacción con la empresa. Estos mapas deben tener la función de trazar el recorrido desde la primera interacción hasta la ejecución de la compra o, incluso más allá. Dedicar recursos a llevar a cabo esta acción es especialmente importante, ya que un mapa del customer journey incorrecto, que no refleje la experiencia real de tu audiencia puede causar complicaciones innecesarias para tu negocio.

Independientemente de si tu empresa se encuentra actualmente en el proceso de definición de su customer journey, o de si ya ha finalizado este proceso, es importante que conozcas las principales razones por las que algunos customer journeys maps no funcionan. Y, si es el caso, puedas hacer los cambios necesarios para que el tuyo refleje perfectamente el recorrido de tu cliente a lo largo de su ciclo de vida.

Problemas comunes del Customer Journey Map

Si bien cada empresa debe hacer un esfuerzo por diseñar un customer journey map que refleje la realidad del cliente, hay un serie de problemas comunes que surgen a lo largo del proceso de diseño, y que pueden impedir la creación de un mapa ideal. A continuación ponemos algunos ejemplos de estos problemas frecuentes. Es importante que, en cada caso, pueda considerarse cómo cada uno de ellos puede afectar al customer journey de tu organización:

  • Recorrido idealizado: Existe una diferencia entre cómo te gustaría que se comportara tu cliente y cómo se comporta verdaderamente. Si tu customer journey solamente refleja el comportamiento e interacciones que te gustaría que tu audiencia tuviera con tu compañía , esta herramienta no podrá ser utilizada para analizar y orientar el comportamiento de los clientes para conseguir tus objetivos. Los customer journey maps que son realmente útiles para tu empresa y equipo son los que muestran cuál es el verdadero recorrido de tu público objetivo. De esta forma seréis capaces de poner en marcha los cambios necesarios que os ayuden a dirigir a vuestra audiencia hacia vuestro customer journey ideal.
  • Dejar de lado los pasos que no incluyen a tu marca o empresa: Un customer journey map de éxito es aquel que contempla todas y cada una de las fases del proceso, incluyendo aquellas que no están relacionadas con tu negocio. Lo que puede incluir aquellos momentos en los que el cliente analiza a la competencia o aprende algo sobre tu producto en una página de un tercero. Puede que no seas capaz de mantener un control sobre estas fases del proceso, pero debes tener en cuenta que también van a tener un impacto en el customer journey real.
  • Olvidar el Punto de vista del cliente: ¿Qué opinión tiene el cliente de tu empresa? Esta es una pregunta importante que toda compañía se debe hacer y que, además, va ayudarte a comprender cómo cada paso del customer journey va a impactar en dicha percepción, así como en incentivar o desmotivar al cliente para dar el siguiente paso hacia la compra. No olvides que este recorrido del cliente con tu empresa todavía depende de la visión y los intereses de la audiencia, independientemente de cómo de efectiva sea tu estrategia de experiencia del cliente.
  • Falta de Indicadores sobre el rendimiento del customer journey: Los mapas de customer journey también son capaces de identificar qué áreas pueden ser optimizadas, a través de la incorporación de indicadores que ayuden a medir su rendimiento. Según Tandem Seven, estos indicadores ofrecen insights sobre el estado emocional del cliente, facilitando la identificación de las razones que pueden estar impidiendo la finalización de la compra. No tener en cuenta este tipo de información puede impedir a la empresa conocer mejor las razones que hay detrás de la compra o abandono por parte del cliente.

Considerar los posibles problemas que pueden darse en el customer journey puede ayudar a las compañías a comprender mejor la efectividad de su mapeo y comenzar a ver las causas subyacentes de los posibles problemas para atajarlos y darles solución.

¿Qué está causando los problemas en tu mapa del Customer Journey?

Frecuentemente, un diseño incorrecto del customer journey es consecuencia de un alcance de visión limitado durante el proceso de su creación. Si una compañía no trabaja lo suficiente para definir con exactitud todas las fases de este proceso, así como para incorporar cada una de las perspectivas, la compañía no será capaz de definir un mapa lo suficientemente detallado y útil.

Asegúrate de que el mapa del customer journey que construyas refleja la opinión provista por parte de tus principales stakeholders, lo que va a proporcionar a tu equipo un mayor conocimiento de los pasos dados por el cliente y que involucran a varios departamentos de la empresa. Recibir la opinión e información de las diferentes áreas de la organización garantizará que ningún área en particular tendrá mayor peso en el diseño del mapa, como puede pasar cuando sólo se tiene en cuenta la interacción del usuario vía redes sociales y se olvidan detalles importantes que pueden aportar desde el servicio de atención al cliente. Según The Customer Framework, mapas del customer journey incorrectos pueden generar diseños que, aunque parezcan completos, en realidad no incluyen aspectos importantes del customer journey. El resultado de ello es la toma de decisión en base a un mapa inexacto, algo que seguramente no vaya a traer los resultados esperados.

Además de garantizar que todos los departamentos y equipos estén implicados en el diseño de este recorrido del cliente, no excluyas hacer una investigación detallada del que es el elemento principal de tu mapa: el cliente. señala que independentemente de la cantidad de informaciones que puedas adquirir internamente, conocer la opinión del cliente es fundamental. De esta forma, las empresas pueden obtener importantes insights y perspectivas distintas a las que se consiguen únicamente tomando como referencia el análisis de datos y feedback internos.

Creando un Mapa del Customer Journey preciso

A día de hoy, las empresas pueden utilizar analíticas detalladas para conseguir informaciones sobre cómo interactúan sus clientes con la marca online. Esto permitirá que tu mapa sea más preciso y basado en datos más reales y medibles. Estos datos pueden incluir: interacciones en redes sociales, anuncios, navegación web, llamadas al servicio de atención al cliente y cualquier otro tipo de acción que genere información que los sistemas de analítica puedan recopilar y clasificar.

Un análisis preciso es lo que va a garantizar que tu empresa pueda conocer realmente cómo interactúan los clientes con la compañía para obtener un customer journey más preciso. La consecuencia será que los cambios y mejoras que hagas en tus estrategias van a tener mayor probabilidad de afectar positivamente al negocio y satisfacer de forma más efectiva las demandas de tu audiencia.

Descubre cómo crear customer journey maps eficientes y capaces de identificar los principales pain points a los que se enfrentan los clientes en el proceso de interacción con la empresa en el siguiente post: Cómo descubrir los principales pain points en la relación de tu empresa con el cliente.

Transforma tu Customer Journey

Tras conocer más tu customer journey, vas a querer mejorarla al máximo. Aprende a cómo transformar las experiencias de tu cliente de la forma que más encaje con tu empresa a través de este whitepaper.

Lee “Four Strategies to Transform Your Customer Experience”   Rebeca Pimentel 2018-02-16T12:58:43Z
Categories: CMS, ECM

OSGi Fragment Bundles

Liferay - Thu, 02/15/2018 - 21:54

Okay, in case it is not yet clear, Liferay 7 uses an OSGi container.

I know what you're thinking: "Well, Duh..."

The point is that OSGi is actually a standard and anything that works within OSGi will work within Liferay. You just need to understand the specs to make something of it.

For example, I'd like to talk about OSGi Fragment Bundles. There's actually stuff in the specs that cover what fragment bundles can do, how they will be treated by the container, etc.

The only way that Liferay typically presents a fragment bundle as a solution is for a JSP fragment, but there's actually some additional stuff that can be done with them.

OSGi Fragment Bundles

Fragment bundles are covered in chapter 3.14 of the OSGi Core 6.0.0 specification document.  In technical terms,

Fragments are bundles that can be attached to one or more host bundles by the framework. Attaching is done as part of resolving: the Framework appends the relevant definitions of the fragment bundles to the host's definitions before the host is resolved. Fragments are therefore treated as part of the host, including any permitted headers.

The idea here is that fragments can supplement the content of a host bundle, but cannot replace files from the host. Since the fragment is appended to the host, resources will always be loaded from the host bundle before they are loaded from the fragment.

This is counter to the old way Liferay used to do JSP hooks, where these hooks could actually replace any JSP or static file from the original bundle.  Fragments can only add new files, but not replace existing ones.

So you might now be wondering how the JSP files from a fragment bundle actually do override the files from the host bundle. The answer? Liferay magic. Well, not magic, per se, but there is special handling of JSP files by the Liferay systems to use a JSP file from a fragment before the host, but this is not normal OSGi Fragment Bundle behavior.

What good are they if they can only add files?

Actually you can do quite a bit once you understand that bit.

For example, I was recently trying to help a team override the notification template handling from the calendar-service module, a ServiceBuilder service module for the Liferay calendar. The team needed to replace some of the internal classes to add some custom logic and had been unsuccessful. They had seen my blog post on Extending Liferay OSGi Modules, but the warnings in the blog were taken to heart and they didn't want to go down that road unless it became necessary.

The calendar-service module has a bunch of internal classes that are instantiated and wired up using the internal Spring context set up for ServiceBuilder service modules. So the team needed to provide new template files, but in addition they needed custom classes to replace the instances wired up by Spring when setting up the context, a seemingly difficult ask.

The Spring aspects of the host module in addition to the appending nature of the fragment bundle handling actually makes this pretty easy to do...

First, create a fragment bundle using the host and version from the original.  For this override, it is com.liferay.calendar.service and rather than use a specific version, I opted for a range [2.3.0,3.0.0).

Next I added a new class, src/main/java/com/liferay/calendar/notification/impl/  It was basically a copy of the original EmailNotificationSender class from the same package, I just added in a bunch of log statements to see that it was being used.  Note that I was actually free to use any package I wanted to here, it really wasn't that important.

Next I added a src/main/resources/META-INF/spring/calendar-spring-ext.xml file to the fragment bundle with a replacement bean definition.  Instead of instantiating the original EmailNotificationSender, I just had to instantiate my custom class:

<?xml version="1.0"?> <beans default-destroy-method="destroy" default-init-method="afterPropertiesSet" xmlns="" xmlns:xsi="" xsi:schemaLocation="" > <!-- Replace the Liferay bean definition with our own. --> <bean class="com.liferay.calendar.notification.impl.NotificationSenderFactory" id="com.liferay.calendar.notification.impl.NotificationSenderFactory"> <property name="notificationSenders"> <map> <entry key="email"> <bean class="com.liferay.calendar.notification.impl.CustomEmailNotificationSender" /> </entry> <entry key="im"> <bean class="com.liferay.calendar.notification.impl.IMNotificationSender" /> </entry> </map> </property> </bean> </beans>

So while I couldn't replace the old class, I could add a new class and a new Spring configuration file to replace the old definition with one that used my class.

Once the fragment was built and deployed, it was working as expected.  The project at this state is available here:

Additionally the team needed to alter the template files.  This was accomplished by adding a src/main/resources/ file with a replacement property key for the template to replace pointing to a new file also included in the fragment bundle.  Since the original file has an "include-and-override" line to pull in, when the fragment bundle is appended to the host the replacement property key will be used and the new file from the fragment bundle will be loaded.

What Else Can I Use Fragments For?

While I don't have working code to demonstrate each of these, the working example makes me think you can use a fragment bundle to extend an existing Liferay ServiceBuilder service module.

Since ServiceBuilder modules are Spring-based and the default Spring configuration declaring the service is in META-INF/spring/module-spring.xml, we can use a fragment bundle to add a META-INF/spring/module-spring-ext.xml file and replace a default wiring to a service instance to a custom class, one that perhaps extends the original but overrides whatever code from the original. Spring would instantiate our class, it would have the right heirarchy and should make everything work.

This wouldn't work for services from portal-impl since they are not loaded by OSGi ServiceBuilder host modules, but it should work for those that are deployed this way.

Another idea is that it could be used to override static .css and/or .js files from the host bundle. Well, not override per se, but introduce new files that, in addition to a Configuration Admin config file, could use the replacements in lieu of the originals.

So, for example, calendar-web has a /css/main.css (actually main.scss file, but it will be built to main.css) file that is pulled in by the portlet. We could use a fragment bundle to add a new file, /css/main-ext.scss file. It could either have everything from main.scss with your changes or it could just contain the changes depending upon how you wanted to manage it going forward.  As a new file, it could be loaded if the portal was going for the file.

The original file is pulled in by the portal due to the properties on the CalendarPortlet annotation:

@Component( immediate = true, property = { "com.liferay.portlet.add-default-resource=true", "com.liferay.portlet.css-class-wrapper=calendar-portlet", "com.liferay.portlet.display-category=category.collaboration", "com.liferay.portlet.friendly-url-mapping=calendar", "com.liferay.portlet.header-portlet-css=/css/main.css", "com.liferay.portlet.icon=/icons/calendar.png", "com.liferay.portlet.preferences-owned-by-group=true", "com.liferay.portlet.preferences-unique-per-layout=false", "javax.portlet.display-name=Calendar", "javax.portlet.expiration-cache=0", "javax.portlet.init-param.copy-request-parameters=true", "javax.portlet.init-param.view-template=/view.jsp", "" + CalendarPortletKeys.CALENDAR, "javax.portlet.resource-bundle=content.Language", ",power-user,user", "javax.portlet.supports.mime-type=text/html" }, service = Portlet.class ) public class CalendarPortlet extends MVCPortlet {

So we would need the portlet to use a new set of properties that specifically changed from /css/main.css to /css/main-ext.css. This we can do by adding a file to $LIFERAY_HOME/osgi/configs/com.liferay.calendar.web.internal.portlet.CalendarPortlet.cfg file. This file format as defined here: and basically allows you to create a file to replace configuration property key values w/ custom versions.

So in our file we would add a line, com.liferay.portlet.header-portlet-css=["/css/main.css","/css/main-ext.css"]. This is the format for including both files, if you just wanted the one file it would simply be com.liferay.portlet.header-portlet-css="/css/main-ext.css". This file would need to be manually deployed to the osgi/configs directory, but once it is done and combined with the fragment bundle, the main.css file and main-ext.css file would be included.

This is the same kind of process that you would use to handle static javascript files pulled in by the portlet's @Component annotation properties.


So OSGi Fragment Bundles can be used for things beyond simple JSP fragment bundles.

I'm hoping what I presented here gives you some ideas on how you might solve problems that you're facing with "overriding" Liferay default functionality.

If you have some ideas, please share below as they may be helpful to others struggling w/ similar issues.


David H Nebinger 2018-02-16T02:54:31Z
Categories: CMS, ECM

"Customize your Database with Custom Fields and Profiles" on-line training - Feb. 22nd

CiviCRM - Thu, 02/15/2018 - 18:39

Cividesk has created an on-line training session to guide you through the basics of creating custom fields and to show you how to use profiles to gather custom data from contacts through the creation of an on-line form. When you leave this class, you'll be able to customize CiviCRM to gather and store data that is unique to your organization, as well as better understand the various uses of profiles in CiviCRM.

Categories: CRM

Adding plugins to the Liferay Alloy Editor

Liferay - Thu, 02/15/2018 - 16:52

I have been working on adding CKEditor plugins to the Alloy Editor in Liferay DXP and figured I would share what I found. Specifically I was trying to add the YouTube Plugin. There are some articles online at Liferay but they focus more on packaged or custom developed plugins. I got close streaming the files into the Dynamic-Include, but there is a better way (thanks to Chema Balsas for the help!): The trick is to create a OSGI module fragment.

First we create a new Liferay Module Project Fragment – this module won’t have much in it, its purpose is to add the plugin files to the ckeditor module Liferay has in it’s core modules.

To do this, we download and extract the plugin, rename it to a simpler name – in my case youtube, and copy it into the resources/META-INF/resources/ckeditor/plugins folder:

Now all we need to do is edit the bnd.bnd file and inform the OSGI container of our awesome new plugin and that we would like to add it to the existing ckeditor module:

Bundle-Name: base22-alloyeditor-plugins Bundle-SymbolicName: base22.alloyeditor.plugins Bundle-Version: 1.0.0 Fragment-Host: com.liferay.frontend.editor.ckeditor.web

You can now test that it works by deploying our fragment and seeing if the js file is accessible. Go to http://localhost/o/frontend-editor-ckeditor-web/ckeditor/plugins/youtube/plugin.js and hopefully you see the JavaScript file.

As you can see we are accessing the same path as the standard editors plugins, we just added our own directory to it using the fragment. Powerful stuff.

Now that we have the plugin, we need to let the editor know we want to use it, and where. For this we need to create a module which implements the EditorConfigContributor – there is a good article at Liferay covering this as well.

We create our class and declare it as a component that is a EditorConfigContributor and tell it to configure the Alloy editor:

@Component(         property = {         "",         "service.ranking:Integer=1000"},         service = EditorConfigContributor.class )

Next we extend the BaseEditorConfigContributor and override the populateConfigJSONObject. This is where we change the JSON that configures the editor. The JSON object will get passed to us and we will adjust it to include our new button.

As a tip, it is really useful to set a breakpoint in the code and look at the overall configuration as you are working with the configuration.

First, we are going to get the extraPlugins section of the configuration JSON and add our youtube plugin. We also want to make sure the ae_uibridge and ae_buttonbridge are loaded to ensure the CK editor plugin is bridged into Alloy editor.

@Override public void populateConfigJSONObject( JSONObject jsonObject, Map<String, Object> inputEditorTaglibAttributes, ThemeDisplay themeDisplay,     RequestBackedPortletURLFactory requestBackedPortletURLFactory) {     String extraPlugins = jsonObject.getString("extraPlugins");     if (extraPlugins == null) {     extraPlugins = extraPlugins+ "ae_uibridge";     }else{         extraPlugins = extraPlugins+ ",ae_uibridge";     }     if(!extraPlugins.contains("ae_buttonbridge")){         extraPlugins = extraPlugins+ ",ae_buttonbridge";     }     if(!extraPlugins.contains("youtube")){         extraPlugins = extraPlugins+ ",youtube";     }     jsonObject.put("extraPlugins", extraPlugins);

Now that the editor knows about our plugin, we need to add the button to a toolbar. We pull the toolbar from the JSON and add our button to it:

JSONObject toolbarsJSONObject = jsonObject.getJSONObject("toolbars"); if (toolbarsJSONObject == null) { toolbarsJSONObject = JSONFactoryUtil.createJSONObject(); }  JSONObject addJSONObject = toolbarsJSONObject.getJSONObject("add"); if (addJSONObject == null) {     addJSONObject = JSONFactoryUtil.createJSONObject(); } JSONArray buttons = addJSONObject.getJSONArray("buttons"); buttons.put("Youtube"); toolbarsJSONObject.put("add", addJSONObject); jsonObject.put("toolbars", toolbarsJSONObject);

Nothing extraordinary is needed in the Gradle or BND files. Deploy your modules and go edit some web content. Your new button should show where you placed it.

This is another way to use OSGI fragments as mentioned by David Nebinger in his post on OSGI fragments.

Christian Klein 2018-02-15T21:52:27Z
Categories: CMS, ECM

6 Vantagens de Plataformas de Experiência Digital com Herança de Portal

Liferay - Thu, 02/15/2018 - 13:36
Gartner lançou seu primeiro Quadrante Mágico para Digital Experience Platforms e reconheceu a Liferay como um Líder. A análise independente do Gartner avaliou 21 provedores baseando-se na abrangência de visão e capacidade de execução de cada tecnologia, com a Liferay entre um dos quatro Líderes.   O Quadrante Mágico para DXPs substituiu o já reconhecido Quadrante Mágico para Portais Horizontais, processo natural já apontado pelo Gartner através do seu artigo sobre a evolução dos portais em plataformas de experiência digital no ano passado. Plataformas de Experiência Digital (DXPs) fornecem um conjunto de ferramentas para gerenciar experiências que surgiram com a necessidade das empresas oferecerem interações consistentes e conectadas através de todos os pontos de contato, como portais, sites, dispositivos móveis e IoTs.   Conforme apresentado no relatório, DXPs geralmente são originadas de portais ou de  sistemas de gerenciamento de conteúdo (CMS). Tecnologias, incluindo o Liferay DXP, com herança de portal, contam com pontos fortes para conectar negócios tanto internamente como com seu público-alvo.   As seis vantagens apresentadas a seguir de DXPs baseadas em portal podem fortalecer os negócios de maneira única. Enquanto estes elementos podem também ser encontrados em algumas tecnologias originadas de CMS, eles são inerentes a maioria das plataformas de portal e, dessa maneira, contam com uma forte presença naquelas que se tornam DXPs, até em versões iniciais.   1.Capacidade de Integração  Plataformas de experiência digital permitem que empresas realizem sua transformação digital tanto em suas operações internas como nas experiências do cliente que criam. Uma experiência do cliente é considerada excelente quando o cliente consegue alternar perfeitamente a navegação entre distintos pontos de contato, como sites, aplicativos e sistemas de backend, enquanto as empresas coletam dados e fornecem serviços personalizados. Uma empresa deve integrar uma série de sistemas com o intuito de prover interações excepcionais.   DXPs com herança de portal contam com capacidades essenciais para a integração de sistemas de backend, que concede aos clientes, funcionários e outros usuários finais, o acesso a dados que eles precisam em vários sistemas que a empresa utiliza. Por exemplo, dados de clientes armazenados em um CRM ou em uma ferramenta de automação de marketing podem ser unificados e compartilhados através de um DXP com herança de portal. Assim, pode-se economizar tempo e esforço tanto das empresas como dos clientes, ao mesmo tempo em que ajuda as empresas a compreenderem e melhor apoiarem seu público-alvo através dos insights fornecidos por estes dados compartilhados.   2. Foco nas Relações de Longo-prazo com Clientes. Portais são projetados para ajudar empresas a conectarem-se com sua audiência através de interfaces seguras. Isto pode incluir bases de usuários específicas, como clientes que precisam acessar informações e ferramentas integradas às suas experiências. Rivet Logic destaca DXPs com herança de portais como particularmente fortes no apoio às relações com clientes a longo prazo, já que sua capacidade de criar experiências individuais únicas através de logins para apoiar e atender às necessidades dos clientes já é algo estabelecido e fundamental em portais desde que foram criados. Está é uma vantagem em comparação a tecnologias CMS, que foca tradicionalmente em prospectos anônimos.   Liferay fortaleceu uma série de negócios para entender e alcançar seu público-alvo através do uso de portais e DXPs com herança de portal. Por exemplo, o Mercury Insurance Group criou um customer portal para gerenciar cada relacionamento entre cliente e empresa, e fornece componentes de autoatendimento que aprimoram a experiência do cliente. Além disso, a empresa global de TI, Unisys, criou o VantagePoint utilizando Liferay, um portal de serviços corporativos usando funcionalidades de integração para fornecer serviços configuráveis para sua ampla variedade de clientes em todo o mundo. O relatório do Quadrante Mágico do Gartner destaca que departamentos de TI modernos estão encontrando frequentemente como solução DXPs com herança de portais horizontais. As experiências do cliente criadas pela plataforma podem ajudar a aumentar a taxa de retorno de clientes e melhor equipar os times de vendas através de insights aprofundados dos clientes.     3. Suporte ao Ambiente de Trabalho Digital Plataformas de experiência digital atendem uma série de necessidades online, incluindo a habilidade de prover suporte a cada funcionário. Ao alavancar as várias ferramentas e métodos de comunicação já utilizados em portais para funcionários, DXPs com herança de portal podem utilizar-se de métodos já comprovados e transformá-los em ambientes de trabalho digitais. Enquanto CMS e DXPs com herança de portal podem ser utilizadas para criar esses ambientes de trabalho digitais, softwares de portal têm o histórico de ser usado para intranets e áreas de trabalho. Estes cenários incluem interfaces customizadas baseadas nas preferências e atividades de cada funcionário, interfaces mobile-friendly que equipam times em andamento e recursos de gerenciamento de informações que melhoram a forma como uma empresa se comunica internamente. Estes vários elementos são usados em um grau ainda maior em locais de trabalho digitais criados por DXP.   Estes ambientes de trabalho digitais concedem aos times o acesso a uma série de informações fundamentais e ferramentas digitais que os ajudam a melhor completar suas atividades e atender às necessidades dos clientes. Com a flexibilidade de uma DXP, os ambientes digitais podem ser acessados através de diversos dispositivos, de maneira que cada funcionário possa encontrar o que ele precisa a qualquer hora. Com o uso de DXPs, as empresas estão renovando seus portais e intranets com o intuito de trazer o mesmo nível de cuidado e personalização dos clientes para funcionários em um ambiente de trabalho online mais eficiente e útil. Além disso, criar suporte para o local de trabalho para todos os departamentos em uma plataforma única pode eliminar silos da empresa através do compartilhamento de informações e insights.   4. Gerenciando Relacionamentos B2B  Conforme já discutido, portais têm um importante papel nos cenários B2C e B2E. No entanto, eles também são fundamentais para DXPs usadas no contexto B2B.   Muitas empresas B2B utilizavam tecnologias de portal para facilitar as interações ao criar interfaces seguras e úteis para os negócios que eles atendem. Harvard Business Review destaca que os processos modernos de compras B2B estão mais complexos do que nunca, levando a complicações e à falta de satisfação que poderiam ser resolvidos com experiências mais parecidas com a realidade de B2C. Isto traduz-se em uma interface do cliente mais clara e customizada que fornece serviços necessários que atendem a jornada do cliente. DXPs com herança de portal eficientes utilizam as conexões bem estabelecidas criadas pelo software de portal e elaboram uma experiência mais robusta através das suas diversas funcionalidades disponíveis. Desta maneira, empresas B2B podem manter as expectativas e fortalecer as relações com os negócios em uma era onde a competição é muito alta devido às rápidas inovações em experiências online.   5. Gerenciamento Seguro de Dados Insights providos por dados têm papel importante no marketing moderno e nas estratégias de serviço ao cliente para empresas dos diversos tipos de indústria. No entanto, estes dados devem estar seguros contra possíveis brechas para prevenir danos às empresas e às pessoas que confiaram suas informações. Além disso, o público atual gera uma grande quantidade de dados, que são utilizados para ações de marketing altamente personalizadas e estratégias de experiência do cliente. De maneira contrária a softwares de CMS, portais são preparados para suportar uma grande quantidade de usuários e um grande fluxo de informação, que às vezes contém dados sensíveis tanto dos negócios como dos clientes. Assim, DXPs com herança de portais são baseadas em sistemas criptografados e prontos para armazenar e analisar dados para um gerenciamento de informações seguro e perspicaz.    6. Agilidade Digital Conforme destacado pelo Gartner, portais podem ser usados como um framework de arquitetura comum. Esta funcionalidade de uma DXP baseada em portal permite que empresas construam sites e rapidamente reutilize o framework criado para outros pontos de contato. Dessa maneira, os negócios não só asseguram que todos os aspectos da sua presença online são uniformes em termos de funcionalidade e aparência, mas também economiza tempo e dinheiro, evitando uma reconstrução do zero. Ao transformar uma plataforma de experiência digital com herança de portal em uma fábrica de soluções, as empresas podem avançar rapidamente suas estratégias digitais, mantendo o controle sobre a qualidade das experiências individuais.   Potencializando a Herança de Portal com Liferay DXP  Ao nomear Liferay como um Líder, o Gartner ressaltou a flexibilidade e agilidade do Liferay DXP para a criação de experiências altamente personalizadas, a responsividade da empresa e o crescimento orgânico ao lançar novos funcionalidades do produto para atender às demandas dos clientes, e um excelente suporte e experiência do cliente.   O Liferay DXP é construído sobre a herança do Liferay como uma plataforma de portal, usando a tecnologia criada para capacitar a força de trabalho e fornecer aos clientes acesso às informações que mais precisam. Empresas de todo o mundo usaram o Liferay DXP para criar vários aspectos da sua experiência online, incluindo sites, aplicativos móveis e experiências digitais conectadas, além de usar a tecnologia de portal para gerenciar cuidadosamente uma grande variedade de ativos para melhor servir seus clientes e apoiar seus funcionários. Estas vantagens da herança de portal ajudaram a distinguir Liferay DXP no mercado.   Isabella Rocha 2018-02-15T18:36:50Z
Categories: CMS, ECM

Liferay and Docker: Dockerised Liferay Workspace

Liferay - Thu, 02/15/2018 - 12:58

In recent times, containers are becoming more and more important in the software lifecycle management, whether we like it or not. The majority of  the leading software companies have already released a Docker version of their products, Microsoft did a huge work to adapt Windows kernel to Docker containers features, many Cloud services sell container-based solutions: containers are everywhere, and we can't just run away.

Also Liferay is playing its part in this. WeDeploy supports a Docker-based deployment and an official guide on how to deploy DXP on a Docker container has been released. We have come quite a journey since the first liferayctl proposal!

But wouldn't it be really nice to work with containers from the beginning of our development process to the last deploy in a production environment? I know that many blog articles, guides and speeches have been made on how to "Dockerise" Liferay, but a complete guide on how to transform our Liferay Workspace in a Dockerised Liferay Workspace, that allows developers to do everything they did before but with Liferay running on its own container, seems to be missing. And this is why I decided to write this blog article, hoping it can help. Enjoy!

Docker in Liferay Workspace

You can find an example of Docker integration in Liferay Workspace on this GitHub repository. It has been tested on a Windows machine running Docker for Windows, but it should work also with Docker Toolbox or with other OSs. Nevertheless, if you will experience some issues while trying it, please report them hereunder.

With this version of the Workspace, you will be able to start and stop a complex container environment, including Liferay 7 CE GA5 and other optional nodes (a separate DB, an Elasticsearch cluster, an Apache frontend, etc.) with just two Gradle tasks. Moreover, a third Gradle task allows you to build a Docker image of your current local environment, for versioning or test purposes or simply to share it with your colleagues or customers.

But the most important thing is that those features come without compromises: you will be able to debug your Liferay container form Eclipse, open a GoGo shell from your terminal, and even to use Gulp watch during theme development. But let's start from the core: the docker-compose file.

Docker Compose for multi-node environments

The core of the Dockerised workspace is the docker-compose.yml file. Even if you plan to run a simple Docker environment, with a single Liferay container, it's anyway better to have a docker-compose file to manage it. This is because you won't have to change anything in your environment start and stop Gradle tasks when you will be forced to use a more complex environment (and you will, be sure). A docker-compose file can manage multi-container contexts, with multiple nodes, networks and volumes: the only limitation will be your local machine processing power. For example you can:

  • Run a separate DB, like MySQL, when Hypersonic is not enough (quite always). In my example repository you will find a commented example on how to add a MySQL node
  • Run a separate Elasticsearch cluster. You will find a great example on how to do that on this Yasuyuki Takeo's blog post
  • Run a Liferay cluster with two or more nodes. You will find a great example on this Antonio Musarra's blog post on

In order to start and stop your environment, all you need to do is to launch the startDockerEnv and stopDockerEnv Gradle tasks, respectively. Those tasks are based on a bunch of additional Gradle properties that can be defined to partially customise their behaviour. Please refer to file in GitHub repository for more details.

Moreover, the docker-compose file defines a list of bind mounts that link your local deployment folders with the container filesystem, so that the stantard Gradle deployment tasks can be used as usual. For the Document Library, a Docker named volume is used instead, in order to persist DL contents when the container is restarted.

Dockerfile for environment snapshot

Another important element of this Dockerised Workspace is the Dockerfile. It allows developers to create a Liferay container that reflects the current local environment, in order to create a snapshot, by simply running the buildDockerImage Gradle task. Such an image can be used for multiple purposes in the different phases of the software lifecycle. For example:

  • As a test environment, maybe in conjunction with a CI tool (Jenkins, Travis CI, etc.). Since containers don't implicitly persist any generated data after they are removed, they are perfect for testing purposes
  • For environment versioning. When you reach a stable version of your code, you can tag it and release both a code archive and a working Docker image associated to that particular version. This can be realised manually, launching the Gradle task, or with an Automated build technique
  • For continuous deployment, again in conjunction with a CI tool. This requires that you can use Docker also in deployment target environments (or at least in a subset of them). The ideal case is when you can propagate the same container from your local machine to production environment, but also less ambitious solutions are possible
  • For WeDeploy deployment. You can add a wedeploy.json file and deploy your image on WeDeploy, following this guide
Liferay Docker containers

Two simple Liferay Docker containers have been realised for this article, in order to provide a starting point to further customisations. You can find them on Docker Hub or on this GitHub repository. In particular, there are:

  • The liferay-portal:7.0-ce-ga5 image, that inherits from openjdk:8 official container and adds a full Liferay 7 CE ga5 installation, exposing port 8080. The aforementioned Dockerfile in Dockerised Workspace inherits from this image
  • The liferay-portal:7.0-ce-ga5-dev image, that inherits from the previous container, adding some features that facilitate the development process. The aforementioned docker-compose file creates a container based on this image

In particular, with the latter image a developer can:

  • Run Liferay in developer mode. The file is attached to Liferay
  • Debug Liferay as a Remote Java Application. This image runs tomcat with JPDA enabled and a socket listening on the exposed port 8000. Docker Compose binds such port to the localhost 8000 port, so that a debugger can be attached directly on localhost:8000 (without having to know the container IP)
  • Open a local GoGo Shell. Setting the property to (instead of the default localhost:11311 value) and exposing port 11311, a remote connection to the GoGo shell is allowed. Docker Compose binds such port to the localhost 11311 port, so that the standard procedure described here can be used

The only thing that really changes between a standard Liferay Workspace and a Dockerised one is how to see Liferay logs. In a standard workspace, they can be viewed on the Eclipse console, while now you have to use the following command from a standard terminal (or Powershell):

docker logs -f [CONTAINER_NAME] Docker Gulp Watch

Here comes the trickiest part. It would be very nice if also frontend developers could rely on the same Dockerised environment to build up Liferay Themes without compromises. Unfortunately, Gulp watch task doesn't work when Liferay runs inside a container. Furthermore, a non trivial amount of customisation to the standard Gulp pipeline is necessary to make it work.

This is why I decided to create a separate npm hook module to handle this integration. You can find such module published here on npm, together with a short description on how to use it with Yeoman generated Liferay Themes.

Basically, this module overrides some Gulp watch and deploy tasks, in order to copy files from a local .web_bundle_build folder to the container file system, using docker cp command. This allows Liferay runtime to succesfully update its packages. Moreover, since this process decouples files managed by Gulp from those handled by Liferay, it seems to solve also some file permission issues that occur on Windows systems and cause Gulp watch to stop working.


We reached the end of this containerised journey.
To sum up, this is an example of how Docker can be integrated into Liferay Workspace, so that developers can rely on all its beautiful features without be constrained to break their habits. I hope that such a guide can be useful to the community. If you have further ideas PLEASE share them hereunder: I hope that this journey is only another step in a much longer one.
Happy Liferay Coding!!!

Iacopo Colonnelli 2018-02-15T17:58:32Z
Categories: CMS, ECM
Syndicate content