Skip to content

Conflict with SureFeedback (Project Huddle) in Latest Version #881

@kkimball

Description

@kkimball

Describe the bug
callback_change_post_meta_created in the changes-log module hooks add_post_meta, which fires before the DB INSERT inside WordPress's add_metadata(). The callback calls get_permalink($post->ID), which on sites with Project Huddle (aka SureFeedback) triggers ph_get_post_access_token() → update_post_meta('access_token') → add_metadata() → add_post_meta fires again → infinite loop → PHP-FPM timeout → HTTP 500.
To Reproduce

Install mainwp-child and Project Huddle on the same WordPress site.
Log into wp-admin.
Navigate to Project Huddle → Websites → Add New.
Page hangs for several seconds then returns HTTP 500.

Expected behavior
The "Add New Website" page loads normally and saves the new website record.
Screenshots
N/A — server-side infinite loop, no visible UI state before the 500.
Environment

OS: Linux (server-side issue; not browser/OS-dependent)
Browser: Chrome
Smartphone: N/A

Additional context
The conflict is in modules/changes-logs/classes/class-changes-handle-wp-metadata.php. The add_post_meta action fires before the INSERT, so when get_permalink() causes any plugin to call update_post_meta() on the same post, update_metadata() runs a SELECT that finds nothing (meta not yet written), calls add_metadata() again, which fires add_post_meta again — infinite recursion.
Fix: Change the hook from add_post_meta to added_post_meta. The added_* variant fires after the INSERT, so the meta exists in the database when get_permalink() runs, breaking the loop.
Workaround currently in place: A mu-plugin that intercepts the add_post_metadata filter at priority 1 and performs the INSERT directly, short-circuiting add_metadata() before it fires the add_post_meta action.

Metadata

Metadata

Assignees

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions