[WIP] Migrate deprecated functions in WP_Customize_Manager class

[Codex]

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

---

This section details on the original issue you should resolve

<issue_title>[Innovator] Migrate deprecated functions in WP_Customize_Manager class</issue_title>
<issue_description>The WP_Customize_Manager class contains multiple deprecated function calls that should be migrated to ensure code quality and maintainability. Addressing these will help prevent potential issues in future updates and improve system health.

Task

1. Identify and replace the deprecated function calls in src/wp-includes/class-wp-customize-manager.php.
2. Implement the necessary changes to use the recommended alternatives.
3. Update or create unit tests to ensure the new implementations function as expected.

Scope

Do not change any public function signatures or hook names.</issue_description>

Comments on the Issue (you are @codex[agent] in this section)

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @codex.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[nopilots-dalton]

Dalton (Security):

The changes in this pull request primarily involve replacing deprecated functions with their recommended alternatives, specifically changing sanitize_url() to esc_url_raw() in several places. This is a positive step as esc_url_raw() is more appropriate for ensuring that URLs are safe for storage and output.

1. Line 2119: The change to $self_url is safe as esc_url_raw() properly sanitizes the URL.
2. Line 2167: The use of esc_url_raw() for the allowed URLs is also safe.
3. Lines 4606-4694: The changes to set_preview_url() and set_return_url() are safe as they use esc_url_raw() correctly.
4. Lines 4926-6139: The modifications in the customize_pane_settings(), _sanitize_background_setting(), and _validate_external_header_video() functions are safe.

Additionally, the new unit tests added to check for unsafe input (like JavaScript URLs) demonstrate a proactive approach to validating the input, which is essential for maintaining security.

Overall, the changes enhance the security posture by replacing deprecated functions with safer alternatives, and the added tests help ensure that malicious input is handled correctly.

INPUT_SANITIZATION: PASS — User input is sanitized with `esc_url_raw()`.
OUTPUT_ESCAPING: PASS — Output is properly escaped.
SQL_PREPARATION: N/A — No SQL queries are present in this diff.
CAPABILITY_CHECKS: N/A — No capability checks are modified in this diff.
NONCE_VERIFICATION: N/A — No nonce verification changes are present in this diff.
ATTACK_SURFACE: PASS — The changes reduce the attack surface by using safer functions.

[nopilots-doc]

Doc (Code Quality):

1. In the diff, the migration from sanitize_url to esc_url_raw is generally appropriate for the context. However, it’s critical to ensure that all instances of URL sanitization conform to the expected behavior of the application. For example, in line 2119, the change to esc_url_raw is suitable for raw data handling, but ensure that this does not inadvertently allow unsafe data through if wp_unslash is used improperly.

2. The change in lines 4926-4934, where multiple instances of sanitize_url are replaced with esc_url_raw, should be scrutinized. Ensure that the context of these URLs is indeed meant for raw output and not for display directly in HTML, as this could lead to potential XSS vulnerabilities if misinterpreted.

3. The test case added in lines 3008-3010 for set_preview_url is a good addition, but consider ensuring that all edge cases are covered, especially with URLs that might be malformed or contain unsafe schemes.

4. The test case for _sanitize_background_setting (lines 3685-3691) is a strong addition, validating that unsafe schemes are stripped. This enhances the security aspect of your changes.

Overall, while the changes seem to improve the code quality by migrating deprecated functions, the implications of the sanitization methods used need to be carefully considered to avoid future misunderstandings or vulnerabilities.

READABILITY: PASS — The changes are clear and maintainable.
PHPDOC: N/A — No new PHPDoc comments were added or modified.
COMPLEXITY: PASS — The changes do not increase complexity.
TESTS: PASS — New tests are added to ensure functionality.
STYLE: PASS — The code style is consistent with existing code.

[nopilots-pat]

Pat (Compatibility + Decision):

The test status is failing, which is a hard stop for any further review. Even though the code changes appear to be on the right track with the migration of deprecated functions, no PR can be approved until it passes its own test suite. The focus on maintaining compatibility and ensuring the ecosystem remains stable is paramount, and that cannot be evaluated without passing tests.

TESTS: FAIL — were PHPUnit and Coding Standards green at review time?
FUNCTION_SIGNATURES: N/A — no changes made
HOOK_COMPATIBILITY: N/A — no changes made
RETURN_TYPES: N/A — no changes made
DEPRECATION_PATH: N/A — no changes made
DECISION: REQUEST_CHANGES
RATIONALE: The PR fails tests, preventing approval until resolved.

DECISION: REQUEST_CHANGES

[nopilots-pat]

Pat (Compatibility + Decision):

The test status is failing, which is a hard stop for any further review. Even though the code changes appear to be on the right track with the migration of deprecated functions, no PR can be approved until it passes its own test suite. The focus on maintaining compatibility and ensuring the ecosystem remains stable is paramount, and that cannot be evaluated without passing tests.

TESTS: FAIL — were PHPUnit and Coding Standards green at review time?
FUNCTION_SIGNATURES: N/A — no changes made
HOOK_COMPATIBILITY: N/A — no changes made
RETURN_TYPES: N/A — no changes made
DEPRECATION_PATH: N/A — no changes made
DECISION: REQUEST_CHANGES
RATIONALE: The PR fails tests, preventing approval until resolved.

DECISION: REQUEST_CHANGES