Assistance with Open Source adoption

Open Source News

Joomla 3.8.5 Release

Joomla! - Tue, 02/06/2018 - 09:45

Joomla 3.8.5 is now available. This is a bug fix release for the 3.x series of Joomla fixing regressions which were reported after the 3.8.4 release.

Categories: CMS

Your 2018 E-Commerce Calendar is ready for download!

PrestaShop - Tue, 02/06/2018 - 05:20
You have the talent and the ideas, the PrestaShop team has a calendar that will support you throughout the year!
Categories: E-commerce

Five critical CMS capabilities for public services

Liferay - Mon, 02/05/2018 - 11:44
Choosing the right Content Management System (CMS) has always been instrumental in the success of any organisation’s digital services. But today, with the citizens of all ages expecting more from digital services than ever before, choosing the right website platform has never been so vital to encourage people to use your digital services and drive efficiencies. New devices, technologies and apps are constantly emerging, making the task of digital transformation even more arduous for public sector organisations trying to keep up with consumer’s digital demands. So in 2018 and beyond what exactly should a public sector service be looking for in a CMS? In this blog I will take a look at the long list of requirements – and where public sector organisations tell us they hit the wall – to highlight those critical capabilities project teams should be aware of before adopting a CMS. 1. A user-centric admin interface First things first. Everybody on your team needs to feel comfortable using the new CMS, and be able to efficiently carry out their work. A friendly user interface that presents the various members of a team with the access and functionality they need to carry out their role is paramount.  This also extends to the content editor, where communications and web personnel are often the most regular users – requiring fast and streamlined workflows. Features like bulk image uploading, drag-and-drop page building and simple formatting tools will all help make it easier and more efficient to write and publish content such as blogs or press releases and publish to all relevant channels. For larger organisations, the ability for the IT team to author templates and workflows for each role within the organisation will help remove IT / web team bottlenecks, and also ensure the website(s) have a consistent structure and look and feel at the source. 2. Asset Management A CMS shouldn’t just be capable of uploading, downloading and storing assets. It should also make it easy for your team to search through those assets in order to find what they’re looking for.  Much thought is given to the structure of public-facing parts of a website, but the experience of those staff accessing the site is also vitally important. A proper content strategy and taxonomy will make it easier and more efficient for users to update a document such as a pdf because that document can be found easily according to its metadata, taxonomy information and if appropriate workflow status (is it approved / final?).  With a proper content strategy and taxonomy, the right CMS encourages reuse of content and makes auditing and archiving and data management manageable over time. 3. Collaboration And Workflows Having a strong content editor is important, but most content workflows start several stages before a piece of content is updated or new content published. At some point, that content needs to be entered into the CMS and prepared in the necessary format for publishing. Workflow and Collaboration capabilities can further streamline operations and reduce subsequent edits and fixes to live content by taking at least part of this process inside the CMS.  For example, the web team may wish to enable an administrator to revise a page that details a service for citizens which must be reviewed by a compliance officer before it is published. Alternatively, an external contractor could post an update that is then reviewed for style and messaging by the communications team they publish. If you have a Document Management System or storage system, consider whether your CMS will integrate the functionality you need.    4. Omni-channel delivery & personalisation Being able to deliver your content and engage audiences across devices and channels is an uphill struggle for many public sector entities. Consumers already expect content on their smartphones and tablets, but their expectations are also growing for a wider range of channels such as smart home assistants (Amazon Echo, Google Home). The starting point is to ensure your CMS (and the theme you use) can deliver content effectively via a web browser using Responsive Web Design approach (for example Bootstrap) or Adaptive Web Design approach (optimised at the server for the device).  If your project needs to provide a high degree of interaction then a mobile app or hybrid web/app approach may be required to deliver the quality of user experience required. A headless CMS is able to decouple the management of content from its presentation and offers an efficient way to deliver content to any channel.  Another important way to improve the citizen's experience is personalisation. If service users receive only information that is relevant to their area, about the services they use and in their chosen format/ language/channels then they will more engaged and adoption will increase. Personalisation is a fast-moving area of technology development, so be sure to evaluate the CMS personalization engine and roadmap. Can it help segment, understand and tailor customer experiences across those channels? This article will help you learn more about delivering personalised content.   5. Multi-site Compliance mandates accessibility – to generalise each citizen must receive equal quality of service, regardless of their age, language or other demographic.  But budget holders must wring out efficiencies and reusability. This suggests fewer sites, less complexity, lower operational costs.  These are just some of the priorities to juggle at the coal face. Here, you may need to look at multiple sites to cater for different audiences or serve different public-facing entities. For example, if two local councils share services they may each need a public facing site or homepage that displays relevant announcements, information, services and branding but the self-service portal could be shared and accessed by both groups of residents. By building multiple websites, each with their own domain name on the same platform, the relevant services and content can be reused across the two sites and the IT and hosting resources managed centrally. For example, the New South Wales Department for Education provides public websites for 2,044 schools from a single platform. Where services need to be delivered in two languages, also look at the localisation requirement – multi-site is one option if the content is unique to that audience, else built-in multi-language capabilities can help to serve multiple versions of a page if a significant amount of content must be served in multiple languages.  The elephant in the room  With the essentials out the way, let's turn our focus to the one area that differentiates a good website from a great citizen experience: integration.  Integration helps in two key areas. Firstly, a CMS with a strong set of integrations will help you keep up to date with new opportunities. “Login with Facebook” might simplify login as an off-the-shelf plugin, but it’s probably not the security and identity management you actually need. Can you integrate system x,y,z? To transform the user experience and achieve the sort of channel shift most public services require it’s essential to connect the back office systems staff use every day. So, an organisation using SAP to manage finance or a CRM system to coordinate across teams must draw the required information from these systems to deliver useful and actionable information for self-service portals. A proprietary platform that does not allow you to build custom applications and integrate the systems of record upon which public services are administered will only hinder your digital transformation, as your developers will need to bridge the gap between the systems (or worse still wait for a solution from the vendor).  The bottom line? No integration, no transformation. Choosing Wisely Choosing a CMS has always been a delicate task, but in 2018 and beyond, you need to consider the demands of the consumer — which is precisely why integration with other systems and open standards is so vital. So, my advice is to get these essentials covered, and then focus on perfecting the front-end user interfaces. Because if your project is lacking foundations, you’ll need to develop custom applications or finance other tools to plug the glaring gaps before you get a chance to transform experiences.   Why does integration improve digital services?

Explore how Liferay DXP helps organisations move from web content management to delivering digital services.

Read more   Robin Wolstenholme 2018-02-05T16:44:43Z
Categories: CMS, ECM

GDPR and CiviCRM

CiviCRM - Sun, 02/04/2018 - 18:24

Our new extension aims to enable charities/organisations to manage their supporters in a GDPR compliant manner. GDPR in itself does not introduce many new requirements however it does introduce a number of new obligations on organisations that hold and use data about individuals.

Categories: CRM

Happy Anniversary—The Next 20 Years of Open Source Begins

Open Source Initiative - Sat, 02/03/2018 - 08:53

Open Source Software—yes, we did coin the term (thanks Christine Peterson) and started the movement—is software that can be freely used, changed, and shared (in modified or unmodified form) by anyone.

Thirty-five years ago when Richard Stallman decided that he could no longer tolerate proprietary software, and started the free software movement, software freedom was misunderstood and dismissed. Twenty years ago a group of free software advocates gathered in California and decided that software freedom needed to be brought to the business world. The result was a marketing program called “open source”. That same month, February 1998, the Open Source Initiative (OSI) was founded as a general educational and advocacy organization to raise awareness and adoption for the superiority of an open development process.

It is said, whenever you start a revolution first they ignore you, then they laugh at you, then they fight you, then they join you.

People did laugh at the idea of free software, they questioned the quality of the software, the feasibility of the development model, and the commitment of the community. English-speaking people only heard the word “free” as in no money, and they laughed at the idea of software being created without cost or payment.

With the launch of the open source marketing program people fought us. SCO fought very strongly. It tried to kill off Linux. Microsoft tried to kill open source, conspiring in something called the Halloween documents.

Yet today they’ve joined us—open source is eating the software world. As the vast majority of users and developers believe, open source improves your efficiency in software development, it leads to and eases interoperability, and fosters higher quality software delivered faster and cheaper. Businesses find open source software fundamental to infrastructure, as well as a critical factor for driving innovation.

But we’re also facing the next 10 years of open source.

The first 10 years of open source were dedicated to advocacy and controlled by controversy. In the second 10 years we saw adoption and even ascendancy within many sectors. Ahead, in the third 10 years, the goal is assimilation, and the expectation is authenticity.

