Fix Abilities Explorer input schema validation

[dkotter]

What?

Closes https://wordpress.org/support/topic/bug-ability_handlervalidate_input-wont-accept-scalar-inputs/

Ensure when we validate the input schema in the Abilities Explorer page we allow both array and scalar inputs

Why?

Abilities can have input schemas that are just scalar (like a single post ID) and also support input schemas that are arrays. Our validation we run in the Abilities Explorer was only allowing array schemas so any Abilities that had scalar schemas were rejected.

How?

Remove the array type hint on both invoke_ability and validate_input so scalar schemas can be used.

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Opus 4.8
Used for: Validating bug, suggesting a fix and executing that fix. Final review and testing by me

Testing Instructions

1. Enable the Abilities Explorer feature
2. Go to Tools > Abilities Explorer
3. Choose an Ability from the list and click on it (like Get Environment Info)
4. Click the Test Ability button
5. From here, click the Validate Input button to ensure the schema validates correctly
6. Click the Invoke Ability and ensure the Ability is triggered successfully

Changelog Entry

Fixed - Ensure scalar input schemas are allowed in the Abilities Explorer validation.

[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: @squarestar.

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

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

Unlinked contributors: squarestar.

Co-authored-by: dkotter <[email protected]>
Co-authored-by: jeffpaul <[email protected]>

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.57%. Comparing base (d400910) to head (b20616f).

Additional details and impacted files

@@              Coverage Diff              @@
##             develop     #787      +/-   ##
=============================================
+ Coverage      76.48%   76.57%   +0.09%     
- Complexity      1869     1870       +1     
=============================================
  Files             89       89              
  Lines           7990     7992       +2     
=============================================
+ Hits            6111     6120       +9     
+ Misses          1879     1872       -7     

Flag	Coverage Δ
unit	76.57% <100.00%> (+0.09%)	⬆️

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

☔ View full report in Codecov by Harness.
📢 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.

[jeffpaul]

Tested via P{layground and using test steps things worked as expected.

[squarestar]

The mark_setting() method in Show_In_Abilities.php is hooked to the register_setting_args filter and has a strict array type declaration for $args. One plugin on my system (WPBakery Page Builder) calls register_setting() with null args, which causes a fatal error. Maybe this method needs to account for issues in plugins? A defensive solution could be:

public function mark_setting( ?array $args, array $defaults, string $option_group, string $option_name ): array {
    $args = $args ?? [];

[dkotter]

The mark_setting() method in Show_In_Abilities.php is hooked to the register_setting_args filter and has a strict array type declaration for $args. One plugin on my system (WPBakery Page Builder) calls register_setting() with null args, which causes a fatal error.

Thanks for the flag there. I'd argue that's an issue in that plugin as they shouldn't be returning null for that, they should be using an empty array, but that is a good flag. I've pushed b20616f to remove the typing on these params to avoid these issues, plus adding an is_array check

[jeffpaul]

@squarestar if you can connect your GitHub and WordPress.org accounts, then I can formally credit you on the release announcement post and grant the AI Contributor badge.

[squarestar]

Thanks but that WP account isn't the one I'd want connected to this GH account. I've connected my WP squarestar account but I used a different one to open the topic on wp.org. No worries if you don't credit me.

[jeffpaul]

@squarestar what's your preferred WPORG account to credit for work on this AI plugin release then?

[squarestar]

https://profiles.wordpress.org/squarestar/

Thanks!