tag widget not working

Thanks for the report. I've reproduced and am working on a fix.

Adding commons release tag.

This bug is another artifact of relying on a serial vocabulary ID set durring install, rather than using Views that filter on a machine name like vocabulary module owner.

I've resolved this issue in a fresh install from github master. We don't want to revert all strongarms set in Commons_core, but the existing variable should continue to be set properly for users upgrading from 1.7

https://github.com/acquia/commons/pull/25

I think the solution should be:
1) Remove variable from strongarm
2) Set the variable on site installation (drupal_commons_config_vars())
3) Set the variable in an update hook (for people upgrading)

The alter approach is more consistent with the fix you preferred for #1071198: Force-setting the "Tags" vid on install causes occasional errors..

Can you provide advantages that support why your proposed approach is more appropriate for this fix?

Those are completely separate. This issue is dealing with variables, and nothing other than variables. Views are very different and my approach to the issue you mentioned in completely necessary. What's the point of providing a variable exported if we're just going to use a hook to alter it. Let's just set it and leave it at that - no additional work needed.

This is exactly how I approached the issue with the User tags variable. It was removed from strongarm and set on site installation.

In my view, the advantage is that by providing a strongarm export, we can still restore the default tagging functionality. We still have the Tagging module as a dependency of commons_core so why not restore its full functionality if it's been overridden?

Why put a variable into strongarm if we're going to just alter it - that doesn't make any sense to me. Having a value for the variable exported that we're just going to change is strange to me.

Use an update hook to just set it based on the commons_tags_vid variable. Do the same on site installation inside drupal_commons_config_vars(). And we're done..

Alright Ezra is right. That does allow for a feature-revert to restore the functionality back to how it comes with Commons.

The pull request has been updated to reflect feedback by Mike in IRC: We should use this this approach for other variables related to the Commons tags vid.

https://github.com/acquia/commons/commit/4d4904484bd17f5ac14b190137cd162...