Rename WP_Http_Cookie methods to snake_case to follow coding standards

[vxo2021]

Currently, WP_Http_Cookie uses camelCase for some method names (getHeaderValue, getFullHeader), which is against the WordPress PHP coding standards. This patch renames them to get_header_value and get_full_header, updates all usages, and removes phpcs:ignore comments. This addresses the @todo in the class docblock.

Steps:

• Rename getHeaderValue() → get_header_value()
• Rename getFullHeader() → get_full_header()
• Update all usages in core
• Remove phpcs:ignore comments

This is a pure refactoring/consistency change, no functional impact.

Renames WP_Http_Cookie methods to snake_case to follow WordPress coding standards.

• getHeaderValue() → get_header_value()
• getFullHeader() → get_full_header()
• Updates all usages in core
• Removes phpcs:ignore comments

Trac ticket: https://core.trac.wordpress.org/ticket/63665

This is a pure refactoring/consistency change, no functional impact.

[peterwilsoncc]

While you are correct that the coding standards require snake case method names, this is not something we can modify in the code base for existing code as it will break backwards compatibility for any developers calling the methods directly.

The WordPress project is more rigorous about enforcing the naming convention for new callables than when these methods were introduced in 2.8.0. While the ideal would be for all code to follow the standards, WordPress prioritizes backward compatibility over that ideal.

[vxo2021]

Replying to peterwilsoncc:

While you are correct that the coding standards require snake case method names, this is not something we can modify in the code base for existing code as it will break backwards compatibility for any developers calling the methods directly.

The WordPress project is more rigorous about enforcing the naming convention for new callables than when these methods were introduced in 2.8.0. While the ideal would be for all code to follow the standards, WordPress prioritizes backward compatibility over that ideal.

Thank you for the detailed explanation!
I completely understand the importance of backward compatibility in WordPress Core and appreciate your quick feedback.
This was a great learning experience for me as a new contributor.
If there are any other areas where I could help (documentation, tests, or other good-first-bug tickets), I’d be happy to contribute.
Thanks again for your time and for maintaining such high standards in the project!

[peterwilsoncc]

Thanks for your understanding and taking the feedback in the spirit intended.

If there are any other areas where I could help (documentation, tests, or other good-first-bug tickets), I’d be happy to contribute.

Extending the test suite is a great way to contribute, there's a ticket for each release for improving coverage (for WordPress 6.9, see #63167). There is a lot of room for extending coverage if you're familiar with writing tests.

There's a similar ticket for each release to improve documentation (for WordPress 6.9 see #63166). The ​code base documentation site is generated from docblocks in the code base.

The good first bugs report also contains some small fixes that would be helpful. It's best to target tickets with the keyword needs-patch.

Another area that may be of interest is improving internationalization of strings (for WordPress 6.9 see #63629). (I gather from the website linked in your profile you speak multiple languages, I apologise if that's incorrect.)

I'll close this off as discussed on the ticket, thanks again for your understanding.