Entity Share - A cost-effective solution to manage multisite content

Many organizations are running into the challenge of managing content on their multiple websites for gaining centralized control and ensuring its secure flow.

Taking a piece-by-piece approach and allocating teams to work on each site separately drives the higher cost of maintenance, development, results in complex infrastructures, and inefficiencies in the process.

While content cannot be shared and shipped using CMI tools unlike configurations, Drupal modules can be utilized for sharing content among different sites or different instances of the same site.

This blog sheds light on the features that enterprises should not overlook while leveraging Drupal modules and also examines the benefits & limitations of the Entity share module and the cases in which it makes the biggest difference.

A Cost-effective Solution to Manage Content Across Sites 

Entity Share module helps enterprises achieve a workflow where subsites of a multisite architecture can share a piece of content across without disrupting the workflow at their respective ends. Besides, it also keeps UI experience and cost-effectiveness in check.

The module works for a setup where each of the sites have different databases. It provides easy means to share entities like nodes, taxonomy terms, media, etc on the basis of endpoints obtained from the JSON:API module via basic authentication.

Note- The websites sharing content among each other are designated by the terms, Server, and Client. The server (site) being the one from where content is shared and the client (site) is the one that takes in shared content.

Installation and Configuration Process of Entity Share Module

Follow these steps to install and configure the module-

1. The entity_share module of desired version might be installed either via composer using
   “ composer require 'drupal/entity_share:2.x-dev '” or downloading from https://www.drupal.org/project/entity_share/releases and placing it in the contrib modules directory of the project.
2. Thereafter the module needs to be enabled using the drush command “drush en entity_share”.
3. Next step is to create channels on the server site containing exact data to be exposed from its end. Channel configuration can be done after enabling the entity_share_server v.i.a command “ drush en entity_share_server” which is a submodule present within entity_share. Additional filtering and sorting rules can be set on these channels as required after navigation through
   
   Configuration-> Web Services-> Entity Share-> Channels.
   The specification of an authorized user is a must to access this channel. 
   
4. The client site, on the other hand, contains remote data that comprises the remote/server URL that it needs data from and authorization details like user and password to connect to the server which is provided after enabling the submodule entity_share_client using command “drush en entity_share_client”. Note this module needs to be enabled on the site that will pull shared content.
    
   Navigate to Configuration-> Web Services-> Entity Share-> Remote Websites and configure the remote settings. Ensure that the username and password in the Basic Auth section is the same as the credentials of the user that has access to entity share channels on the server end configured earlier.
   
5. After successful authentication, all the shared content (from server end) will be available to the client site at [client_base_url]/admin/content/entity_share/pull to be pulled and displayed at its end. 
   
   This provides an added advantage to the client-side where it can accept the shared content only after complete verification. The shared content simply does not get created as soon as the server shares it.
   
   Moreover, the interface that the module provides for the entities to be pulled is user-friendly and easily understandable. It clearly depicts newly created and already pulled content along with its synchronization status. In case the content after being shared and pulled gets edited either at the server or client-side, the status gets immediately updated.

Use Case of Entity Share

We implemented Entity Share module for a client project 

Recently Srijan came across a requirement where one of its established clients had local websites in regional languages distributed across many countries in the world.

Our main objective was to provide them with a solution where the administrator or central authority would be able to share some content like news updates, press releases, etc from the main/corporate website without affecting the rest of the content at each end. 

Additionally, a necessity of central control over each of the shared content/nodes was required where any change on the main site would be available on the client end to be pulled again or re-synchronized. 

Similarly, if a client site made any change on the content at its end, changes would appear on the corporate/main to be synced. The entity share module was best suited for such a scenario. 

We configured channels and remote sites as described above and the functionality was achieved. One of the custom functionalities added was to set the default status of the node being pulled into the Draft state so that the content editor can review the same before publishing. 

Despite the fact that Entity Share module is not yet identified as secure since a lot of inaccessible data is exposed using JSON:API endpoints, we implemented it for the client project. 

Because an extra security layer can be implemented to the web server configuration level by blocking requests from unwanted sources and allowing only trusted sources to fetch data. No third party expensive integrations were required. It matched with the clients’ requirements and also simplified our process of adding custom functionalities to it.

Benefits of Entity Share Module

It offers the following benefits-

1. Authorized access- The module provides content exposure to a site ensuring authentication. Without proper authentication, no site can have access to the channel data exposed from the server website.
   
   
2. Enhanced security for verifying content- The client site has a choice to pull data from the available list of content shared with it. This allows an extra layer of security that allows the administrator/editor of the client site to verify data at its end before synchronizing it. A link to the content/entity being shared is available beside each item in the list of entities present in the respective channel.
3. Different versions to detect changes, if made- The module lets you view the difference between the already pulled entity and the entity on the server end, in case anyone of them gets changed.
   
   Given this, you have to install a module called diff to let you view revisions of an entity. Although the module has issues depicting differences in the reference fields; developers have an opportunity here to contribute to the community by finding an appropriate solution to the same.
   
   
4. Multilingual support- Translated entities may be shared among sites provided the language is configured on both the ends. Even in the case where the default language of the server and the client site is different, this module is appropriate to use. 
   The client site may add appropriate translations based on the pulled content at its respective end.
   
   
5. Auto-creation of referenced entities- All the referenced entities are auto-created based on UUID when a content/entity gets pulled if not present on the client end. Hence referenced paragraphs, images, and media that contain references to such fields need not be present on the client end before pulling content. They will be automatically created and linked.
6. Clean and simple user interface- Lastly, the UI interface that entity_share provides for pulling/synchronizing content is easy to use. The entity pull access might be given to a specific user/editor of the website without developer intervention, once configured properly.

Limitations of Entity Share Module

Like other modules mentioned above, entity_share has limitations too:

1. The entity when pulled on the client site, is displayed in the same state, i.e., published/unpublished as that on the main/server website. It implies that the module doesn’t obey customized editorial workflow and moderation process. Editors can’t take appropriate action of passing content through various workflow states such as draft, ready for review, approved and then published.
   
   For example - A published content when pulled is directly assigned a state from the pulled reference i.e published rather than in draft mode.
   
   However, there is a possibility to change this functionality by subscribing to the event
   \Drupal\entity_share_client\Event\EntityListDataAlterEvent
   provided by entity_share_client module to alter the status of the content being pulled.
   
   Likewise, other events are also available in the module that can be used to   tweak any functionality as and when required.
2. The revision history of the node gets affected after pulling an already pulled entity that has been edited on the client end as well. This is because the changed timestamp that the JSON:API endpoint provides gets added to the client-side as it is after synchronization.
   
   This also needs to be fixed in the module to allow pull operations without affecting revisions on both ends. You can find another related issues  too.
   
   

Instead of using exorbitant and ineffective Drupal modules for content management across the various sites, give a try to Entity share module, it is a cost-effective solution that can be optimized as per enterprises' requirements.

Looking for a similar solution? Drop us a line and our team will get back to you.