Over the next ten years, the OSI anticipates open source communities to gradually change. The first decade was characterized by enthusiasts or hobbyists—a hacker community—devoted to developing specialized tools or projects to replace off-the-shelf software. In the second decade open source focused on components, and was dominated by single-project specialists (i.e. individual companies, or non-profit organizations). The third decade will be dominated by generalists—businesses, consortia, and foundations—that work across many open source communities, integrating them and their outputs.

We also saw the first decade dominated by the search for “the open source business model.” We may never have found it, just companies that started up and tried to control us through their business. During the second decade, businesses focused on services supporting their internally-developed open source products. Over the next decade businesses will sell (and hire) the skills to assemble, integrate, and operate the component parts that characterizes today’s businesses like Google and Facebook and Twitter—every business will face complexity, and scaling that complexity in production.

Open source succeeded because the OSI first defined open source (thanks Bruce Perens & Debian), then standardized licenses. What we'll see in the next decade is the consolidation of licenses, and sadly, we expect to see abuse of the open source software label (i.e. fauxpen source and openwashing). We will see a stabilization and a shrinking of the number of licenses in use, because of the need to manage ecosystems of complexity.

In the third decade of open source, we will rediscover software freedom. We allowed ourselves to be divided—the free software and open source communities—and pretended there was a difference between the two, but there is not. They are both expressions of software freedom and we're going to rediscover that in the next 10 years because we will be forced to solve problems with new models: cloud computing, the Internet of Things, manipulation of Big Data, Blockchain, 5G, etc. As we solve those problems we will discover that it is vital to go back to the Four Freedoms, ensuring software is free to use, that it is open to study, that it may be freely changed, and that it may be equally distributed.

Finally, the OSI has a future as well. The OSI has been crystallizing consensus for the last 20 years, and we're committed to that work. Our support for continued growth, in both open source software and the communities that enable it, will change. “Open Source has won” so the need for combating "fear, uncertainty and doubt," the propaganda that questioned open source software’s viability or feasibility, has waned. An organization dedicated to simply promoting adoption and advocating for collaboration is no longer enough. Although the OSI will take on this work when needed, the upcoming decade will require adopting and contributing organizations to operate and engage authentically, ensuring interactions between projects and communities conform to established norms, best practices, and an open ethos if they want to successfully manage the emerging complexity. Helping open source users, developers, and communities here, will be an important role for the OSI in the third decade.

New initiatives with institutions of higher education and professional development programs will allow those just beginning with open source or those working to address complexity, no matter what their role—developer, community manager, project/program manager, marketing professional, attorney, CIO, CEO or any other—to benefit from all the opportunities of software freedom.

OSI Working Groups will be expanded. We will continue to invest in groups and projects that directly increase the awareness and adoption of open source, and build bridges between communities. But we realize, due to open source’s broad influence spanning many technologies, sectors, and industries, that we will need to extend the scope of our initiatives to address new issues, emerging from fields which we never anticipated impacted before, or simply did not exist.

In the very near-term—and on a much lighter note—over the next year we will be celebrating: celebrating 20 years of open source and 35 years of software freedom. So along with our affiliate members, sponsors and some of the worlds most influential conferences, we're calling a big party and you're all invited. That big party starts on the 3rd of February, 2018—today—with anniversary celebrations throughout the world, the first are at FOSDEM (right now) in Brussels, and at Campus Party Brasil, in Sao Paulo (also right now). In addition to these events we will be hosting celebrations at other venues and conferences across the globe, at ACT-W, All Things Open, FOSSAsia,, LinuxFest Northwest, OpenApereo, OpenCamps, OpenExpo, OSCON, Paris Open Source Summit, and SCaLE16x.

In recognition of both OSI's and Open Source Software’s 20th Anniversary, and in order to begin our work for the next decade, we are launching the Open Sources Network (online via, which will serve both as a community of practice and a mentorship program for those addressing legacy issues of open source as well as facing the complexity ahead. The goal of the Open Sources Network at is to further promote and support adoption of open source software over the next twenty years as issues shift from open source’s viability and value to issues around complexity and authentic participation.

The Open Sources Network connects those that “get it” and “did it” with a global network of highly qualified peers across industries. Your experiences as an exemplar in the community will help others address common (or unique) issues. Some open source themes you will find to explore include:

  1. Development : How has open source benefited code development at organizations in terms of costs, quality, customization, security, support, and interoperability? How do organizations manage open source development/contributions?
  2. Business: What business practices align best with open source? How do companies collaborate with others to enhance products and services while creating new business opportunities?
  3. Brand Awareness: How have organizations’ commitment to open source helped promote their brand among the open source community, their communities, markets, and industries?
  4. Community Building: How has open source helped organizations connect with developers, businesses, non-profits, government, and/or educational institutions.
  5. Talent Nurturing: How has participation in the open source community helped organizations attract and retain the best talent?
  6. Open Innovation: How has open source, both from a legal perspective (e.g. OSI-approved licenses) and social perspective (culture of collaboration), helped organizations drive innovation?
  7. Leadership: What is the future of open source? What are the challenges and opportunities for the next 20 years within and across different organizations, projects, technologies? How will open source shape industry, and what role will organizations play?

We hope you will join us in celebrating throughout 2018, but also join us in our work over the next decade. We've come an amazing distance from 35 years ago, and we’ve achieved so much over the past 20 years: we can all be proud of what we’ve accomplished, excited about what is yet to come, and committed to continued development. The future of open source belongs to us!

Image credit: RevolutionOS, ©Copyright 2002 Wonderview Productions, LLC All Rights Reserved
Edited by, Patrick Masson.

Categories: Open Source

Organizing Successful Events in CiviCRM - February 7th at 10 am MT

CiviCRM - Fri, 02/02/2018 - 16:09

Cividesk wlll be offering the intermediate level on-line training for Events, Organizing Successful Events in CiviCRM on Wed., February 7th from 10 am to 12 pm MT.  This class is a good follow-up to the Fundamentals of Event Management taught by Cividesk.

Categories: CRM

Free CiviCRM Training

CiviCRM - Fri, 02/02/2018 - 11:59

One way we try to give back to the CiviCRM community is by offering free user training each Wednesday in the form of one-hour webinars focused on specific areas of Civi. We've recently posted our upcoming training sessions for the next few months. To find out more or to register, go to We hope you will join us!

Brought to you by Greenleaf Advancement.

Categories: CRM

The Power of Patience

Liferay - Fri, 02/02/2018 - 11:01

So, as a developer, I'm like usually whacking my whole runtime environment and starting over.

Why? Well, regardless how much I try to keep it clean, cruft will find its way into the environment. I'm left with users I don't want, content I don't want, pages I'm not using any more, sites created to demo something I'm not demoing any more...

So I'll throw out my data directory, drop my database and create a new one, purge old logs, modules, osgi/state and the work directories, ... Basically I get back to a point where I am starting up a brand new bundle, all shiny and new.

One of the things I often find when I do this, though, is that I'm a lazy developer.

So for awhile I was actually writing code that had dependencies on some environmental aspect. For example, my code would assume that a custom field had been created, roles or organizations were defined, ...

When I would bring up the environment, my code would fail because I had forgotten to create the dependent data.

So I got a little smarter, and I learned about the Liferay Upgrade framework. I now use this framework when writing my modules so I can just deploy my modules and, if the dependent data is missing, it will be created automagically. This works really great and, from a deployment perspective, I can promote my modules to test, QA, and prod knowing that my modules will create whatever they have to have to function properly.

This has been working really well for me, well, until today.

Today I did one of my purges and then fired up the environment and my upgrade process was failing.

I had created an upgrade process that was creating a custom field for the User model object. The code totally works when deploying to a previously-running instance, but I was getting an error during startup after the purge because my code was executing before the portal finished loading all of the default data. So one of the things you need for a custom field is a company id to bind them to, but my upgrade process was running before the first Company record was created.

Not company record, no company ID, and my code was just throwing all kinds of exceptions.

So I was effectively still being lazy. I was assuming that my code always ran at a particular time and that certain things were already available, and I found that when starting up from a clean state my assumptions caused my code to fail.

Basically I wasn't waiting for a good time for my code to execute (well, I didn't think I had to wait).  As a module developer, we can all often assume that if our code works on a hot deploy, well then it will always work. The problem, of course, is that environment startup we really don't have control over when our modules load, when our components start. As far as OSGi is concerned, if the references have been resolved and injected, the component is good to go.

But often times our components may have some sort of dependency that is hard to declare. For me, I was dependent upon the initial Company record being available, and I can't really declare a dependency on that which OSGi would be able to verify. In this forum thread, the code wanted to unload a component that had not been loaded/started when the componen t was activated, so sometimes the right thing happened and sometimes it didn't.

