Force-setting the "Tags" vid on install causes occasional errors.

I'm not sure how for down the road you are with your Aegir installation, but the Aegir Barracuda-Octopus distribution comes with the latest version of Commons (as well as about 8 other Drupal distributions) pre-installed and works like a charm. Really, it is an extraordinary package.

I'm not sure when you were trying it, but I know there were some DC-specific issues around 1.3 or 1.2, I think. They have been resolved now, however. I use it on linode and, from a clean ubuntu install, it's literally a matter of changing a few lines in the barracuda and octopus scripts and you're off and running in two commands.

I can confirm that this is a problem with commons 1.5.

The hack solution is to change line 5 of profiles/drupal_commons/drupal_commons.profile from
define('DRUPAL_COMMONS_TAG_ID', 2); to define('DRUPAL_COMMONS_TAG_ID', 10);

The proper fix would involve only defining the constant after the free tagging vocab is created. Something similar to this around line 420 of profiles/drupal_commons/drupal_commons.profile should work:

if (SAVED_NEW === taxonomy_save_vocabulary($vocab)) {
  define('DRUPAL_COMMONS_TAG_ID', $vocab->vid);
}
else {
  // fatal error handler here
}

I would submit a patch, but I don't have time to prepare and test my proposed fix.

Can this be fixed in the git repository? Some people want to run multiple drupal commons sites.

The problem is, to the best of my knowledge, there is no (good) way to have Views use a vocabulary machine name, rather than an ID. All of the views in Commons have been exported with a certain vocabulary ID to point to the Tags vocabulary (2).

Open another ticket if you'd like to discuss this or suggest a viable alternative.

This hits one of the limitations of D6, which has already been solved in D7 - machine names being assigned to vocabs. In the mean time we must acknowledge that this is still a problem in D6. I doubt, backporting machine names for vocabularies is unlikely to happen in D6 core, even though it is available in D7, so it should be resolved in the installation profile.

This specific bug isn't triggered in views it is triggered when trying to install commons using Aegir. I think that the bug belongs in the commons queue.

It should be possible in the installation profile to create the vocab, capture the vid and store it in {variable}. A $GLOBALS hack should work for the installation profile, while the module can define the constant using the variable_get().

Why does an ID of 10 work, but 2 doesn't?

Because vid of 2 is already "claimed" and so it triggers a conflict. It is also a bad idea to manipulate primary keys, especially if you want to have any hope of supporting MMM. I also seem to recall that pgsql doesn't like it either, but don't quote me on that my postgres skills are fairly weak.

For the record, I wasn't advocating changing the value to 10, that was just a hack around. The real fix is to implement my proposal at #7. I'd do it, but I don't have time to make it happen any time soon. I'm also a bit over having to fix (almost) every Commons release because no one at Acquia could be bothered to run a test deployment or migration with Aegir before shipping it.

I still don't see that being a viable alternative. Method aside, think of the numerous amounts of existing Commons sites. If we shipped with all new views which used a primary key for the vocab or 10 (or whatever), we'd have to change their tags vocabulary to key 10, force-revert all the views. It's just a mess..

The key manipulation, since it only happens on a clean installation, seems harmless to me. I wasn't aware of any aegir issues, since I've never used it before. How is key 2 already in use?

I was able to install 1.6 from the download in aegir 1.1 successfully.

However there were these notices/errors that did not stop installation:

Missing argument 1 for drupal_commons_theme_form(), called in /media/data/aegir/platforms/drupal_commons-6-x-1-6/profiles/drupal_commons/includes/drush.inc on line 43 and defined in /media/data/aegir/platforms/drupal_commons-6-x-1-6/profiles/drupal_commons/includes/form.inc on line 219.
Missing argument 2 for drupal_commons_theme_form(), called in /media/data/aegir/platforms/drupal_commons-6-x-1-6/profiles/drupal_commons/includes/drush.inc on line 43 and defined in /media/data/aegir/platforms/drupal_commons-6-x-1-6/profiles/drupal_commons/includes/form.inc on line 219.

I've tested the install on the latest version of AEgir and Commons, and everything works fine.

Marking this as "major" per batsonjay.

Cash, did you test how none of the taxonomy filters in any of the views work if the Tags vocab isn't set to 2?

I don't see how vid 2 is in use before the function is called to take that slot (it's ran before almost all else).

http://drupal.org/node/1071198#comment-4514454

We're experiencing an issue similar to this now, but changing the vid isn't a fix. I think something has to be done to update the vocabulary table that vid 2 is now being used; since it's a serial table.

Marking this as 2.0, but changing the title.

On some environments, duplicate key errors are reporting during install.

Removed need to force-set any vocabulary ids. We now store the "tags" vocab id in a variable, and use hook_views_default_views_alter() to inject it, where it's needed.

https://github.com/acquia/commons/commit/73d73d2c4c914cc2198c3cbb7954be7...