[Waiting for user confirmation] Heartbeat autosave fatal error

[Author]

Posts

[anttiP]

I am getting a PHP 8.3 Fatal TypeError during Heartbeat autosaves in Toolset Forms v2.6.23. Line 926 of notification_manager/base.php is passing a string to reset() instead of an array.

[Minesh]

Hello. Thank you for contacting the Toolset support.

That is really strange.

Just to ensure there is no conflict between the theme/plugins you use:

Could you please try to resolve your issue by deactivating all third-party plugins as well as the default theme to check for any possible conflicts with any of the plugins or themes?
- Do you see any difference? if no:

Can you please share problem URL and exact steps I will have to follow that should help me to see the issue.

*** Please make a FULL BACKUP of your database and website.***
I would also eventually need to request temporary access (WP-Admin and FTP) to your site. Preferably to a test site where the problem has been replicated if possible in order to be of better help and check if some configurations might need to be changed.

I have set the next reply to private which means only you and I have access to it.

[anttiP]

Hi Minesh,

Thank you for getting back to me.

I won't need to do a plugin/theme conflict test or provide FTP access, as I have actually already debugged this and found the exact root cause of the error within the Toolset Forms codebase.

This is a PHP 8+ strict type compatibility bug that triggers a Fatal Error in the background during WordPress autosaves (via the Heartbeat API).

The Bug Location:

Plugin: Toolset Forms v2.6.23

File: cred-frontend-editor/application/controllers/notification_manager/base.php

Function: save_pre_snapshot() (around line 926)

The Problem:
In the save_pre_snapshot function, the code currently looks like this:

PHP
$attached_data = $model->getAttachedData( $object_id );
if ( ! $attached_data ) {
return;
}
reset( $attached_data );

The flaw here is that the code assumes $attached_data will always be an array if it exists. However, in my environment, it is returning a string. Because PHP 8+ is strictly typed, passing a string to the reset() function immediately throws this fatal error: Uncaught TypeError: reset(): Argument #1 ($array) must be of type array, string given.

The Fix:
The if statement simply needs to verify that the data is an array before passing it to reset(). I have manually patched my own file with the following:

PHP
$attached_data = $model->getAttachedData( $object_id );
if ( ! is_array( $attached_data ) || empty( $attached_data ) ) {
return;
}
reset( $attached_data );

Could you please escalate this directly to your development team so they can include this patch in the next Toolset Forms update? Anyone running PHP 8.0 or higher is likely triggering these silent background crashes during autosaves.

Thanks!

[Minesh]

if you can - can you please share the fatal error stack trace that I will include to the internal ticket I will create.

[anttiP]

Sure, I can attach the stack trace in this thread. Minesh, could you please switch the next reply to private, thanks

[Minesh]

I have set the next reply to private which means only you and I have access to it.

[anttiP]

WordPressin versio 6.9.4
Nykyinen teema: Enfold Child (versio 1.0)
Lisäosa: Toolset Forms (versio 2.6.23)
PHP versio 8.3.30

Virheen lisätiedot
===================
Tiedoston /home2/hunajane/public_html/wp-content/plugins/cred-frontend-editor/application/controllers/notification_manager/base.php rivillä 926 havaittiin virhe lajia E_ERROR. Virheviesti: Uncaught TypeError: reset(): Argument #1 ($array) must be of type array, string given in /home2/hunajane/public_html/wp-content/plugins/cred-frontend-editor/application/controllers/notification_manager/base.php:926
Stack trace:
#0 /home2/hunajane/public_html/wp-content/plugins/cred-frontend-editor/application/controllers/notification_manager/base.php(926): reset()
#1 /home2/hunajane/public_html/wp-includes/class-wp-hook.php(343): CRED_Notification_Manager_Base->save_pre_snapshot()
#2 /home2/hunajane/public_html/wp-includes/class-wp-hook.php(365): WP_Hook->apply_filters()
#3 /home2/hunajane/public_html/wp-includes/plugin.php(522): WP_Hook->do_action()
#4 /home2/hunajane/public_html/wp-includes/post.php(4901): do_action()
#5 /home2/hunajane/public_html/wp-includes/post.php(5296): wp_insert_post()
#6 /home2/hunajane/public_html/wp-admin/includes/post.php(453): wp_update_post()
#7 /home2/hunajane/public_html/wp-admin/includes/post.php(2179): edit_post()
#8 /home2/hunajane/public_html/wp-admin/includes/misc.php(1352): wp_autosave()
#9 /home2/hunajane/public_html/wp-includes/class-wp-hook.php(343): heartbeat_autosave()
#10 /home2/hunajane/public_html/wp-includes/plugin.php(205): WP_Hook->apply_filters()
#11 /home2/hunajane/public_html/wp-admin/includes/ajax-actions.php(3506): apply_filters()
#12 /home2/hunajane/public_html/wp-includes/class-wp-hook.php(341): wp_ajax_heartbeat()
#13 /home2/hunajane/public_html/wp-includes/class-wp-hook.php(365): WP_Hook->apply_filters()
#14 /home2/hunajane/public_html/wp-includes/plugin.php(522): WP_Hook->do_action()
#15 /home2/hunajane/public_html/wp-admin/admin-ajax.php(192): do_action()
#16 {main}
thrown

