[Crabcyborg]

Replace the ORDER BY field_order DESC LIMIT 1 lookup in FrmFieldsHelper::setup_new_vars() with MAX(field_order), so MySQL keeps a running max instead of sorting every field in the form. The result is the same, including for a form with no fields (new field gets order 1).

Testing

1. Open a form in the builder and add a new field.
2. The new field is placed at the end, with field_order one higher than the previous last field.
3. Add a field to a new, empty form. It gets field_order 1.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 27 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

Run configuration

• Source mode: Auto
• Repository: Strategy11/formidable-forms
• Branch: perf/max-field-order
• File: .coderabbit.yaml
• Commit: 119300a
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: c675a4bb-6edc-422c-abbb-bec7cf0d0b25

Commits

Reviewing files that changed from the base of the PR and between 826f89e and 119300a.

Files selected for processing: 1

• classes/helpers/FrmFieldsHelper.php

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.}

[deepsource-io]

DeepSource Code Review

We reviewed changes in 826f89e...119300a on this pull request. Below is the summary for the review, and you can see the individual issues we found as inline review comments.

See full review on DeepSource ↗

PR Report Card

Overall Grade

Security   Reliability   Complexity   Hygiene

Code Review Summary

Analyzer	Status	Updated (UTC)	Details
PHP		Oct 29, 2026 4:12p.m.	Review ↗
JavaScript		Oct 29, 2026 4:12p.m.	Review ↗

---

Important

AI Review is run only on demand for your team. We're only showing results of static analysis review right now. To trigger AI Review, comment @deepsourcebot review on this thread.

[franky-the-going-merry]

Approving. Nothing blocking.

Live check (PR branch 119300aba loaded in a WP Playground env, Formidable Lite only):

• The new query is SELECT MAX(field_order) FROM wp_frm_fields WHERE form_id=3 LIMIT 1. It is valid and FrmDb::get_var still routes it through $wpdb->prepare; $field is a constant, so there is no injection surface.
• Empty form: setup_new_vars() returns field_order 1 (MAX() gives NULL, NULL+1 = 1), matching the PR description.
• After three real FrmField::create() calls the new fields get field_order 1, 2, 3, and the DB rows read back 1, 2, 3. The per-form result cache doesn't go stale between consecutive adds.

Not exercised: I did not click through the builder UI, and I did not compare against master side by side. The change is one line with the same semantics, so I checked behavior at the helper level. A fields-with-gaps case (e.g. 1, 5, 3, where MAX should return 5) was not cleanly tested because my test edited rows directly and hit the cache; it follows from SQL semantics and the old ORDER BY ... DESC LIMIT 1 gave the same answer.

Other notes:

• Psalm is red, but it fails on 912 pre-existing MissingPureAnnotation errors in files this PR doesn't touch (stripe/, etc.). Not caused by this change. Most other CI jobs show skipping, so the PHPUnit and PHPCS signal is absent here; the one-line diff carries no new lint risk that I can see.
• The branch is 7 commits behind master but merges cleanly.
• The perf motivation is real but small (a sort over one form's fields, usually tens of rows). That is fine as a cleanup and not worth asking for a benchmark.