Discussed this with ChatGPT, so I let the ticket write by ChatGPT:
TL;DR:
I’m seeing a reproducible fatal error during WS Form PRO updates on two completely separate WordPress installations. The error points to CommandUI calling a method that no longer exists in the latest WS Form. The site continues working fine after the update, but I wanted to report it.
I haven’t analyzed this in depth, but I’ve now seen this on two different websites over the past weeks when updating WS Form PRO.
Environment (both sites):
WordPress 6.8.3
PHP 8.3.26
WS Form PRO 1.10.60 and 1.10.62
CommandUI 1.10
Uncaught Error: Call to undefined method WS_Form_Common::abilities_api_enabled()
in /wp-content/plugins/ws-form-pro/includes/config/class-ws-form-config-option.php:1407
Stack trace (excerpt):
#0 /wp-content/plugins/ws-form-pro/includes/class-ws-form-config.php(199): WS_Form_Config_Option::get_options()
#1 /wp-content/plugins/commandui/src/integrations.php(335): WS_Form_Config::get_options()
#2 /wp-content/plugins/commandui/src/main.php(471): Snicco\CommandUI\WSFormsIntegration::subSettings()
...
#15 /wp-admin/update.php(53): iframe_footer()
!<
Behavior observed:
Error happens only during the WS Form PRO update process (admin update iframe).
Both frontend and backend work fine after the update finishes.
Workaround: deactivate CommandUI → update WS Form → reactivate CommandUI.
It seems that abilities_api_enabled() has been removed or changed in WS Form and CommandUI is still calling it. A simple method_exists check or update to the current WS Form API might fix it.
Just reporting this here for visibility — I didn’t investigate further.