[Minesh]

I've escalated the issue in front of our Devs. Please hold on for further updates. I will get in touch with you as soon as I have any update on this issue.

[anttiP]

I have an important update regarding this ticket. While debugging further, I encountered a **second** Fatal Error in the Notification Manager module, and I have a theory about what might be causing the underlying data corruption.

Here is some additional context that I hope will be helpful for your developers' investigation:

**1. The Potential Root Cause (Race Condition Theory)**
I suspect the corrupted metadata might be the result of a race condition on the front-end CRED form. If a visitor double/triple-clicks the submit button (or uses their browser's "Back" button to resubmit), the form can fire multiple simultaneous POST requests since the submit button isn't natively disabled after the first click.

My theory is that when 2-3 identical posts are generated, the simultaneous database writing might be corrupting the Toolset metadata for those specific posts—saving it as a malformed string instead of the expected array.

**2. The Second Fatal Error (The Deletion Crash)**
Regardless of *how* the data gets corrupted, this strict-type vulnerability also completely breaks WordPress post deletion.

When an Admin attempts to delete (Move to Trash) one of these duplicated posts, it triggers this new Fatal Error (I have redacted my specific server paths for privacy):

Fatal error: Uncaught TypeError: array_keys(): Argument #1 ($array) must be of type array, string given in [server-path]/wp-content/plugins/cred-frontend-editor/application/controllers/notification_manager/post.php:188
Stack trace:
#0 [server-path]/wp-content/plugins/cred-frontend-editor/application/controllers/notification_manager/post.php(188): array_keys()
#1 [server-path]/wp-content/plugins/cred-frontend-editor/application/controllers/notification_manager/post.php(154): CRED_Notification_Manager_Post->check_for_notifications()
#2 [server-path]/wp-includes/class-wp-hook.php(343): CRED_Notification_Manager_Post->check_for_notifications_by_status_switch()
#3 [server-path]/wp-includes/class-wp-hook.php(365): WP_Hook->apply_filters()
#4 [server-path]/wp-includes/plugin.php(522): WP_Hook->do_action()
#5 [server-path]/wp-includes/post.php(4050): do_action()
#6 [server-path]/wp-admin/post.php(260): wp_trash_post()
#7 {main}

**The Impact:** Because this crash happens during the `wp_trash_post()` hook, it completely aborts the WordPress deletion process. Admins are locked out with a white screen and cannot remove the posts from the dashboard. I had to manually delete the corrupted entries directly via phpMyAdmin.

**3. Suggested Safeguards for the Dev Team**
I've added custom JS and redirects on my end to try and prevent double-submissions. However, I highly recommend the development team look into auditing the `CRED_Notification_Manager` module for PHP 8 strict-type compatibility.

Even if database metadata is malformed or unexpected, it ideally shouldn't trigger a Fatal Error that breaks core WordPress functions (like autosaving or trashing). Adding a simple `is_array()` check before running functions like `reset()`, `array_keys()`, or `foreach()` on fetched metadata (like `$attached_data`) could be a great safeguard against this.

I hope these clues help the team track down and patch the issue!

[Minesh]

Thank you for sharing all those details and definately it will help our Devs.

Just to let you know and you will be happy that our Dev has fixed this issue as well and fix will be published with the next release.