So the key is to identify when you have code that really needs to wait on something, but also to have something identifiable to OSGi to wait on.

What if you can't identify something for OSGi such as the initial Company record? Or the creation of some service in a different module that you don't want to declare as an @Reference in your component?

One trick I like to do to solve this case is to add a final dependency on portal startup. By adding the following to your @Component class, you will typically get the right outcome:

@Reference(target = ModuleServiceLifecycle.PORTAL_INITIALIZED, unbind = "-") protected void setModuleServiceLifecycle(ModuleServiceLifecycle moduleServiceLifecycle) { }

That's it. This code basically has OSGi wait to start your component until the portal has been initialized. Note that I'm not doing anything with the injected object; I'm just forcing OSGi to delay the start of my component until it can be injected.

Adding this line to my Upgrade class, I did my purge stuff and started up the portal. After the portal was initialized, the Company record is guaranteed to be available, and my Upgrade had no problem creating the custom field.


So, keep this in mind if you need to ensure that some component doesn't try to do its thing too early in the startup process.

Oh, and if you just need to enforce a start sequence between your own components? Well, just remember that OSGi will not start a component until its @References can be injected. So if B depends on A, and C depends on B, just add the necessary @Reference guys to B and C. At startup, OSGi will be able to start A (since it has no dependencies), which means it can then start B and finally start C, guaranteeing the startup sequence that you need to have.

David H Nebinger 2018-02-02T16:01:33Z
Categories: CMS, ECM

Las 6 ventajas competitivas de las Plataformas de Experiencia Digital heredadas del Portal

Liferay - Thu, 02/01/2018 - 07:34

Gartner ha divulgado su primer Magic Quadrant para Digital Experience Platforms (Plataformas de Experiencia Digital, DXP), en el que ha reconocido a Liferay como líder. Este análisis independiente, permitió a Gartner evaluar 21 proveedores en base a su visión completa y su capacidad de ejecución y de integración, entre el conjunto de funcionalidades ofrecidas; un contexto en el que Liferay ha sido nombrado como uno de los cuatro únicos líderes de este nuevo cuadrante.

El Cuadrante Mágico para DXP es el sustituto del antiguo Cuadrante Mágico para Portales Horizontales, lo que se puede considerar un paso natural ya que Gartner predijo la evolución de los portales hacia las plataformas de experiencia digital el año pasado. Las DXPs ofrecen un conjunto de herramientas para una gestión de experiencias coherentes y conectadas en cada etapa del customer journey y sus diferentes touchpoints, como pueden ser los portales, websites, móviles y dispositivos IoT.

Según la explicación de las tecnologías analizadas en el informe, las DXPs suelen tener una herencia de portal o de sistemas de gestión de contenidos (CMS: content management system) en su tecnología. Proveedores, como Liferay DXP, que tienen sus raices en los software de portal tienen su principal fortaleza en el hecho de que son capaces de conectar a las empresas tanto con su público interno, como con su target externo.

A continuación describimos las 6 ventajas de las DXPs basadas en plataformas de portal y que pueden empoderar los negocios de una manera única. Mientras que algunas de estas ventajas también se encuentran en algunos CMS, En la mayoría de los casos, estas son inherentes a la mayoría de las plataformas de portal y, por tanto, tienen una fuerte presencia en aquellas que evolucionan a DXP, incluso durante la fase de lanzamiento inicial, por lo que las probabilidades de que encuentres estas ventajas en esta tipología son mucho más altas.

1. Capacidades de Integración

Las plataformas de experiencia digital permiten que las empresas afronten el proceso de la transformación digital tanto en lo que respecta a sus operaciones internas como a su oferta de experiencias de cliente (UX). Las UX modernas dependen de la facilidad y consistencia con la que un cliente pueda llevar a cabo un proceso accediendo desde los diferentes puntos de contacto disponibles: desde un website a las aplicaciones, pasando por los sistemas de back-end y otros touchpoints, todo ello mientras la empresa recopila sus datos para analizarlos posteriormente y ofrecerle así un servicio personalizado. Las compañías deben ser capaces de integrar la gran variedad de los sistemas ya existentes para poder proporcionar excelentes experiencias de usuario.

Las DXPs con herencia de portal tienen las competencias fundamentales para integrar los sistemas de back-end, lo que permite que ofrezcan a clientes, empleados y otros usuarios acceso a las informaciones que sean necesarias a través de múltiples aplicaciones de la empresa. Por ejemplo, los datos del cliente almacenados en un CRM u otras herramientas de automatización de marketing pueden ser unificados y compartidos a través de una DXP basada en una plataforma de portal. De esta forma se consigue un ahorro de tiempo y de esfuerzo tanto para las compañías como para los clientes; ayudando así a las organizaciones a entender mejor a su audiencia objetivo a través de las conclusiones extraídas de esta compartición de datos.

2.Foco en crear relaciones con el cliente a largo plazo.

Los portales están diseñados para ayudar a conectar las empresas con su público objetivo a través de interfaces seguras. Esto puede incluir bases de usuarios específicas, como clientes que necesitan acceder a información y herramientas de forma integral, a través de experiencias consistentes. Rivet Logic, destaca las fortalezas de las DXPs basadas en tecnología de portal en la construcción de una relación a largo plazo con el cliente, gracias a su capacidad de creación de experiencias individuales únicas desde el login hasta el soporte. Además, el servicio al usuario ha venido siendo la principal función de los portales desde sus orígenes. Esta puede ser considerada otra ventaja competitiva con respecto a las DXPs provenientes de los CMS, ya que estas últimas están tradicionalmente más centradas en prospects anónimos.

A través de su DXP con herencia de tecnología de portal, Liferay ha ayudado a una gran variedad de negocios a comprender y comunicarse mejor con su público objetivo. Como hizo con el Mercury Insurance Group, que ha creado un portal para gestionar la relación que cada cliente tiene con la compañía a lo largo del tiempo y ofrecerles los auto-servicios necesarios, algo que mejora su experiencia. Además, la empresa global de IT, Unisys, ha creado el VantagePoint con Liferay, un portal de servicios que utiliza funcionalidades de integración para ofrecer servicios configurables para los clientes que tiene en alrededor del mundo.

El informe del Magic Quadrant de Gartner destaca el hecho de que los departamentos más modernos de IT suelen encontrar la solución en las DXPs provenientes de los portales. Las experiencias resultantes ayudan a aumentar el número de clientes fidelizados, además de dotar al equipo de ventas de información relevante.

3. Soporte para un lugar de trabajo digitalizado

Las plataformas de experiencia digital suplen diversas necesidades online que surgen en la vida cotidiana de los trabajadores. Aprovechando las diversas herramientas y métodos de comunicación que ya se utilizan en los portales de empleados, las DXP con herencia de portal pueden utilizar los métodos ya probados anteriormente, y expandirlos para crear un ambiente de trabajo digitalizado robusto. Mientras que tanto las DXPs basadas en CMSs, como aquellas que tienen herencia de portal son válidas para crear estos espacios de trabajo, el software de portal viene siendo usando tradicionalmente para crear las intranets de los empleados. Algunas de las funcionalidades ofrecidas por los portales son las interfaces personalizadas en base a las preferencias y funciones del trabajador, su capacidad mobile-friendly, permitiendo que tu equipo pueda actuar sobre la marcha, así como sus capacidades de gestión de información, lo que va a promover una mejor comunicación interna. Estos diversos elementos se utilizan en mayor medida en los espacios de trabajo digitales creados por DXPs.

Los lugares de trabajo digitalizados dan a los equipos acceso a una gran cantidad de información y a herramientas digitales que les ayudarán a completar mejor sus tareas y dar respuesta a las necesidades de los clientes. Gracias a la flexibilidad ofrecida por una DXP, estos espacios de trabajo son accesibles a través de cualquier dispositivo permitiendo que los empleados encuentren las informaciones que necesitan en cada momento. Además, de esta forma, las empresas están renovando sus portales e intranets con el objetivo de proporcionar a sus trabajadores el mismo nivel de importancia y cuidado que tienen con sus clientes, convirtiendo el ambiente de trabajo en un espacio más colaborativo y agradable. La consecuencia del uso de una única plataforma para dar respuesta a las necesidades de todos los departamentos, será la eliminación de los silos de la compañía a través de la creación de una cultura de comunicación que va a facilitar el flujo de informaciones y insights sobre el cliente.

4. Gestión de las relaciones B2B

Tal como se ha mencionado, los portales tienen un gran rol en las relaciones B2B y B2E. Sin embargo, tienen un importante papel también en los escenarios B2B.

