Problem/Motivation
As a site maintainer I want a fieldable "documentation entity" that can entity reference a content type, paragraph, taxonomy, or field so that I am able to add fields to contain the information I need.
Proposed resolution
This should avoid the simple solution of using a node bundle as then the documenation will polute the normal node content. Example "documentation entities" should not appear under /admin/content.
The unique id for the documentation entity might need to be something like entity:bundle:field
The entity should have a minimum set of fields that are default but open for adding or removing any that are not needed.
Possible default fields
- Purpose of this ____ (long text)
- link to external documentation
- link to web component
- date added
Would also be interesting if these were config entities so the content is deployable.
User interface changes
Tabs added to each of the paths identified that surface and save the fields that exist on that entity.
Comments
Comment #2
swirtComment #3
swirtComment #4
swirtSome possible approaches
1. Configuration entity -
+ This has the pro of having the values wide with config so it exports an imports the the values can be changed along with any actual config changes.
- The drawback is that I have not found a way to have fieldable config entities.
2. Content entity of its own entity type so that it does not intermingle with node bundles.
+ The advantage is that it is easily fieldable.
- Drawback it that it is not natively exportable/importable.
3. Third party settings.
+ This is the proper use for third party settings so it makes sense to use it.
+ exports as config
- unknown if a View can access them
- to make it flexible/"fieldable" I think it might take a form alter (and hopefully not much more.
Comment #5
swirtComment #6
swirtComment #7
swirtI moved the pathing and tab requirement to separate issues.
Comment #10
swirtComment #11
swirtThis has been released as part of alpha4.
There are still a couple of known issues.