Contenta JSON API profile.

[greg-1-anderson]

No description provided.

[stevector]

Nice, I was going to suggest we tackle Contenta as part of the ACE team Composer Week next week.

[greg-1-anderson]

I'm planning on using it for the updatinator server.

[greg-1-anderson]

The workflow set up by the build tools plugin no longer allows the installation profile to be changed in a PR, since we use the database from the dev environment rather than re-installing for pull requests as we used to do. This means that the passing test here doesn't mean much -- it simply installed the Contenta profile and ran the tests on the existing site w/out using any Contenta modules.

Starting fresh:

terminus build:project:create pantheon-systems/example-drops-8-composer:dev-contenta testsitename --team="My Team"

This gave an error in site-install, but the message wasn't printed for some reason. Calling site-install again directly:

$ terminus drush updatinator.dev -- site-install contenta_jsonapi --account-mail='[email protected]' --account-name=admin --account-pass="???" --site-mail='???' --site-name=testsitename --yes
You are about to DROP all tables in your 'pantheon' database. Do you want to continue? (y/n): y
Starting Drupal installation. This takes a while. Consider using the        [ok]
--notify global option.
Installation complete.                                                      [ok]
This import is empty and if applied would delete all of your             [error]
configuration, so has been rejected.
The configuration synchronization failed validation.                    [status]
Congratulations, you installed Contenta JSON API!                       [status]

Not sure where that config-import is coming from, but presumably it is the Contenta profile. Not sure how this is supposed to work, but the error code is set to 1, which stops the Build Tools Plugin from continuing.

Trying to install Contenta locally following their instructions to compare against my results.

[stevector]

@e0ipso was working an Contenta repo with Circle 2.0 over in https://github.com/e0ipso/contentacms-demo/blob/master/.circleci/config.yml

[greg-1-anderson]

Neat. It would be good to have Circle CI 2.0 support in the Terminus Build Tools plugin too.

[stevector]

I've been working on automated tests for the forthcoming pantheon_advanced_page_cache module and decided to use 2.0. It runs so much faster! https://github.com/pantheon-systems/pantheon_advanced_page_cache/pull/2/files

[greg-1-anderson]

Contenta has the following in their settings.php:

$config_directories['sync'] = 'profiles/contrib/contenta_jsonapi/config/sync';

The build tools plugin relocates the configuration directory to be outside the document root; that directory is empty, ergo the message I was getting above. Updating the sync directory to what Contenta expected it to be allowed the installation to complete successfully.

This strategy of putting the Config sync directory on top of the installation profile configuration directory was advanced by Alex Pott. It's a great idea in principal, but I'm not sure that it works well for a Composer workflow, as this directory is not committed to the git repository, and is overwritten by composer install when set up in this configuration.

I'm not sure what the best solution is, both in terms of Contenta, specifically, and also in general for other profiles that we might wish to use with the Composer workflow. Note that these profiles might prefer to keep their config sync location inside the profile itself when not using the Configuration workflow. Maybe we need to detect this situation and copy the profile's initial config to our preferred config directory location once, at initial install time.

[greg-1-anderson]

Successful install: http://dev-updatinator.pantheonsite.io/

[dawehner]

So much <3 happening here!

This strategy of putting the Config sync directory on top of the installation profile configuration directory was advanced by Alex Pott. It's a great idea in principal, but I'm not sure that it works well for a Composer workflow, as this directory is not committed to the git repository, and is overwritten by composer install when set up in this configuration.

I think this is indeed a good idea for actual files ... the scripts in contenta partially are there in order to support development on contenta itself. I think chagning the folder for actual config to be somewhere else is a good idea!

[stevector]

Thanks for the input @dawehner! I'd like to get to a point where doing an all Composer-based install of Contenta with Pantheon is a one-line command like what @greg-1-anderson mentioned above with

terminus build:project:create pantheon-systems/example-drops-8-composer:dev-contenta testsitename --team="My Team"

