Currently the location field lives in Commons_Events. Per #1730044: Store location information for users, events and groups in AddressField we need to be able to re-use this field definition.

Comments

Project:Drupal Commons» Commons Events

The first action item here is probably to re-export Commons events.

Project:Commons Events» Drupal Commons
Component:Code» Events

Moving this to the main Drupal Commons issue queue per #1812492: Consider using central issue queue for Commons projects.

Assigned:Unassigned» jpontani

Status:Active» Needs review
StatusFileSize
new1.16 KB

Commons Location project created: http://drupal.org/project/commons_location
Commons Events committed with no field_base for field_address, and added commons location dependency: http://drupalcode.org/project/commons_events.git/commit/2081bf2

Patch for Drupal Commons make file and info file adding Commons Location to the list of contrib is attached.

Status:Needs review» Fixed

"The feature commons_location cannot be enabled because it conflicts with commons_events."

I'm not sure if you're aware of this. This is with Commons dev(Oct15) and from Clocations & Cevents pulled today.

Edit: Commons_Locations has a check mark and looks enabled. I don't see any conflicts listed.

Status:Fixed» Needs work

Looks like Commons Events still defines the base for field_location: http://drupalcode.org/project/commons_events.git/blob/refs/heads/7.x-3.x...

Status:Needs work» Fixed

This should be fixed in the latest commit. It was still declared as part of the feature in the info file (the field_base was).

http://drupalcode.org/project/commons_events.git/commit/22c49c4

Status:Fixed» Needs review

The events module (and some others) still depends on Adress_Field. Is there a way to remove this dependecy. After that it will be less difficult to implement an alternative location module.

Status:Needs review» Fixed

We chose Address field to store locations over at at #1730044: Store location information for users, events and groups in AddressField. While keeping Commons as flexible as possible is a top priority, there are cases where we need to make a choice of approach, and this is one of those choices.

If you wanted to remove this dependency, you can implement hook_system_info_alter(): http://api.drupal.org/api/drupal/modules%21system%21system.api.php/funct....

If you think address_field is not the right choice, please re-open #1730044 with some justifications for that perspective.

My idea is that only commons location should depend on adress_field and the commons modules that nedd adress_field should depend on commons location. In my opinion this will work well for standard commons, but will leave a easy way for my plan to implement an alternative location module.
Maybe a general switch to get_locations_field would be usefull. The geocoding-function would be much better for sites with much data based on locative information.

If Commons Events depends on Commons Location, and Commons Location depends on Addressfield, then inherently Commons Events depends on Addressfield. Without Addressfield, Location can't be enabled, and thus Events can't be enabled.

The only difference here is that Events depends on Addressfield directly. I can remove that dependency from Events, but it is still required for Events to be enabled at all.

I started down this path with my own build.

I had an event type with an entity reference autocomplete field to location.
I used entityconnect to allow the user to add the location node if not already defined or edit it if it was.

I tried to use a modal to popup the location but that did not work primarily because I had added a media field in the location entity.
There is not a solutiont hat works for a modal within a modal
I tried these:
colorbox
ctools_automodal_admin
overlay

just my $.02

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.