Add filters for input and output validation

[priethor]

What

Closes#149 by adding validation filters to the Abilities API to allow custom validation strategies.

Why

Current validation uses only WordPress REST's JSON Schema subset (Draft 4), whereas extenders might need support for modern JSON Schema features.

How

• Added wp_ability_validate_input filter in WP_Ability::validate_input()
• Added wp_ability_validate_output filter in WP_Ability::validate_output()
• Both filters run AFTER default WordPress validation, allowing overrides
• Filters receive validation result, data, ability name, and ability instance
• Backward compatible—default behavior unchanged if no filters attached

Testing Instructions

1. Register an ability with input_schema and output_schema
2. Add a filter to wp_ability_validate_input to use custom validation
3. Execute the ability with test data
4. Verify that the custom validator is called and validates correctly

Alternatively, run the new seven tests against trunk and verify they fail.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.48%. Comparing base (41ccde1) to head (3302da2).
⚠️ Report is 1 commits behind head on trunk.

Additional details and impacted files

@@ Coverage Diff @@## trunk #150 +/- ##
============================================
+ Coverage 80.46% 80.48% +0.02% 
Complexity 178 178 ============================================
Files 20 20 Lines 1474 1476 +2 Branches 120 120 ============================================
+ Hits 1186 1188 +2 
Misses 288 288 

