Skip to content

About

Xtended Content is a Drupal module that provides access to external content from Drupal 8.

Technical vision

The golden features in Drupal is the fact that it is a Content Centric CMS. As time goes by, while dealing with websites that are bigger, more complex and more advanced, it appears more and more that reality is in fact: a Drupal database Content Centric CMS.

As the Web is going more and more complex and interconnected, it starts to appear as a limitation. Ten years ago, we started to build bigger and more complex websites: Drupal 7 was just great for that. From now on, RSS ans Schema are not enough: API web is the key word. And migrating data is always a project in the project, a bigger risk for planning and money.

From our point of view, we should stop migrating data, and start plugging it. That's it.

Principles

Stop format-locking

From the origins of Drupal, contents are stored in the database to benefit from very advanced toolbox like Views, CTools and Paragraphs.

Xtended Content (or XTC) provides an abstract layer to help Drupal 8 access data that are not stored in the D8 database, and display it directly.

Don't change the code

As a start, XTC is helping Drupal developers to easily connect their Drupal projects to a large diversity of sources in a solid way:

  • Define a Profile (a Yaml D8 plugin), create a Route, and load Data from a plain controller to display it through a Drupal hook_theme() defined destination (or a JsonResponse).
  • Change the definition of your Profile (4 or 6 lines in your Yaml file), don't touch the code.
  • That's it! You've just switched from a Json file to your permanent Guzzle webservice.

CI/CD oriented

Server plugin-manager allows to define as many environments as needed for a given Server. Just set the name fo the current environment (at server level) in the settings.local.php file.

Make your own handlers

Here are some examples of Data handlers XTC already manages:

  • Files and Directories of files: csv, Html, Json, Markdown, Readme, MkDocs, Text, Yaml.
  • Webservices through Guzzle
  • Metadata parsed from webpages with Micrometa
  • Elasticsearch
  • Drupal local API

CRUD is not an option

We are not only expecting to read, but also to provide CRUD features. To do this, Profiles plugins are defined by types and verbs: file_delete can be defined to code a plugin based on the File handler, an helping to delete... a file.

Caching workflow

Cache plugin-manager was created to help define workflow to easily obtain better performance. A simple case:

  • Parse a Recipe data from 750g web page and normalize it to display it in a given template.
  • Store it in a local page, not to have to connect to 750g website each time you want to make your prefered Apple crumble.
  • Test if the local file exists, and fetch only on fail.
  • Create a Memcache handler, change cache profile to a memcache definition, and it will be faster. Change it to an Elasticsearch profile, and it will be more fun.

We shouldn't have to change any existing business code for that.

What's next?

These are examples of the roadmap:

  • Propose plugin managers similar to Cache for purposes like Mirror and Balance.
  • Complete local Drupal API as much as possible: more popular entities, and some basic views handlers would be a good start.
  • Dedicated modules to Drupal Rest API and WordPress Rest API: this would help us to build complex workflow architectures with simple nodes, with a strong dedicated business, and really easy to maintain. An Akineo Rest API module could be great too! Nuxeo, anyone?
  • A new version of XTC Search based on the new API.
  • A Dummy entity that will eventually bring us back to the real Drupal world: widgets, displays, formatters, and, as a consequence: Views!

If you believe this is challenging and fun: come aboard!

Main modules

Architecture

Helpers

Many Helper functions can be found in the XtendedContent/API directory in xtc module.

Plugins

10 plugins-managers are defined throughout the XTC modules.

  • Yaml plugins are used when the Default class is mostly used, and plugins are data driven.
  • Annotation plugins are used when plugins are code driven.

Modules that need works

These modules need to be updated. So they are not covered by the current documentation.

XTC Elastica

Provides access to ElasticSearch using the Elastica library. It uses a legacy API that needs to be updated.

To access ElasticSearch data, please consider using XTC PHP ElasticSearch that is based on the PHP Elasticsearch library, and is up to date.

Provides a full search UI experience with dynamic facets, but is based on XTC Elastica. So it needs to be updated too.

No alternative based on XTC PHP ElasticSearch is presently provided.

Deprecated code

API\Config

Helper static functions defined in \Drupal\xtc\XtendedContent\API\Config are considered deprecated.

Serve\Client & Serve\XtcRequest

  • Classes defined in \Drupal\xtc\XtendedContent\Serve\Client are considered deprecated.
  • Classes defined in \Drupal\xtc\XtendedContent\Serve\XtcRequest are considered deprecated.

This is mostly first version code. Cleanup is not over. It should only concern XTC Elastica & XTC Search modules. These need to be updated and are not covered by present documentation.

To be done

@todo tags are used in the project to identify what is to be done.

We recommend using tools like PhpStorm TODO panel to help track these tasks directly in the deep code.