Produce CiviCRM-Drupal8 tarballs

Also from the Gitlab thread, I asked:

do I understand correctly:

we could produce a .tar.gz of the vendor/civicrm/civicrm-core directory, that, if published correctly (in a way for composer to find it), people could composer require it

but they would still need to install modules/civicrm-drupal-8 separately.

Responses:

"that's pretty much it" -- @jackrabbithanna

"So then the drupal module just says require this library which is the core + packages etc packaged up right?" -- @seamuslee

"that would be ideal" -- @jackrabbithanna

Seamus posted: https://superuser.com/questions/936802/composer-install-tar-gz

So we could include a "dist" URL in the composer.json, but that dist URL would be d8-only. ~~Might be a problem for cross-CMS compatibility?~~ Although the resulting tar.gz might work for WordPress too, because some CMS-specific code was removed from core.

Presumably the next step is creating a distmaker script?

https://github.com/civicrm/civicrm-core/tree/master/distmaker/dists

@totten @monish.deb @dsnopek is the above broken out in steps already? How close are we given work so far?

See https://www.mydropwizard.com/blog/how-install-civicrm-drupal-8-and-why-choose-it-over-pure-drupal-crm

We're trying to get rid of the need of this gist in "The full, Manual process", step 2 https://gist.github.com/dsnopek/56311dbea347874e75180883efabb620

These are the current steps...there's nothing in here but getting the civicrm packages and other things and putting them in the proper places in the vendor/civicrm/civicrm-core folder, and one bower install command and this: cat /tmp/civicrm/civicrm-version.php | sed -e 's/Drupal/Drupal8/' > vendor/civicrm/civicrm-core/civicrm-version.php

Which I think there has been a PR for this already?

So the process can be:

Download and install Drupal 8
Go into the root directory in the shell and run composer require civicrm/civicrm-core (or civicrm-core-d8, or civicrm-core-packages, or whatever the community wants to settle on)
If you use Apache, remove the vendor/.htacess file. This is a security measure from Drupal, which prevents resources like CSS/JS being loaded. This will need some collaboration with the Drupal project to figure out a proper solution for because removing this file altogether is a bad idea on production. See: https://www.drupal.org/node/2896308 (link is external) Use Nginx preferably!
Go into the /modules directory and do: git clone git@github.com:civicrm/civicrm-drupal-8.git civicrm OR just download the stable release from civicrm.org or D.O project page and place in /modules
Go to the "Extend" page (at /admin/modules) and install the CiviCRM module
CiviCRM works!

Call that an "official release install method" phase 1

Additionally, we may add this composer require statement to the Drupal module composer.json, for those people wanting to install D8 and D8 modules with composer, although that takes a little extra love to work...

People had been having to symlink to the vendor directory outside the webroot, from the vendor inside the webroot..

Work has already been done on this too:

https://github.com/civicrm/civicrm-core/pull/12499

PRS waiting for review or need a little love, that seem to be related:

Let's keep organizing necessary todos here, so we all know where to look for what to do, and status...

Let's not get bogged down in details, surely we can have a workable MVP in a short time.

Something is better than nothing, and we can always make it better!

We've put a bunch of time into moving aspects of this forward at

(edited by ML: formatting)

added Concept approved triaged type:proposal labels

@JoeMurray Much appreciated!

From that list, all of those open issues are indeed important, but only drupal#7 (closed) seems like a high priority to me. It's almost ready to merge. If we can fix that, I think we can start working on distmaker?

The latest PR from Monish is here:

https://github.com/civicrm/civicrm-core/pull/12370

@monish.deb will aim to put in some time on this in the coming 3-4 business days.

@jackrabbithanna It sounds like you're loading your CSS/JS assets from the vendor folder, as per the docs @dsnopek so helpfully maintains.

I had worked with this configuration - with vendor symlinked in the webroot and trying other tricks - but the process fell over once I needed to use scripts in the extern folder. They can't bootstrap Civi if they're in the vendor folder, and I need me my REST APIs.

