The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.The homepage should function smoothly regardless of whether site administrators need to have events functionality. However, currently, it is not possible to disable commons_events because it is listed as a dependency in the commons_site_homepage.info file.
It's listed there because the homepage panel has a pane which loads a view from the commons_events feature. However, removing the dependency and disabling commons_events does not break the homepage other than removing the view from the panel.
I am also working to remove this dependency from commons_user_profile_pages feature, which has the same problem. I posted a general task inside of the 7.3 Commons issue queue as well. http://drupal.org/node/1952434
Patch coming below.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | commons_site_homepage-remove-commons-events-depencency-1952524-1.patch | 452 bytes | sheldonkreger |
Comments
Comment #1
sheldonkreger commentedHere is the patch, which simply removes the dependency from the commons_site_homepage.info file.
Comment #2
ezra-g commentedMoving back to the main Commons issue queue, which we use to track all Commons_* projects.
This is by design. These landing pages contain Views displays that require the modules listed as dependencies. If you don't want to use those features on your site, you have the option to create a custom landing page feature in place of the ones shipped with Commons.
Feel free to re-open with an explanation and alternative if you feel this is not an adequate architecture.
Comment #3
ezra-g commentedDoesn't that leave us with broken Views and/or overridden features? If so, I think this is "by design" per #1.
Comment #4
sheldonkreger commentedI like your thinking. It's much easier to disable the Commons features, build my own landing pages, and then put them in my own feature than to override them and deal with the features override module.
My only concern is that it's probably best to keep each sub-module as compartmentalized as possible, so that disabling them is easy based on the needs of each site. Most of the features in Commons function independently without cross-dependencies; I just happened to notice that this configuration isn't quite as clean.
The only way to really clean this up would be to remove the events views from the panels in question. That would eliminate the need for the dependency, but it would also be a pretty big modification to the homepage and user profile pages. I'm happy to roll a patch that does this if you think it's worthwhile. Regardless, my site is running well and I'm generally pleased with how well Commons 7.x is working for me.
Comment #5
quiethero commentedThis is my 5th iteration with trying to effectively install Commons and Drupal 7.22. (Exhausted) Everytime I try to use it after a few modules are installed I get the same message and cannot get out of it without totally starting the site from scratch. Even my backups don't load.
Also, I found 4 instances of field.info.inc and know that the problem therein lay. Could this be correct?
/public_html/sites/all/modules/commons/modules/field/field.info.inc
/public_html/modules/field/field.info.inc
/public_html/sites/all/modules/commons/profiles/commons/modules/contrib/entity/modules/field.info.inc
/public_html/sites/all/modules/entity/modules/field.info.inc
"Seems like each one of them are declaring something different to each other and the system"
Errors Messages:
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'module' cannot be null: INSERT INTO {role_permission} (rid, permission, module) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array ( [:db_insert_placeholder_0] => 2 [:db_insert_placeholder_1] => create event registration [:db_insert_placeholder_2] => ) in user_role_grant_permissions() (line 3076 of /home/mysite/public_html/modules/user/user.module).
/public_html/sites/all/modules/commons/modules/field/field.info.inc
Fatal error: Cannot redeclare class DrupalQueue in /home/warpro/public_html/modules/system/system.queue.inc on line 60
Line 60
class DrupalQueue {
I would rather use the "new" DC as designed because it looks awesome and has great promise but I am just spinning my wheels from install to install. Right now, my website, all functions, Ctools all green. Not one error on installation.
Now... I am having to load DC via my server because its too large for the 8 MB limit (11 MB) directly to /sites/all/modules and extract there or should I ftp from filezilla or something like that?
I need DCommons but I am stuck at this point. All dressed up "Green Lights on everything" and can't enable Commons. I can load it; but once loaded the damage is done (Those darn complicated dependencies).
Any suggestions?
Comment #6
sheldonkreger commentedQuiethero,
Thanks for jumping in.
Your support request isn't related to the issue I've described here. I suggest starting a new thread if you would like help. It will be much easier for community members to find your problem and give you support that way.
Comment #7
japerryElevating this issue. For sites that do not have events, it should be simple to turn this off and remove the menu item and related panels.
Comment #8
devin carlson commentedI believe that this is no longer an issue as I'm able to disable the Commons Events Pages and Commons Events features (they do not have any dependencies).