Panels integration

I think the [#nnnnnn] only works for issues,
here is that link to the documentation: http://drupal.org/node/336114

Can location be added to panels 3 context ?

Should I open up another issue for that?

Chris

http://drupal.org/files/issues/location_panels.zip was posted over at the (duplicate) #750894: Integration with Panels

I need something like that, so I'll probably take a look at it now and post my findings here... Stay tuned. ;)

The code is a bit messy (doesn't follow Drupal coding standards, some careless typos and such), but it appears that the basics are there. I'm cleaning it up now, stay tuned...

Okay, this is closer. The previous assumes location CCK (and therefore, I'm not sure why it's even needed -- aren't CCK fields automatically exposed to panels?). Anyway, the attached patch adds a contrib/location_panels folder to the location module which starts to properly expose location data to panels.

At this point, the relationship and location context are tested and working (assuming you're using location, not location_cck). Currently, there's only a single content (pane) type available, the country name of the related location. This either needs:

A) separate content types for each location field

and/or

B) a more complicated location content type that either honors the existing location display settings and/or allows you to customize which location fields you want rendered in the pane

Really, this "needs work", but I'm setting to "needs review" so other location maintainers can take a look, play with it, and provide feedback on the approach.

Thanks,
-Derek

Even closer. ;) Based on some feedback from merlinofchaos, sdboyer, and bdragon, I've done the following since #8:

A) Moved the hook_ctools_plugin_directory() implementation directly into location.module, instead of asking site admins to enable another module if they want this stuff. None of it is loaded unless ctools is looking for plugins, so there's basically 0 cost to non-ctools users and it's a lot easier/better this way for people with ctools.

B) I actually got the whole location_from_node relationship working properly, with both location_node and location_cck. Whoot! ;) It's heavily commented, so it should be pretty obvious from reading it. I think the UI is pretty good, based on the complicated edge cases it has to handle, and I hope the code is clear about what's going on.

C) I punted on the content_type plugin for now. Since ctools has a cool keyword substitution system where each context can advertise its own keywords, you can actually do all kinds of slick/powerful stuff just using a custom content item. For example, on a site I'm building, I made a panel custom content item with the following body:

%location:street
%location:city, %location:province

You can use these tokens to select exactly the fields you need, and you can format them however you want...

We could still create location-specific content type plugins if we wanted, which could either respect the node's settings for how to display location fields and just render as if it was a node_view(), provide checkboxes for which fields to show in that specific pane, and/or provide a text area and the keyword substitution (just like the custom content item does) but perhaps add some value to that in some way (TBD).

But, I actually think this patch is now ready to review for real, and I think it'd be a fine thing to just commit upstream as-is. We don't *have* to decide on the content_type plugin(s) before at least the context and relationship stuff is useful.

@bdragon, should I go ahead and commit this to the end of DRUPAL-6--3? I'm happy to maintain it (since I'll be needing it on the site I'm building, and probably a few others in the near future).

Thanks!
-Derek

Sorry, one minor bug in the previous patch in a *really* obscure edge case. If you save a panel with a variant that uses a location relationship when the site has location_cck enabled, then you disable location_cck and enable location_node, the relationship settings UI was correctly only showing you the location_node stuff, but the relationship was still being saved as if it was using location_cck. Basically, if only one location module is enabled (location_node vs. location_cck), we just need to ignore the current value in $conf['location_type'] and save it with the only active location module as the location_type for the relationship.

I'm signing off on this patch style wise. It has not been tested by me, but the part that modifies existing code is minimal, and it is a new feature. dww will maintain this piece of functionality for the time being.

Committed to HEAD and DRUPAL-6--3. Let's actually just start a separate issue about a fancier content_type plugin that's more user-friendly and doesn't require using keyword substitution..

#803526: Add panels/ctool content_type plugin for easier display of location data for interested parties...

Exciting to see this, something new, and people working together. All around good for moral. Thanks all. :)

Updated file plugins/relationships/location_from_node.inc to Drupal 7.

Notes:

• hardcoded LANGUAGE_NONE.
• "Location CCK field to use for this relationship" now showing the field's machine-name, not the label, since each field would have different labels per entity bundle. Dunno.
• %location:country only prints out "id". :(

#1931088: [META] Fixing tests tests were broken, so triggering to active

bot

#16 commited pushed to 7.x-3.x
this needs follow-ups and testing coverage

Updated issue summary.

Updated issue summary.

Updated issue summary.

fix