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 aJsonResponse
). - 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¶
- Xtended Content: API module
- Xtended Content Drupal
- Xtended Content File
- Xtended Content Guzzle / ReST
- Xtended Content Schema.org
- Xtended Content PHP ElasticSearch
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.
XTC Search¶
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.