Before reading :
Sorry for the long post, but after hours spent reading issues and documentation, I realized several things :
- Some issues/points/explanations need reproductible examples to be properly understood / treated
- Sometimes answers are creating new unanswered questions
- I do appreciate that this is complex and that I do not master all the technical aspects of Features’ code.
So I’m writing this issue to expose many study cases and observations. I will open several other issues for treating some specific points I have seen afterwards.
Motivation :
As I’m working in a web agency we always try to find balance between fast developpement rules and easy maintenance process. Actually something seems to prevent Features ( D8 version) to create configuration packaging / identification as it used to. As said before, I’ve read quite a few open/closed/alive issues and I think it might be necessary to expose study cases and discuss how Features should export (actually how he fails to export) generated configuration for each case.
The goal of these study cases is to make reproducible test cases from structure extracted from real project.
Principal references :
Features 8.x Documentation ( workflow, package assignment plugins )
Issues :
Prepare a clean install
Solution 1
- Install a drupal (case made with a 8.4.4) with standard profile
- Delete article/page content type and the tags vocabulary
- Activate Features/Features_ui/Paragraph modules
Solution 2
- Install a drupal (case made with a 8.4.4) with test_ft profile ( join on this issue)
Study cases List :
- Basic : with 2 content types and 1 paragraph
- Basic extended : much more paragraphs
- Taxo extended case : Basic case + taxonomy
- Taxo basic case
- NativeMedi extended case : Basic case + media
- MyMediaa extended case : Basic case + media
- Custom Block Type
Basic case :
For this case, I created a study case structure explained in this image.
This case will be the base of most of the following cases.
List of structures :
2 Content Types :
- An Editorial content type ( CT1) with:
- a text_field ( text_field storage)
- a multiple reference to paragraph P1 ( p_list storage)
- A basic content type (CT2) with :
- a text_field ( text_field storage)
- a wysiwyg ( wysiwyg2 storage)
1 Paragraph ( P1) with :
- a text_field ( text_field2 storage)
- a wysiwyg ( wysiwyg storage)
Preparation
- Make a clean installation
- Create Paragraph P1
- Add text_field2 and wysiwyg fields
- Create CT1 content Type
- Delete body field
- Add text_field and p_list fields
- Create CT2 content Type
- Delete body field
- Reuse text_field
- Add wysiwyg2 field
- Edit Feature Default Bundle configuration
- Add Paragraph as base type
Export
Export packages CT1, CT2, P1 via write option as it is described in the features “workflow” documentation.
All package are exported with all of their fields storage except the field.storage.node.field_text_field configuration exported with Core package ( as explained in the documentation ).
All interdependencies are correct.
Create a backup of these sources as it will be used for “starter kit” for other cases. An archive with all of these configurations are also joined with this issue.
Note : Good news !
Basic extended case :
In this case, we’re working with the Basic case final state.
Evolution of structures
Add new paragraph types used as a “structured editorial element”
- Two columns ( paragraph with two wysiwyg fields )
- Section title ( just a text_field)
- Number list ( a paragraph with a list of Number Item paragraphs plus a title )
- Number Item ( 3 text_field : number, unit, legend)
P1 is renamed “title, wysiwyg”
In CT1 content type, the p_list field now reference 4 paragraph types :
- “title, wysiwyg” ( ex: P1)
- Two columns
- Section title
- Number list
Features configuration
- Edit Feature Default Bundle configuration
- Add Paragraph as base type
Export
As for the basic case, the export will be correct and the Core package contain all shared field storage.
Note :
In this case, the export generate two different packages : “Number Item” and “Number List” . As they form a single “Content Structure” together, the export should only generate a unique package, not two separate ones.
Taxo Extended case :
Add taxonomy at the party
Preparation
- Make a clean installation
- Install basic case packages
- Edit Feature Default Bundle configuration
- Add Paragraph as base type
You are ready
Evolution of structures
Add to existing configuration ( like a update of site) :
- A taxonomy Vocabulary “Taxo” with a field “link”
- A field in CT1 and CT2 with a taxonomy “taxo
”
Export note :
- If we don’t change feature bundle configuration, the taxonomy vocabulary declaration are lost in “site” package when all of it’s configuration is in the “core” package.
So we cannot have a unique package like other bundable entities. - If we edit features bundle configuration to set taxonomy as “base type” like node or paragraphs ( set as base type and unset as site type), a new package “taxo” can be exported but contains the field storage “node.field_taxo”. This will create a huge circular dependency. CT1 and CT2 packages depends of “taxo” package, and “taxo” depends of CT1 AND CT2
Questions :
Is there a method to export Vocabulary like other bundable entities ?
The issue #2579753 explains that taxonomies are required too much (true for “tags” like vocabulary), but they can be used as a huge classification data with multiple fields. In this case, a package per vocabulary with all of it’s configurations is a much better solution.
Taxo Basic case :
Trying a taxonomy vocabulary with a field in a blank content type.
Preparation
- Make a clean installation
- Add a taxonomy Vocabulary “Taxo” with a field “link”
- Add a content type CT3
- Delete body field of CT3
- Add a field “taxo_field” to CT3 using “Taxo” vocabulary
Export note :
Why detecting vocabulary inside the content type, but not put it’s configuration within ?
NativeMedia Extended case :
Add Media ( which is in the core module since 8.4, but hidden), with the same preparation as Taxo study case. Let’s try to use media type set by media module.
Preparation
- Make a clean installation
- Install basic case packages
- Edit Feature Default Bundle configuration
- Add Paragraph as base type
You are ready
Evolution of structures
Add to existing configuration ( like an update of site) :
- Activate Media module
- Add a “copyright” field_text to “Image” media Type
- Add a “legend” field_text to “File” media Type
- A field “Image gallery” in CT1 and CT2 with a reference to the media type “Image”
- A field “documents” in CT1 with a reference to the media type “File”
- Edit Feature Default Bundle configuration
- Add Media type as base type
Export note :
MyMedia Extended case :
Same but with “custom” media Type
Preparation
- Make a clean installation
- Install basic case packages
- Edit Feature Default Bundle configuration
- Add Paragraph as base type
You are ready
Evolution of structures
Add to existing configuration ( like a update of site) :
- Activate Media module
- Delete present “Image” and “File” media type*
- Create an MyImage and MyFile media type with respectively “copyright” and “legend” field_text
- A field “Image gallery” in CT1 and CT2 with a reference to the media type “Image”
- A field “documents” in CT1 with a reference to the media type “File”
- Edit Feature Default Bundle configuration
- Add Media type as base type
Export
With custom media Type, the configuration detection and organisation are fine.
The node field_storage share between CT1 and CT2 is set in Core package.
CT1 package contains all data for the “field_document”
MyFile and MyImage package contain all data needed, everything is correct.
Note : Interesting, isn’t it ?
Block Type case :
With a block Type created in block Layout
Preparation
- Make a clean installation
- Install basic case packages
- Edit Feature Default Bundle configuration
- Add Paragraph as base type
You are ready
Evolution of structures
Add to existing configuration ( like a update of site) :
- Create a block_type ( block_layout > custom block library > block type > Add custom block type ) : MyBlockType
- Delete body field
- Create a “text_field” field
- Create a paragraph reference to P1 paragraph ( “ref”)
- Edit Feature Default Bundle configuration
- Add “block custom type” as base type ( and unset it in site type)
Export
A package “MyBlockType” and all of its configuration are present and exportable
Export note :
As explained in documentation, if the paragraph reference field “ref” has a machine name as “ref_to_P1”, it will be detected as part of P1 package.
Conclusions :
Generals :
In many basic cases, if the RTFM rule is respected, the export allows correct installation/update.
On the other hand, for Drupal 7 developers, it is not common to use prepared packages and it seems we need to change our habits.
The last point is the need of customisation of “feature bundles” configuration. At this point, it seems we have to create a custom “feature bundle” configuration in a “starter kit” profile to be sure that each entity type needed will be correctly detected and exported.
I’m stopping here for the presentation of the study cases and I’m waiting your feedbacks and discussions on the different points I’ve highlighted.
Comment | File | Size | Author |
---|---|---|---|
profil.zip | 4.91 KB | DrDam | |
Basic_case.zip | 13.13 KB | DrDam |
Comments
Comment #2
nedjo@DrDam
Thanks for taking the time to document in detail the various tests you've done.
We currently ship with a single default Features bundle. This cannot, course, address all use cases.
For much of what you are suggesting, it may be useful to consider introducing one or more additional features bundles that could be useful as a starting point for distinct use cases.
You could consider doing so through writing one or more contrib modules that provide features bundles for distinct use cases.
Comment #3
nedjo@DrDam
Also, a heads up that in terms of the energy you're putting in, that ideas are always welcome but at this point in the D8 cycle there is a big backlog of undone work captured already in the Features issue queue and a shortage of available volunteer contributions for basic maintenance, let alone significant new enhancements.