As a Drupalist, I want a UI that allows me access to the relevant standard features of Drupal

[ba66e77]

...so that I can leverage taxonomy, contrib modules, and other core Drupal features.

This issue is a continuation of a discussion begun in #21. Reservoir's decision to gear the UI to non-Drupalists makes things easier for those users but adds some impediments to users who are comfortable with the standard interface and feature sets.

A potential solution proposed in the previous issue is a sub-module of Reservoir UI which would restore those UI elements relevant for headless Drupal sites with, potentially, "a "I'm a Drupalist" checkbox during the installer, to install the reservoir_ui_drupalist module"

I'm hoping in this space we can find out if others are interested in similar features, figure out the best way to implement, and handle any other related discussion.

[jrbeeman]

(Started writing this in #21, but looks like this is a more appropriate place to respond)

Taxonomy is an important aspect of a strong content model. Without core's implementation of the entity type, I think we'd end up wanting to create a custom entity type that mimic its purpose. So, I can imagine any project our team delivers to end up overriding-the-override referenced in #21 to restore its access, or creating custom entity types (not content types) to fulfill the same purpose.

Similarly, I foresee text formats continuing to be an important configuration to manage in the UI. While editors may (or may not) be using a decoupled front-end to author content, it's still important for me as a site builder to control what happens when parsing and returning input text, even if I'm doing so through an API.

While taxonomy and text formats are a couple of examples that @ba66e77 has listed, disabling full administrative routes could also have unintended consequences of blocking / obscuring access to configuration for contrib dependencies.

[damontgomery]

The approach we have found to be the best in other situations is to have the profile contain two separate pieces. One is the list of contributed modules and glue code. The other is the significant differences from the Drupal system. If you can decouple them, you can support both use cases.

Person is new to Drupal -> installs both the functionality and the default UI.

Person is not new to Drupal and wants to customize the editorial UI more -> Chooses to disable the UI portion and build out the text formats / field settings / find things where they normally are in the menu.

[JakeWilund]

Is there a reason why the access to to additional administrative areas can't simply be solved with permissioning, as it is in most cases?

[danepowell]

Even if access to admin/structure isn't necessary in a production environment (a position I generally agree with), it's hard to imagine getting by without it for local development. There simply aren't good alternatives to the UIs provided there for configuring so many aspects of a site.

Similarly, I think Views should be installed or at least allowed. Views are not strictly a visitor-focused / frontend tool--they are imminently useful in building administrative interfaces (e.g. content listings) and for things like media selection via entity browser.

[wimleers]

Taxonomy is an important aspect of a strong content model. Without core's implementation of the entity type, I think we'd end up wanting to create a custom entity type that mimic its purpose. So, I can imagine any project our team delivers to end up overriding-the-override referenced in #21 to restore its access, or creating custom entity types (not content types) to fulfill the same purpose.

So all of your projects use hierarchical vocabularies? Reservoir is for now assuming that the "Tags" vocabulary (a folksonomy, no hierarchy) is "good enough".

In a headless system like Reservoir, you might as well create additional content models (node_types in Drupal lingo) and then reference content of those content models instead. Exposing taxonomy vocabularies means you can have "two kinds" of content models. And both are fieldable. For many intents & purposes, they just have different internals, and have different UIs. That's … very confusing for non-Drupalists.

Similarly, I foresee text formats continuing to be an important configuration to manage in the UI. While editors may (or may not) be using a decoupled front-end to author content, it's still important for me as a site builder to control what happens when parsing and returning input text, even if I'm doing so through an API.

Can you back this up with some data? For example, in my experience most D8 sites use the default basic_html text format and that's it. Furthermore, I'd think that most decoupled use cases don't want to add a whole bunch of filters to their text formats. IOW: Reservoir is for now assuming that basic_html is "good enough".

obscuring access to configuration for contrib dependencies.

The point is that the set of tools that Reservoir presents you with is limited, therefore accessible, understandable, internalizable for everybody, so that you don't need to learn these Drupalisms. You build your content models, and you connect the content models.

So Reservoir is about a conscious subset of what Drupal has to offer, that satisfies a majority use case, simplifies development, simplifies maintenance, simplifies the mental model … while still making it possible for Drupalists to extend it as they please, knowing that they then leave simplicity behind.

Person is not new to Drupal and wants to customize the editorial UI more -> Chooses to disable the UI portion and build out the text formats / field settings / find things where they normally are in the menu.

Yes, this is a possibility. But like I said in #21: until this is requested many times, I'm going to have to disagree for the sake of making Reservoir accessible to non-Drupalists.

---

Can you see how we're trying to reduce the numbers of knobs? All the knows you're asking for are Drupalisms. And those Drupalisms are often less relevant.

[wimleers]

There simply aren't good alternatives to the UIs provided there for configuring so many aspects of a site. Which aspects?

Similarly, I think Views should be installed or at least allowed.

Reservoir is not disallowing the installation of Views? If that's not working, please create a separate issue for that.

Views are not strictly a visitor-focused / frontned tool--they are imminently useful in building administrative interfaces (e.g. content listings) and for things like media selection via entity browser.

Views is not necessary right now. If we end up adding things like Entity Browser, we could re-add it. The point is that Reservoir's surface is as small as possible. That makes it more supportable because more predictable because less code.

[danepowell]

Correct, Reservoir apparently disallows installation of Views: #27

[tedbow]

So serious question.

As a Drupalist if want many of the admin routes back that Reservoir intentionally is taking away and if we add the ability to easily to disable the the portion of Reservoir UI that disables admin routes, what is the benefit of using Reservoir at all?

All Reservoir is at this point basically

1. Taking away some admin options
2. Moving some admin options to the top level
3. Enabling a pre-seleted set of the contrib modules 4 Enabling some default content and configuration

If you are coming at Reservoir from a Drupalist point of view wouldn't just looking that composer.json provided by this project and including the same contributed modules and libraries be a better starting point?

What of what Reservoir DOES do makes it a better starting point for a Drupalist?

[damontgomery]

I want to put together a better response in a few days perhaps.

The short of it is that Reservoir can be curated. If there is a large enough user base, one person finds a solution to the bundle of modules and the rest of the community benefits. Selecting the modules and enabling certain features is not trivial to someone beginning to use Drupal.

Especially if you are the site build team and not the maintenance team, it's nice to pass on something to the maintenance team that they can have help supporting. It's likely they will be even less familiar with the bundle of modules, etc, and checking to see if there are upstream fixes for issues is always nice.

Here is an example:

For a while, the contrib module CORS handled access across domains, but this was brought into Drupal 8.2. It wasn't until I started having issues with the contrib module and saw everyone linking to the 8.2 notes that I made the switch. If Reservoir had existed when CORS was the solution, I would expect to see a targeted release note and update path between the two systems as in the domain of the profile. As a use of Reservoir, I would have been able to get ahead of the issue.

Another example:

Right now all of the contrib modules are pinned to very specific releases. If I just copy the composer.json file, I now have to keep up with why all of those releases are pinned and find out when it's a good idea to upgrade. I'm assuming this is another thing that is within the domain of the profile.

[tedbow]

@damontgomery I guess 1 way to solve the problem you are describing could be for us you are maintaining Reservoir to:

1. Create another project reservoir-contrib(or something better named)
2. Move all contrib project dependencies from this project's composer.json to reservoir-contrib's composer.json
3. Add a dependency to reservoir-contrib

Then anybody like yourself who knows Drupal or someone who wants to build a decoupled Drupal(not just use Drupal as a content store) could just composer require reservoir-contrib

Of we would want to make sure we documented this well in the README