acquia/reservoir

A back end for your front end: a content repository. Powered by Drupal 8, JSON API and OAuth2.

Warning: this project has been deprecated.

Please consider using Headless Lightning or Contenta.

reservoir's Issues

Add back Manage Form tab to content types

In Reservoir UI we removed the "Manage Form" tab. I think we should added it back. We could rename it something like "Manage Edit Form".

Since we offer the form on the site and we explicitly have "content editor" role we should let the admin control the form.

It would probably make sense to alter the many of the existing field on content type and make NOT editable on the manage form. So everything in the right tabs and title itself isn't on that page. Then will be much simpler and focused on the fields the administrator actually adds.

related: #13

Scale images on advanced API form

When you go to admin/api/advanced you'll see that the images are not scaled.

I already fixed the issue, but have not experience on committing a patch. Anyone who can help me?

You can change the height and width of those images in ApiAdvancedForm.php

Customize the installer: Reservoir logo + add/skip some steps?

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

...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.

jsonapi 404 spits out HTML

If I access a JSONAPI resource that can't be found, the default drupal 404 page is returned. The returned header are good, 404.

I expect the returned body to be in JSON-format, not the default drupal 404 html response.

Cannot access API documentation

Version: Alpha 1

Go to:
admin/api
admin/api/config

Get error:

Oops... ReDoc failed to render this spec
Error downloading http://local.well.com/admin/whoops HTTP ERROR 404

This happens on any of the API pages.

Dev branch (with 8.3.4) cannot be installed with composer.

On a new project, if I try to pin to the 8.x-1.x branch which includes the 8.3.4 security release, I cannot install the dependencies with composer.

On an existing project with Reservoir, I can update core, composer update drupal/core. This is using the alpha release and then updating core. I haven't tested any functionality yet, just composer installation.

I tried a fresh install using the reservoir-project repo as a starting point,

Changed: "acquia/reservoir": "dev-8.x-1.x"

composer.json

{
    "name": "acquia/reservoir-project",
    "description": "Project template for Drupal 8 sites built with the Reservoir distribution.",
    "type": "project",
    "license": "GPL2",
    "minimum-stability": "dev",
    "prefer-stable": true,
    "repositories": [
        {
          "type": "composer",
          "url": "https://packages.drupal.org/8"
        }
  ],
  "require": {
    "composer/installers": "^1.0",
    "cweagans/composer-patches": "~1.0",
    "drupal-composer/drupal-scaffold": "^2.0.0",
    "acquia/reservoir": "dev-8.x-1.x"
  },
  "extra": {
      "installer-paths": {
          "docroot/core": [
              "type:drupal-core"
          ],
          "docroot/modules/contrib/{$name}": [
              "type:drupal-module"
          ],
          "docroot/profiles/contrib/{$name}": [
              "type:drupal-profile"
          ],
          "docroot/themes/contrib/{$name}": [
              "type:drupal-theme"
          ],
          "drush/contrib/{$name}": [
              "type:drupal-drush"
          ]
      },
      "enable-patching": true
  }
}

This produces the error,

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for acquia/reservoir dev-8.x-1.x -> satisfiable by acquia/reservoir[dev-8.x-1.x].
    - acquia/reservoir dev-8.x-1.x requires webflo/drupal-core-strict ^8.3.4 -> satisfiable by webflo/drupal-core-strict[8.3.4, 8.3.x-dev, 8.4.x-dev].
    - webflo/drupal-core-strict 8.3.4 requires composer/installers v1.2.0 -> satisfiable by composer/installers[v1.2.0].
    - webflo/drupal-core-strict 8.3.x-dev requires composer/installers v1.2.0 -> satisfiable by composer/installers[v1.2.0].
    - webflo/drupal-core-strict 8.4.x-dev requires composer/installers v1.2.0 -> satisfiable by composer/installers[v1.2.0].
    - Conclusion: don't install composer/installers v1.2.0

I believe this is because Drupal core and webflo/drupal-core-strict are not compatible. I got similar (but slightly different) composer errors when trying to upgrade from the alpha to this branch.

$ composer require acquia/reservoir:dev-8.x-1.x
    1/1:	http://packagist.org/p/provider-latest$ff0af8c2229d07f162d42f6d3525c6f84b1d168edc303d9f03273fb503a156a9.json
    Finished: success: 1, skipped: 0, failure: 0, total: 1
./composer.json has been updated
    1/1:	http://packagist.org/p/provider-latest$ff0af8c2229d07f162d42f6d3525c6f84b1d168edc303d9f03273fb503a156a9.json
    Finished: success: 1, skipped: 0, failure: 0, total: 1
Gathering patches for root package.
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for zendframework/zend-stdlib (locked at 3.1.0) -> satisfiable by zendframework/zend-stdlib[3.1.0].
    - Installation request for acquia/reservoir dev-8.x-1.x -> satisfiable by acquia/reservoir[dev-8.x-1.x].
    - acquia/reservoir dev-8.x-1.x requires webflo/drupal-core-strict ^8.3.4 -> satisfiable by webflo/drupal-core-strict[8.3.4, 8.3.x-dev, 8.4.x-dev].
    - webflo/drupal-core-strict 8.3.4 requires zendframework/zend-stdlib 3.0.1 -> satisfiable by zendframework/zend-stdlib[3.0.1].
    - webflo/drupal-core-strict 8.3.x-dev requires zendframework/zend-stdlib 3.0.1 -> satisfiable by zendframework/zend-stdlib[3.0.1].
    - webflo/drupal-core-strict 8.4.x-dev requires zendframework/zend-stdlib 3.0.1 -> satisfiable by zendframework/zend-stdlib[3.0.1].
    - Conclusion: don't install zendframework/zend-stdlib 3.0.1


Installation failed, reverting ./composer.json to its original content.

Text fields: embedded image URLs should be absolute?

