Publisher does not support the Fluid field type. Please do not contact asking when support will be available.

If you purchased an add-on from expressionengine.com, be sure to visit boldminded.com/claim to add the license to your account here on boldminded.com.

Ticket: Relationships within grids not being saved on publish

Status	Resolved
Add-on / Version	Publisher Lite 2.8.3
Severity
EE Version	3.5.10

Oliver Jackson

Jul 17, 2018

Description:
Hi there, we are having issues with relationship fields within grid fields. When saving as a draft, relationships within grid fields and as standard fields seem to save as expected, but when saving as published, the relationship fields within the grid fields reset with no stored related items. The standard relationship fields on the same entry do seem to save, however.

Detailed steps to reproduce the issue:
1. Create a channel with two extra fields: 1 relationship field, and 1 grid field with at least one relationship field within it.
2. Edit an entry within that channel, creating a relationship in both relationship fields.
3. Save as a draft - note that both related entries persist
4. Safe as published - note that only the non-grid relationship persists.

We can replicate this behaviour reliably on our dev site so feel free to test the entry with id: 8039 (Testing Publisher)

BoldMinded (Brian)

Is the relationship field or channel itself ignored?

BoldMinded (Brian)

Comment has been marked private.

Oliver Jackson

> Is the relationship field or channel itself ignored?

Hi Brian - not sure what you mean by this. Possibly superseded by next comment anyway?

> Try this build https://www.dropbox.com/s/e8w0noui0ewg0kn/publisher2-283-lite-3a9bb2b5.zip?dl=0

Will do, and we’ll let you know.

Oliver Jackson

Hi Brian - We’ve replaced the version we had with the one you’ve supplied (now saying version 2.8.3 build 3a9bb2b5). Unfortunately it doesn’t seem to have helped.

Furthermore, it appears that the grid relationships are now clearing regardless of whether Draft or Published is selected on save. (Which is possibly good because it’s at least consistent now!)

BoldMinded (Brian)

I’ll try to replicate locally first, but it may not be until Thursday.

BoldMinded (Brian)

What build number did you originally have before I sent the new one?

BoldMinded (Brian)

I’m going to need admin access to the CP, right now I can’t see Publisher’s settings, and I’ll need to be able to look at the database tables.

BoldMinded (Brian)

I can see some oddities happen in my local environment, but it seems to be a specific pattern. Saving as Published seems to work fine, but saving as Draft is when it goes wonky. My schedule for the next few days is very busy… I’m not sure when I’ll be able to deliver a fix for this… maybe by Friday, or maybe middle to end of next week.

Oliver Jackson

Comment has been marked private.

#10

Oliver Jackson

> I can see some oddities happen in my local environment, but it seems to be a specific pattern. Saving as Published seems to work fine, but saving as Draft is when it goes wonky. My schedule for the next few days is very busy… I’m not sure when I’ll be able to deliver a fix for this… maybe by Friday, or maybe middle to end of next week.

Ok, great - well just let us know when and/or if you manage to figure this one out. Thanks for your help so far!

#11

BoldMinded (Brian)

I need elevated admin permissions in the CP, when I look at the DB I need to look to see how the tables are updated in real time when saving an entry.

#12

Oliver Jackson

It’s unlikely I’ll be able to get you DB access in a timely manner, but if you are able to replicate some of this behaviour locally anyway could you try basing the fix on your replicated behaviour first and if we need to go down that road we can try sorting out another environment next week?

Either that or you could potentially use the SQL I’ve sent you to create a new instance?

I’ve given the admin group access to Publisher — let me know if that suffices.

#13

BoldMinded (Brian)

I dno’t need direct DB access, I’m referring to the DB viewer in EE’s admin that is only accessible if you’re an admin user with full CP access.

#14

BoldMinded (Brian)

Can you do me a favor and open the publisher/Service/Field/Type/RelationshipType.php, and on line 34 change the following:

$entryId = $entry->getId();

$entryId = $entry->entry_id;

See if that fixes the issue.

#15

Oliver Jackson

> I dno’t need direct DB access, I’m referring to the DB viewer in EE’s admin that is only accessible if you’re an admin user with full CP access.

No problem - have updated your member group to super admin

> Can you do me a favor and open the publisher/Service/Field/Type/RelationshipType.php, and on line 34 change the following:

Will let you know when my colleague has made the change

#16

Oliver Jackson

Developer has made the change - relationships within grid and non-grid both persist when saving as a draft, but relationships within grids are failing to persist on publish. (i.e. the original behaviour as reported).

#17

BoldMinded (Brian)

Did you try this on a new entry with fresh Grid rows or are you editing the existing entry?

#18

BoldMinded (Brian)

After I made that change I’m unable to replicate the issue, Rels seem to be saving fine, regardless of the direction (draft->published, published->draft), number of grid rows, or number of relationships assigned to each row.