Flag	Coverage Δ
javascript	94.61% <ø> (ø)
unit	76.35% <100.00%> (+0.04%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[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.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: priethor <priethor@git.wordpress.org>
Co-authored-by: justlevine <justlevine@git.wordpress.org>

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

[justlevine]

thanks so much for this PR @priethor , 🙇‍♂️ I love the use case!

Only reviewed from mobile (I'm sick ATM) and had
a quick question:

Both filters run AFTER default WordPress validation, allowing overrides

Can you share your reasoning here?
If the goal is to BYO validation, I would assume we'd want the filter to be a precheck and return early instead of running validation you know you're throwing out in favor of another parser/validation. I personally don't feel strongly either way, but since it was intentional enough for you to call out, I am curious.

(FWIW since it's a public method, a bypass hook could still be used to override/recover from a WP_Error, just with admittedly not too great ergonomics. Ironically my unrelated comment below recommends making those ergonomics slightly worse 😅)

[priethor]

Thanks, @justlevine !

Can you share your reasoning here?

I'm glad you asked, since I gave this a few thoughts. I considered adding a pre-validation filter to short-circuit it entirely, similar to how the REST works, but I think there are cases where extenders might want to extend the validation output rather than completely replace it.

For example, I could see a case where extenders want to apply the core validation to verify the input structure and, when it succeeds, apply an extra dynamic filter (e.g., checking an API) to detect forbidden words.

I don't feel very strongly either way, but it seemed to me that the potential computational cost of applying the core validation first is worth the tradeoff for the flexibility it provides. Another option that could make sense is to provide both pre- and post-filters.

[priethor]

Trac ticket, since core is the source of truth: core.trac.wordpress.org/ticket/64311

[priethor]

What

Closes#149 by adding validation filters to the Abilities API to allow custom validation strategies.

Why

Current validation uses only WordPress REST's JSON Schema subset (Draft 4), whereas extenders might need support for modern JSON Schema features.

How

• Added wp_ability_validate_input filter in WP_Ability::validate_input()
• Added wp_ability_validate_output filter in WP_Ability::validate_output()
• Both filters run AFTER default WordPress validation, allowing overrides
• Filters receive validation result, data, ability name, and ability instance
• Backward compatible—default behavior unchanged if no filters attached

Testing Instructions

1. Register an ability with input_schema and output_schema
2. Add a filter to wp_ability_validate_input to use custom validation
3. Execute the ability with test data
4. Verify that the custom validator is called and validates correctly

Alternatively, run the new seven tests against trunk and verify they fail.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.48%. Comparing base (41ccde1) to head (3302da2).
⚠️ Report is 1 commits behind head on trunk.

Additional details and impacted files

@@ Coverage Diff @@## trunk #150 +/- ##
============================================
+ Coverage 80.46% 80.48% +0.02% 
Complexity 178 178 ============================================
Files 20 20 Lines 1474 1476 +2 Branches 120 120 ============================================
+ Hits 1186 1188 +2 
Misses 288 288 

Flag	Coverage Δ
javascript	94.61% <ø> (ø)
unit	76.35% <100.00%> (+0.04%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[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.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: priethor <priethor@git.wordpress.org>
Co-authored-by: justlevine <justlevine@git.wordpress.org>

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

[justlevine]

thanks so much for this PR @priethor , 🙇‍♂️ I love the use case!

Only reviewed from mobile (I'm sick ATM) and had
a quick question:

Both filters run AFTER default WordPress validation, allowing overrides

Can you share your reasoning here?
If the goal is to BYO validation, I would assume we'd want the filter to be a precheck and return early instead of running validation you know you're throwing out in favor of another parser/validation. I personally don't feel strongly either way, but since it was intentional enough for you to call out, I am curious.

(FWIW since it's a public method, a bypass hook could still be used to override/recover from a WP_Error, just with admittedly not too great ergonomics. Ironically my unrelated comment below recommends making those ergonomics slightly worse 😅)

[priethor]

Thanks, @justlevine !

Can you share your reasoning here?

I'm glad you asked, since I gave this a few thoughts. I considered adding a pre-validation filter to short-circuit it entirely, similar to how the REST works, but I think there are cases where extenders might want to extend the validation output rather than completely replace it.

For example, I could see a case where extenders want to apply the core validation to verify the input structure and, when it succeeds, apply an extra dynamic filter (e.g., checking an API) to detect forbidden words.

I don't feel very strongly either way, but it seemed to me that the potential computational cost of applying the core validation first is worth the tradeoff for the flexibility it provides. Another option that could make sense is to provide both pre- and post-filters.

[priethor]

Trac ticket, since core is the source of truth: core.trac.wordpress.org/ticket/64311

[priethor]

What

Closes#149 by adding validation filters to the Abilities API to allow custom validation strategies.

Why

Current validation uses only WordPress REST's JSON Schema subset (Draft 4), whereas extenders might need support for modern JSON Schema features.

How

• Added wp_ability_validate_input filter in WP_Ability::validate_input()
• Added wp_ability_validate_output filter in WP_Ability::validate_output()
• Both filters run AFTER default WordPress validation, allowing overrides
• Filters receive validation result, data, ability name, and ability instance
• Backward compatible—default behavior unchanged if no filters attached

Testing Instructions

1. Register an ability with input_schema and output_schema
2. Add a filter to wp_ability_validate_input to use custom validation
3. Execute the ability with test data
4. Verify that the custom validator is called and validates correctly

Alternatively, run the new seven tests against trunk and verify they fail.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.48%. Comparing base (41ccde1) to head (3302da2).
⚠️ Report is 1 commits behind head on trunk.

Additional details and impacted files

@@ Coverage Diff @@## trunk #150 +/- ##
============================================
+ Coverage 80.46% 80.48% +0.02% 
Complexity 178 178 ============================================
Files 20 20 Lines 1474 1476 +2 Branches 120 120 ============================================
+ Hits 1186 1188 +2 
Misses 288 288 

Flag	Coverage Δ
javascript	94.61% <ø> (ø)
unit	76.35% <100.00%> (+0.04%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[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.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: priethor <priethor@git.wordpress.org>
Co-authored-by: justlevine <justlevine@git.wordpress.org>

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

[justlevine]

thanks so much for this PR @priethor , 🙇‍♂️ I love the use case!

Only reviewed from mobile (I'm sick ATM) and had
a quick question:

Both filters run AFTER default WordPress validation, allowing overrides

Can you share your reasoning here?
If the goal is to BYO validation, I would assume we'd want the filter to be a precheck and return early instead of running validation you know you're throwing out in favor of another parser/validation. I personally don't feel strongly either way, but since it was intentional enough for you to call out, I am curious.

(FWIW since it's a public method, a bypass hook could still be used to override/recover from a WP_Error, just with admittedly not too great ergonomics. Ironically my unrelated comment below recommends making those ergonomics slightly worse 😅)

[priethor]

Thanks, @justlevine !

Can you share your reasoning here?

I'm glad you asked, since I gave this a few thoughts. I considered adding a pre-validation filter to short-circuit it entirely, similar to how the REST works, but I think there are cases where extenders might want to extend the validation output rather than completely replace it.

For example, I could see a case where extenders want to apply the core validation to verify the input structure and, when it succeeds, apply an extra dynamic filter (e.g., checking an API) to detect forbidden words.

I don't feel very strongly either way, but it seemed to me that the potential computational cost of applying the core validation first is worth the tradeoff for the flexibility it provides. Another option that could make sense is to provide both pre- and post-filters.

[priethor]

Trac ticket, since core is the source of truth: core.trac.wordpress.org/ticket/64311

[priethor]

What

Closes#149 by adding validation filters to the Abilities API to allow custom validation strategies.

Why

Current validation uses only WordPress REST's JSON Schema subset (Draft 4), whereas extenders might need support for modern JSON Schema features.

How

• Added wp_ability_validate_input filter in WP_Ability::validate_input()
• Added wp_ability_validate_output filter in WP_Ability::validate_output()
• Both filters run AFTER default WordPress validation, allowing overrides
• Filters receive validation result, data, ability name, and ability instance
• Backward compatible—default behavior unchanged if no filters attached

Testing Instructions

1. Register an ability with input_schema and output_schema
2. Add a filter to wp_ability_validate_input to use custom validation
3. Execute the ability with test data
4. Verify that the custom validator is called and validates correctly

Alternatively, run the new seven tests against trunk and verify they fail.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.48%. Comparing base (41ccde1) to head (3302da2).
⚠️ Report is 1 commits behind head on trunk.

Additional details and impacted files

@@ Coverage Diff @@## trunk #150 +/- ##
============================================
+ Coverage 80.46% 80.48% +0.02% 
Complexity 178 178 ============================================
Files 20 20 Lines 1474 1476 +2 Branches 120 120 ============================================
+ Hits 1186 1188 +2 
Misses 288 288 

Flag	Coverage Δ
javascript	94.61% <ø> (ø)
unit	76.35% <100.00%> (+0.04%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[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.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: priethor <priethor@git.wordpress.org>
Co-authored-by: justlevine <justlevine@git.wordpress.org>

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

[justlevine]

thanks so much for this PR @priethor , 🙇‍♂️ I love the use case!

Only reviewed from mobile (I'm sick ATM) and had
a quick question:

Both filters run AFTER default WordPress validation, allowing overrides

Can you share your reasoning here?
If the goal is to BYO validation, I would assume we'd want the filter to be a precheck and return early instead of running validation you know you're throwing out in favor of another parser/validation. I personally don't feel strongly either way, but since it was intentional enough for you to call out, I am curious.

(FWIW since it's a public method, a bypass hook could still be used to override/recover from a WP_Error, just with admittedly not too great ergonomics. Ironically my unrelated comment below recommends making those ergonomics slightly worse 😅)

[priethor]

Thanks, @justlevine !

Can you share your reasoning here?

I'm glad you asked, since I gave this a few thoughts. I considered adding a pre-validation filter to short-circuit it entirely, similar to how the REST works, but I think there are cases where extenders might want to extend the validation output rather than completely replace it.

For example, I could see a case where extenders want to apply the core validation to verify the input structure and, when it succeeds, apply an extra dynamic filter (e.g., checking an API) to detect forbidden words.

I don't feel very strongly either way, but it seemed to me that the potential computational cost of applying the core validation first is worth the tradeoff for the flexibility it provides. Another option that could make sense is to provide both pre- and post-filters.

[priethor]

Trac ticket, since core is the source of truth: core.trac.wordpress.org/ticket/64311

[priethor]

What

Closes#149 by adding validation filters to the Abilities API to allow custom validation strategies.

Why

Current validation uses only WordPress REST's JSON Schema subset (Draft 4), whereas extenders might need support for modern JSON Schema features.

How

• Added wp_ability_validate_input filter in WP_Ability::validate_input()
• Added wp_ability_validate_output filter in WP_Ability::validate_output()
• Both filters run AFTER default WordPress validation, allowing overrides
• Filters receive validation result, data, ability name, and ability instance
• Backward compatible—default behavior unchanged if no filters attached

Testing Instructions

1. Register an ability with input_schema and output_schema
2. Add a filter to wp_ability_validate_input to use custom validation
3. Execute the ability with test data
4. Verify that the custom validator is called and validates correctly

Alternatively, run the new seven tests against trunk and verify they fail.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.48%. Comparing base (41ccde1) to head (3302da2).
⚠️ Report is 1 commits behind head on trunk.

Additional details and impacted files

@@ Coverage Diff @@## trunk #150 +/- ##
============================================
+ Coverage 80.46% 80.48% +0.02% 
Complexity 178 178 ============================================
Files 20 20 Lines 1474 1476 +2 Branches 120 120 ============================================
+ Hits 1186 1188 +2 
Misses 288 288 

Flag	Coverage Δ
javascript	94.61% <ø> (ø)
unit	76.35% <100.00%> (+0.04%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[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.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: priethor <priethor@git.wordpress.org>
Co-authored-by: justlevine <justlevine@git.wordpress.org>

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

[justlevine]

thanks so much for this PR @priethor , 🙇‍♂️ I love the use case!

Only reviewed from mobile (I'm sick ATM) and had
a quick question:

Both filters run AFTER default WordPress validation, allowing overrides

Can you share your reasoning here?
If the goal is to BYO validation, I would assume we'd want the filter to be a precheck and return early instead of running validation you know you're throwing out in favor of another parser/validation. I personally don't feel strongly either way, but since it was intentional enough for you to call out, I am curious.

(FWIW since it's a public method, a bypass hook could still be used to override/recover from a WP_Error, just with admittedly not too great ergonomics. Ironically my unrelated comment below recommends making those ergonomics slightly worse 😅)

[priethor]

Thanks, @justlevine !

Can you share your reasoning here?

I'm glad you asked, since I gave this a few thoughts. I considered adding a pre-validation filter to short-circuit it entirely, similar to how the REST works, but I think there are cases where extenders might want to extend the validation output rather than completely replace it.

For example, I could see a case where extenders want to apply the core validation to verify the input structure and, when it succeeds, apply an extra dynamic filter (e.g., checking an API) to detect forbidden words.

I don't feel very strongly either way, but it seemed to me that the potential computational cost of applying the core validation first is worth the tradeoff for the flexibility it provides. Another option that could make sense is to provide both pre- and post-filters.

[priethor]

Trac ticket, since core is the source of truth: core.trac.wordpress.org/ticket/64311

[priethor]

What

Closes#149 by adding validation filters to the Abilities API to allow custom validation strategies.

Why

Current validation uses only WordPress REST's JSON Schema subset (Draft 4), whereas extenders might need support for modern JSON Schema features.

How

• Added wp_ability_validate_input filter in WP_Ability::validate_input()
• Added wp_ability_validate_output filter in WP_Ability::validate_output()
• Both filters run AFTER default WordPress validation, allowing overrides
• Filters receive validation result, data, ability name, and ability instance
• Backward compatible—default behavior unchanged if no filters attached

Testing Instructions

1. Register an ability with input_schema and output_schema
2. Add a filter to wp_ability_validate_input to use custom validation
3. Execute the ability with test data
4. Verify that the custom validator is called and validates correctly

Alternatively, run the new seven tests against trunk and verify they fail.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.48%. Comparing base (41ccde1) to head (3302da2).
⚠️ Report is 1 commits behind head on trunk.

Additional details and impacted files

@@ Coverage Diff @@## trunk #150 +/- ##
============================================
+ Coverage 80.46% 80.48% +0.02% 
Complexity 178 178 ============================================
Files 20 20 Lines 1474 1476 +2 Branches 120 120 ============================================
+ Hits 1186 1188 +2 
Misses 288 288 

Flag	Coverage Δ
javascript	94.61% <ø> (ø)
unit	76.35% <100.00%> (+0.04%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[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.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: priethor <priethor@git.wordpress.org>
Co-authored-by: justlevine <justlevine@git.wordpress.org>

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

[justlevine]

thanks so much for this PR @priethor , 🙇‍♂️ I love the use case!

Only reviewed from mobile (I'm sick ATM) and had
a quick question:

Both filters run AFTER default WordPress validation, allowing overrides

Can you share your reasoning here?
If the goal is to BYO validation, I would assume we'd want the filter to be a precheck and return early instead of running validation you know you're throwing out in favor of another parser/validation. I personally don't feel strongly either way, but since it was intentional enough for you to call out, I am curious.

(FWIW since it's a public method, a bypass hook could still be used to override/recover from a WP_Error, just with admittedly not too great ergonomics. Ironically my unrelated comment below recommends making those ergonomics slightly worse 😅)

[priethor]

Thanks, @justlevine !

Can you share your reasoning here?

I'm glad you asked, since I gave this a few thoughts. I considered adding a pre-validation filter to short-circuit it entirely, similar to how the REST works, but I think there are cases where extenders might want to extend the validation output rather than completely replace it.

For example, I could see a case where extenders want to apply the core validation to verify the input structure and, when it succeeds, apply an extra dynamic filter (e.g., checking an API) to detect forbidden words.

I don't feel very strongly either way, but it seemed to me that the potential computational cost of applying the core validation first is worth the tradeoff for the flexibility it provides. Another option that could make sense is to provide both pre- and post-filters.

[priethor]

Trac ticket, since core is the source of truth: core.trac.wordpress.org/ticket/64311

[priethor]

What

Closes#149 by adding validation filters to the Abilities API to allow custom validation strategies.

Why

Current validation uses only WordPress REST's JSON Schema subset (Draft 4), whereas extenders might need support for modern JSON Schema features.

How

• Added wp_ability_validate_input filter in WP_Ability::validate_input()
• Added wp_ability_validate_output filter in WP_Ability::validate_output()
• Both filters run AFTER default WordPress validation, allowing overrides
• Filters receive validation result, data, ability name, and ability instance
• Backward compatible—default behavior unchanged if no filters attached

Testing Instructions

1. Register an ability with input_schema and output_schema
2. Add a filter to wp_ability_validate_input to use custom validation
3. Execute the ability with test data
4. Verify that the custom validator is called and validates correctly

Alternatively, run the new seven tests against trunk and verify they fail.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.48%. Comparing base (41ccde1) to head (3302da2).
⚠️ Report is 1 commits behind head on trunk.

Additional details and impacted files

@@ Coverage Diff @@## trunk #150 +/- ##
============================================
+ Coverage 80.46% 80.48% +0.02% 
Complexity 178 178 ============================================
Files 20 20 Lines 1474 1476 +2 Branches 120 120 ============================================
+ Hits 1186 1188 +2 
Misses 288 288 

Flag	Coverage Δ
javascript	94.61% <ø> (ø)
unit	76.35% <100.00%> (+0.04%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[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.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: priethor <priethor@git.wordpress.org>
Co-authored-by: justlevine <justlevine@git.wordpress.org>

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

[justlevine]

thanks so much for this PR @priethor , 🙇‍♂️ I love the use case!

Only reviewed from mobile (I'm sick ATM) and had
a quick question:

Both filters run AFTER default WordPress validation, allowing overrides

Can you share your reasoning here?
If the goal is to BYO validation, I would assume we'd want the filter to be a precheck and return early instead of running validation you know you're throwing out in favor of another parser/validation. I personally don't feel strongly either way, but since it was intentional enough for you to call out, I am curious.

(FWIW since it's a public method, a bypass hook could still be used to override/recover from a WP_Error, just with admittedly not too great ergonomics. Ironically my unrelated comment below recommends making those ergonomics slightly worse 😅)

[priethor]

Thanks, @justlevine !

Can you share your reasoning here?

I'm glad you asked, since I gave this a few thoughts. I considered adding a pre-validation filter to short-circuit it entirely, similar to how the REST works, but I think there are cases where extenders might want to extend the validation output rather than completely replace it.

For example, I could see a case where extenders want to apply the core validation to verify the input structure and, when it succeeds, apply an extra dynamic filter (e.g., checking an API) to detect forbidden words.

I don't feel very strongly either way, but it seemed to me that the potential computational cost of applying the core validation first is worth the tradeoff for the flexibility it provides. Another option that could make sense is to provide both pre- and post-filters.

[priethor]

Trac ticket, since core is the source of truth: core.trac.wordpress.org/ticket/64311

[priethor]

What

Closes#149 by adding validation filters to the Abilities API to allow custom validation strategies.

Why

Current validation uses only WordPress REST's JSON Schema subset (Draft 4), whereas extenders might need support for modern JSON Schema features.

How

• Added wp_ability_validate_input filter in WP_Ability::validate_input()
• Added wp_ability_validate_output filter in WP_Ability::validate_output()
• Both filters run AFTER default WordPress validation, allowing overrides
• Filters receive validation result, data, ability name, and ability instance
• Backward compatible—default behavior unchanged if no filters attached

Testing Instructions

1. Register an ability with input_schema and output_schema
2. Add a filter to wp_ability_validate_input to use custom validation
3. Execute the ability with test data
4. Verify that the custom validator is called and validates correctly

Alternatively, run the new seven tests against trunk and verify they fail.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.48%. Comparing base (41ccde1) to head (3302da2).
⚠️ Report is 1 commits behind head on trunk.

Additional details and impacted files

@@ Coverage Diff @@## trunk #150 +/- ##
============================================
+ Coverage 80.46% 80.48% +0.02% 
Complexity 178 178 ============================================
Files 20 20 Lines 1474 1476 +2 Branches 120 120 ============================================
+ Hits 1186 1188 +2 
Misses 288 288 

Flag	Coverage Δ
javascript	94.61% <ø> (ø)
unit	76.35% <100.00%> (+0.04%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[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.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: priethor <priethor@git.wordpress.org>
Co-authored-by: justlevine <justlevine@git.wordpress.org>

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

[justlevine]

thanks so much for this PR @priethor , 🙇‍♂️ I love the use case!

Only reviewed from mobile (I'm sick ATM) and had
a quick question:

Both filters run AFTER default WordPress validation, allowing overrides

Can you share your reasoning here?
If the goal is to BYO validation, I would assume we'd want the filter to be a precheck and return early instead of running validation you know you're throwing out in favor of another parser/validation. I personally don't feel strongly either way, but since it was intentional enough for you to call out, I am curious.

(FWIW since it's a public method, a bypass hook could still be used to override/recover from a WP_Error, just with admittedly not too great ergonomics. Ironically my unrelated comment below recommends making those ergonomics slightly worse 😅)

[priethor]

Thanks, @justlevine !

Can you share your reasoning here?

I'm glad you asked, since I gave this a few thoughts. I considered adding a pre-validation filter to short-circuit it entirely, similar to how the REST works, but I think there are cases where extenders might want to extend the validation output rather than completely replace it.

For example, I could see a case where extenders want to apply the core validation to verify the input structure and, when it succeeds, apply an extra dynamic filter (e.g., checking an API) to detect forbidden words.

I don't feel very strongly either way, but it seemed to me that the potential computational cost of applying the core validation first is worth the tradeoff for the flexibility it provides. Another option that could make sense is to provide both pre- and post-filters.

[priethor]

Trac ticket, since core is the source of truth: core.trac.wordpress.org/ticket/64311