Muchas empresas del sector B2B, han utilizado la tecnología de portales para facilitar sus relaciones con otras compañías a las que prestan servicios, creando interfaces útiles y seguras. Harvard Business Review destaca que el moderno proceso de ventas B2B se ha vuelto más complicado que nunca, lo que genera confusión y una insatisfacción que puede resolverse si se reenfoca, abordando estas experiencias como se hace desde los procesos B2C. Esto significa tener una interfaz más clara y personalizada que ofrezca los servicios demandados y que se adapte a las fases del customer journey. Las DXPs provenientes del portal utilizan las conexiones ya establecidas por su antecesor y las suman a sus nuevas capacidades. Al hacer esto, las empresas B2B pueden cumplir con las expectativas de sus usuarios y fortalecer las relaciones comerciales con sus clientes, en una era donde la competencia es alta dada la rápida evolución de la innovación en lo que respecta a las experiencias online.

5. Capacidades de gestión segura de datos.

La información de valor extraída de los datos tiene un papel relevante para las estrategias de marketing y de servicio al cliente de compañías de todos los sectores en la actualidad. Sin embargo, todos los datos utilizados para obtener estos insights deben ser almacenados de manera segura para evitar posibles brechas de seguridad y prevenir una posible fuga de información que pueda perjudicar tanto a los clientes, como a la propia empresa. Además, en la actualidad, el nuevo tipo de usuario moderno genera una mayor cantidad de volumen de datos, lo que es utilizado para el diseño de de estrategias específicas de marketing y de experiencias de clientes. Al contrario que los CMS, los portales están diseñados para soportar un gran número de usuarios, así como un gran flujo de información que, a menudo, contiene datos sensibles tanto de clientes como de negocios. Por ello, las DXPs basadas en plataformas de portal son desarrolladas sobre sistemas cifrados, listos para realizar una gestión del almacenamiento y análisis de la información de manera segura.

6. Procesos de digitalización ágiles.

Tal como ha sido destacado por Gartner, los portales pueden ser utilizados con una arquitectura de framework común. Esta funcionalidad, presente, por ende, en una DXP con herencia de portal, permite que las compañías creen un website y reutilicen el framework que han creado para construir otros touchpoints. De este modo, las empresas no solo se aseguran de que todos los aspectos de su presencia digital son uniformes tanto en funcionalidad como apariencia, sino que también ahorran tiempo y dinero por el hecho de evitar tener que crear todo desde el principio. Al convertir una DXP basada en portal en una fábrica de soluciones, las compañías son capaces de avanzar con sus estrategias digitales , al tiempo que mantienen el control sobre la calidad de cada experiencia ofrecida.

Sacando provecho de la herencia de portal de Liferay DXP

Al reconocer a Liferay como líder, Gartner ha destacado la flexibilidad y agilidad con la que Liferay DXP puede crear experiencias extremadamente personalizadas, la capacidad de respuesta de la empresa a la hora de desarrollar productos y funcionalidades que tienen en cuenta las necesidades del mercado y su sólida trayectoria en la oferta de un excelente soporte y servicio al cliente.

Liferay DXP se basa en el legado de Liferay como una plataforma de portal, que utiliza la tecnología desarrollada para capacitar a los equipos de trabajo y proporcionar a los clientes acceso a la información que más necesitan. Muchas compañías alrededor del mundo han utilizado la tecnología Liferay DXP para abordar diversos aspectos de la experiencia online que ofrecen a sus clientes y empleados, incluyendo websites, aplicaciones móviles y experiencias digitales conectadas. Esta herencia de portal ha dotado a Liferay DXP de ventajas competitivas que le hacen distinguirse en el mercado.

Accede al Magic Quadrant de Gartner para Digital Experience Platforms

Descubre por qué Gartner ha reconocido a Liferay como líder en el sector en su primer informe del Cuadrante Mágico para Plataformas de Experiencias Digitales y conoce todas las ventajas de las DXPs.

Lee el informe del Magic Quadrant  Rebeca Pimentel 2018-02-01T12:34:06Z
Categories: CMS, ECM

Hidden Dangers of Trying to Keep Liferay Up to Date

Liferay - Wed, 01/31/2018 - 22:09

At Liferay Symposium North America 2017, I had a discussion with a few of our customers on the hidden dangers of rolling back Liferay changes.

There are multiple ongoing efforts to improve how we will handle the issue for the upcoming 7.1 release, such as LPS-76923. However, the 7.0 release is already affected, and DE-40 is fast approaching with another round of hidden dangers scheduled to arrive with it.

This blog post was drafted to provide a little more transparency around what is about to happen so that people who have a rollback plan actually have enough information to formulate a complete rollback plan.

With that being said, not everyone immediately realizes there is a problem that arises when you need to rollback the Liferay platform, so I'll start with an example starting from the side of customization, which may be easier to relate to.

Imagine that you've followed the guide on Creating Upgrade Processes for Modules, and you decide to create an upgrade process in order to transition to a new version. While it's a very complete article from the perspective of what you do to move forward, there's one thing the article doesn't try to answer: what happens if you need to go backwards?

If you've ever tried it, you'll find that there is actually little you can do.

And therein lies the problem: some people do not realize that this lack of things you can do to rollback changes applies to the Liferay platform in the same way it applies to customizations.

Core Schema Changes

Of course, it turns out that in some cases, Liferay has as much of a problem moving forward as it does moving backward.

Let's say you've skimmed through the javadocs linked in Development Reference, and you've decided that you want to take advantage of some newer API that's been made available in the later tags of the Core Portal Artifacts. Or maybe, you've browsed through our issue tracker or our release notes and decided that you need one of the fixes or changes. To do so, in theory all you do is rebuild Liferay from source at a later revision that is equal to or later than the specific tag containing the API change you need.

But, what happens if you decide that the newer commit contains changes that you dislike, and you decide you want to rollback to an earlier version?

In theory, all you need to deal with is the changing API, assuming you started using that new API. However, in practice, one other thing you have to face much more prominently in the current Liferay release (at least, when compared to past releases) is schema changes.

Let's say that you started at a release that has 7.0.3 GA4 as its nearest parent tag, but you've decided that you want to roll forward to a new release where 7.0.4 GA5 is its nearest parent tag.

However, if you perform this update, Liferay's core schema version (essentially, a version number that describes the schema for service builder classes living in portal-impl) has also changed. These updates are documented as new versions added to ReleaseInfo. Any time this happens, Liferay treats this as a schema change.

Core Schema in Pre-7 Releases

Early on in Liferay's history (5.1, 5.2, 6.0), Liferay code review allowed new point releases within the same branch to have schema changes. For example, if you were on 5.2 EE SP1, there might be a schema change if you attempted to go to 5.2 EE SP2. These schema changes would apply to the next release.

Of course, with schema changes happening in both a 5.2 branch and a 6.0 branch, you can imagine that depending on where you started within the 5.2 branch, you would need different processes to run in order to reach the correct final state in 6.0. So in order to ensure Liferay ran the correct upgrade processes, you would need to set the upgrade.processes values in portal properties for the upgrade, and there was documentation describing what those properties should be depending on where you started your upgrade.

Later on in Liferay's history (6.1, 6.2), Liferay decided that all of the different permutations were getting really unwieldy. Therefore, we added all the known paths to portal properties (something we later called "seamless upgrade") so that there wouldn't be mistakes from people following the documentation, and we strongly discouraged schema changes after the official release.

If there was something that seemed like it would need a schema change in order to fix, we invested a lot of extra effort into finding a way that would not require a schema change. If there was no way to address something without a schema change (for example, performance issues that required we reorganize how we store data in a column), we might hide the schema change inside of verify.processes. This resulted in an increase in the number of upgrade-like fixes that appeared as verify processes.

Core Schema in Post-7 Releases

For Liferay 7, we added a policy around verify processes where you needed to demonstrate that it's something that must be run for every release before you could make it a verify process.

Because we knew from past experience that sometimes schema changes might need to happen anyway, this also meant that we would need to re-allow actual schema changes within the same branch. If it weren't for the shared core of CE and DXP, this would have brought us back to Liferay's darker days of multiple variations in upgrade steps, but the shared core side-steps this particular problem.

However, what happens if you try to startup Liferay against a code base that assumes a newer Liferay core schema version?

Well, we also removed the logic which automatically ran core upgrades as you started up, which used to allow you to start up Liferay as long as you were switching to a newer version. As a result, this meant that whenever a version change happened, you would always need to consciously run the upgrade process whenever you transition to that new version, giving you a stronger sense that significant changes were about to happen to your database.