Once we validate that the build:project:create command works with Contenta, it might be cleaner to have a separate repo for as the basis for Contenta + Pantheon. The build:project:create command could copy from a contentacms/pantheon-example-demo repo. (FWIW, build:project:create is a wrapper around composer create-project). @greg-1-anderson, is that what you have in mind for distros like Contenta? @dawehner would you be open to putting such a repo under the Contenta org?

[e0ipso]

I'd like to get to a point where doing an all Composer-based install of Contenta with Pantheon is a one-line command like what @greg-1-anderson mentioned above

That would be so great!

[greg-1-anderson]

The one line above already works, with just one deferred task: you need to update your configuration sync directory in settings.php after installation.

I'm not sure how to "fix" Contenta so that this is not necessary. The config_installer manually imports configuration, but the Contenta profile seems to simply depend on setting config_install in its .info file.

I suspect that the right thing to do is to move the Contenta default configuration to the standard location, config/install, and make the corresponding change in settings.php to handle the non-Composer case. The Composer use-case, then, would be the same, except the config sync directory would be set to a location outside of the document root. This should handle the use-case of installing Drupal only once, and copying the database from dev or live for each test run. This is how this example Pantheon Config workflow is set up currently. I'm not sure about handling the case where your Drupal site is re-installed for each test run (as this project was previously configured to do). I suspect that the thing to do would be to install configuration as the config installer does. I'm not sure if there's a good way to re-use, rather than copy the config installer here.

[greg-1-anderson]

I made a hack that points the config directory to the place Contenta expects it during installation, and reverts it back to its location outside of the document root after installation is complete. This works great (although hacky) in the Drupal GUI, but does not work in Drush site install.

I need to either enhance the hack to also detect drush si, or wait for this to be fixed in Contenta.

[dawehner]

Well, this is all coming from the issue in core: https://www.drupal.org/node/2788777 which allows to install from scratch. I'm quite sure I'm using that patch on another project without any problems with using drush.

Can you clarify why you think we should use a different way of installing configuration?

[greg-1-anderson]

@dawehner For Drupal sites that are not Composer-managed, the current technique is fine.

For Composer-managed Drupal sites, the current mechanism works just fine for installation; however, the problem is that once you are done, the config directory points inside the Contenta profile. In a Composer-managed Drupal site, this location is not stored in the git repository, which makes future configuration exports problematic.

My hack puts the config directory where Contenta expects it to be for installation, and then moves it back to a location that is saved in the repository after installation is complete. For Composer-managed sites, it would be better if Contenta would still install correctly even if the Config sync directory is not pointing at its initial configuration directory. Maybe moving the initial config directory from config/sync to config/install would do the trick.

[stevector]

@dawehner, @e0ipso I'm curious how you have handled oauth keys with Pantheon. I see that by default the installer will put them in a directory above the Drupal root: https://github.com/contentacms/contenta_jsonapi/blob/8.x-1.x/contenta_jsonapi.install#L45

And that the keys directory is ignored in this demo repo: https://github.com/contentacms/contenta_jsonapi_demo/blob/master/.gitignore#L72

Are you instead putting the key files in the unversioned private files directory?

[e0ipso]

@stevector we did not have to worry about that since we always do a full reinstall when deploying. A part from that, we can just generate the keys via the UI if we need to. Unelegant, but we didn't have the need to solve it properly.

[stevector]

Thanks @e0ipso! I'll keep investigating options. I think I'll start a contenta--take-2 branch to be merged into this contenta branch which is now a few months out of date.

[ehausen]

Hello!

How is it going with this one? I'm looking for a solid way to get Contenta running on Pantheon and keeping it running following best practices. Already skimmed through https://pantheon.io/docs/guides/build-tools/ and have been doing my best to familiarize myself with this thread and related files.

But I could use some pointers. Any up to date recipes, guides?

[slattery]

@ehausen this looks like the install got solved? pull 128

But I could use some pointers. Any up to date recipes, guides?