#19

Oliver Jackson

> Did you try this on a new entry with fresh Grid rows or are you editing the existing entry?

This was an existing entry. I’ll get the dev to try a brand new entry and report back.

#20

Oliver Jackson

The entry retains its relationships on save as draft, but when being published, they are lost.

It may also be worth noting that the relationships don’t seem to actually be getting lost on the front end, but are simply not recalled correctly when reloading the edit page. This appears to be the case whether “save” or “save and close” are clicked.

#21

BoldMinded (Brian)

Yeah, I’m just not able to replicate that anymore. Are you sure the change I suggested in comment #14 is still in place? I can save as draft, then open, then draft, then back to open and all the relationships are still intact. Is your team able to make a video of this happening?

https://www.dropbox.com/s/fuwa2m42p2xa9kz/Screenshot 2018-07-19 15.33.13.png?dl=0

This is the field setup I have in place to replicate it. They all save fine.

https://screenshots.firefox.com/7OGcZXipKaE4N455/ee400.vm

#22

BoldMinded (Brian)

I just tested in a different environment on a different computer and the relationships still saved fine. Please see my previous comments about ensuring that fix is in place and providing a video screencast of the issue as you’re experiencing it.

#23

Oliver Jackson

Thanks Brian, will have a dev look into this when they can and get back to you.

#24

Oliver Jackson

Comment has been marked private.

#25

BoldMinded (Brian)

What happens if you only have 1 Grid field on the page (create a new channel and assign only 1 Grid field to it) and added multiple rows to it, each with a Relationship field?

#26

Oliver Jackson

Same issue unfortunately. I created a new channel with a new field group, yet the relationships are disappearing when published.

Interestingly, if I then re-populate the grid with different entries and save as draft, then select ‘View (Published)’, the previously published relationships are displayed.

#27

Oliver Jackson

Comment has been marked private.

#28

BoldMinded (Brian)

I will try to replicate this again in a day or two. I have family visiting so my time is limited right now. In the mean time, if you have an EE4 license, try installing Publisher in it and replicating the issue. Usually this sort of issue isn’t EE version specific, but I’d like to see if this may be one of those cases.

#29

BoldMinded (Brian)

Have you tried creating a fresh EE environment (EE3 or EE4) with only Publisher and Bloqs installed to see if you an replicate the issue there?

#30

BoldMinded (Brian)

I just tried to replicate this in a 3rd environment and I’m not able to. Before I spend more time looking into this I’ll need you to create that fresh EE environment and replicate the issue there. If you can’t replicate it in a fresh environment, then at least we can say definitively its something with your existing environment and not a general bug, and go from there.

#31

Oliver Jackson

Hi Brian,

I have now installed Publisher in a fresh EE3 environment with a couple of the other add-ons I was using that may have affected it in some way (publisher low-search and low-search), though have also been unable to replicate the problem.

#32

Sears Davies

The fix at #14 worked for me but I did have to uninstall/reinstall the module before the problem was solved.

#33

BoldMinded (Brian)

The uninstall/reinstall was probably the deciding factor. Do you have a copy of your exp_extensions table before the uninstall to compare it to the reinstall? I wonder if a hook didn’t get registered correctly.

#34

Oliver Jackson

Uninstalling/reinstalling the module has also rectified our issue, thanks Behzad.

When comparing the exp_extensions tables, the only difference appears to be that the fresh install does not have the following rows:

entry_submission_absolute_end 
entry_submission_end 
entry_submission_start

#35

Sears Davies

Herere all the relevant entries from our exp_extensions table :