In drupal#9 (closed) @totten outlines the steps used by the Roundearth distribution, which I found to work much better, and bypasses the need to figure out how to deal with the security implications of removing the .htaccess file from the vendor directory. I also assume that since this is also maintained by @dsnopek it represents a newer way of thinking on how to package the stable D8.

I'd love to hear feedback from folks on this, because ideally our current D8 sites should mirror the eventual packaged D8.

@JonGold good feedback...

The .htaccess issue is not a big one for people using nginx.

Is the Roundearth way superior, in that you could install CiviCRM via composer and make use of the scripts in the extern folder?

This would also apply to payment processor webhooks? To use stripe or some other pp for recurring contributions, it must definitely be setup in a similar fashion?

If the Roundearth way of packaging Civi is better, should it be the official way, and that way outlined here as the common goal?

There are two options for installing D8, with or without composer...So it's possible we'll need two official ways? IDK the answer to that question.

I think that without centralized leadership on this issue soon there will be 10 "unofficial" ways, and the marketing of D8 + Civi will be done by partners and organizations, and not by the LLC at all. I can imagine any number of us making our own Civi+D8 distros, and there will be no one place to go to find your way with D8/D9 + Civi, we can all compete on the packaging and marketing, and we all start to loose the collective identity and branding, and resource pooling, at least in the Drupal realm. Sounds very free market, so maybe that is the way it should be. Not making a decision, is still a decision!

Small clarification:

"This would also apply to payment processor webhooks? To use stripe or some other pp for recurring contributions, it must definitely be setup in a similar fashion?"

Payment Processors now use /civicrm/ipn, not the extern scripts, so not affected.

@JonGold from drupal#9 (closed), tl;dr: we would host civicrm/vendor files under /library/civicrm ?

Are there any downsides to this?
Could we package those files as a library that Drupal/composer can easily download?

In drupal#9 (closed) @totten outlines the steps used by the Roundearth distribution, which I found to work much better, and bypasses the need to figure out how to deal with the security implications of removing the .htaccess file from the vendor directory. I also assume that since this is also maintained by @dsnopek it represents a newer way of thinking on how to package the stable D8.

In Roundearth, we use a bash script to copy the necessary web-accessible files from vendor into /library/civicrm. However, I think this could (and should!) be converted to composer script that could be included in CiviCRM, so that others can easily use it in a composer-based workflow. (It should also be improved to optionally allow symlinking instead of copying, so that platforms/configurations that allow that can save the disk space.)

It is definitely superior to making the whole vendor directory web-accessible, since that is a security risk - one that has bit Drupal over and over again since the release of Drupal 8. And, it does also allow the extern/ scripts to work, but I'm happy to see those being progressively deprecated. :-)

In Roundearth, we use a bash script to copy the necessary web-accessible files from vendor into /library/civicrm. However, I think this could (and should!) be converted to composer script that could be included in CiviCRM, so that others can easily use it in a composer-based workflow. (It should also be improved to optionally allow symlinking instead of copying, so that platforms/configurations that allow that can save the disk space.)

Can we use that bash script in composer as-is?

A script, in Composer's terms, can either be a PHP callback (defined as a static method) or any command-line executable command. Scripts are useful for executing a package's custom code or package-specific commands during the Composer execution process. From: https://getcomposer.org/doc/articles/scripts.md

Can we use that bash script in composer as-is?

Hm, I suppose...

However, I think it'd be better converted to PHP, because then it'll work on any platform that supports composer (including Windows, for example), and doesn't depend on having certain CLI tools installed (ie. rsync which is used by the current script).

So, returning to the original topic of this issue (skipping all the discussion above): I don't know that a tarball release makes sense for Drupal 8 -- CiviCRM needs to be installed via Composer, and there just isn't a clean way around that.

Having a template for composer create-project can help people without an existing site to get started quickly, for example:

https://gitlab.com/roundearth/drupal-civicrm-project

And a composer plugin can help for existing sites:

https://gitlab.com/roundearth/civicrm-composer-plugin

Closing this issue, since it seems indeed unlikely there will ever be tarball releases for Drupal8.

For reference, official install docs: https://docs.civicrm.org/installation/en/latest/drupal8/

closed

Produce CiviCRM-Drupal8 tarballs

Child items ...

Activity