New function FrmForm::prepare_form_row_data

[Crabcyborg]

Related ticket https://secure.helpscout.net/conversation/2518729092/191090/

A lot of code works on the assumption that $form->options is an array.

I tried adding some checks in some updates yesterday (in #1543, https://github.com/Strategy11/formidable-pro/pull/4845 and https://github.com/Strategy11/formidable-pro/pull/4844) but I think we're better off just forcing $form->options as an array right away. Trying to fix this in every place where we assume $form->options is an array is turning into too much work and too many undetected bugs.

This update now forces all results from FrmForm::getOne to have an array $form->options value when $form is not null. I used the lite form defaults so some basic keys are defined, to help fix an issue with a PHP warning.

Questions

1. Would we want to try calling FrmFormsHelper::get_default_opts() as well to define some Pro defaults?
2. Would we want to start only filtering frm_form_object when it's an object and not null? That might help with stability as well.

Fatal error: Uncaught TypeError: Cannot access offset of type string on string in .../wp-content/plugins/formidable/classes/models/FrmForm.php:605 Stack trace: #0 .../wp-content/plugins/formidable/classes/models/FrmForm.php(559): FrmForm::trash() #1 .../wp-content/plugins/formidable/classes/controllers/FrmFormsController.php(658): FrmForm::set_status() #2 .../wp-content/plugins/formidable/classes/controllers/FrmFormsController.php(626): FrmFormsController::change_form_status() #3 .../wp-content/plugins/formidable/classes/controllers/FrmFormsController.php(1754): FrmFormsController::trash() #4 .../wp-includes/class-wp-hook.php(324): FrmFormsController::route() #5 .../wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters() #6 .../wp-includes/plugin.php(517): WP_Hook->do_action() #7 .../wp-admin/admin.php(259): do_action() #8 {main} thrown in .../wp-content/plugins/formidable/classes/models/FrmForm.php on line 605

Coming from this line of code:

$options['trash_time'] = time();

Since $options is a string, trying to set $options['trash_time'] triggers a fatal error.

[codecov]

Codecov Report

Attention: Patch coverage is 88.88889% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 29.54%. Comparing base (058d0ed) to head (b42e971).
Report is 51 commits behind head on master.

Files	Patch %	Lines
classes/models/FrmForm.php	88.88%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #1547      +/-   ##
============================================
+ Coverage     29.45%   29.54%   +0.08%     
- Complexity     7696     7735      +39     
============================================
  Files           115      115              
  Lines         25404    25482      +78     
============================================
+ Hits           7484     7529      +45     
- Misses        17920    17953      +33     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ghost]

@Crabcyborg Hi!
I installed the provided FormidableForms version, and I tested the following:

• [ x ]Moving the form to the Trash.
• [ x ]Clicking on Undo when moving the form to the trash.
• [ x ]Build, Settings, Entries, and Views tabs work fine.
• [ ]Style tab is returning this warning

"Warning: Undefined array key "custom_style" in
/home/u103776375/domains/protecontech.com/public_html/wp-content/plugins/formidable/classes/views/styles/_styles-list.php
on line
11"

-[ x ]Added field and updated the form successfully
-[ x ]Form looks good when previewing it.
-[ x ]Form submitted fine.

[Crabcyborg]

Thanks @joaovictorangeline.

I'm thinking we may want to set the default form options instead of an empty array to solve that issue.

[ghost]

Thanks @joaovictorangeline.

I'm thinking we may want to set the default form options instead of an empty array to solve that issue.

Yes, @Crabcyborg when I enabled the default style, it worked fine!
Should I wait for a new patch or should I answer the customer with what we already have? The warning will disappear when WP_DEBUG is false.

[Crabcyborg]

@joaovictorangeline

Here's a more up to date pre-release you can share that should fix that issue as well,
formidable-6.8.3b.zip

I went ahead and started using the lite defaults when there are no options. This includes the custom_style and should resolve that warning.

[ghost]

I tested and it worked @Crabcyborg !
Thanks for putting your efforts on this.

[stephywells]

This looks like a great approach.

1. I think it's fine to not set the defaults for the pro options. The code should handle that already since many forms would start as lite forms before an upgrade.
2. That sounds like a good adjustment to only run the hook if it's an object.