contentacms
Separate JSON API from the Contenta profile
I've been involved in multiple projects to create a new distribution for an organisation, these are new distributions because of the way they have to be security assessed and auditable. In a couple of recent cases these distributions require good RESTful support for headless.
The problem is, with all the headless Drupal examples available (Lightning, Headless Lightning, Reservoir, Contenta), there is none I've found that I can include in this distribution as an upstream in my composer.json.
The Drupal community has a handle on headless, but the way we solve the problem keeps getting repeated and trapped in these type: drupal-profile. It makes it impractical for anyone to access this logic in new distributions, we have to reinvent the wheel.
This is not just a headless problem, it happens with Media and other Workflows and more.
This repo is a prototype of how I would love to see Contenta split out its RESTful package requirements into a type: drupal-module. Then anyone can add the Contenta JSON setup to any existing site or distribution, and we should start seeing better upstreaming of best-practice in this space, instead of the current silo situation.
Note that this wouldn't make Contenta profile obsolete in any way. Contenta profile would remain important for building Contenta as a Distribution - config, UI, theme, and so on.
Looking forward to the discussion.
I've been looking for an example of this and finally found one. Many distributions have "media" feature which can't be re-used.
PreviousNext have created pnx_media, which defines module dependencies and initial config, and can be easily included by any distribution. Sweet.
It would be awesome if Contenta split its JSON related modules out in the same way so that it can re-used in other distributions.
Ideally you should be able to install these meta-packages to add required modules and config, then immediately uninstall, so they can get out of the way, don't become a required dependency themselves, etc. This just leads to headaches, e.g supporting an upgrade path. I'd advocate for the 'starter kit' approach.
I'm working right now to mark contenta use pnx_media, that's something which is totally worth not sharing.
I'm curious though how useful the other stuff might be. I guess the only really reusable bit (which is not tied to the data model) is the customization of the admin UI.
Kim Pepper [email protected] schrieb am So., 3. Dez. 2017 um 22:15 Uhr:
Ideally you should be able to install these meta-packages to add required modules and config, then immediately uninstall, so they can get out of the way, don't become a required dependency themselves, etc. This just leads to headaches, e.g supporting an upgrade path. I'd advocate for the 'starter kit' approach.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/contentacms/contenta_jsonapi/issues/232#issuecomment-348818400, or mute the thread https://github.com/notifications/unsubscribe-auth/AABz7m7vbKZiKAl4P4gcbA7hCZM1gT5Mks5s8xoFgaJpZM4QzIxP .
I just want to reiterate a few things to watch out for (perhaps so I don't lead anyone astray).
You really don't need all your general UI stuff (eg Material) in a separate metapackage - it belongs in your profile (to your product).
Don't maintain config with a metapackage - after the site is installed, the config belongs to the site. Anything tied to the data model, leave in the profile.
I'd like to see a few distributions use/share one or two metapackages, and see how the practice evolves (or if it turns into a dependency nightmare). I think it's awesome that you are going to try using pnx_media, but use it as a test.
One major problem I see with splitting things up: how do we still don't provide an update path? By putting out a module out there, there seems to be a level of communication associated.
On Mon, 4 Dec 2017, 22:23 Simon Hobbs, [email protected] wrote:
I just want to reiterate a few things to watch out for (perhaps so I don't lead anyone astray).
You really don't need all your general UI stuff (eg Material) in a separate metapackage - it belongs in your profile (to your product).
Don't maintain config with a metapackage - after the site is installed, the config belongs to the site.
I'd like to see a few distributions use/share one or two, and see how the practice evolves (or if it turns into a dependency nightmare).
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/contentacms/contenta_jsonapi/issues/232#issuecomment-349126721, or mute the thread https://github.com/notifications/unsubscribe-auth/AABz7hhHersqrXuMBhLJ-uinaJql_qINks5s9HDpgaJpZM4QzIxP .
I don't think it changes. Currently it is the responsibility for individual modules to handle their own config updates - that doesn't change. Distributions can also take a sort of paternal responsibility for all the children playing nice together - that doesn't change.
I'm really interested in this idea that Lightning advertises itself as the "best of Drupal". Customers ask to have Lighting Workflow - but what is that? It's just the knowledge of a developer to choose correct modules, enable and configure them. Then the Drupal developer goes away. (I'm going to ignore patch management for the sake of argument.)
pnx_media does the same thing, then it leaves (literally it can go away, you could remove it as kimpepper says). In my case I would probably want to keep it, because I'm interested in the version constraints it sets.
I think that at this point we're all already sold on the idea. Any chance we can get an initial patch?
Ok if it's me who is a crap coder, then I have to work out how the heck to do it without wasting everyone's time, so I'm going to try and do this with Lightning Workflow on my current project.
Aaaannd oddly enough, two weeks ago a wild Lightning Workflow appeared on Drupal.org, https://www.drupal.org/project/lightning_workflow - but they tell you not to use it stand-alone (which I'm basically going to try to do).