Hey, i love Reservoir UI, nice to see JSON API so easily from the back, i was able to build really quickly a front-end with Vue.js, great job !

My issue : when i display my content from my Nuxt.js front-end, images url are broken because they are relative to my client server :

src="/sites/default/files/inline-images/Capture%20d%E2%80%99e%CC%81cran%202017-06-14%20a%CC%80%2021.06.18.png"

Expected behavior is an absolute url to Reservoir Server on rendered content. This was https://www.drupal.org/project/pathologic job when using D7

PS : looks forward to see GraphQL implemented, that would give D8 a big advantage in comparison to other back-end solutions

Demo content types + content should be optional during the installation process

Reservoir provides a default article content type for demo purposes. Many (most?) production sites won't use this particular content type, so it should be able to be deleted.

The problem is that Reservoir creates a "hello world" article at install time. So using any sort of standard configuration management workflow, when you install the site (or immediately after you install the site) and you try to import site configuration (which would delete the article content type), the import fails because content already exists:

Entities exist of type Content and Content type Article. These entities need to be deleted before importing.

I think the best solution would be to make the creation of demo / dummy content optional (perhaps by creating a separate reservoir_demo module).

Drupal's Security Model

When Reservoir & the Reservoir distribution of Drupal 8 get security updates, how will I be informed.

Usually this has been done through Drupal.org so all users get notified & can keep track. I couldn't find a d.o project for this.

Could be that there are additional tools I'm not familiar with, but would make sense to post something on drupal.org/project/reservoir I think. Like many projects, it is fine to use GitHub for engaging with other developers and getting access to their tool-set. But there should be releases up on d.o still I think.

Figure out how to simplify the admin UI but not remove e.g. /admin/structure so that contrib module still work as expected

Mentioned in both #22 and #37.

Integrate Reservoir with search

As a site user I want to be able to search content so that I kind find information relevant to my needs

It would be great to be able to expose a new endpoint that integrates with Drupal search. The standard way of doing this in Drupal may be exposing a searchapi view to REST, but this does not fit with the approach taken by Reservoir, so there may be a more elegant way of achieving this.

Reservoir doesn't install since drupal-scaffold 2.4.0

We require "drupal-composer/drupal-scaffold": "^2.0.0", which will bring in the latest release.

I tried to install Reservoir and didn't work but using "drupal-composer/drupal-scaffold": "2.3.0" does work. I am sure what would cause it to break yet.

Error: Call to a member function getTypeName() with jsonapi tags and user resources

/docroot/jsonapi/taxonomy_term/tags and /docroot/jsonapi/user/user gives an error Call to a member function getTypeName() ...

Need to provide ID when updating (PATCH) even though the URL contains the ID.

As described in the wiki guide, https://github.com/acquia/reservoir/wiki/Quick-Start-Guide#update-an-article

You need to make a request like,

PATCH to /jsonapi/node/article/141962d7-2180-4419-bb8e-a9c1d337aeb2

with body

{
  "data": {
    "id": "141962d7-2180-4419-bb8e-a9c1d337aeb2",
    "attributes": {
      "title": "Mr Patchy"
    }
  }
}

Which seems a bit unnecessary since the URL already contains the ID and I don't think you can pass multiple pieces of content at the same time.

Composer install crashes on Install -- "Killed" before completing build

Trying a default install on a MyPHPadmin server (512 MB Memory / 20 GB Disk / SGP1 - Ubuntu PhpMyAdmin on 16.04)

Using the following command it crashes trying to retrieve / write the config.json file.

composer create-project acquia/reservoir-project _*myproject_name*_ --stability=alpha -vvv

...

Reading /root/.cache/composer/repo/https---packagist.org/provider-drupal$views-ui.json from cache
Reading /root/.cache/composer/repo/https---packagist.org/provider-drupal$workflows.json from cache
Reading /root/.cache/composer/repo/https---packages.drupal.org-8/provider-drupal$media.json from cache
Reading /root/.cache/composer/repo/https---packagist.org/provider-drupal$media.json from cache
Reading /root/.cache/composer/repo/https---packagist.org/provider-drupal$settings-tray.json from cache
Reading /root/.cache/composer/repo/https---packagist.org/provider-drupal$core-class-finder.json from cache
Reading /root/.cache/composer/repo/https---packagist.org/provider-symfony$expression-language.json from cache
Reading /root/.cache/composer/repo/https---packagist.org/provider-symfony$config.json from cache
Killed

Not sure how to get past this bug, nor where to look for a more detailed log... I also tried installing on a fresh Ubuntu build and it still breaks.

Suggestions on how to get past this error?

Getting 500 error on hitting the api for taxonomy terms

I created a taxonomy and added terms to it . After adding terms , I assigned those terms to the respective node of article content model . What I wanted was to filter the node according to the taxonomy term .
But I am getting internal server error on filtering the data using taxonomy term . Also when I hit the json url generated by reservoir to list the taxonomy_terms . It shows internal server error .

Is there any plans to support JWT tokens

I think, the JWT could be a nice choice for simple apps where only web app and backend exists, since it suggests a more simple way to authorize front-end requests to backend.

Is there any plans to provide such type of authorization?

Can't install reservoir due to drupal-core-strict

Hi;

I can't see the way to install reservoir following the official docs. There seems to be an issue related to #56 .

