I've tried this a few different ways and this feels the cleanest thus far. Entity_field.inc content_type plugin needs to be able to set a view_mode when it's rendering. We still retain the ability to set custom overrides, but we aren't forced to always use it that way.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

merlinofchaos’s picture

Status: Needs review » Needs work

Ok, I'm going to needs work this for a couple of reasons.

1) One of the things that needs to happen is that entity contexts that can run a view process need to have an option to do so, so that we can make sure _view hooks get run in a sane manner.

2) In so doing, that means they'll need a view mode.

3) If we do that, the context itself will probably be caching field results and we'll need to pull data from that, which is good.

4) If we then want to render in a different view mode (or if the context didn't perform a view) THEN we'll use a custom solution.

That's a pretty big piece of work, though, but I think that's the direction this needs to go.

deggertsen’s picture

I updated the patch to apply to the most recent dev. I think I did everything right. There were a few minor changes I had to make to the patch due to changes since the initial patch was created.

With this patch what I'm trying to accomplish (defined in #1182712: Page Manager Integration (postponed pending a ctools patch)) is now working perfectly.

Thanks!

EclipseGc’s picture

Status: Needs work » Needs review
deggertsen’s picture

Rerolled patch against most recent dev. Fixed some whitespace errors.

I've now been using this on 2 production sites for a month now with great results. I guess we're just waiting for others to review the patch now...

deggertsen’s picture

Still needs tests

maxplus’s picture

Hi deggertsen,

are you using Panels in combination with Commerce on production sites?

I'm still facing the problem of losing my Product image when changing an attribute in the add to cart form.

When I use the specific product image field from the Commerce_product entity category, it keeps displaying the image of the first product variation and does not change with ajax when changing the attribute.

I have also looked at this thread: https://drupal.org/node/1182712 but there is not a real answer...

mglaman’s picture

Status: Needs review » Reviewed & tested by the community

Using this for a Panopoly + Commerce distro, product variations display properly when changing the options in the Add to Cart form.

deggertsen’s picture

FileSize
41.19 KB

@maxplus. I am using this on several production sites with success. In face this is a blocker for me updating to newer versions of ctools. Every time I update I have to reapply this patch.

Based on your screenshots I'm not seeing the "Product fields from entity" option that you should be seeing. Perhaps the patches didn't get applied correctly or you need to flush your caches? You may be the first one trying this on a non-english site as well which might be something.

Here's a screenshot of what it should look like.

maxplus’s picture

@deggertsen
I have found my problem: there seems to be an issue if a field is rendered twice on the same page. I had a product image on top of my page and when I had the same product rendered inside a carousel on the bottom of the page, my product image field disappeared when switching the product attribute in the add to cart form...

When I removed the "duplicate" rendered node on the bottom of the screen, switching the product attribute in the add to cart form perfectly loads the other product image.

Problem solved!

deggertsen’s picture

Seeking maintainer review... Patch #4 still applies perfectly to current dev.

japerry’s picture

Status: Reviewed & tested by the community » Postponed

I talked with EclipseGc about this issue. In short, its not trivial. While your use of the current patch may work with your use case, ctools is pretty stable in its current form and this patch does not address the issues Earl brought up in #1.

While its possible to fix this issue, the whole context pipeline would need to be re-written. Efforts instead are being focused on d8 and this feature will end up there instead.

Feel free to keep using this patch, but it'll most likely not make it into a d7 release. Marking postponed until we see a fully worked out patch (or patches) that is backported from d8.

deggertsen’s picture

@japerry, thanks for the info.

deggertsen’s picture

FileSize
5.39 KB

Updated the patch for the most recent dev.

joelpittet’s picture

Thanks for the re-roll. Couple of notes on the patch:

  1. +++ b/plugins/content_types/entity_context/entity_field.inc
    @@ -173,8 +185,22 @@ function ctools_entity_field_content_type_formatter_options($form, &$form_state)
    +  $modes = array();
    

    This initialization isn't needed.

  2. +++ b/plugins/content_types/entity_context/entity_field.inc
    @@ -199,12 +230,18 @@ function ctools_entity_field_content_type_formatter_options($form, &$form_state)
    +	'#states' => array(
    
    @@ -217,27 +254,34 @@ function ctools_entity_field_content_type_formatter_styles($form, &$form_state)
    +	$subtype = $form_state['subtype_name'];
    

    Looks like there is a tab by accident in here. Should be 2 space tabs.

  3. +++ b/plugins/content_types/entity_context/entity_field.inc
    @@ -217,27 +254,34 @@ function ctools_entity_field_content_type_formatter_styles($form, &$form_state)
    -    if (!empty($info['settings'])) {
    -      foreach ($info['settings'] as $field_name => $value) {
    -        if (isset($form_state['values'][$field_name])) {
    -          $form_state['conf']['formatter_settings'][$field_name] = $form_state['values'][$field_name];
    +  if ($form_state['conf']['view_mode'] == 'ctools_custom') {
    +    $fields = $form_state['values']['ctools_field_list'];
    +    $formatter_info = ctools_fields_get_field_formatter_info($fields);
    

    This may be easier to see if the if was just an earlier return instead of nesting further?

deggertsen’s picture

@joelpittet I've updated the patch with your suggestions; however, I'm hoping you can just check to make sure I did the last part right with the return instead of nesting. I'm still a php novice (I can read it, but I have a hard time writing it!).

joelpittet’s picture

Thanks for attempting the fixes @deggertsen. A couple of things still to try to explain what I was getting at:

  1. +++ b/plugins/content_types/entity_context/entity_field.inc
    @@ -209,12 +239,18 @@ function ctools_entity_field_content_type_formatter_options($form, &$form_state)
         '#default_value' => $conf['formatter'],
    +	'#states' => array(
    +      'visible' => array(
    +        ':input[name="view_mode"]' => array('value' => 'ctools_custom'),
    

    Must have missed this errant tab as well. It should align with the #default_value key but with spaces. (I'm reviewing with dreditor.org extension btw)

  2. +++ b/plugins/content_types/entity_context/entity_field.inc
    @@ -227,20 +263,28 @@ function ctools_entity_field_content_type_formatter_styles($form, &$form_state)
    +  if ($conf['view_mode'] == 'ctools_custom') {
    

    I was thinking more like

    if ($conf['view_mode'] == 'ctools_custom') {
      return $form;
    }
    

    That was you don't have to indent things and it's a smaller patch and easier to see mistakes weren't made outside the hunks.

Also interdiffs are nice when making changes, it's easier to focus on the changes instead of re-reading the whole patch. @see https://www.drupal.org/documentation/git/interdiff

deggertsen’s picture

Thanks for teaching me @joelpittet. I'll try to get another patch out with an interdiff =).

deggertsen’s picture

Alright, here's my first attempt at an interdiff. However, I didn't really understand #2 in your comment #16 (or #3 in #14 for that matter). To clarify my misunderstanding better, It seems to me that there needs to be all of the nested information rather than simply returning the form or it wouldn't load everything correctly for the view mode would it? In all honesty, I don't fully understand the patch and have not taken the time to understand it fully. It was originally written by @EclipseGc and I have mostly been simply updating it so it would work with the most recent dev...