Unable to utilise new fields with post entity

I've just given this a test and I can't replicate. What I'd recommend you do is something very basic on simplytest.me, this will rule out outside factors such as other modules and server setup.

To explain what I've did to check this.

Spin up simplytest.me with harmony_core, default permission sub module, devel and regular stuff like admin menu, field_ui etc.

When ready I went to:
admin/harmony/structure/post/fields

Added a field, checkbox titled "quack", then went to create a new thread at:
thread/add

I can see the new field present, I check it. Once on the new thread I determine the post ID my hovering over a like link (if editing the first post in a thread harmony will instead force you to edit the thread instead), if starting from scratch this will be 1.

Following that navigate to:
post/1/devel

Here you'll get to see the new field is present and has a value.

Thanks for the quick response on this one - I've done a little more investigation into this and the issue is specifically with fields that make ajax calls.

Try recreating the issue with the following steps:
- Install Drupal 7.41 and Harmony alpha 6
- Add a standard image field to the post entity and display mode (just so you can see it)
- As an admin create a new thread and upload an image and it works
- As an authenticated user create a new post
- Select an image and hit the upload button

After hitting upload the create post form is displayed with the image field completely missing - see the attached for the steps.

Inspecting the ajax calls, it looks like the return value from Drupal is incorrect - possibly because the post entity form does not fully support the Ajax methods.

I think this is the underlying cause for why other Ajax fields - e.g. paragraphs work on threads but not on posts.

Any ideas on why threads and posts might be behaving differently re: Ajax?

Hey Rich, good to hear from you. After a quick look an image field works fine on the thread form (where the post form is embedded via inline_entity_form), but the reply/standalone post form fails as you've described. I don't have time right now to get in to this but after a quick Google found the following.

I expect we need to make sure that the field_attach_form stuff is working when ajax is a factor, build info is something I've not heard of but gut feeling is that could be a direction to go in:

https://www.drupal.org/node/1118114#comment-4575298
https://www.drupal.org/node/1336212
http://drupal.stackexchange.com/questions/18618/cant-use-file-field-in-c...

My test gave the following as an error
"Notice: Undefined index: field_image in file_ajax_upload() (line 271 of /var/www/harmony/6/modules/file/file.module)."
Location: http://xxxxxx/file/ajax/field_image/und/0/form-u8-Hj96Q5vCg4Eh_JWMQ5f8Wq...

Hey Alli,

With a bit more investigation we've found the cause of this issue. The bail out logic in harmony_core_post_form was being fired when a field in the form makes an Ajax callback and hence returned the bailout message to the parent form.

Here's a quick and dirty patch that solves this issue with a simple check for if we're loading a form using Ajax.

Would it be better to move the bail out logic to an access callback (in $items['post/add']) so it's fired before we start to build the form?

Cheers

Rich

Nice one guys, thanks! I tweaked it slightly and added a watchdog call. The post form was upset about it not being able to work out a thread id.

Alpha7 now contains this fix.