With composer updated on its stable channel (1.5.2 as today), there is a dependency problem which prevents installation:

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - webflo/drupal-core-strict 8.4.0 requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0].
    - webflo/drupal-core-strict 8.4.0-rc2 requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0].
    - webflo/drupal-core-strict 8.4.x-dev requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0].
    - webflo/drupal-core-strict 8.5.x-dev requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0].
    - don't install composer/installers v1.4.0|don't install composer/installers v1.2.0
    - acquia/reservoir 1.0.0-alpha2 requires composer/installers 1.2.0 -> satisfiable by composer/installers[v1.2.0].
    - Conclusion: don't install webflo/drupal-core-strict 8.3.7
    - Installation request for acquia/reservoir 1.0.0-alpha2 -> satisfiable by acquia/reservoir[1.0.0-alpha2].
    - webflo/drupal-core-strict 8.3.4 requires asm89/stack-cors 1.0.0 -> satisfiable by asm89/stack-cors[1.0.0].
    - webflo/drupal-core-strict 8.3.5 requires asm89/stack-cors 1.0.0 -> satisfiable by asm89/stack-cors[1.0.0].
    - webflo/drupal-core-strict 8.3.6 requires asm89/stack-cors 1.0.0 -> satisfiable by asm89/stack-cors[1.0.0].
    - webflo/drupal-core-strict 8.3.x-dev requires asm89/stack-cors 1.0.0 -> satisfiable by asm89/stack-cors[1.0.0].
    - Conclusion: don't install asm89/stack-cors 1.0.0|install webflo/drupal-core-strict 8.3.7
    - acquia/reservoir 1.0.0-alpha2 requires webflo/drupal-core-strict ^8.3.4 -> satisfiable by webflo/drupal-core-strict[8.3.4, 8.3.5, 8.3.6, 8.3.7, 8.3.x-dev, 8.4.0, 8.4.0-alpha1, 8.4.0-beta1, 8.4.0-rc1, 8.4.0-rc2, 8.4.x-dev, 8.5.x-dev].
    - webflo/drupal-core-strict 8.4.0-alpha1 requires doctrine/annotations v1.2.7 -> satisfiable by doctrine/annotations[v1.2.7].
    - webflo/drupal-core-strict 8.4.0-beta1 requires doctrine/annotations v1.2.7 -> satisfiable by doctrine/annotations[v1.2.7].
    - webflo/drupal-core-strict 8.4.0-rc1 requires doctrine/annotations v1.2.7 -> satisfiable by doctrine/annotations[v1.2.7].
    - Conclusion: don't install doctrine/annotations v1.2.7|install webflo/drupal-core-strict 8.3.4|install webflo/drupal-core-strict 8.3.5|install webflo/drupal-core-strict 8.3.6|install webflo/drupal-core-strict 8.3.7|install webflo/drupal-core-strict 8.3.x-dev

The official drupal-core-strict repo doesn't helps too much:

To fix to dependencies tested on Drupal 8.3.0 add "webflo/drupal-core-strict": "8.3.0" to the require section of your composer.json and run composer update from the command line.

In other words: this is a virtual package, that causes you to get exactly the versions of Drupal core's dependencies as they are specified in Drupal core's composer.lock file.

Using composer require is problematic on an existing site.

Any info?

API explorer ignores port numbers

My site is running on reservoir.dd:8083

WHen I go to API explorer the example URL on the right side is reservoir.dd/node/... - ignoring the port number

Refreshing an access token

I tried to follow auth0's tutorial for refreshing my access token, but I get the following error in Postman:

{
    "error": "invalid_grant",
    "message": "The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.",
    "hint": "Check the configuration to see if the grant is enabled."
}

This is a screenshot of my Postman setup:

Is there some configuration I have to do on the backend to support refresh tokens?

Protect the /admin/api/advanced route

Currently the reservoir_ui.api.advanced route is open to the public due to https://github.com/acquia/reservoir/blob/8.x-1.x/modules/reservoir_ui/reservoir_ui.routing.yml#L41

Schema errors at SwaggerHub

Tried to use OpenAPI specification generated by reservoir at swaggerhub, got a bunch of schema errors: https://app.swaggerhub.com/apis/tormi/reservoir-json_api/1.0.0 This is probably also from upstream.

Create a "Prepare for production" button

… which:

• deletes all demo content
• deletes the auto-generated key pair
• overrides the default CORS settings
• screams fire if Reservoir is not served via HTTPS

… and keeps warning the user with a ERROR message on every page until they fix all these things.

Cannot create clients

Version: Alpha 1

If I try to create a client, the Save button is grayed out and there is a notice, Create a role for every logical group of permissions you want to assign to a client. I'm not sure if they are related.

As a content editor I want to be able to use workflow to moderate my content between stages

Cannot assign roles to Clients

Version: Alpha 1

As I understand it, I create a User (or use one) and that user has roles. Then I create clients for that user and the client has it's own roles? Then I can use that client.

I cannot assign roles to a client using the Demo App client and I don't see any way to link the user to the client. The demo-writer user doesn't have any configuration pointing to the client and neither does the client.

See the screenshot below which shows only Label, Secret, and Is Confidential are values on the client.

Default content is breaking drush installation from configuration.

Steps to reproduce:

• Install the reservoir site with drush drush si reservoir
• Export the configuration (no changes made) with drush drush cex
• Attempt to reinstall the site from configuration drush si reservoir --config-dir="../config/default"

Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization. in            [error]
Drupal\Core\Config\ConfigImporter->validate() (line 728 of
/var/www/well/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php).
The import failed due for the following reasons:                                                                   [error]
Entities exist of type <em class="placeholder">Taxonomy term</em> and <em class="placeholder">Vocabulary</em>
<em class="placeholder">Tags</em>. These entities need to be deleted before importing.
Entities exist of type <em class="placeholder">Content</em> and <em class="placeholder">Content type</em> <em
class="placeholder">Article</em>. These entities need to be deleted before importing.

Possible fix:
Don't create default nodes and terms. See below for relevant code. When I remove those lines, everything works fine, although there is no demo content. :)

Suggested long term fix:
Maybe if you go through the UI, provide an option to create default roles / permissions / content. By default, don't create any of this. The site recommends against keeping these long term anyway.

