Make WordPress Core

Opened 17 months ago

Last modified 9 days ago

#57021 new defect (bug)

Sanitize should accept broader types

Reported by: kkmuffme's profile kkmuffme Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 6.2
Component: Formatting Keywords: has-patch close dev-feedback
Focuses: Cc:

Description

by default $_GET/$_POST can be string|array type.

All sanitize functions accept only string, which makes it necessary to validate $_GET/$_POST for is_string all the time before calling sanitize function to avoid PHP notices.

Instead sanitize function should accept mixed param and validate string internally.

Change History (7)

This ticket was mentioned in PR #3576 on WordPress/wordpress-develop by @kkmuffme.


17 months ago
#1

  • Keywords has-patch added

This ticket was mentioned in Slack in #core by kkmuffme. View the logs.


2 months ago

#3 @swissspidy
2 months ago

The expectation here is that the caller should be doing this initial sanity check. I don't think it's scaleable for core to add these is_string() checks everywhere.

#4 @swissspidy
2 months ago

  • Focuses coding-standards removed
  • Keywords close dev-feedback added

#5 @kkmuffme
2 months ago

The expectation here is that the caller should be doing this initial sanity check.

Why? Like you say: this wouldn't be feasible for WP core, since it would require changes in 1000s of places. This PR ensures that it works fine everywhere in WP core and eventually also with PHP native types.

Manually checking this everywhere, creates tons of redundant code for is_string checks in lots of places.

#6 @kkmuffme
2 weeks ago

  • Type changed from enhancement to defect (bug)

The expectation here is that the caller should be doing this initial sanity check.

It seems this wasn't the expectation, since there are existing tests that pass non-string.

This leads to a bug where the types declared in apply_filters are wrong therefore breaking any callbacks that use PHP native types.

This is why I changed the type to bug now - since it was annotated as string type, but it accepted mixed (but only handled some cases correctly) and passed an invalid type in the apply_filters.

That's also why I reverted my @since annotations in many cases I added in the initial commit, since they wouldn't make sense - since it was mixed all along.

It's ready to be reviewed and merged now.

This ticket was mentioned in Slack in #core by kkmuffme. View the logs.


9 days ago

Note: See TracTickets for help on using tickets.