Add new sniff to simplify truthy checks#2751
Conversation
|
Warning Rate limit exceeded@Crabcyborg has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 10 minutes and 17 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
WalkthroughA systematic refactoring replaces Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
classes/helpers/FrmStylesHelper.php (1)
373-383: Fix apparent PHP parse errors (extra)in conditionals).As written, these
if/elseiflines won’t parse.Proposed fix
- if ( str_starts_with( $hex, 'rgba(' ) ) { + if ( str_starts_with( $hex, 'rgba(' ) ) { $rgba = str_replace( ')', '', str_replace( 'rgba(', '', $hex ) ); list ( $r, $g, $b, $a ) = array_map( 'trim', explode( ',', $rgba ) ); $r = max( 0, min( 255, $r + $steps ) ); $g = max( 0, min( 255, $g + $steps ) ); $b = max( 0, min( 255, $b + $steps ) ); return 'rgba(' . $r . ',' . $g . ',' . $b . ',' . $a . ')'; } ... - } elseif ( str_contains( $color, 'rgb(' ) ) { + } elseif ( str_contains( $color, 'rgb(' ) ) { $color = str_replace( 'rgb(', 'rgba(', $color ); $color = str_replace( ')', ',1)', $color );Also applies to: 861-872
classes/helpers/FrmAppHelper.php (1)
2793-2807:generate_new_key: current max can produce$num_chars + 1length and needs input validation now that it’s public.
Example:$num_chars = 2⇒ max36**2 = 1296⇒base_convert(1296, 10, 36) === "100"(3 chars). Also,$num_chars < 2can makerandom_int($min, $max)invalid.Proposed fix (range correctness + clamp)
public static function generate_new_key( $num_chars ) { - $max_slug_value = 36 ** $num_chars; - - // We want to have at least 2 characters in the slug. - $min_slug_value = 37; - return base_convert( random_int( $min_slug_value, $max_slug_value ), 10, 36 ); + $num_chars = max( 2, (int) $num_chars ); + + // Base-36 values with exactly $num_chars digits are in: + // [ 36**($num_chars-1), (36**$num_chars) - 1 ]. + $min_slug_value = 36 ** ( $num_chars - 1 ); + $max_slug_value = ( 36 ** $num_chars ) - 1; + + return base_convert( random_int( $min_slug_value, $max_slug_value ), 10, 36 ); }
🤖 Fix all issues with AI agents
In @classes/controllers/FrmFieldsController.php:
- Around line 92-97: The check before merging field options doesn't guard
against non-array input so array_merge in include_new_field can throw a
TypeError; update the condition to verify $field_options is an array (e.g.,
is_array($field_options)) before calling array_merge and otherwise ignore or
cast/normalize it; locate the include_new_field method and the array_merge call
on $field_values['field_options'] (after FrmFieldsHelper::setup_new_vars) and
ensure only arrays are merged.
In @classes/models/FrmField.php:
- Line 1096: The change from using ! empty($order_by) to checking $order_by
directly causes the string "0" to be treated as false and skips prepending '
ORDER BY '; restore the previous semantics by using ! empty($order_by) (or
explicitly check $order_by !== '' && $order_by !== null) in the conditional
around str_contains so that "0" and similar non-empty strings are still treated
as present when building the ORDER BY clause in FrmField.php (the condition that
currently reads if ( $order_by && ! str_contains( $order_by, 'ORDER BY' ) )
should be updated).
In
@phpcs-sniffs/Formidable/Sniffs/CodeAnalysis/RedundantEmptyOnParameterSniff.php:
- Around line 1-16: The file
Formidable_Sniffs_CodeAnalysis_RedundantEmptyOnParameterSniff has PHP CS Fixer
violations (phpdoc_types_order and blank_line_before_statement); run
./vendor/bin/php-cs-fixer fix against this file or manually reorder types in any
PHPDoc blocks and add the required blank lines before statements so phpdoc type
annotations follow the configured order and a blank line is present where the
fixer expects (adjust docblocks and spacing in the
Formidable_Sniffs_CodeAnalysis_RedundantEmptyOnParameterSniff file/namespace).
🧹 Nitpick comments (8)
phpcs-sniffs/Formidable/Sniffs/CodeAnalysis/RedundantEmptyOnParameterSniff.php (2)
264-269: Remove unreachable condition.Lines 266-268 are dead code. If execution reaches this point,
$codecannot beT_OPEN_PARENTHESISbecause that case was already handled and returned at line 249-262. The check$code !== T_OPEN_PARENTHESISis always true here.♻️ Proposed fix
// If we hit an open parenthesis, check if it belongs to if/elseif. if ( $code === T_OPEN_PARENTHESIS ) { // Check what's before this parenthesis. $beforeParen = $phpcsFile->findPrevious( T_WHITESPACE, $i - 1, null, true ); if ( false !== $beforeParen ) { $beforeCode = $tokens[ $beforeParen ]['code']; if ( $beforeCode === T_IF || $beforeCode === T_ELSEIF ) { return true; } } // This parenthesis doesn't belong to if/elseif. return false; } - // If we hit something else (like another function call), stop. - if ( $code !== T_OPEN_PARENTHESIS ) { - return false; - } + // If we hit something else (like another function call), stop. + return false; }
182-197: Correct the arrow function support condition.The method should handle arrow functions (
T_FN, PHP 7.4+) in addition toT_FUNCTIONandT_CLOSURE. Arrow functions do havescope_openerandscope_closerset in PHP_CodeSniffer's tokenization, so the fix requires only addingT_FNto the condition—no special scope_condition handling is needed.♻️ Proposed fix
private function findContainingFunction( File $phpcsFile, $stackPtr ) { $tokens = $phpcsFile->getTokens(); for ( $i = $stackPtr - 1; $i >= 0; $i-- ) { - if ( $tokens[ $i ]['code'] === T_FUNCTION || $tokens[ $i ]['code'] === T_CLOSURE ) { + if ( $tokens[ $i ]['code'] === T_FUNCTION || $tokens[ $i ]['code'] === T_CLOSURE || $tokens[ $i ]['code'] === T_FN ) { // Check if the stackPtr is within this function's scope. if ( isset( $tokens[ $i ]['scope_opener'], $tokens[ $i ]['scope_closer'] ) ) { if ( $stackPtr > $tokens[ $i ]['scope_opener'] && $stackPtr < $tokens[ $i ]['scope_closer'] ) { return $i; } } } } return false; }classes/controllers/FrmXMLController.php (1)
189-195: Consider consistent truthiness checks.Line 190 now mixes truthiness (
$form) withempty()checks (! empty( $form[ $value ] )). For consistency with the broader refactor pattern, consider updating both parts:♻️ Consistent pattern
- if ( $form && ! empty( $form[ $value ] ) ) { + if ( $form && isset( $form[ $value ] ) && $form[ $value ] ) {Note: Using
isset()first prevents potential PHP notices when accessing array keys.classes/controllers/FrmDashboardController.php (1)
193-205: Truthiness check looks fine here; consider either enforcing array CTA or honoring$type.
if ( $cta )is equivalent for the expected$ctaarray usage, but if this method is called with a non-array truthy value, you’ll still inject it into view args. Also,$typeis currently ignored (always'default').Proposed tweak (keep truthiness style, add type + basic shape guard)
public static function view_args_build_counter( $heading, $cta = array(), $value = 0, $type = 'default' ) { $counter_args = array( 'heading' => $heading, 'counter' => $value, - 'type' => 'default', + 'type' => $type, ); - if ( $cta ) { + if ( $cta && is_array( $cta ) ) { $counter_args['cta'] = $cta; } return $counter_args; }classes/controllers/FrmFormActionsController.php (1)
613-620: Consider asserting$old_actionsis an array before iterating.With truthiness checks, a non-array truthy value would still pass and then
foreachwould iterate oddly (or error, depending on PHP version/settings).Proposed tweak
public static function delete_missing_actions( $old_actions ) { - if ( $old_actions ) { + if ( $old_actions && is_array( $old_actions ) ) { foreach ( $old_actions as $old_id ) { wp_delete_post( $old_id ); } FrmDb::cache_delete_group( 'frm_actions' ); } }classes/helpers/FrmStylesHelper.php (1)
474-479:! $varsis OK, but consider enforcing array type for$vars.This avoids accidental non-array truthy values flowing into
array_diff/foreach.Proposed tweak (no empty(), keep truthiness style)
public static function output_vars( $settings, $defaults = array(), $vars = array() ) { - if ( ! $vars ) { + if ( ! is_array( $vars ) || ! $vars ) { $vars = self::get_css_vars( array_keys( $settings ) ); }classes/controllers/FrmFormsController.php (1)
297-301: Defaulting from$_POSTon any falsy$valuesis OK; consider tightening to “not array”.This avoids surprising behavior if a caller accidentally passes
0/''and triggers a POST read.Proposed tweak
public static function update( $values = array() ) { - if ( ! $values ) { + if ( ! is_array( $values ) || ! $values ) { $values = $_POST; // phpcs:ignore WordPress.Security.NonceVerification.Missing }classes/helpers/FrmAppHelper.php (1)
1005-1040:decode_amp: consider guarding non-string inputs beforestr_contains.
If$stringcan ever be non-string (e.g., int/object),str_contains( $string, '&' )can throw aTypeError. A defensiveis_stringcheck would make this more robust.Proposed hardening
private static function decode_amp( &$string ) { // Don't bother if there are no entities - saves a lot of processing - if ( ! $string || ! str_contains( $string, '&' ) ) { + if ( ! is_string( $string ) || $string === '' || ! str_contains( $string, '&' ) ) { return; }
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
phpcs.xmlis excluded by!**/*.xml
📒 Files selected for processing (28)
classes/controllers/FrmAppController.phpclasses/controllers/FrmDashboardController.phpclasses/controllers/FrmEntriesController.phpclasses/controllers/FrmFieldsController.phpclasses/controllers/FrmFormActionsController.phpclasses/controllers/FrmFormsController.phpclasses/controllers/FrmStylesController.phpclasses/controllers/FrmXMLController.phpclasses/helpers/FrmAppHelper.phpclasses/helpers/FrmDashboardHelper.phpclasses/helpers/FrmFieldsHelper.phpclasses/helpers/FrmFormsHelper.phpclasses/helpers/FrmStylesHelper.phpclasses/helpers/FrmXMLHelper.phpclasses/models/FrmCreateFile.phpclasses/models/FrmDb.phpclasses/models/FrmEntry.phpclasses/models/FrmEntryValidate.phpclasses/models/FrmField.phpclasses/models/FrmFormApi.phpclasses/models/FrmInstallerSkin.phpclasses/models/FrmSolution.phpclasses/models/fields/FrmFieldDefault.phpclasses/models/fields/FrmFieldType.phpphpcs-sniffs/Formidable/Sniffs/CodeAnalysis/RedundantEmptyOnParameterSniff.phpstripe/helpers/FrmTransLiteAppHelper.phpstripe/models/FrmStrpLiteAuth.phptests/phpunit/emails/test_FrmEmail.php
🧰 Additional context used
🧬 Code graph analysis (3)
classes/models/FrmEntryValidate.php (1)
js/src/admin/admin.js (1)
exclude(3183-3183)
classes/models/FrmDb.php (1)
js/src/admin/admin.js (1)
limit(7910-7910)
stripe/models/FrmStrpLiteAuth.php (1)
classes/models/FrmUsage.php (1)
actions(468-488)
🪛 GitHub Actions: Inspections
phpcs-sniffs/Formidable/Sniffs/CodeAnalysis/RedundantEmptyOnParameterSniff.php
[error] 1-1: PHP CS Fixer found 1 file that can be fixed (phpdoc_types_order, blank_line_before_statement). Exit code 8. Run './vendor/bin/php-cs-fixer fix' to apply fixes.
⏰ 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). (9)
- GitHub Check: PHP 7.4 tests in WP 6.9
- GitHub Check: PHP 8 tests in WP 6.9
- GitHub Check: Cypress
- 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 7.4 tests in WP 6.9
- GitHub Check: PHP 8 tests in WP 6.9
🔇 Additional comments (46)
stripe/models/FrmStrpLiteAuth.php (1)
698-701: LGTM — semantically equivalent guard clause.Since
$actionsis a function parameter (always defined),! $actionsbehaves identically toempty( $actions )for the expected array type. Both correctly guard against empty arrays and other falsy values before theforeachloop.classes/models/FrmSolution.php (1)
657-659: LGTM! Simplified truthy check is appropriate.The change from
empty($options)to! $optionsis semantically equivalent for the expected array type and aligns with the PR's objective to simplify truthy checks.classes/models/FrmEntry.php (1)
466-472: LGTM! Refactor maintains existing behavior.The change from
empty($entry)to! $entryis semantically equivalent here and aligns with the PR's goal of standardizing truthiness checks. The logic correctly handles:
- Numeric entry IDs → fetches entry object
- Falsy values → normalizes to
false- Existing objects → leaves unchanged
The edge case of entry ID
0being treated as falsy is not a practical concern since WordPress entry IDs start at 1.One optional consideration: the
'false' === $entrycheck handles the string literal 'false', which seems like an unusual input. If you know this is no longer needed, it could be removed for clarity.stripe/helpers/FrmTransLiteAppHelper.php (2)
367-369: LGTM with minor semantic note.The change from
empty($format)to! $formatsimplifies the truthy check. Note that this introduces a subtle behavior change: the string'0'will now be treated as a valid format instead of triggering the default. Since'0'is not a practical date format, this edge case is unlikely to cause issues.
411-419: The behavior change claim is incorrect. The simplification from!empty($value)to$valuedoes not change behavior for string'0'. In PHP, the string'0'is falsy in boolean context, so both conditions evaluate to false and produce identical results. The change is still a valid simplification—it's shorter and equivalent—but there is no behavioral difference to verify.classes/models/FrmFormApi.php (2)
256-258: LGTM! Truthy check simplification is correct.The refactoring from
empty($addons)to! $addonsis semantically equivalent for arrays and preserves the existing behavior.
412-414: LGTM! Consistent truthy check simplification.The refactoring from
empty($addons)to! $addonsis semantically equivalent for arrays and maintains consistency with the change at line 256.classes/models/fields/FrmFieldType.php (1)
960-967: Truthiness check is appropriate for this refactor.The change from
empty()to! $valuesis safe and consistent with the PR's systematic refactoring. All two callers ofget_options()pass empty arrays (array()), which are falsy in both conditions. Both checks behave identically for all actual usage in the codebase.classes/models/FrmEntryValidate.php (3)
115-117: LGTM! Truthy check simplification is correct.The change from
! empty( $exclude )to$excludeis safe for thebool|string[]type. Both conditions behave identically since empty arrays are falsy in PHP.
521-532: Truthy check simplification looks good, with one edge case note.The change from
empty( $pattern )to! $patternis appropriate here. Note that this actually fixes a subtle edge case: if the first pattern part is'0', the old code would incorrectly treat the second iteration as the first (sinceempty('0')is TRUE), while the new code correctly handles it as a subsequent iteration.This edge case is unlikely in regex pattern contexts, so the change is safe and improves correctness.
552-555: Truthy check simplification is correct, but note the type hint inconsistency.The change from
! empty( $exclude )to$excludeis safe and works correctly for boolean context.However, there's a pre-existing type documentation issue: Line 540 declares
$excludeasbool, but it actually receivesbool|string[]from thevalidate()function (line 17, passed on line 50). The simplified truthy check works correctly for both types since empty arrays are falsy in PHP, but the type hint should be updated for accuracy.Consider updating the type hint on line 540 to match the actual usage:
/** * Check for spam. * * @param bool|string[] $exclude * @param array $values * @param array $errors By reference. * * @return void */phpcs-sniffs/Formidable/Sniffs/CodeAnalysis/RedundantEmptyOnParameterSniff.php (4)
39-41: LGTM!The token registration is correct for detecting
empty()calls.
51-98: LGTM!The validation logic properly handles edge cases with appropriate early returns. Skipping array access cases (
$var['key']) is a sensible simplification.
120-171: LGTM!The fix logic correctly handles both negated and non-negated cases, properly manages whitespace removal, and uses
beginChangeset()/endChangeset()for atomic operations.
207-225: LGTM!The parameter extraction correctly identifies
T_VARIABLEtokens within the function signature, which excludes type hints and other non-parameter tokens.classes/models/FrmDb.php (2)
426-432: LGTM - Refactoring maintains consistent behavior.The change from
! empty()to direct truthiness checks is safe here because:
- Both
$order_byand$limitare function parameters with default values (empty string), so they're always defined- For all relevant falsy values (
'',0,'0',null,false), both approaches behave identically- This aligns with the existing
esc_limit()method (line 605) which also uses a truthiness checkThe refactoring preserves the existing behavior while simplifying the code.
426-432: The refactoring is safe. TheRedundantEmptyOnParameterSniffis specifically designed to apply only to function parameters with default values, where the distinction between empty string, 0, and false is not semantically meaningful. For$order_byand$limitin this function, truthiness checks correctly replaceempty()without introducing undefined variable warnings or losing intent—an empty string and 0 both mean "no ordering" or "no limit."classes/models/FrmField.php (1)
924-924: No breaking changes in practice; simplification is safe for current usage patterns.While the change from
! empty( $limit )to$limitintroduces a semantic difference (string "0" would be treated as falsy instead of truthy), this has no practical impact. Examination of all callers shows:
- No calls pass
0or"0"as limit values- Only explicit limit usage is integer
1(FrmSubmitHelper.php:48)- Default parameter is
'', which behaves identically in both checks- All other calls omit the limit parameter entirely
The parameter type hint (
int|string) appears to be vestigial; actual usage is limited to integers and empty string. The change is semantically sound for the codebase's actual calling patterns.Note: Line 964 in
get_all_for_formstill uses theif ( ! $limit )pattern while lines 924 and 975 now useif ( $limit )— consider standardizing if consistency is desired.Likely an incorrect or invalid review comment.
tests/phpunit/emails/test_FrmEmail.php (1)
710-713: LGTM! Truthiness check is appropriate here.The change from
empty($property)to! $propertyis functionally equivalent for this use case where$propertyis expected to be either a non-empty string or falsy when not provided.classes/models/FrmCreateFile.php (1)
157-165: LGTM! Truthiness check is appropriate for file path defaulting.The change from
empty($file)to! $fileis functionally equivalent and appropriate for this file path parameter check.classes/controllers/FrmStylesController.php (1)
1345-1360: LGTM! Truthiness check is appropriate here.The change from
empty($screen)to! $screenis functionally equivalent for checking whether a screen object/string was provided or needs to be fetched viaget_current_screen().classes/models/FrmInstallerSkin.php (1)
72-93: LGTM! Truthiness check is appropriate for error handling.The change from
! empty($errors)to$errorsis functionally equivalent for checking whether an error (string or WP_Error object) exists before processing.classes/helpers/FrmDashboardHelper.php (1)
188-188: LGTM - Truthiness check is semantically equivalent here.The change from
empty( $buttons )to! $buttonsis appropriate. Since$buttonshas a default value ofarray(), it's always defined, and both checks evaluate identically for arrays (empty arrays are falsy in PHP).classes/models/fields/FrmFieldDefault.php (1)
24-26: LGTM - Expanded falsy handling is appropriate for type defaulting.The change from
empty( $type )to! $typebroadens the set of falsy values that trigger the default type assignment (including0,'0', etc.). This is consistent with PHP truthiness semantics and appropriate for this context, as field types are expected to be non-empty strings like 'text', 'email', etc.classes/controllers/FrmAppController.php (1)
261-263: LGTM - Truthiness check maintains identical behavior.The change from
empty( $show_nav )to! $show_navis semantically equivalent here. The variable is always defined (set viaget_param()on line 259), and both checks evaluate identically for all falsy values including'0', which is falsy in PHP.classes/helpers/FrmFieldsHelper.php (1)
2749-2751: LGTM - Truthiness check is cleaner and equivalent.The change from
! empty( $should_hide_bulk_edit )to$should_hide_bulk_editis semantically equivalent and more concise. Both evaluate identically for all practical boolean/truthy values of the parameter.classes/helpers/FrmXMLHelper.php (2)
407-414: LGTM - Truthiness check is appropriate for array iteration guard.The change from
! empty( $form_fields )to$form_fieldsis semantically equivalent. The variable is assigned earlier (line 251 or 258) and is eitherfalseor an array of fields. Both checks prevent iteration when the value is falsy.
503-540: LGTM - Truthiness check is appropriate for object validation.The change from
! empty( $this_form )to$this_formis semantically equivalent. The variable is assigned earlier (line 248) viamaybe_get_form()and returns either a form object orfalse. Both checks correctly determine whether to update or create a new field.classes/controllers/FrmFormActionsController.php (2)
359-363: Guard change is OK assuming$formis always an object/false.
if ( ! $form )is fine here and keeps the intent clear.
695-703: Entry guard change looks fine; keep an eye on$entrytype expectations.
if ( ! $entry || ... )is equivalent for0,'',false,nulland avoids calling into draft checks for invalid entries.classes/controllers/FrmFormsController.php (1)
2485-2496:if ( $id )is fine as a guard here.Given
$idcan be an id or key, truthiness matches the intended “only query when something is provided”.classes/helpers/FrmFormsHelper.php (4)
97-101: LGTM: truthy check works for expected usage.
$classbeing'0'still correctly skips; other non-empty strings behave the same.
338-346: LGTM:$valuestruthiness reads cleanly here.Keeps the intended “use provided array or fall back to request” behavior for the expected input types.
1114-1119: LGTM: guard reads better and stays behaviorally consistent for typical inputs.
1356-1379: LGTM:if ( $link_details )is fine for the expected array shape.classes/controllers/FrmEntriesController.php (5)
338-355:check_hidden_cols: truthiness swap looks safe for$prev_valuehere.
$prev_valueis a defined parameter, so switching fromempty()to!shouldn’t introduce “undefined var” differences, and falsy handling remains effectively the same for expected types.
440-448:base_column_key: ok, but confirm callers never intentionally pass"0"as a meaningful menu name.
! $menu_nametreats"0"as “missing” (same asempty()), which is usually fine for menu names but worth sanity-checking.
579-602:remove_excess_cols: condition change is fine given$resultis normalized to an array upstream.
Sincehidden_columns()forces non-arrays toarray(),! $resultis equivalent toempty($result)in practice.
610-649:display_list: truthiness guard is fine and preserves intent.
$messageis a local variable (always set), so! $messageis a clean simplification for the import-message flow.
750-817:process_entry: verify$errorsis never a sentinel string like"0"(unlikely), otherwise behavior is unchanged.
For typical$errorsshapes (array/string/false),! $errorsmatches the oldempty()check; worth confirming no caller uses"0"to mean “has errors”.classes/helpers/FrmAppHelper.php (6)
1152-1165:allowed_html:elseif ( $allowed )is a reasonable simplification.
For expected inputs (array of tags or empty), this matches prior behavior while being clearer.
2847-2855:setup_edit_vars:! $post_valuesis fine for the intended “missing/empty array” check.
Given$post_valuesis expected to be an array, this is equivalent to the previousempty()usage.
2890-2901:prepare_field_arrays:if ( $fields )is a clean simplification.
Handles''and[]as “no fields” and avoids iterating empty inputs.
3060-3067:custom_style_value: truthiness check is fine, but ensure$post_valuesis always an array in callers.
If any callsite passes a non-array truthy value,isset( $post_values['options']... )would warn/error; assuming it’s always an array, this change is good.
3569-3584:select_current_page: condition simplification looks correct.
! $actioncleanly covers empty arrays, keeping behavior consistent with the oldempty($action)style.
2408-2429:permission_nonce_error: all callsites correctly pass the nonce action as the 3rd parameter; implementation is safe.All 10 callsites consistently pass nonce actions (e.g.,
'frm_save_form_nonce','frm_ajax','import-xml-nonce') rather than nonce values, which matches the implementation's use of the third parameter as the action argument towp_verify_nonce(). No breaking changes to existing integrations.The optional refactoring suggestion to rename
$nonceto$nonce_actionremains valid for improving code clarity and reducing ambiguity.
…uthy_checks Add new sniff to simplify truthy checks
1 participant
This sniff tries to remove uses of
emptyinside of if conditions where we know that the value exists. This update only targets function parameters.