Possible causes:
I believe the way drush does the site install is that it first does a normal site install which generates it's own site ID. This will be different than the one previously exported. Then, drush updates the new site's key to match exported configuration. Then, because all the configuration files loaded have different keys than those exported, it basically deletes them all and reloads from the files. It cannot delete the configuration files around article nodes and tags terms because Reservoir has created content.

Acquia BLT uses the site install as a core piece of it's local development and testing and this is causing issues with those.

Relevant code:
reservoir.install hook reservoir_install()

  // Create default content.
  file_unmanaged_copy(\Drupal::root() . '/' . drupal_get_path('profile', 'reservoir') . '/reservoir-logo.png', 'public://reservoir-logo.png');
  $file = File::create(['uri' => 'public://reservoir-logo.png']);
  $file->save();
  $term = Term::create([
    'name' => 'Camelids',
    'vid' => 'tags',
  ]);
  $term->save();
  Node::create([
    'type' => 'article',
    'field_body' => [
      'value' => 'The name "llama" was adopted by European settlers from native Peruvians.',
      'format' => 'basic_html',
    ],
    'field_image' => [
      [
        'alt' => 'Reservoir logo: a "pancake stack" with layers of water instead of pancakes, to reference Drupal!',
        'title' => 'Reservoir logo',
        'target_id' => $file->id(),
      ],
    ],
    'field_tags' => [
      [
        'target_id' => $term->id(),
      ],
    ],
  ])
    ->setTitle('Hello world!')
    ->setOwnerId(1)
    ->save();

Add the Coffee module to improve the administrator experience

Lightning combined with Reservoir

acquia/lightning requires a similar (but different) combination of components to Reservoir, and in fact there is a conflict if you try to use some combinations of Reservior and Lightning in the same composer.json. Do you consider Reservoir tools to be redundant if we're using Lightning?

If Reservoir does some special things that Lightning doesn't (and lets ignore the customized reservoir UI, let's just focus on API tools) - then if a client wants the Lightning editor experience in their headless Drupal, how would you recommend combining them together?

I'm not adverse to patching one or the other (eg with composer) to make them work together, but I want to see if there's an official way.

For those watching at home, the overlap is in:
drupal/jsonapi
drupal/openapi
drupal/simple_oauth

Are install steps correct?

I did as mentioned in the install,

$ composer create-project acquia/reservoir-project MY_PROJECT --stability=alpha

Created a host reservoir.local, pointed it to the docroot directory,

All I see when I goto the host is an empty page with core, modules & profiles directory?

What am I missing?

My virtual host,

<VirtualHost *:80>
    DocumentRoot "/Applications/MAMP/htdocs/personal/reservoir/docroot"
    ServerName reservoir.local
    ErrorLog "logs/com-error_log"
    CustomLog "logs/com-access_log" common
    <Directory /Applications/MAMP/htdocs/personal/reservoir/docroot/>
        Options FollowSymLinks Indexes
        AllowOverride All
        order allow,deny
        allow from all
    </Directory>
</VirtualHost>

Error when running the curl request example

When I try to run the curl request that is shown on the api authentication page (from a default install), I get the following error:

The website encountered an unexpected error. Please try again later.

Looking into it further, I found that the issue seemed to stem from when it tried to look in the RSA.php which says It was not possible to parse your key. I do see the token getting generated though I'm unsure what else could be the cause of the issue.

Challenging some CMS restrictions

Hi,

We currently used Reservoir the first time for building an API driven Drupal website/CMS. Thereby we enabled some modules for some additional functionalities. Unfortunately, there are some issues we can't fix so far, which mainly are related to the usability of the CMS by the client. Could anyone tell us if it's possible to fix the following issues/restrictions of this system:

• At /admin/content it's not possible to filter the content by language, content type (model), etc. or sorting it by "updated". We currently enabled the views module but this overview isn't visible there and we can't modify it by going to "/admin/structure/views/view/content" in de adres bar.
• Is there some way we can enable "Edit form display" ourselves? We want to edit the the ordering of the fields, group them and want to reference fields being displayed as dropdowns instead of (autocomplete) input fields.
• We want to add some extra items in het menu, like a link to the taxonomy page. We enabled the modules "Custom Menu Links" and "Menu UI" but if we go to /admin/structure/menu we receive an error that the entity type "menu" doesn't exist.

Is there someone who challenged the same issues earlier and could help us with these questions?

Thanks in advance!

CORS configuration has no effect when using default services.yml

#29 intended to allow cross-origin requests out of the box by adding CORS settings to reservoir.services.yml. This is a great idea, but unfortunately I don't think it will have any effect on most installs.

The problem is that the default.services.yml file provided by Drupal core disables CORS by default, and this takes precedence over the configuration provided by Reservoir. Any site that's using a services.yml file copied from default.services.yml (i.e. most sites?) will need to modify this file--CORS won't work out of the box as intended.

At the least, it would be good to document this in the Reservoir README. But there might be other ways to force the service definition to take effect and work out of the box.

Cannot install Reservoir sites using config management best practices

This problem is identical to one described for Lightning, except a little worse: https://github.com/acquia/lightning/issues/387

Long story short, it's impossible to install a Reservoir site and then import configuration (i.e. from config/default) as you would normally do for a standard configuration management workflow. If you try, you will get errors like this:

Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization. in Drupal\Core\Config\ConfigImporter->validate() (line 728 of docroot/core/lib/Drupal/Core/Config/ConfigImporter.php).
The import failed due for the following reasons:
Entities exist of type Taxonomy term and Vocabulary Tags. These entities need to be deleted before importing.
Entities exist of type Content and Content type Article. These entities need to be deleted before importing.

The reason is that Reservoir does not provide a static/default UUID for its fields, content types (article), and vocabulary (tags). Thus, Drupal picks a random UUID for each at install time. Then when you try to import the existing site configuration, it has a different UUID, so Drupal perceives it as a completely new configuration entity and tries to delete the existing one. But it can't do that if it already contains content.

