Preview doesn't update when editing the value of a field via FAPE

Interesting! When I was working on that other issue, I was able to reproduce your problem. For me, it was showing the preview when first opening the settings dialog, but not updating it when I made any changes. I suspect it would just show "[no preview]" when first adding it. I haven't had a chance to re-test, though!

I think I've narrowed down the issue as I was seeing it (hopefully the same as you). Basically, when are editing the value of a field via FAPE, it won't actually change the preview. Which is why I was always seeing "[no preview]" when first creating a widget and filling in it's value.

This is still an issue. I'm seeing it when customizing a page to change the image style of the Featured Image field.

The problem here seems to be that we aren't updating the settings of the field in a way that the CTools plugin can see those changes when rendering.

Here's a patch that fixes updating the preview when editing the field value, so for example, editing the body field through FAPE. This is what's described in the issue summary here.

However, there's a couple problems:

• This doesn't work on image fields, and in fact, breaks preview for rendered images
• It doesn't fix the problem @cboyden is describing in #6: changes to the field formatter settings (like which image style is being used) are still not reflected in the preview

This patch is a little closer. There's a hack to allow images to render - I tried a bunch of things using the Field API, but couldn't get anything working, which is why I went for the hack which basically special cases on images/files. It still doesn't update the preview based on field formatter settings changes, but it gets a little closer: previously the preview wasn't even actually reloading after changes, and now it is - but strangely the configuration changes don't end up in $form_state['values'] and I'm not sure why.

So, this still needs some more work! And once that's done, this will need piles and piles of testing. :-)

Here's a new patch!

It's a little less hacky, in that it remove the special casing for file/image fields, and instead calls the fields hook_field_load(), which fixes it in the case of file/image fields (and will hopefully allow this to work generally).

And it's got the field formatter settings actually affecting the preview! However, that feels a little hacky (although not super badly) because it's directly looking at $form_state['input'] rather than $form_state['values'].

This will a TON of testing to make sure it doesn't break something somewhere.

Ideally, this would also have some new tests, because we don't want to break this again.

The third chunk of this patch almost-duplicates something from #3030479: Notice: Undefined index: triggering_element in panopoly_magic_form_ctools_entity_field_content_type_formatter_options_alter(). Would it be possible to commit that issue and remove the third chunk here? Updated patch without it is attached.

Sure, I merged the other issue

Here's a patch for panopoly_test that adds steps for FAPE live preview (body field text and image field style) to the existing FAPE test.

The Magic patch is working as expected. I'm able to see changes in Live Preview when editing text in a Body field, and when changing the image style of an image field. For the new tests, they fail without the Magic patch, and pass with it.

Thanks! Here's a Travis build:

https://travis-ci.org/panopoly/panopoly/builds/580391695

The changes in this patch have been making me a little nervous, but after some thought, I think they're gonna be OK. Looking at the 3 hunks in the patch:

Hunks 1 and 2: These are hacks, specifically for dealing with field formatters settings, which I think are weird because it's using a CTools Wizard to make the field formatter settings on a 2nd page. It would be nice to not have to special case for just this particular instance, but this is an important widget, and looking at the code, I think the chance of regression is small.

Hunk 3: This is a totally sensible thing to do (aka not a hack) and it makes a lot of sense, but calling the Field API directly is always kinda weird and easy to get wrong. Hopefully there aren't any fields out there in contrib that won't work with this, but I guess we'll find out. :-) While not a hack, I see this as having a higher chance of a regression.

Anyway, I think the risk here is acceptable, so I'll merge once Travis gets back.

Travis failed because Travis. :-( Here's a new build that should work better:

https://travis-ci.org/panopoly/panopoly/builds/580422954

Tests pass! Committed :-)