CiviCRM Community Forums (archive)

Hi,
most of Drupal's contrib modules are hosted on drupal.org, and can be downloaded with "drush dl".
This is not the case for CiviCRM, for several reasons: License being one of them.
CiviCRM is not the only Drupal module that requires to download code from a 3rd party site. Other examples are various jquery plugin integrations, htmlpurifier, textile, etc.

The common practice in Drupal for modules with 3rd party code is like this:
- The Drupal integration is hosted on drupal.org, and will be downloaded to sites/all/modules/contrib/$modulename/*.
- The module requires the 3rd party code to be downloaded to sites/all/libraries/$name/*. Otherwise, it will either not install, or it will complain.

To make this work, we should use the libraries module:
http://drupal.org/project/libraries
(the module page does contain some useful links for further reading)

---------

For civicrm this would mean:
sites/all/modules/contrib/civicrm, or sites/all/modules/civicrm for the drupal integration, under GPL, downloaded from drupal.org.
sites/all/libraries/civicrm for the library, downloaded from civicrm.org, under the civicrm license (whatever that currently is)

In theory, any folders and subfolders within the sites/all/modules/* can contain module info files or Drupal template files.
For instance, there could be a module info file in
sites/all/modules/contrib/civicrm/x/y/z/civicrm_foo.info

Every now and then, Drupal needs to scan all these directories and subfolders to find these submodules (that is, a module in a project subfolder), and template files.
Having a huge directory tree such as civicrm inside the modules folders does add up to the cost of such a scan.

Whether this problem will still exist in Drupal 8, we do not know yet.

---

Btw, one nice idea would be to integrate a downloader into the civicrm contrib package. For instance, with "drush civicrm-download", one could download the rest of the civicrm code.

For priorities, I fully understand if there is more important stuff to do!
This one is probably not too difficult, so maybe still a good ratio of hours / impact. However, there will be some significant noise in version control.

---------

1. Just one download?
With the original idea, we'd have two downloads. That is one more than we used to have.. Also, there would be two code repositories to maintain, instead of just one.
Whether that is a huge problem, is up for discussion.
There are some alternatives we could consider, if we want to stick with one download only.

2. Easy install process
From what I remember, the most annoying part of setting up CiviCRM was to configure the civicrm.settings.php. There was a few absolute paths and urls to set up, which should rather be determined automatically. Also, there are Joomla details, that we don't need to care about in a Drupal context. Better to have separate template settings files for Drupal and Joomla.
Compared to that, the download thing is probably a minor issue. Drupal site builders are used to having to download 3rd party stuff for some modules.
Whether the suggested move into sites/all/libraries does make install easier or harder, is up to discuss.

3. Not everyone uses drush
I would assume that very few people dare to run Drupal + CiviCRM on a cheap host with no commandline. So, most people probably do have drush, or can get it.
Still, this is a valid argument.
However, people who do not use drush are used to having to download and upload stuff manually - be it drupal contrib modules or 3rd party libraries. There could be an alternative downloader via the web ui, but that would probably create problems with file permissions - suddenly all of civicrm library would be owned by http-user.

------------

Conclusion:
- There is a price to pay: One more thing to download / upload. Drush users are luckier than those w/o drush, but it is still one more step to take.
- That said, the downloading is probably not the most difficult part of CiviCRM installation
- One benefit is to avoid unnecessary scandir()
- Another supposed benefit is to conform with Drupal common practice (whatever that would give us)
- Another supposed benefit is to be present on drupal.org with a real download (whatever that would give us)
- Whether there are other benefits, I need to think more about.

------------

The alternative I was talking about:
As an intermediate step, we could do this:
- like today, you can upload the entire thing to sites/all/modules/civicrm or sites/all/modules/contrib/civicrm, and it will just work.
- alternatively, you can upload the full thing to sites/all/libraries/civicrm, and then symlink from sites/all/modules/contrib/civicrm to sites/all/libraries/civicrm/drupal, so that only the drupal module would be under sites/all/modules.

Maybe this does already work today. If not, it is probably only a few hardcoded php or js/css/img paths, that need to be more dynamic about the location of civicrm root.

This is something we can slowly work towards, without breaking anything.

Ok, I see your point, and I am absolutely ok with it
I started the thread because I noticed that CiviCRM does behave differently than other Drupal modules. Whether there are other benefits of this, I will let you know when I can think of some
If the suggested change does make things more difficult, then let's drop it, np.

I think, for other modules with 3rd party libraries, the benefit of putting the 3rd party in a separate download is:
- separate version history for the module and the 3rd party library
- separate maintainer and download location for the 3rd party. Very often, the maintainers of the 3rd party library know nothing about the Drupal integration, and the maintainers of the Drupal module are not involved in development of the 3rd party library. This is very different for CiviCRM.

This said..
what about the smaller version of this? (two posts above, with the symlink from sites/all/modules/contrib/civicrm to sites/all/libraries/civicrm/drupal)
Maybe I am going to try this when I have time.

Hi,

The main benefits for everyone I could see is
1) being able to use drush dl civicrm/drush en civicrm
2) using the "normal" drupal update feature to inform about a new version

And for devs, potentially making it easier to get a d6 version on svn

This being said, if it involves downloading separately and so on, probably not worthwhile indeed.

X+

After rethinking this, here are the main reasons for a move like this:

1) Make the CiviCRM version independent of Drupal core version.

This would mean:
- One could upgrade civicrm to the most recent version, while still sitting on Drupal 6.
- One could upgrade Drupal 6 to Drupal 7, but leave CiviCRM as it is.
- CiviCRM development need not be targeted at a specific Drupal core version.

Whether this is desirable, is to be discussed.
Whether we do the same for Joomla and WordPress, can be decided independently.

2) Avoid scandir() for Drupal module *.info files, when flushing the cache. (minor issue)

EDIT:
3) Use the same instance of CiviCRM from different host applications.
E.g. have one D6 install, one D7 install, one Symfony install, one WordPress install, all using the same civicrm codebase + database (with symlinks, maybe)
Not sure whether the sites/all/libraries move is actually necessary for this.. it certainly is for the D6 / D7 split.