A simple solution that we're also trying with Lightning is for the profile to provide default UUIDs.

Long-term, there should also be a way to disable the auto-creation of content at install time. This will at least prevent the error (although it will still require running entity-updates, as with the Lightning issue).

As a content editor I want to be able to attach Media to my content

Delete 'Content model' Article breaks openapi/jsonapi

Delete the Article node "Hello world!"
Delete the 'Content Model' Article.
Open the API documentation /admin/api
Error downloading openapi/jsonapi HTTP 500.
`1

Error: Call to a member function label() on null in Drupal\openapi\OpenApiGenerator\OpenApiJsonapiGenerator->getBundleTag() (line 332 of /Users/spoetnik/Projects/klaartje/reservoir/docroot/modules/contrib/openapi/src/OpenApiGenerator/OpenApiJsonapiGenerator.php) #0 /Users/spoetnik/Projects/klaartje/reservoir/docroot/modules/contrib/openapi/src/OpenApiGenerator/OpenApiJsonapiGenerator.php(43): Drupal\openapi\OpenApiGenerator\OpenApiJsonapiGenerator->getBundleTag('node', 'article') #1 /Users/spoetnik/Projects/klaartje/reservoir/docroot/modules/contrib/openapi/src/OpenApiGenerator/OpenApiGeneratorBase.php(91): Drupal\openapi\OpenApiGenerator\OpenApiJsonapiGenerator->getPaths(Array) #2 /Users/spoetnik/Projects/klaartje/reservoir/docroot/modules/contrib/openapi/src/Controller/ApiSpecificationControllerBase.php(50): Drupal\openapi\OpenApiGenerator\OpenApiGeneratorBase->getSpecification(Array) #3 [internal function]: Drupal\openapi\Controller\ApiSpecificationControllerBase->getSpecification() #4 /Users/spoetnik/Projects/klaartje/reservoir/docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array) #5 /Users/spoetnik/Projects/klaartje/reservoir/docroot/core/lib/Drupal/Core/Render/Renderer.php(574): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber{closure}() #6 /Users/spoetnik/Projects/klaartje/reservoir/docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) #7 /Users/spoetnik/Projects/klaartje/reservoir/docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) #8 [internal function]: Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber{closure}() #9 /Users/spoetnik/Projects/klaartje/reservoir/vendor/symfony/http-kernel/HttpKernel.php(144): call_user_func_array(Object(Closure), Array) #10 /Users/spoetnik/Projects/klaartje/reservoir/vendor/symfony/http-kernel/HttpKernel.php(64): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #11 /Users/spoetnik/Projects/klaartje/reservoir/docroot/modules/contrib/simple_oauth/src/HttpMiddleware/BasicAuthSwap.php(67): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #12 /Users/spoetnik/Projects/klaartje/reservoir/docroot/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Drupal\simple_oauth\HttpMiddleware\BasicAuthSwap->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #13 /Users/spoetnik/Projects/klaartje/reservoir/docroot/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #14 /Users/spoetnik/Projects/klaartje/reservoir/docroot/core/modules/page_cache/src/StackMiddleware/PageCache.php(99): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #15 /Users/spoetnik/Projects/klaartje/reservoir/docroot/core/modules/page_cache/src/StackMiddleware/PageCache.php(78): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true) #16 /Users/spoetnik/Projects/klaartje/reservoir/docroot/modules/contrib/jsonapi/src/StackMiddleware/FormatSetter.php(38): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #17 /Users/spoetnik/Projects/klaartje/reservoir/vendor/asm89/stack-cors/src/Asm89/Stack/Cors.php(40): Drupal\jsonapi\StackMiddleware\FormatSetter->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #18 /Users/spoetnik/Projects/klaartje/reservoir/docroot/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Asm89\Stack\Cors->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #19 /Users/spoetnik/Projects/klaartje/reservoir/docroot/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(50): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #20 /Users/spoetnik/Projects/klaartje/reservoir/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #21 /Users/spoetnik/Projects/klaartje/reservoir/docroot/core/lib/Drupal/Core/DrupalKernel.php(656): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #22 /Users/spoetnik/Projects/klaartje/reservoir/docroot/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #23 /Users/spoetnik/.composer/vendor/drush/drush/commands/runserver/d8-rs-router.php(67): include('/Users/spoetnik...') #24 {main}.

`

Install not working --> fatal: reference is not a tree

Was introduced to reservoir today.

When I try the install using the the composer based project template it fails ...

[RuntimeException]
Failed to execute git checkout '8325d172e1d6880aa24073f8f751ef089282cf9a' -- && git reset --hard '8325
d172e1d6880aa24073f8f751ef089282cf9a' --
fatal: reference is not a tree: 8325d172e1d6880aa24073f8f751ef089282cf9a

Not sure what I'm doing wrong

Can't install views module

I'm trying to install the Views module with Reservoir 1.0.0-alpha1. It appears that this isn't possible via the UI, since no admin/extend route exists, so I'm using drush:

drush en views

This produces the following error:

Argument 1 passed to Drupal\Core\Config\Entity\ConfigEntityBase::calculatePluginDependencies() must implement interface Drupal\Component\Plugin\PluginInspectionInterface, null given, called in docroot/core/modules/views/src/Entity/View.php on line 281 and defined PluginDependencyTrait.php:29

I'm assuming this has something to do with how Reservoir is modifying / suppressing administrative routes. Note that this is on a fresh install of Reservoir, also via Drush.

Content model dropdown lists removed tabs, doesn't list added tab

• Remove: Manage form display
• Remove: Manage display
• Add: API

Revisit/refine the dual-representation viewing of content

See contentacms/contenta_jsonapi#60 (comment):

For the the dual-format view of a node in the back-end - I really like it, but I think it's a terrible editorial experience so +1 if it goes onto a separate tab and the edit interface is the default.