31, Publisher_ext, sessions_start, sessions_start, , 1, 2.7.3, y, 32, Publisher_ext, core_boot, core_boot, , 1, 2.7.3, y, 33, Publisher_ext, entry_submission_end, entry_submission_end, , 5, 2.7.3, y, 34, Publisher_ext, entry_submission_absolute_end, entry_submission_absolute_end, , 10, 2.7.3, y, 35, Publisher_ext, entry_submission_start, entry_submission_start, , 5, 2.7.3, y, 36, Publisher_ext, custom_field_modify_data, custom_field_modify_data, , 5, 2.7.3, y, 37, Publisher_ext, channel_form_entry_form_tagdata_start, channel_form_entry_form_tagdata_start, , 5, 2.7.3, y, 38, Publisher_ext, channel_form_entry_form_tagdata_end, channel_form_entry_form_tagdata_end, , 5, 2.7.3, y, 39, Publisher_ext, publish_form_entry_data, publish_form_entry_data, , 5, 2.7.3, y, 40, Publisher_ext, channel_entries_query_result, channel_entries_query_result, , 5, 2.7.3, y, 41, Publisher_ext, channel_search_modify_search_query, channel_search_modify_search_query, , 5, 2.7.3, y, 42, Publisher_ext, channel_search_modify_result_query, channel_search_modify_result_query, , 5, 2.7.3, y, 43, Publisher_ext, channel_entries_tagdata_end, channel_entries_tagdata_end, , 5, 2.7.3, y, 44, Publisher_ext, channel_module_categories_start, channel_module_categories_start, , 5, 2.7.3, y, 45, Publisher_ext, channel_module_category_heading_start, channel_module_category_heading_start, , 5, 2.7.3, y, 46, Publisher_ext, core_template_route, core_template_route, , 11, 2.7.3, y, 47, Publisher_ext, cp_custom_menu, cp_custom_menu, , 5, 2.7.3, y, 48, Publisher_ext, cp_js_end, cp_js_end, , 5, 2.7.3, y, 49, Publisher_ext, cp_member_login, cp_member_login, , 5, 2.7.3, y, 50, Publisher_ext, channel_entries_tagdata, channel_entries_tagdata, , 5, 2.7.3, y, 51, Publisher_ext, template_post_parse, template_post_parse, , 5, 2.7.3, y, 52, Publisher_ext, email_send, email_send, , 5, 2.7.3, y, 53, Publisher_ext, relationships_query, relationships_query, , 5, 2.7.3, y, 54, Publisher_ext, relationships_display_field, relationships_display_field, , 5, 2.7.3, y, 55, Publisher_ext, relationships_post_save, relationships_post_save, , 5, 2.7.3, y, 56, Publisher_ext, relationships_modify_rows, relationships_modify_rows, , 5, 2.7.3, y, 57, Publisher_ext, grid_query, grid_query, , 5, 2.7.3, y, 58, Publisher_ext, grid_save, grid_save, , 5, 2.7.3, y, 59, Publisher_ext, assets_save_row, assets_save_row, , 5, 2.7.3, y, 60, Publisher_ext, assets_field_selections_query, assets_field_selections_query, , 5, 2.7.3, y, 61, Publisher_ext, assets_data_query, assets_data_query, , 5, 2.7.3, y, 62, Publisher_ext, structure_get_data_end, structure_get_data_end, , 5, 2.7.3, y, 63, Publisher_ext, structure_get_selective_data_results, structure_get_selective_data_results, , 5, 2.7.3, y, 64, Publisher_ext, structure_reorder_end, structure_reorder_end, , 5, 2.7.3, y, 65, Publisher_ext, structure_create_custom_titles, structure_create_custom_titles, , 5, 2.7.3, y, 66, Publisher_ext, structure_modify_publish_tab_settings, structure_modify_publish_tab_settings, , 5, 2.7.3, y, 67, Publisher_ext, structure_get_custom_variables, structure_get_custom_variables, , 5, 2.7.3, y, 68, Publisher_ext, blocks_get_blocks, blocks_get_blocks, , 5, 2.7.3, y, 69, Publisher_ext, blocks_disassociate, blocks_disassociate, , 5, 2.7.3, y, 70, Publisher_ext, blocks_create_block, blocks_create_block, , 5, 2.7.3, y, 71, Publisher_ext, blocks_delete_block, blocks_delete_block, , 5, 2.7.3, y, 72, Publisher_ext, blocks_set_block_order, blocks_set_block_order, , 5, 2.7.3, y, 73, Publisher_ext, blocks_set_atom_data, blocks_set_atom_data, , 5, 2.7.3, y, 74, Publisher_ext, blocks_pre_save_blocks, blocks_pre_save_blocks, , 5, 2.7.3, y, 75, Publisher_ext, blocks_post_save_block, blocks_post_save_block, , 5, 2.7.3, y, 76, Publisher_ext, before_channel_entry_save, before_channel_entry_save, , 5, 2.7.3, y, 77, Publisher_ext, after_channel_entry_delete, after_channel_entry_delete, , 5, 2.7.3, y, 78, Publisher_ext, after_channel_entry_save, after_channel_entry_save, , 5, 2.7.3, y, 79, Publisher_ext, after_channel_field_save, after_channel_field_save, , 5, 2.7.3, y, 80, Publisher_ext, after_channel_field_delete, after_channel_field_delete, , 5, 2.7.3, y, 81, Publisher_ext, cp_css_end, cp_css_end, , 5, 2.7.3, y;

#36

BoldMinded (Brian)

Behzad & Oliver, if that query dump is from before the re-install, then you’re missing 3 hooks, which may explain the issue. If Publisher’s updates are run correctly then all of the hooks should be present. What version of Publisher did you have before your last upgrade? Or if possible are you able to remember the exact version numbers you’ve had since the original install?

blocks_post_save blocks_delete_blocks_by_entry blocks_update_field_data

#37

Sears Davies

We were on version 2.7.3 before the upgrade.