Allow Commons Events to be disabled

The intended use of the Panels-based landing pages and the reason they are exported as separate issues is so that you can customize them, re-export into your own site-specific feature module, and disable the Panels pages that ship with Commons.

That way, you can still revert features without worrying about customizations and reduce the amount of enabled functionality on your site if you wish.

I'm actually going to re-open this issue, because I don't think the original question was answered properly.

Many other Commons features can be disabled and Commons rolls with the punches due to the way it integrates these features, example being Polls, if it's enabled, it shows up on the homepage and any other relevant location, if it's disabled it does not.

So the question is, why is Events different? Why can it not be disabled where other features can?

And as far as duplicating features and exporting them into your own modules for any customizations you want made, this drastically reduces the maintainability of your site, because it means when an updated version of Commons comes out that makes feature or security fixes to any of the features you have cloned, you will not necessarily benefit from said changes, and to determine exactly what the specific changes are between the updated version, the old version, and your customized version is a very slow and painful process. Currently I am using Features Override, which is far from perfect, to ensure that any customizations I make are on top of the original features so that I can still benefit from the updates. Not perfect, but more maintainable.

To the issue at hand, I intend to investigate further and see if the hard dependency on this feature can be removed allowing for Events to be disabled.

So it appears really quite simple:

- I couldn't see any reason why commons_events was even a dependency of commons_user_profile_pages, it's not referenced in the feature other than in the .info
- Wrapping the pane in commons_site_homepage and removing the hard dependency allows for an optional dependency, if commons_events is enabled it will show a pane (if it has content), otherwise it will not. Though it will require a fr-all to make the change, but it's a small price to pay, and that's only when/if toggling the commons_events feature, it could probably event be automated.

Patch attached.

Putting a module_exists() in commons_site_homepage.pages_default.inc can be problematic as it requires you to remember that there's some special case code that can easily be overwritten when rebuilding the feature.

I think conditionally altering it into the default page manager pages would be easier to maintain, as is currently done for setting the home page panel title and body . :)

Works for me.

I mean that hypothetically, haven't tested your patch. Any chance of getting an interdiff?

A reroll of #6.

An updated version of #8.

Tested #9 with an existing Commons install by checking to see if Commons Events could be disabled and that the anonymous front page could still be visited without generating any errors. Commons Events could be disabled and the anonymous homepage was simply lacking the "Upcoming events" block.

Also, there were no errors with features displaying as overridden with Events enabled or disabled and Commons Events and Commons Events Pages are both declared in commons.info so they will still be enabled on a fresh install.

Committed #9 to Commons 7.x-3.x.

http://drupalcode.org/project/commons.git/commit/d97ff24