Most decoupled projects I've worked on don't even provide the rendered node under the "View" tab, so even better I think would be the edit form with a JSON view that could slide in from the side.

Reservoir for production?

I'm thinking about reservoir for production, I do not want to risk it until it's not ready.
What is the estimated time to be released in beta?

Add support for GraphQL

The README mentions that there are plans to add GraphQL support "once it matures". I think we have reached that point. Actually quite some time ago to be honest. We are using GraphQL in production successfully for a while now. The module has good test coverage (although there is room for improvement of course). We've been very careful with doing a stable release because we are still actively working on additional features. The core APIs have been stable for a while, however. A few days ago we released the first alpha version. I'd like to highlight, however, that the module is considerably more stable and production ready than the average module published on d.o.

So... I'd like to kickstart a discussion of how we can add GraphQL to Reservoir. How do y'all envision support for various service models side-by-side in the first place?

I am open for chatting about this in person at Decoupled Dev Days or in a call at your convenience.

/cc @pmelab

Seems JSON API Extras is incompatible with Reservoir

It seems as if Reservoir and JSON API Extras don't play together. I get this error:

Recoverable fatal error: Argument 3 passed to Drupal\jsonapi_extras\JsonapiResourceConfigListBuilder::__construct() must be an instance of Drupal\jsonapi_extras\ResourceType\ConfigurableResourceTypeRepository, instance of Drupal\reservoir_ui\ReservoirResourceTypeRepository given, called in ....

The full message gives an indication as to what might be wrong. Would the features provided by that module be useful in Reservoir please?

Sample output on a vanilla D8 site:

Thanks.

composer create-project acquia/reservoir-project reservoir-project --stability=alpha failed

Got conflict, tried composer create-project --stability=alpla and --stability=dev, same conflict:

  Problem 1
    - Installation request for acquia/reservoir 1.0.0-alpha3 -> satisfiable by acquia/reservoir[1.0.0-alpha3].
    - webflo/drupal-core-strict 8.4.0 requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0].
    - webflo/drupal-core-strict 8.4.0-rc2 requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0].
    - webflo/drupal-core-strict 8.4.1 requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0].
    - webflo/drupal-core-strict 8.4.2 requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0].
    - webflo/drupal-core-strict 8.4.3 requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0].
    - webflo/drupal-core-strict 8.4.4 requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0].
    - webflo/drupal-core-strict 8.4.5 requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0].
    - webflo/drupal-core-strict 8.4.x-dev requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0].
    - webflo/drupal-core-strict 8.5.0-alpha1 requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0].
    - webflo/drupal-core-strict 8.5.0 requires composer/installers v1.5.0 -> satisfiable by composer/installers[v1.5.0].
    - webflo/drupal-core-strict 8.5.0-beta1 requires composer/installers v1.5.0 -> satisfiable by composer/installers[v1.5.0].
    - webflo/drupal-core-strict 8.5.0-rc1 requires composer/installers v1.5.0 -> satisfiable by composer/installers[v1.5.0].
    - webflo/drupal-core-strict 8.5.x-dev requires composer/installers v1.5.0 -> satisfiable by composer/installers[v1.5.0].
    - webflo/drupal-core-strict 8.6.x-dev requires composer/installers v1.5.0 -> satisfiable by composer/installers[v1.5.0].
    - don't install composer/installers v1.4.0|don't install composer/installers v1.2.0
    - don't install composer/installers v1.5.0|don't install composer/installers v1.2.0
    - acquia/reservoir 1.0.0-alpha3 requires composer/installers 1.2.0 -> satisfiable by composer/installers[v1.2.0].
    - acquia/reservoir 1.0.0-alpha3 requires webflo/drupal-core-strict ^8.4.0 -> satisfiable by webflo/drupal-core-strict[8.4.0, 8.4.0-alpha1, 8.4.0-beta1, 8.4.0-rc1, 8.4.0-rc2, 8.4.1, 8.4.2, 8.4.3, 8.4.4, 8.4.5, 8.4.x-dev, 8.5.0, 8.5.0-alpha1, 8.5.0-beta1, 8.5.0-rc1, 8.5.x-dev, 8.6.x-dev].
    - webflo/drupal-core-strict 8.4.0-alpha1 requires twig/twig v1.32.0 -> satisfiable by twig/twig[v1.32.0].
    - webflo/drupal-core-strict 8.4.0-beta1 requires twig/twig v1.32.0 -> satisfiable by twig/twig[v1.32.0].
    - webflo/drupal-core-strict 8.4.0-rc1 requires twig/twig v1.32.0 -> satisfiable by twig/twig[v1.32.0].
    - Conclusion: don't install twig/twig v1.32.0

