Problem/Motivation
Our client can only do so much without a Drupal instance to talk to. What can we do to make sure it is easy for developers to test with a Drupal environment? Could include:
* A hosted / public Drupal environment that can be used to simplify project setup. This seems like the higher priority.
* A local Drupal environment that can be used with this project in cases where Drupal related configuration changes and tests are necessary. A docker based configuration? A cloud based configuration?
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Issue fork api_client-3379155
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
brianperryWe should address this somehow for 1.0, even if it is just documenting our public JSON:API Drupal Instance.
Comment #3
mglamanWe have the quick start command which just uses PHP and SQLite and can install Umami. However JSON:API isn't installed
There could be a DDEV quick start which documents installing JSON:API with Umami. See https://ddev.readthedocs.io/en/stable/users/quickstart/#drupal
There also could be an extended Docker image that uses SQLite and has Drupal installed. But I think DDEV is a best approach so there is a proper living site to play around from and develop off of.
Comment #4
brianperryComment #5
brianperryComment #7
brianperryOpened draft MR with basic scripts to create and destroy a local Drupal DDEV environment. It installs using the Umami profile and enables jsonapi and decoupled_router. Things I'd still like to do:
- Strip down the examples to work with any Drupal instance (remove UUID things)
- Add a .env file set for development with a local Drupal environment
- Update install script to open up CORS
- Update config during install to make JSON:API writable.
Comment #8
brianperryComment #9
brianperryComment #10
brianperryMerging so I can more easily use this for local development, but keeping open for review for now.
Comment #11
coby.sher CreditAttribution: coby.sher as a volunteer commentedComment #12
brianperry> My only minor suggestion is tp add the scripts to the pnpm scripts in package.json so we could call pnpm ddev:init or pnpm ddev:destroy but a very minor thing we can add in the future.
That's a good idea - I'll add that.
Comment #14
brianperry