The SettingSanitization sniff is incorrectly flagging valid WordPress code patterns. Here's a minimal example demonstrating the issue:

[digitaldonkey]

The SettingSanitization sniff is incorrectly flagging valid WordPress code patterns. Here's a minimal example demonstrating the issue:

<?php
/**
 * Example demonstrating valid WordPress register_setting() usage
 * that is incorrectly flagged by PluginCheck.CodeAnalysis.SettingSanitization
 */
class Example_Plugin {
    public function register_settings() {
        // This is valid WordPress code but gets flagged:
        register_setting(
            'example_options',
            'example_options',
            array(
                'type' => 'array',
                'sanitize_callback' => array($this, 'sanitize_options'),
                'default' => array(
                    'setting_1' => true,
                    'setting_2' => 'default'
                )
            )
        );
    }

    public function sanitize_options($input) {
        $sanitized = array();
        $sanitized['setting_1'] = !empty($input['setting_1']);
        $sanitized['setting_2'] = sanitize_text_field($input['setting_2']);
        return $sanitized;
    }
}

Issues with Current Sniffer:

1. The sniffer flags array($this, 'method_name') as a dynamic argument, but this is standard WordPress practice
2. WordPress core itself uses this exact pattern extensively
3. Static arrays with 'sanitize_callback' are valid and secure
4. The current implementation forces less maintainable code patterns

Example from WordPress Core

Here's how WordPress core itself uses this pattern (from wp-admin/includes/options.php):

register_setting('general', 'blogname', array(
    'sanitize_callback' => array($this, 'sanitize_option_blogname'),
    'show_in_rest'     => true,
    'type'             => 'string',
));

Suggested Improvements

The sniffer should be updated to:

1. Recognize static arrays with 'sanitize_callback' as valid
2. Allow class method callbacks using array($this, 'method_name')
3. Consider WordPress core's own usage patterns as valid
4. Focus on actual dynamic/unsafe arguments rather than standard WordPress patterns

This would help prevent false positives while still catching genuinely unsafe code.

Originally posted by @nightwalker89 in #854 (comment)