Result of composer install on master branch causes same conflict:

  Problem 1
    - webflo/drupal-core-strict 8.6.x-dev requires composer/installers v1.5.0 -> satisfiable by composer/installers[v1.5.0] but these conflict with your requirements or minimum-stability.
    - webflo/drupal-core-strict 8.5.x-dev requires composer/installers v1.5.0 -> satisfiable by composer/installers[v1.5.0] but these conflict with your requirements or minimum-stability.
    - webflo/drupal-core-strict 8.5.0-rc1 requires composer/installers v1.5.0 -> satisfiable by composer/installers[v1.5.0] but these conflict with your requirements or minimum-stability.
    - webflo/drupal-core-strict 8.5.0-beta1 requires composer/installers v1.5.0 -> satisfiable by composer/installers[v1.5.0] but these conflict with your requirements or minimum-stability.
    - webflo/drupal-core-strict 8.5.0-alpha1 requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0] but these conflict with your requirements or minimum-stability.
    - webflo/drupal-core-strict 8.5.0 requires composer/installers v1.5.0 -> satisfiable by composer/installers[v1.5.0] but these conflict with your requirements or minimum-stability.
    - webflo/drupal-core-strict 8.4.x-dev requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0] but these conflict with your requirements or minimum-stability.
    - webflo/drupal-core-strict 8.4.5 requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0] but these conflict with your requirements or minimum-stability.
    - webflo/drupal-core-strict 8.4.4 requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0] but these conflict with your requirements or minimum-stability.
    - webflo/drupal-core-strict 8.4.3 requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0] but these conflict with your requirements or minimum-stability.
    - webflo/drupal-core-strict 8.4.2 requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0] but these conflict with your requirements or minimum-stability.
    - webflo/drupal-core-strict 8.4.1 requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0] but these conflict with your requirements or minimum-stability.
    - webflo/drupal-core-strict 8.4.0-rc2 requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0] but these conflict with your requirements or minimum-stability.
    - webflo/drupal-core-strict 8.4.0 requires composer/installers v1.4.0 -> satisfiable by composer/installers[v1.4.0] but these conflict with your requirements or minimum-stability.
    - webflo/drupal-core-strict 8.4.0-alpha1 requires twig/twig v1.32.0 -> satisfiable by twig/twig[v1.32.0].
    - webflo/drupal-core-strict 8.4.0-beta1 requires twig/twig v1.32.0 -> satisfiable by twig/twig[v1.32.0].
    - webflo/drupal-core-strict 8.4.0-rc1 requires twig/twig v1.32.0 -> satisfiable by twig/twig[v1.32.0].
    - Conclusion: don't install twig/twig v1.32.0
    - Installation request for webflo/drupal-core-strict ^8.4.0 -> satisfiable by webflo/drupal-core-strict[8.4.0, 8.4.0-alpha1, 8.4.0-beta1, 8.4.0-rc1, 8.4.0-rc2, 8.4.1, 8.4.2, 8.4.3, 8.4.4, 8.4.5, 8.4.x-dev, 8.5.0, 8.5.0-alpha1, 8.5.0-beta1, 8.5.0-rc1, 8.5.x-dev, 8.6.x-dev].

webflo/drupal-core-strict creates dependency conflicts

Composer is generally built on the philosophy that you shouldn't "pin" package versions unless absolutely necessary (such as when patching a package, deploying a build artifact, or working with a "root level" project where you obviously want to use composer.lock).

With that in mind, I'm not sure why Reservoir relies on webflo/drupal-core-strict, which pins all Drupal core dependencies to the exact versions used by core. The problem is that this can easily create dependency conflicts with all sorts of other packages, such as BLT: acquia/blt#1792

I could see how this would theoretically improve stability somewhat by ensuring that no package version is ever used that hasn't specifically been tested with core. But as a practical matter, I've never actually seen problems arise from using floating package versions, and other distributions such as Lightning don't use webflo/drupal-core-strict.

Also, extending this pattern to other packages besides Drupal core would create a completely unusable ecosystem--you'd hardly be able to install any packages at all due to dependency conflicts. So I'm not sure why we should treat Drupal core as a special snowflake.

Cannot apply patch https://www.drupal.org/files/issues/2870904-22.patch

Ran:
jimmy@Jakub:~/Sites/devdesktop$ composer create-project acquia/reservoir-project reservoir --stability=alpha

• Installing drupal/schemata (dev-1.x 99c723d) Cloning 99c723ddd4 from cache
• Applying patches for drupal/schemata
  https://www.drupal.org/files/issues/2870904-22.patch (Add entity type only schema routes for entity types with bundles)
  Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2870904-22.patch

Detailed error when rerunning with -vvv

cd 'docroot/modules/contrib/schemata' && git --git-dir=. apply --check '-p1' '/var/folders/w2/t69w4fpx11961dxt7ds1r8mm0000gn/T/59542662aa871.patch'
Executing command (CWD): cd 'docroot/modules/contrib/schemata' && git --git-dir=. apply --check '-p1' '/var/folders/w2/t69w4fpx11961dxt7ds1r8mm0000gn/T/59542662aa871.patch'
error: patch failed: src/Controller/Controller.php:82
error: src/Controller/Controller.php: patch does not apply
error: patch failed: src/Routing/Routes.php:71
error: src/Routing/Routes.php: patch does not apply

error: tests/expectations/node.api_json.json: already exists in working directory
error: tests/expectations/node.hal_json.json: already exists in working directory
error: tests/expectations/node.json.json: already exists in working directory
error: tests/expectations/taxonomy_term.api_json.json: already exists in working directory
error: tests/expectations/taxonomy_term.hal_json.json: already exists in working directory
error: tests/expectations/taxonomy_term.json.json: already exists in working directory
error: patch failed: tests/src/Functional/RequestTest.php:92
error: tests/src/Functional/RequestTest.php: patch does not apply

cd 'docroot/modules/contrib/schemata' && git --git-dir=. apply --check '-p0' '/var/folders/w2/t69w4fpx11961dxt7ds1r8mm0000gn/T/59542662aa871.patch'
Executing command (CWD): cd 'docroot/modules/contrib/schemata' && git --git-dir=. apply --check '-p0' '/var/folders/w2/t69w4fpx11961dxt7ds1r8mm0000gn/T/59542662aa871.patch'
error: a/src/Controller/Controller.php: No such file or directory
error: a/src/Routing/Routes.php: No such file or directory

error: a/tests/src/Functional/RequestTest.php: No such file or directory

cd 'docroot/modules/contrib/schemata' && git --git-dir=. apply --check '-p2' '/var/folders/w2/t69w4fpx11961dxt7ds1r8mm0000gn/T/59542662aa871.patch'
Executing command (CWD): cd 'docroot/modules/contrib/schemata' && git --git-dir=. apply --check '-p2' '/var/folders/w2/t69w4fpx11961dxt7ds1r8mm0000gn/T/59542662aa871.patch'
error: Controller/Controller.php: No such file or directory
error: Routing/Routes.php: No such file or directory