However, there is one thing missing in all of this planning put into preventing startup on core schema version changes: it only works if you only use traditional CE releases, where the core schema version formally changes. If you are in an environment where that version number never changes, how many schema changes you've successfully run starts to get murky.

A particularly awkward variant of this limitation arises if you choose to use DXP rather than CE: your version number is fixed at 7.0.10 from the time you first installed or upgraded Liferay. As a result, Liferay will never force you to run additional core upgrade processes, even when more are added in subsequent Liferay releases.

Known Symptoms of Incomplete Schema Upgrades

If you upgraded to DXP before SP1 (November 1, 2016), or you upgraded with a hotfix that uses DE-7 or earlier as a baseline (the fix pack corresponding to SP1, as noted in the Service Pack Matrix), you might be affected by the following issues due to missing schema updates:

  • LPS-66133: Discussion-enabled assets with zero comments cause performance issues
  • LPS-66599: MBDiscussion table has entries where groupId is 0, which prevents staging from working
  • LPS-44965: For a specific upgrade path (6.1.10 -> 6.1.20 -> 7.0.10), text columns are the wrong size on Oracle

If you upgraded to DXP before SP2 (March 28, 2017), or you upgraded with a hotfix that uses DE-12 or earlier as a baseline, you might be affected by the following issues due to missing schema updates:

  • LPS-68410: Certain text columns, like LayoutPrototype.description, allow fewer characters on SQL Server and Sybase than they would allow on other databases
  • LPS-68775: Organization.type_ column contains values not defined in the organizations.types portal property
  • LPS-69878: Group_.groupKey column is a CLOB instead of a VARCHAR on MySQL

If you upgraded to DXP before SP3 (May 11, 2017), or you upgraded with a hotfix that uses DE-14 or earlier as a baseline, you might be affected by the following issue due to missing schema updates:

  • LPS-70807: PortletPreferences table contains references to 1_WAR_kaleoformsportlet
Module Schema Changes

Just as before, let's say you've skimmed through the javadocs, and you've decided that you want to take advantage of some newer API that's been made available in the later tags of the Core Portal Artifacts. However, this time let's also assume LPS-72269 was recently applied to the core source code of Liferay, and you both started and ended on a commit that sits between 7.0.3 GA4 and 7.0.4 GA5.

So, you fast-forward your repository to a point in time which contains the API that you want, and you build Liferay from source. However, you encounter some behavior that you dislike, and so you decide to bring things back to how they used to be. To do so, you rollback to your original commit, and you build Liferay from source again.

When you start up Liferay after this rollback, something unexpected happens. You no longer see the "Navigation" option in the Control Panel side menu.

When Module Schema Changes Occur

Essentially, as long as the portal can start, and the module has all of its packages satisfied, its upgrades will run.

In theory, when you use only CE releases without building from source, the only time you will see a module schema change is when you acquire the new release containing the updated core schema version. As a result, Liferay will refuse to start due to the core version changes, and the only time module upgrades happen is when you manually run the upgrade process.

In practice, in fulfilling the dream of modularity, module schema versions change independently of the core schema version, and so it is theoretically possible for a module upgrade to happen without a core schema version change, as long as the release manager is configured to allow it (it is allowed by default).

Of course, because transitioning between actual CE releases prevents the portal from starting until the upgrade process is officially run, this really only affects two audiences: those who build from source between core schema changes, and those who choose to use DXP instead of CE.

In those situations, because there is no additional restriction on when a module upgrade will run beyond "can the portal start up", we have a situation where module schema upgrades will simply run as soon as the portal starts up and the module is deployed, and there will be no advance warning.

Transitive Component Dependencies

So how does all of this lead to the "Navigation" option disappearing? Welll, between the commit you started from and the commit you tested, pull request #50722 was merged, which resulted in an updated Liferay-Require-SchemaVersion on the

As a result, after starting Liferay with the newer module, the database was automatically updated to reflect the module schema changes. Liferay recorded that this updated schema occurred, and when you rolled back, the rolled back version of declares that it provides an older schema version.

And this is where the problem arises. Liferay announces to the different modules that only code that knows how to work with the newer schema version should be run. (Of course, it does so very quietly, which is another point of contention; it just quietly fails instead of loudly complaining about it.)

This means that even though the bundle starts, none of its service builder components are made available as OSGi components. Through several layers of transitive dependencies, the code responsible for rendering "Navigation" option in the Control Panel side menu no longer has its dependencies satisfied, and it disappears.

Identifying Module Schema Changes

So how do you know if you're having problems that might be related to schema changes?

If you are building from source, you will need to know both the starting commit and the ending commit. From there, you can get a list of all the schema versions by scanning all the bnd.bnd files in the source for the Liferay-Require-SchemaVersion header, and use a diff tool in order to compare the differences.

git ls-files modules | grep -v '^modules/sdk/' | grep -F bnd.bnd | xargs grep '^Liferay-Require-SchemaVersion' | sort

If you are working with releases and fix packs, you can use a tool that I built after we discovered the problem between DE-26 and DE-27 (which was caused by LPS-72269 mentioned above) to understand just how often this actually happened. This link shows the differences between DE-29 and DE-30, which involved services that are fairly critical to Liferay's function: Liferay-Require-SchemaVersion Changes Since DXP Release

If you've recently attempted to rollback, and you're worried about whether you're affected, you can check its symptoms. While there are many reasons for Spring beans to not be registered as OSGi components (one of which we encountered in Troubleshooting Liferay from Source), if you're affected by a module schema change, you are definitely in a situation where the Spring beans are not registered as OSGi components.

For example, by using dm wtf, because Felix's dependency manager is used in order to prevent the registering of the service builder services as OSGi components, and everything that's failing to resolve should be reported as a result.

You can also have Liferay automatically report problems by creating a configuration file and add unavailableComponentScanningInterval=60 to that file, which will turn on scanning of unavailable Spring components, as described in Detecting Unresolved OSGi Components. You will also want to turn on INFO level logging by following the instructions on Adjusting Module Logging.

  • Between and including DE-24 and DE-30 (which includes 7.0.4 GA5), you would update the file com.liferay.portal.spring.extender.internal.configuration.SpringExtenderConfiguration.cfg and enable INFO logging on com.liferay.portal.spring.extender.internal.context which lives in the com.liferay.portal.spring.extender module
  • After and including DE-31, you would update the file com.liferay.portal.osgi.debug.spring.extender.internal.configuration.UnavailableComponentScannerConfiguration.cfg and enable INFO logging on com.liferay.portal.osgi.debug.spring.extender.internal which lives in the com.liferay.portal.osgi.debug.spring.extender module
Fixing Module Schema Changes

You may have encountered Liferay-Require-SchemaVersion in the article Creating Data Upgrade Processes for Modules: it attempts to prevent outdated code from running against an upgraded schema.

Of course, the mechanism is not cluster-aware, so it doesn't prevent outdated nodes in a cluster from running older code against the newer schema, so this functionality really only helps with accidental bad deployments.

So now we run into a dilemma. Assuming you have no choice but to rollback (in other words, whatever issue you encountered in the updated Liferay requires the rollback), how can we get everything working again? Well, as noted at the beginning, there's very little you can do, but a little is better than nothing.

Restore the Older Schema

If you ask around, the recommended way is to restore a database backup that contains the older schema for your module. This will have the appropriate Release_ table entries in Liferay for it to know that this older schema exists for the module, and everything is known to work with the older module code.

However, you wind up losing all data from the time the backup was made up until today. Therefore, you will have to determine if this trade-off is actually acceptable.

Restore the Newer Bundle

