Starting point

What is Entity Share?

Entity Share is a collection of modules allowing you to share content like articles or media between different Drupal instances.

Its development has started at the beginning of 2017 to answer the problem of deploying content in webfactory type projects we had for our clients.

At that moment, the state of art was not satisfying enough to correctly answer our needs.

How does Entity Share work?

In short, when you have at least two websites:

You configure one to be a content server with the Entity Share Server sub-module. On this website, you configure “channels” which allows you to expose which content types(, media types, etc.) in which languages are available for sharing.

You configure the other website to be a client with the Entity Share Client sub-module. On this website, you enter the URL and authentication information to the other website. Then you have access to a “Pull form” allowing you to select which content you want to import.

Other presentations to go deeper

For more details about the current version (8.x-2.0-alpha11) of Entity Share, you can take a look at the presentations we have done before:

• French Drupalcamp Lannion October 2017 (in French)
• DrupalCon Amsterdam October 2019
• Paris Open Source Summit December 2019

You can also take a look at this very well detailed article: Entity Share - A cost-effective solution to manage multisite content.

To go beyond this article, which is focused on the current version, this article will present the new version in development.

Limitations

Currently, on the client site, when you want to pull content, you have to:

• select the website you want to pull content from (auto selected if only one website is available),
• select one of the available channels (auto selected if only one channel is available),
• select the contents you want to import.

Then all the import processing is done, and there is no way to configure that using the back-office (there are partial ways for developers using events). The import processing consists of creating or updating an entity, then recursively import all the referenced entities and import the physical files.

For example, you can’t limit the recursion depth when referenced entities are imported. So depending on your website topology, if you have a lot of crossed-linked contents, importing one content can result in a ton of contents imported by recursion.

With the feedbacks accumulated on our client projects or by other Drupal community actors, the Entity Share’s issue queue has been filled with a lot of feature requests to handle more and more advanced usages.

Which is great! This means that the Entity Share module is more and more used and answers a recurring need!

But the current architecture is not ready to answer those features requests in a proper manner and not ready to allow developers to customize Entity Share properly for their projects. So it is time for a rework of the module’s architecture.

The new architecture

To ease maintenance, customization and to allow fine grained configuration, we introduced a dedicated plugin type and clearly defined steps in the import process, so that each plugin could react at any of these steps.

This is inspired by both code and ideas from the Search API module in which you can configure processors that can act on the way your data is indexed, queried, displayed, etc. with your search indexes.

When released, we will have a dedicated configuration entity, the “Import config” entity type, which stores:

• which plugins is enabled or not,
• the configuration of each plugin: for example, the depth of recursion of entity reference import,
• the weight of each enabled plugin in each import steps: so you can have a total control on the order of execution of the import processing.

With this new architecture, the steps to import entities are:

• select one of the available import configurations (auto selected if only one import config is available),
• select the website you want to pull content from (auto selected if only one website is available),
• select one of the available channels (auto selected if only one channel is available),
• select the contents you want to import.

Yes, this adds an extra step, but this extra step allows your import to behave differently depending on your needs.

For example, if there is a plugin to automatically import entities referenced in link fields (see this issue), there is no need to have it enabled if you don’t want or need it. Whereas with the previous architecture, such a feature would have been enabled by default on all imports. And so with each feature request implemented, this would have caused a lot of unnecessary processing depending on your needs.

Benefits for developers (DX)

With this new plugin system, developers:

• are able to alter the import processing from code inside dedicated classes, no more need to patch Entity Share,
• have more entry points to alter the import processing at the right time for their need,
• can fully override or disable common behavior provided by the Entity Share module and sub-modules.

The main import process code had been revamped into new services, with clear interfaces to remove duplicated code and to ease the development of custom code.

For example, the new “ImportService” service allows to import specific entities from a channel or a whole channel using the “importEntities” or the “importChannel” methods. These methods had been thought to be used by providing only the strict minimum of arguments to ease the usage.

Also the command line integration will be revamped to benefit from the “import config” and therefore to have the same features and behavior if the import is launched from the command line or from the Drupal BO.

Benefits for administrators (UX)

With this new plugin system, administrators:

• can have different import behaviors and select the one they want for their import,
• are able to control with a fine grained granularity how they want their import to behave.

This rework is also the opportunity to improve all parts of the module and for example:

• now administrators are able to import a whole channel using the “Pull form”, whereas it was only possible using the command line before,
• some inconsistent behavior when indicating if an imported content is not synchronized will be fixed.

Conclusion and roadmap

After 3 years of existence, with more and more feedback and feature requests accumulated, it was time to rethink the module’s architecture to be prepared for future evolutions.

The new architecture empowers both developers, administrators and eases the module’s maintenance.

For a detailed and up-to-date roadmap, you can take a look at the following issue: https://www.drupal.org/project/entity_share/issues/3082611

Help is always welcomed, you can provide feedback and patches in the issue queue. And if you want to sponsor the module maintenance or some specific features, or if you need dedicated support time, get in touch with us!