error: src/Functional/RequestTest.php: No such file or directory

patch '-p1' --no-backup-if-mismatch -d 'docroot/modules/contrib/schemata' < '/var/folders/w2/t69w4fpx11961dxt7ds1r8mm0000gn/T/59542662aa871.patch'
Executing command (CWD): patch '-p1' --no-backup-if-mismatch -d 'docroot/modules/contrib/schemata' < '/var/folders/w2/t69w4fpx11961dxt7ds1r8mm0000gn/T/59542662aa871.patch'
patching file src/Controller/Controller.php
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.

1 out of 1 hunk ignored -- saving rejects to file src/Controller/Controller.php.rej

patching file src/Routing/Routes.php

Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.

1 out of 1 hunk ignored -- saving rejects to file src/Routing/Routes.php.rej

The next patch would create the file tests/expectations/node.api_json.json,
which already exists!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.

1 out of 1 hunk ignored -- saving rejects to file tests/expectations/node.api_json.json.rej


The next patch would create the file tests/expectations/node.hal_json.json,
which already exists!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.

1 out of 1 hunk ignored -- saving rejects to file tests/expectations/node.hal_json.json.rej

The next patch would create the file tests/expectations/node.json.json,
which already exists!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.

1 out of 1 hunk ignored -- saving rejects to file tests/expectations/node.json.json.rej

The next patch would create the file tests/expectations/taxonomy_term.api_json.json,
which already exists!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.

1 out of 1 hunk ignored -- saving rejects to file tests/expectations/taxonomy_term.api_json.json.rej

The next patch would create the file tests/expectations/taxonomy_term.hal_json.json,
which already exists!  Assume -R? [n] 

Apply anyway? [n] 
Skipping patch.

1 out of 1 hunk ignored -- saving rejects to file tests/expectations/taxonomy_term.hal_json.json.rej


The next patch would create the file tests/expectations/taxonomy_term.json.json,
which already exists!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.

1 out of 1 hunk ignored -- saving rejects to file tests/expectations/taxonomy_term.json.json.rej

patching file tests/src/Functional/RequestTest.php
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file tests/src/Functional/RequestTest.php.rej


patch '-p0' --no-backup-if-mismatch -d 'docroot/modules/contrib/schemata' < '/var/folders/w2/t69w4fpx11961dxt7ds1r8mm0000gn/T/59542662aa871.patch'
Executing command (CWD): patch '-p0' --no-backup-if-mismatch -d 'docroot/modules/contrib/schemata' < '/var/folders/w2/t69w4fpx11961dxt7ds1r8mm0000gn/T/59542662aa871.patch'
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/src/Controller/Controller.php b/src/Controller/Controller.php
|index 5a201b8..4a448c1 100644
|--- a/src/Controller/Controller.php
|+++ b/src/Controller/Controller.php
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.

1 out of 1 hunk ignored
can't find file to patch at input line 18
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/src/Routing/Routes.php b/src/Routing/Routes.php
|index 4309bf9..b832206 100644
|--- a/src/Routing/Routes.php
|+++ b/src/Routing/Routes.php
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.

1 out of 1 hunk ignored

patching file b/tests/expectations/node.api_json.json

patching file b/tests/expectations/node.hal_json.json

patching file b/tests/expectations/node.json.json

patching file b/tests/expectations/taxonomy_term.api_json.json

patching file b/tests/expectations/taxonomy_term.hal_json.json

patching file b/tests/expectations/taxonomy_term.json.json

can't find file to patch at input line 1683
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/tests/src/Functional/RequestTest.php b/tests/src/Functional/RequestTest.php
|index cd906f1..5645a7d 100644
|--- a/tests/src/Functional/RequestTest.php
|+++ b/tests/src/Functional/RequestTest.php
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.

1 out of 1 hunk ignored

patch '-p2' --no-backup-if-mismatch -d 'docroot/modules/contrib/schemata' < '/var/folders/w2/t69w4fpx11961dxt7ds1r8mm0000gn/T/59542662aa871.patch'
Executing command (CWD): patch '-p2' --no-backup-if-mismatch -d 'docroot/modules/contrib/schemata' < '/var/folders/w2/t69w4fpx11961dxt7ds1r8mm0000gn/T/59542662aa871.patch'
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/src/Controller/Controller.php b/src/Controller/Controller.php
|index 5a201b8..4a448c1 100644
|--- a/src/Controller/Controller.php
|+++ b/src/Controller/Controller.php
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.

1 out of 1 hunk ignored
can't find file to patch at input line 18
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/src/Routing/Routes.php b/src/Routing/Routes.php
|index 4309bf9..b832206 100644
|--- a/src/Routing/Routes.php
|+++ b/src/Routing/Routes.php
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.

1 out of 1 hunk ignored

patching file expectations/node.api_json.json

patching file expectations/node.hal_json.json

patching file expectations/node.json.json

patching file expectations/taxonomy_term.api_json.json

patching file expectations/taxonomy_term.hal_json.json

patching file expectations/taxonomy_term.json.json

can't find file to patch at input line 1683
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/tests/src/Functional/RequestTest.php b/tests/src/Functional/RequestTest.php
|index cd906f1..5645a7d 100644
|--- a/tests/src/Functional/RequestTest.php
|+++ b/tests/src/Functional/RequestTest.php
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.

1 out of 1 hunk ignored

   Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2870904-22.patch

Restore /admin/structure path access and provide link from Manage menu

In the ReservoirUIRouteSubscriber, access to the system.admin_structure route is forced to FALSE. While this in some ways simplifies the UI by removing Display Modes and other aspects which are meaningless in a headless system, it has the (presumably) unintended side effect of blocking access to the configuration screens for taxonomy and for input formats, both of which are still meaningful for headless systems.