One way is to deploy a bundle that is actually compatible with the upgraded schema, where it might be simplest to deploy just the updated module (if you're dealing with a release bundle where everything is in .lpkg files, the updated module needs to go into ${liferay.home}/osgi/marketplace/override).

However, this approach is risky for all the reasons we just experienced with TermsOfUseContentProvider in Keeping Customizations Up to Date with Liferay Source, and it can rapidly become unwieldy. If you're dealing with a release bundle, any of the modules you are forced to override can no longer be patched, which makes your installation unsupportable.

Even if you assume that you don't need supportability, if the service module we're redeploying implements a ProviderType interface and the package containing that interface has updated, things get really messy really fast.

To start, you will need to deploy an updated version of the module that provides that interface, or use one of the Import-Package approaches described in the previous blog entry. If the service module we're redeploying also exports a package containing a ProviderType interface, you may have to deploy an updated version of everything that implements that interface so that the correct Import-Package versions are listed.

Ultimately, with this approach, you may have to deploy an updated version of all of the transitive dependencies as well, if any of these updated modules either provides or implements ProviderType interfaces. It may get to the point where you're redeploying large parts of the portal as an override in order to counteract package updates for any packages holding or any components implementing ProviderType interfaces.

Erase Module Tables

It's entirely possible that you don't actually care about the data in the affected module. For example, in the case of Mobile Device Rules, it might not have been a component you used at all, so you'd be perfectly comfortable erasing all of its data (because there is no data).

We started this blog post from the side of customization. From the customization side, if you'd run across the problem and tried to find a solution, you would eventually run into a tool named the DB Support Gradle Plugin. This tool provides a single command, cleanServiceBuilder, which does just one thing: "Cleans the Liferay database from the Service Builder tables and rows of a module."

In other words, a fairly straightforward way to get things working is to simply start over from scratch for that module.

If you have access to the Liferay source, you can simply navigate to the module that's failing to start, update the Gradle configuration so that the DB Support Gradle Plugin can function (though you may need to update it if you're using a database other than MySQL, due to a regression bug introduced with the fix to LPS-73124, resolved in LPS-76854), and use cleanServiceBuilder to erase all of that module's data.

Stopping Module Schema Changes

As described in Running the Upgrade Process, you can prevent module upgrades from running by adding autoUpgrade=false to com.liferay.portal.upgrade.internal.configuration.ReleaseManagerConfiguration.cfg. Normally this is done during an actual upgrade so you can run the module upgrade separately from the core schema upgrade, but it also has the side-effect that it prevents module upgrades from running if new upgrades are added without warning.

However, this doesn't actually prevent the problem of transitive component dependencies, because we now simply have the problem in reverse.

Just as is the case when you create a custom service builder module that doesn't have an upgrade process to a schema version, Liferay is declaring that it only knows how to work with the older schema version, but the code says that it only knows how to work with the newer schema version. As a result, none of the service builder components are made available as OSGi components.

So, what happens is components will stop working. However, at least it's very easy to rollback to the earlier version, as no module schema changes have actually happened.

Minhchau Dang 2018-02-01T03:09:18Z
Categories: CMS, ECM

Meet Jehyson, Ambassador of the month | January 2018

PrestaShop - Wed, 01/31/2018 - 11:03
Jehyson is our Ambassador of the month from Cali in Colombia! He is a very active contributor who joined us as Ambassador in September 2017.
Categories: E-commerce

CiviCamp Calgary 2018 - Registration now Open!

CiviCRM - Tue, 01/30/2018 - 14:59

