Fixed issue where GF Feed Forge reprocessing would not properly handle edited entries for Gravity Connect plugins.#20
Conversation
…e edited entries for Gravity Connect plugins. ~ Fixed PHPCS.
There was a problem hiding this comment.
I'm thinking this should be handled at the GC plugin level by adding "upsert" functionality to the add_entry_to_resource_methods().
My gut feel is that adding upsert logic at the GC plugin to add_entry_to_resource() methods will be a lot easier to work with in the long run (less points of failure). Would also help ensure compatibility for any other plugins using the GF Feed Processor.
Here's a very untested patch of approximately what that would look like in GCA: gca.patch
And a Loom talking through it: https://www.loom.com/share/aecd622936bc4e3e88c879cc866ee344
Edit: here's the Airtable get record endpoint reference https://airtable.com/developers/web/api/get-record
| $resource_id = $addon->get_resource_id( $entry, $feed ); | ||
|
|
||
| // Build the edit hook name from addon slug (e.g., gc-airtable -> gc_airtable_edit_entry_in_database) | ||
| $edit_hook_name = str_replace( '-', '_', $feed['addon_slug'] ) . '_edit_entry_in_database'; |
There was a problem hiding this comment.
You can also get hook name like this:
$addon->hook_name_add_entry_to_resource();
2 participants
Context
⛑️ Ticket(s): https://secure.helpscout.net/conversation/3193477620/95892?viewId=3808239
Summary
Fixes GF Feed Forge reprocessing for edited Gravity Connect plugin entries. Previously, entries edited while feeds were inactive would not be properly detected during bulk reprocessing, causing "Add Record" actions instead of "Update Record" actions.
Now detects previously processed GC plugin entries and routes them to the correct edit pathway, ensuring proper update operations.
DEMO:
https://www.loom.com/share/4d0a4b3b2572446a87d3cc204ac01f08
Checklist