I am wondering how best to arrange my instance (or instances?) of Drupal Commons so that I can both (1) create a new site from scratch intended for production launch soon after release of C3.3 and (2) test the latest dev code so that C3.3 is as awesome as possible.

I would prefer to manage a single instance of Drupal Commons, but I am struggling. It seems like patches require me to have local git repos for each relevant project (e.g., Commons Documents, Commons Groups, etc) and those (it seems) sit squarely inside the destination folders where my "drush make" rebuilds go. I am also trying to establish a baseline site DB (i.e., my soon-to-be-production C3.3 site) and I am not sure if it's reasonable to do that and each day (or week) update the code that sits on top of that DB.

Thanks for advice!

(At risk of TMI, here are reasons why I am trying to do all those at once: I am simultaneously (a) creating a brand new community site for my company, (b) planning to use Commons 3.3 for that community site, (c) using Commons 7.x-3.x-dev to create mock-ups for key stakeholders of the new site, (d) establishing baseline Drupal settings/DB for the new site, (e) testing Commons 7.x-3.x-dev, and (f) learning Drupal, drush, and git as fast as I can.)

Comments

ezra-g’s picture

ezra-g commented
Status: Active » Fixed

I agree that it's unnecessarily complex to get a dev snapshot of Commons currently. Until #1983606: Move some of the Commons_* modules into the Commons distro repo is complete, your best bet is to package Commons with

drush make --working-copy build-commons-dev.make

and copy the results of that build over your existing environment.

Feel free to re-open with any further questions or clarifications.

RobKoberg’s picture

RobKoberg commented

@ezra-g, re: #1, that is not really enough. First you are kind of screwed if have changed settings provided in any of the commons features. You can try and revert, but most things don't revert, and even if they do, you lose your changes.

In addition to what ezra-g recommends, after copying profile/commons over your working copy, you probably should do:
* disable your custom features
$ drush cc all
$ drush updb
$ drush cc all

Then revert as many features as you can and reenable your custom features.

I think it would be very useful for the Acquia people to try and build a custom project off of commons, keep it up-to-date with dev, and hopefully use a custom theme (preferably not based on commons_origins).

behoppe333’s picture

behoppe333 commented

thanks @ezra-g and @robkoberg!

I am not deliberately changing settings in any commons features--at least not via the features UI. However, I am creating and customizing rules that are triggered by registering for a commons_event and joining a commons_group. I guess(?) that effectively changes settings of commons features(?) and so I will take a close look at all your advice.

behoppe333’s picture

behoppe333 commented
Status: Fixed » Active

@ezra-g could you please confirm my interpretation of your help in #1

  • I should use some temporary folder to hold results of "drush make --working-copy build-commons-dev.make"
  • Then I copy contents of that temporary folder over my existing environment

At first I tried running "drush make" in the root folder of my existing site (with build destination of ".") but that did not seem to work. Lots of "OK" messages until it complained that "sites/default" folder was not writable and it seems that the whole make process bailed at that point.

Then I tried it using a temporary holding folder and that seems to have worked. I am observing glitches in the updated default theme and am logging those separately -- assume those glitches are not due to some mistake in my site-updating process.

Thanks for your help!

lsolesen’s picture

lsolesen commented
Issue summary: View changes
Status: Active » Fixed

@behoppe333 I hope you solved your problem.

As to the sites/default folder not being writable, you should just make it writable before starting.

But easiest way to getting started, I think is:

$ git clone --branch 7.x-3.x http://git.drupal.org/project/commons.git
$ cd commons
$ drush make --prepare-install --working-copy build-commons.make ../mycommonssite
$ cd ../mycommonssite
$ drush si commons --account-name=admin --account-pass=admin --db-url=mysql://user:pass@host/dbname -y

Then you have your commons distro alive.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.