Trim whitespace at either end of a condition value

[sean-e-dietrich]

Summary

Follow-up to #61 (#60). Storing condition values as typed also stopped trimming them. Before #60, WordPress's sanitiser trimmed every value, so this restores that one piece of the old behaviour and keeps everything else #60 fixed.

Why trim: a space nobody can see is almost always pasted by accident, and it fails silently in the worst direction. A block rule on /wp-admin (starts_with, equals, ends_with) matches nothing, and nothing says so. That's a fail-open no Site Health check can catch.

• What changes: Condition_Rule_Type_Base::validate_settings() trims leading and trailing whitespace after removing control characters. Because it's the validator, the rule screen, an import and WP-CLI all get it.
• What stays: whitespace inside a value is kept (a b), and everything Saving a rule strips < and percent-encodings from condition values #60 fixed (<, %xx, entities, quotes) is still stored as typed.
• Matching an edge space on purpose: a rule that really means to match a leading or trailing space can use a regex, where \s or \x20 is visible.
• No migration needed: Store condition values as typed; remove the unused geolocation license key (#60, #54) #61 hasn't been released, so no stored rule has a value that relies on an edge space.
• Unchanged: the 4,096-character limit.

Testing

• New ConditionValueRoundTripTest::test_whitespace_at_either_end_is_trimmed:

  • through the screen: " /wp-admin \t " is stored as /wp-admin;
  • straight through the validator (the import and WP-CLI path): edge spaces are trimmed and a b is kept.

• Unit: 326 tests pass.

• Integration: 640 tests pass. The only warnings are the existing two about the local short DB_PASSWORD.

• Static checks: composer lint and composer analyse are clean.

• CHANGELOG: the Saving a rule strips < and percent-encodings from condition values #60 entry under [Unreleased] now says values are trimmed.

• Was AI used in this pull request?