Anyone successfully install commons and Atrium on separate sub-domains?
I have a client site for which I want to install Commons on one subdomain and Atrium on another sub-domain. I am considering my options. When I tested installing Atrium all I had to do was add the profile folder into the profiles of the main site (which is a plain Drupal 6.15 on PHP 5.2.8).
When I tried just adding the commons profile folder and creating the sub-domain within the sites folder (with the settings.php file as well), I got an error that atrium.profile was already setting the system hook form alter. So, I removed the Atrium profile file temporarily, which seemed to solve the conflict (since commons.profile also includes the form overrides for adding timezone during install).
Next, I thought I was home free. Not so. I installed as usual. The process kept hanging after installing all of the modules and just before moving to configuration. I have installed Commons successfully before. So, this perplexed me. Here is what I get:
Fatal error: Class 'flag_flag' not found in/home/dominic/public_html/tephinet/profiles/drupal_commons/modules/contrib/heartbeat/modules/flag_heartbeat/class.flag_heartbeat_message.inc on line 12
I tried the heartbeat module issues queue and replacing the older heartbeat module included with Commons with the newest. No luck there. Any ideas? The path seems to be resolving. The class is actually on line 12 in the code. The path does resolve exactly to the file. The mem limit is 128M. The timeout is not being reached.
Any help is appreciated!
Poll
Latest discussions
-
30 Oct 2011 - 09:17 by yeeloon
-
12 Sep 2011 - 09:50 by anandyrh
3 comment(s)
- 1 of 109
- ››
Latest discussion comments
-
Eleanor
-
aronhally84112ws
-
mykarizma
-
onion
-
meredith
- 1 of 127
- ››
Recent content
Group members (244)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Comments
My two-penneth
I thought about doing it this way, but in the end opted for installing on sub-domains, but in entirely separate folders: i.e. each distribution its own Drupal instal. The advantage is when these distribution upgrade, it is relatively easy to do, partic, with Drush.
Not the help you were looking for, but my two-penneth / cents
Yep, I considered that too - Problem is cookie domain, right?
SO, I did think about doing that way. The problem I ended up having was with clean URLs and the cookie domain. If I put the whole code into the sub-folder and allowed it its own index.php I ran into either I can get the cookie domain working or I can get clean URLs working. Without the cookie domain, Bakery SSO is broken. Without clean URLs, the usability went down.
Were you using Bakery SSO? Were you using multisite? Did you get shared user accounts and profile data working in the setup you used?
Mmmm…
I'm not sure about all that you're referring to. I've got an Atrium intranet in one folder (intranet)—intranet.domain.org.uk—Drupal commons in another folder (commons)—domain.org.uk. At present, I've not tried Bakery, but assumed I would be able to when ready. I do have clean URL's on all. I use shared hosting and CPanel to set it all up.
The challenge is getting them to share a single code base
So the question is really whether you have them as sub-domains within one Drupal codebase as separate folders within the sites folder or whether you have them as totally separate installs?
Semantics?
I have separate installs…separate folders…
I am using the term sub-domain in reference to sub.domain.org etc., not to refer to a sub-site within a drupal multi-site.
The problem with shared code bases is that when one distribution is updated, it impacts upon the other distribution and can cause complications if that distro is not ready to work with an updated module.
True... semantics.
Indeed, fine points of difference in meaning. I have commons running with bakery 6 Aplha 2 on subdomains setup as separate installs with URL aliasing working. The challenge I ran into is fixing the initial profile setup that caused inability to have more than onr profile in a shared code base. It seems to me that the commons .profile file actually needs to check for the timezone correction prior to firing the form alter hook. That way it would not conflict with Atrium or some other install. I am not sure this would be a global fix, particularly if some other profile actually had a timezone addition that did not do the same things. But, if we can imagine a site such as Drupal Gardens in which we can allow people to create new sub-sites drawing on a library of profiles, we will need to be able to have a library of profiles work together in the same code base. See what I mean?
Just a thought
Just a thought, but have you tried moving the distros' modules/contrib modules into the shared sites/all/modules folder and then installing that way? I wonder if that would help.
Okay…a little over my
Okay…a little over my head! I haven't really got my head around the .profile aspect of distro's. I've simply downloaded or drush-ed them and set them up separately. I do see your point: it should be workable, but I think I'm not qualified to advise on the finer points of your issue—sorry! Hope my comments haven't been an entirely red herring for you!?
No problem.
No problem. I think this sort of application (like Drupal Gardens) will become more common, and people will need to be able to have multiple installation profiles available within a single codebase. Thus, there appears to be an architectural problem with the way hook handling is done in profile installation. Now that we have had the discussion, perhaps it will help going forward once a few more people run into the same problem (of course one problem here is that our discussion is not on Drupal.org and may not be found by those who need to find it).