Tickets as low as CAD $49 (includes lunch) for CiviCamp and as low as CAD $15 for Workshops; Sprint is Free (if you're an official CiviCRM Partner contact me for a discount code)

Categories: CRM

Six Customer Experience Trends to Expect in 2018

Liferay - Tue, 01/30/2018 - 14:35

What defines great customer experience in the modern age is constantly changing due to the shifting demands of audiences and the use of new technology. But while CX may change over the years, its importance to prospective customers and the success of businesses is only growing.

According to a study by Spigit, 75% of companies surveyed in 2016 put improving customer experiences as their top objective. However, the path to great customer experience is a continuous one. The following six trends in customer experience in 2018 will help you and your business create effective CX strategies in order to stay ahead of audience demands and find success throughout the coming year.

1. Companies Face Their Biggest Internal Challenges in CX

According to Forrester research, the three biggest challenges for companies implementing their customer experience strategies are organization culture (54%), organizational structures (45%) and internal processes (41%). All three of these hurdles are most often associated with the CEO of a business. As such, 2018 may be a big year for companies, and CEOs in particular, making decisions that could enable their teams to make big gains regarding their CX efforts. CEOs and departments should focus on collaborating and communicating effectively in order to make substantial forward progress.

2. The Prevalence of Frictionless Experiences

Services like Amazon Go are leading the charge in creating frictionless customer experiences by allowing users to skip grocery stores and even removing the checkout process through instant charging upon leaving. As shown by Customer Think, audiences expect customer experiences to consistently move forward and a major player like Amazon often sets the bar for other businesses. In this instance, it comes in the form of frictionless shopping that makes purchases smoother and faster than ever.

3. Improving Location-Based Experiences

Beacon technology has been in use for many years now, but companies are now using it to make customer experiences faster and more seamless than ever. According to Dimension Data, businesses are working to make physical touchpoints as simple and efficient as online experiences. With hotels using beacons to replace room keys and companies providing employees with access to secure locations and sensitive information based on location through beacons, the gap between in-person interactions and online experiences is growing smaller so that customers can integrate all aspects of their lives and histories with companies with everyday activities.

4. Increasing and Improving A.I. in Business Operations

Artificial Intelligence will play a role in many aspects of CX, but ensuring that these helpers can properly perform their duties depends on recognizing customer speech. Customer Think detailed how speech recognition systems can help voice assistants quickly learn how individual users speak, including their unique patterns, dialects and accents, in order to avoid frustration and make their roles within businesses and home essential in the future. Gartner predicts that 85% of customer interactions will be managed without a human employee by the year 2020, meaning that automated systems and artificial intelligence will manage the vast majority of processes. With an ever-escalating usage of artificial intelligence in company operations through chatbots, data aggregation and analysis tools and many more programs, expect 2018 to find many more businesses using A.I. in an even greater variety of ways.

5. Leveraging Customer Identity and Access Management (CIAM)

Data will only continue to play an increasingly important role in the way companies interact with customers. In turn, companies are embracing customer identity and access management (CIAM) solutions, which use features including customer registration, multi-factor authentication, self-service account management, data access governance and more to scale and customize channels to individual users and their personal goals, As discussed by Janrain, CIAM creates personalized interactions by creating engagement strategies based on data insights and eliminating obstacles that may be complicating customer experiences. Companies will be in search of CIAM solutions that are both robust in the ways they can manage data and highly secure in the ways such data is safeguarded.

6. Time Becomes a Commodity

While overall enjoyable experiences will remain a priority, The Economic Times highlights that a customer’s time is a factor that will become increasingly important in CX. From making the checkout process as fast as possible to removing complications in finding a needed item online to getting answers quickly through chatbots, companies should strive toward lessening the amount of time needed from customers in receiving the products or services they want. This should help prevent audience frustration and keep potential customers from abandoning their journey before completion.

Digital Business Changes Coming in 2018

The way companies do business and how they are impacted by changes in digital marketing will once again shift in 2018. Read more about these changes in digital business.

Transform Your Customer Experience in 2018

Keeping up with modern expectations concerning customer experience requires software that is ready to meet a variety of demands. Learn more about the strategies possible with Liferay.

Read “Four Strategies to Transform Your Customer Experience”   Matthew Draper 2018-01-30T19:35:10Z
Categories: CMS, ECM

Light up your life with Liferay and Philips Hue

Liferay - Tue, 01/30/2018 - 12:59

On October 6, 2017 my colleague Sebastiaan and I held a presentation at Liferay DevCon about a cool integration the COIN team made. We were looking for a fun and exciting Internet of Things integration in Liferay. After a fruitful brainstorm, we decided to use Philips Hue. Another couple of brainstorms later, we formed the actual idea.

The setup was to create an imaginary travel agency, named ACA Light Travel, that wants to provide the ultimate personalized experience to its customers. Potential travelers can browse through all available destinations by visiting a kiosk tailor-made for this travel agency. The nice thing about this kiosk is that it's equipped with contextual lighting. While the customer browses the website, the bulbs and LEDs in the kiosk will recognize which kind of destinations he or she is mostly interested in, and adapt their lighting accordingly.

But what is Philips Hue?

Hue is a great product line of Philips that consists of several types of lights, light bulbs, LED strips, ... They call it "Personal Wireless Lighting" and it's a stepping stone towards smart lighting.

The line is based around a central unit called the bridge, which you need to plug into your own network using an ethernet cable. The bridge will then communicate wirelessly with the light bulbs, LEDs and other components in your network. You can turn the lights on or off, dim them, change the colors, perform some effects, etc. By grouping bulbs together, you don't even need to direct them individually anymore. All this can be done programmatically based on timers and events for instance. There really are plenty of options.

Liferay meets Hue

Liferay DXP can communicate with the Philips Hue system through a REST API that the people from Philips Hue provide. If you want to create something yourself, you can just go to the Philips Hue Developer Program website, download this API in two jars and start your own development.

ACA Light Travel

So, for our travel agency we used the Audience Targeting module of Liferay DXP and defined 5 different user segments. One segment for every type of holiday destination: sunny holidays, adventurous trips, city trips, cruises and winter holidays.

All destinations on the site, which are plain web content articles, are categorized as one or more of these segments. Each time a visitor takes a look at the details of a certain destination, the system increments a counter for the corresponding segment. This is a by-default available rule in Audience Targeting.

We also wrote a custom Audience Targeting rule. This rule determines that the user belongs to the segment that corresponds with the highest counter. On a first visit, the user randomly sees all of the articles. When this user clicks on an article to look at the details of a city trip destination, the Audience Targeting rule increments the counter corresponding to that segment. Through the API, Liferay DXP communicates to the Philips Hue bridge that the lights need to turn red, because the user now belongs to that user segment.

To actually control the lights, we have written a page listener in Liferay. With each page load, it will identify the segment that the user is in and change the lights to the corresponding color by calling the Philips Hue API. Upon a next visit to the homepage, the user will first see the destinations that match the "city trip" user segment, which is the segment that the user belongs to. Of course, it's possible that a customer liked city trip destinations before, but is more interested in sunny vacations now. In this case, he or she will move from the "city trip" segment to the "sunny" segment after enough clicks.

Under the hood We implemented this project by making use of version 1.20 of the Hue API. The code is subject to change according to updates in the API.

Now that you know what we created, lets take a look at the how. As mentioned before, we created two custom modules. One is a custom Audience Targeting rule that determines that the user belongs to the segment that corresponds with the highest counter. The other is a page listener that identifies the segment the user is in on each page load and changes the lights into the corresponding color. Next to these modules, we also implemented the usual plugins and components. There are several portlets to show the suggested content items and two service modules to minimize the duplication of code. 

Hue Service

This OSGi bundle consists of just one service that contains the logic to control the Hue lights. This is the only implementation in the project that actually holds the specific Hue API calls. Upon activating the bundle, a connection is made to the Hue Bridge by using the fixed IP and UserName we had set up. The service provides the possibility to toggle the lights on/off, change the brightness, set the color and start or stop blinking the lights. When you deactivate the bundle, you terminate the connection to the Hue Bridge.

User Segment Service

This bundle is the connection of our portlets to the Audience Targeting functionality of Liferay DXP. It contains all business logic required for our portlets to provide the desired filtering and segmented content.

Hue Page Listener

This is the plugin that determines the segment that the user belongs to after each page load and communicates to the bridge to change the color of the lights. It will only do this when the user is part of just one user segment. The plugin retrieves the required color from the description of the segment that the user currently belongs to.

Score Points Maximum Rule

The custom Audience Targeting Rule determines to which segment the user currently belongs by calculating the highest counter. The counter is set by the default available Score Point rule in Liferay DXP.

Promotion Listener

When a JournalArticle is categorized as a promotion, the lights in the kiosk will start blinking. This visual effect informs the user that it's a special kind of destination.

Suggestions Portlet

This is a portlet bundle that contains three different portlets, one for each type of filtering.

  • YourSelectionSuggestionsPortlet: a portlet that shows all JournalArticles categorized by the segment that the user currently belongs to.
  • OtherSuggestionsPortlet: shows all JournalArticles that do not belong to the segment that the user currently belongs to.
  • PromotionsSuggestionsPortlet: this portlet first shows the promotions for segments that the user belongs to, supplemented with all other promotions available.

Audience targeting is one of the most powerful features in Liferay DXP. If implemented the right way, it can really learn what the user tries to accomplish and steer him or her in the right direction. It can even persuade the user to perform a transaction. Liferay, as an open platform, can really integrate with anything. Connecting the Audience Targeting module of Liferay to the Philips Hue system wasn't too hard thanks to the existing API. Just imagine which other IoT integrations are possible. The sky is the limit!


You can find the code for the ACA Light Travel website on our public Bitbucket.

The presentation was recorded at Liferay DevCon and is published on Youtube.

The slides that go with the presentation are also available through Liferay.

Koen Olaerts 2018-01-30T17:59:05Z
Categories: CMS, ECM

Joomla 3.8.4 Release

Joomla! - Tue, 01/30/2018 - 09:45

Joomla 3.8.4 is now available. This is a security release for the 3.x series of Joomla addressing four security vulnerabilities and including over 100 bug fixes and improvements.

Categories: CMS

Clone of Meet Jose & Ismael, Ambassadors of the month | December 2017

PrestaShop - Tue, 01/30/2018 - 09:16
Jose and Ismael are our very enthusiastic Ambassadors in Malaga and always organize their meetups together!
Categories: E-commerce

Three reasons to take a Liferay training course in 2018

Liferay - Mon, 01/29/2018 - 12:40
Training. It might sound like going back to school, but I would ask if there’s any better way to start the year than acquiring new skills that will help you and your team hit their goals.  A study by HR Magazine found that those who receive training are 58% more likely to meet the future demands of a business, and for most of our readers this means delivering digital project success.   Liferay has evolved more in the past two years than at any point in its 18-year history. With Liferay DXP there are new ways to architect, deploy and develop applications that your team will need to understand to reap the benefits and support your future plans – be it rolling out your mobile UX or transforming a business process.   So what exactly are you going to get out of coming to one of our training courses being held this year in London?   1. Develop a rock-solid platform from day one Learning best practices from the get-go is vital in every project, be it an intranet, partner portal or CMS – especially when we’re talking about building the digital backbone of your company. The last thing you want on a project is to have to back-track because you find something out that could have identified beforehand. Furthermore, those companies that have developed their platform strategy have become better equipped to react to changes in their business and future requirements.   "Training was awesome. It really helped me to understand some fundamentals I'd had no idea about when I was working. Now I understand the platform better." Manovinayak Ayyappan, NCS Pte Ltd.   Features such as staging, workflows and web content management included in our Liferay Fundamentals course are sure to get you or your team ready to implement the most stable possible platform you can with Liferay.    2. Exploit the full UX capabilities of Liferay DXP

User experience plays a crucial role in establishing the trust of visitors, and their trust of the information being offered to them on your Liferay-powered projects.

Liferay has a vast array of functionality and quite often some of the most useful features can go unnoticed. If you want your instance of Liferay to really stand out and provide an excellent User Experience (UX), our training courses will provide this. Whether you’re designing for an employee using the CMS or a customer visiting your customer portal for the first time, we will show you the best ways to implement an effective UX, how to iterate and how to empower business users to build and publish their own experiences with reusable templates that serve their needs and skills.   Front End Developer training can help your UX and front-end development teams build engaging experiences.   3. Save time and money, and mitigate risk Security and privacy are at the top of many agendas at the moment with increasingly public breaches and GDPR imminent. We can't solve your GDPR challenges for you, but our training courses can help operations, IT and DevOps teams understand how to maintain a robust and secure platform. If you would like to know more about our commitment to a secure platform at Liferay this paper may be of some interest to you. With a comprehensive System Administrator course available you can prevent unauthorised system access, reduce downtime, and minimize risk.     UK Liferay Training Programme 2018 These are only a few reasons to take part in our courses here in London. It’s a great chance to see a beautiful part of London, with a picturesque riverfront that overlooks Eel Pie Island, a famous music venue where bands like the Rolling Stones and The Who cut their teeth in the 60’s, and plenty of good pubs and varied restaurants.   We have held many private training sessions here in London, but this is our first full public training programme and it's held in our office training facility, so come in and get to know the Liferay UK team!   Liferay UK training

Choose from training courses throughout 2018, starting from February with Application Developer.

Book now   Sylvia Assumpção 2018-01-29T17:40:01Z
Categories: CMS, ECM

Someone Else Pays

CiviCRM - Mon, 01/29/2018 - 08:01

We are thinking about creating a native CiviCRM extension Someone Else Pays.

Categories: CRM

Tipos de Portal: 3 Aspectos para Levar em Consideração.

Liferay - Fri, 01/26/2018 - 12:25

Com todo o foco hoje na transformação digital e mobile first, os portais podem tornar-se comuns . No entanto, muitos tipos desta tecnologia desempenham um papel incrivelmente importante na mudança para a cultura digital. Se você está envolvido em uma iniciativa de transformação digital, vale a pena conferir como portais podem ajudar neste processo.

O que Define um Portal?

Em termos gerais, um portal é uma plataforma baseada na web que coleta informações de fontes distintas e as reúnem em uma única interface de usuário.

Pense na última vez que você fez login em sua conta bancária online. Uma combinação de nome de usuário e senha direcionou você a uma página onde você tem acesso a uma série de serviços, como pagar contas, atualizar informações pessoais e acessar opções de autoatendimento. Este é um exemplo típico de um portal moderno.

Tradicionalmente, o mercado adota 2 principais segmentações para portais, podendo esses serem considerados verticais (com uso específico para um determinado público) ou horizontais (com uso comum a diversas indústrias). Você pode tentar rapidamente aprofundar-se nessas 2 categorias mas, logo irá compreender a complexidade de diferenciar casos de uso similares (knowledge portal versus portal de funcionários versus intranet). Estas categorias são relevantes, mas se você está tentando aprender como os portais podem ajudar sua organização, o ideal seria começar o projeto examinando três aspectos: Conteúdo, Acesso e Formato.

Conteúdo: Público & Demanda

Portais personalizam o conteúdo considerando sua audiência e seu uso. Em outras palavras, eles precisam saber quem está usando e o que precisam fazer.

Geralmente, quanto mais específico o seu público, mais específico serão os serviços que deverão ser fornecidos. Por exemplo, pense na diferença entre um portal de pacientes e um de estudantes. Ambos são verticais, visando um público bastante singular. Os 2 exemplos a seguir demonstram o impacto que cada um tem sobre o tipo de conteúdo oferecido.

O portal MedImpact conta com ferramentas relacionadas aos cuidados com a saúde, como ferramenta de comparação de preços de medicamentos, localizador de farmácias e dicas para a saúde.


O portal estudantil da Capella University inclui inscrição em cursos, atualizações de classificação de turma e uma maneira de entrar em contato com colegas de classe, ou seja,  todos os recursos que você espera apenas no contexto de um portal de estudantes.

Agora, se o portal MedImpact fosse apenas para pacientes com doença cardíaca, o conteúdo e os serviços oferecidos na página inicial poderiam ser ainda mais específicos.

Por outro lado, se a Capella University criar um portal para todos os estudantes dos EUA que estão se preparando para entrar na universidade pela primeira vez, o painel poderá mudar para oferecer informações sobre programas de bolsas nacionais, links para escolas inscrições em comum ou lista das melhores universidades com programas mais acessíveis.

O conteúdo que você oferece no seu portal depende do seu público e serviços que eles esperam encontrar. No entanto, no back-end, não há muita diferença entre projetar para um público amplo ou um público limitado. Para isso, precisamos entender as próximas seções: Acesso e Formato.

Perguntas a serem feitas sobre o conteúdo:

  • Qual público será atendido?
  • O que eles precisam fazer?
  • O que mais beneficiaria sua organização: projetar para uma ampla audiência ou criar uma experiência altamente personalizada para um tipo de usuário?
Acesso: Externo vs. Interno

Embora os portais geralmente exigem um login, eles ainda podem ser internos ou externos. Um portal de funcionários pode mostrar uma página de acesso para usuários anônimos, enquanto um de clientes pode exibir quase todo o site e pedir aos usuários que realizem login apenas para determinados recursos, como realizar uma compra.

O acesso é uma consideração importante, pelo impacto gerado na quantidade de trabalho que  será necessário para projetar e manter seu portal. Considere os diferentes aspectos no desenvolvimento de um site de varejo público que incorpora um portal de clientes, em comparação a um de autoatendimento que requer login.

  • Um varejista de roupas, que exige uma conta para realizar uma compra, deve focar em:
    • integrar recursos específicos do usuário sem alterar drasticamente a interface do usuário no site
    • fazer a transição do usuário anônimo para o logado de maneira harmoniosa
    • ocultar informações importantes/sensíveis de usuários anônimos
    • gerenciar a fidelização de clientes
    • integração SSO (iniciar sessão  através do Facebook ou outras plataformas)
    • integração com ferramentas de engajamento para rastrear o comportamento do usuário
  • Um portal interno de autoatendimento de clientes tem mais controle sobre quem o acessou, pois exige que todos os usuários façam o login. Assim, os esforços deverão se concentrar em:
    • navegação fácil entre conteúdos
    • pesquisa rápida e eficaz
    • atualizações em pedidos pendentes, como o acompanhamento de envio ou devolução
    • integração às operações de call center e disponibilização de recursos click-to-call ou  click-to-chat
    • chatbots para lidar com consultas simples

Pode-se argumentar que estes são o mesmo tipo de portal (portais verticais projetados para clientes de varejo), mas eles têm propósitos muito diferentes e poderiam existir facilmente lado a lado dentro de uma única empresa.

Perguntas a serem feitas sobre o acesso:

  • Quem precisa acessar o site e qual o nível de segurança necessário?
  • Quais funcionalidades e permissões precisa-se criar para manter este site?
  • Que tipo de experiência oferecer aos usuários anônimos?
  • O site tem valor suficiente para convencer as pessoas a criarem uma conta?
Formato: Gateway vs. Dashboard

A última grande área a considerar é a forma que o seu portal vai ter. O que um usuário típico vê ao logar pela primeira vez? 

Os dois formatos mais comuns são gateway ou dashboard. Ambos fornecem informações personalizadas, mas o design de gateway geralmente possui um portlet padrão, com conteúdo que atualiza dinamicamente dentro dos aplicativos. Esses são mais fáceis de desenvolver e não exigem muita manutenção.


A página inicial do é um exemplo sólido de um portal gateway. Ele reúne uma série de informações de diferentes sistemas e programas, mas o layout é bastante simples. Podemos ver uma seção para News (o banner da imagem acima), Updates e Open Grant Opportunities. O conteúdo de cada seção pode ser alterado manualmente ou através de uma ferramenta de segmentação de audiência, mas, no geral,  cada seção é uma porta de entrada para informações mais detalhadas.

Dashboards, por outro lado, podem ser considerados altamente customizáveis. Além do usuário visualizar conteúdos diferenciados, eles também contam com aplicações ou serviços personalizados que mudam dependendo das suas responsabilidades na empresa e do trabalho a ser feito.


A Unisys conta com o VantagePoint, um dashboard corporativo que utiliza um layout de quadros para oferecer aos usuários corporativos informações sobre os sistemas que eles geralmente precisam acessar. Os seis portlets dentro deste painel estão fazendo mais do que exibir um fluxo de conteúdo ou uma lista de links úteis. Cada um está agregando dados de sistemas e fazendo recomendações para as próximas etapas que precisam ser tomadas para resolver problemas potenciais. A forma deste portal é mais baseada no trabalho do que no conteúdo e visa ajudar o usuário a sair do problema "Este sistema está quebrado" para "Aqui está o motivo" em segundos. Os principais portlets utilizados podem mudar diariamente, de modo que os painéis possam exigir uma integração e uma atenção mais recorrentes devido às  necessidades de seus usuários.

Perguntas a serem feitas sobre o formato:

  • Os usuários estão focados em encontrar informações ou realizar alguma atividade?
  • O time de desenvolvimento consegue lidar com atualizações frequentes?
  • Quantos sistemas os usuários precisam ter acesso desde a primeira página?
Portais Tornam a Transformação Digital mais Fácil

A transformação digital requer mudanças significativas em modelos de negócio e na cultura corporativa, exigindo mudanças na forma como pensamos sobre os diferentes tipos de software. Os portais continuaram a evoluir nos últimos dez anos, mas sempre foram definidos por uma prioridade principal: oferecer uma experiência personalizada que apenas apresente o que é relevante para o usuário final. Com a crescente ênfase na experiência do cliente, os portais continuam a ser parte fundamental de qualquer estratégia de transformação digital, não importa qual seja o aspecto do projeto final.

  Saiba Mais Sobre Quatro Tipos de Portais que Resolvem Problemas Empresariais

Descubra como Portais de Autoatendimento, Portais de Serviço Interno, Portais de Colaboração e Portais de Parceiro resolvem problemas comum aos negócios digitais, com quatro estudos de caso de grandes empresas.

Baixe o E-book   Isabella Rocha 2018-01-26T17:25:30Z
Categories: CMS, ECM

Analytics role in Experience Platforms

Liferay - Fri, 01/26/2018 - 00:27

Leaders in the 2018 Gartner's Magic Quadrant for Digital Experience Platforms have mentions on their analytical capabilities. IBM and Sitecore have specific strengths in artificial intelligence and analitics. But for Liferay analytics it is a caution, it is also the only open source leader for this quadrant.


- 2018 Gartner's Magic Quadrant for Digital Experience Platforms

  - IBM     - STRENGTHS       - AI: IBM was an early and aggressive adopter of AI to improve user engagement and the user experience.   - Sitecore     - STRENGTHS       - Applied analytics: In addition to appreciating Sitecore's fundamental strength in content management,          customers have high regard for the Sitecore Experience Platform's ability to exploit web analytics.   - Liferay     - CAUTIONS       - Analytics: Liferay customers may need to invest separately in best-of-breed analytics.          Surveyed Liferay reference customers scored Liferay's analytics capability relatively low.   Fabian Larroca 2018-01-26T05:27:36Z
Categories: CMS, ECM
Syndicate content