Use strict in more in_array checks

[Crabcyborg]

No description provided.

[coderabbitai]

Walkthrough

Multiple controller, helper, model, and view files update in_array checks to use strict type comparison by passing true as the third argument, ensuring exact type and value matching instead of relying on PHP's loose comparison.

Changes

Cohort / File(s)	Summary
Controllers classes/controllers/FrmAddonsController.php, classes/controllers/FrmEntriesController.php, classes/controllers/FrmFormActionsController.php	Enforces strict in_array comparisons when checking license duplicates, screen options visibility, and action group membership.
Helpers classes/helpers/FrmAppHelper.php, classes/helpers/FrmEntriesListHelper.php, classes/helpers/FrmXMLHelper.php	Applies strict type comparison in unit mapping, primary column detection, and field type checks to prevent false positives from type coercion.
Models classes/models/FrmDb.php, classes/models/FrmFormMigrator.php	Tightens membership tests in ORDER BY clause validation and section boundary detection using strict comparison.
Views classes/views/frm-form-actions/settings.php	Updates action control and group action matching to use strict type comparison in visibility logic.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

• Use strict for more array checks #2712: Applies the same consistent pattern of converting loose in_array checks to strict comparisons across overlapping files and classes.
• Use strict equals more #1761: Both PRs tighten comparison semantics by switching to strict checks and modify the FrmDb class.

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	No pull request description was provided, making it impossible to assess whether it relates to the changeset.	Add a description explaining the rationale for enforcing strict type comparison in in_array checks and any potential impacts.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title directly and accurately describes the main change: converting in_array checks to use strict type comparison across multiple files.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

classes/controllers/FrmFormActionsController.php (1)

138-162: Strict membership check for action grouping is appropriate

$grouped contains action slugs and $action->id_base is also a slug, so switching to in_array( $action->id_base, $grouped, true ) keeps the grouping logic the same for normal usage while avoiding any cross‑type matches. The only behavior change would be for custom filters that mix non‑string types into actions, which seems unlikely and would be better aligned by normalizing those to strings.

classes/controllers/FrmAddonsController.php (1)

633-681: Stricter license de‑duplication is fine; consider normalizing license values

Using in_array( $new_license, $checked_licenses, true ) keeps the “one API call per license” behavior intact as long as licenses are consistently stored as strings, and removes any chance of type‑juggling collisions.

If you ever expect license values to come in with differing types or whitespace (e.g., 123 vs '123' vs ' 123 '), consider normalizing before the check:

• Cast to string and trim (and/or uppercase if needed) prior to adding/checking in $checked_licenses.

This would keep the stricter comparison while ensuring logically identical licenses are still de‑duplicated.

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d436d36 and 62319c2.

📒 Files selected for processing (9)

• classes/controllers/FrmAddonsController.php
• classes/controllers/FrmEntriesController.php
• classes/controllers/FrmFormActionsController.php
• classes/helpers/FrmAppHelper.php
• classes/helpers/FrmEntriesListHelper.php
• classes/helpers/FrmXMLHelper.php
• classes/models/FrmDb.php
• classes/models/FrmFormMigrator.php
• classes/views/frm-form-actions/settings.php

🧰 Additional context used

🧬 Code graph analysis (2)

classes/views/frm-form-actions/settings.php (1)

classes/controllers/FrmFormActionsController.php (1)

• action_control (444-450)

classes/controllers/FrmEntriesController.php (1)

classes/helpers/FrmAppHelper.php (2)

• FrmAppHelper (6-5050)
• is_admin_page (495-509)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)

• GitHub Check: PHP 8 tests in WP 6.9
• GitHub Check: PHP 7.4 tests in WP 6.9
• GitHub Check: Cypress
• GitHub Check: Cypress
• GitHub Check: PHP 8 tests in WP 6.9
• GitHub Check: PHP 7.4 tests in WP 6.9

🔇 Additional comments (11)

classes/helpers/FrmAppHelper.php (1)

3348-3357: Stricter unit lookup in get_unit is correct and non‑breaking

$unit and the values in $strings are all strings, so adding the strict flag to in_array preserves existing behavior while preventing any accidental cross‑type matches in the future. No issues here.

classes/models/FrmDb.php (1)

547-566: Strict in_array in esc_order safely tightens the whitelist check

$order is always a string token and $safe_order contains only 'count(*)', so using in_array(..., true) keeps behavior the same for valid input and makes the whitelist more robust against any future cross‑type values. Looks good.

classes/helpers/FrmEntriesListHelper.php (1)

299-307: Primary column detection remains unchanged with strict in_array

$column_key and the entries in $hidden are all strings from WordPress core, so adding the strict flag keeps the primary‑column selection identical and just avoids any accidental matches if non‑string values ever appeared in $hidden.

classes/controllers/FrmEntriesController.php (1)

193-193: LGTM: Strict comparison improves type safety.

The strict comparison for the in_array check is appropriate here. The $action variable from sanitize_title returns a string, and you're comparing it against an array of strings ('', 'list', 'destroy'), so type coercion is not needed.

classes/views/frm-form-actions/settings.php (2)

43-43: LGTM: Strict type checking for action identification.

Both in_array checks on this line now use strict comparison, which is correct for comparing action identifiers. This ensures exact string matches without type coercion.

---

52-52: LGTM: Consistent strict comparison.

The strict comparison aligns with the check on line 43 and ensures type-safe membership testing for displayed actions.

classes/helpers/FrmXMLHelper.php (2)

666-666: LGTM: Type-safe field type checking.

The strict comparison is appropriate for checking field types. Since $f['type'] is a string field type identifier being compared against an array of string literals, this eliminates any risk of unexpected type coercion during XML import.

---

2307-2307: LGTM: Consistent strict comparison in notification setup.

The strict comparison properly checks if $add_field is exactly 'plain_text' or 'inc_user_info', avoiding any type coercion issues. This is part of the broader pattern in this PR to enforce type-safe comparisons.

classes/models/FrmFormMigrator.php (3)

306-306: LGTM: Type-safe section membership check.

The strict comparison ensures that field types are checked with exact string matching against the array returned by fields_with_end(). This prevents any unexpected behavior from type coercion when determining if a field should be placed in a section.

---

314-314: LGTM: Consistent strict comparison for section tracking.

This strict comparison correctly identifies fields that require an end section marker, maintaining consistency with the check on line 306.

---

378-387: LGTM: Type-safe field type validation.

Both in_array checks on lines 378 and 387 now use strict comparison when checking field types against the $with_end array. This ensures type-safe matching when automatically adding end section fields during form migration.