Query inconsistency between WP_Query and WP_Term_Query

[tonydjukic]

For the sake of standardization and simplicity would it be beneficial to use 's' for searches in WP_Term_Query rather than using 'search'?

$wpquery = new WP_Query( array( 's'=>'search term' ) );

$wptermquery = new WP_Term_Query( array( 'search'=>'search term' ) );

Not entirely sure why there's a differentiation between how a search term is used in the query args. For the sake of standardization and a reduction in confused developers (like I was about 30 minutes ago) I think this is worth some consideration.

[SergeyBiryukov]

Hi there, welcome back to WordPress Trac! Thanks for the ticket.

Yes, I think it would make sense to have s as an alias for search here in WP_Term_Query.

Changing the version to 4.6 as the earliest applicable, since WP_Term_Query was introduced in [37572] / #35381.

That said, the search argument for get_terms() was introduced in [6799], so the inconsistency dates back to WordPress 2.5.

The 'search' parameter takes precendence if both 's' and 'search' are populated. I've included two unit tests:

• Test that the 's' returns the correct terms
• Test that 'search' takes precedence when both 's' and 'search' are used

This is my first pull request so please let me know if anything needs amending! :)

Fixes: https://core.trac.wordpress.org/ticket/51811

Trac ticket:

Hi @JWardee! 👋

Thank you for your contribution to WordPress! 💖

It looks like this is your first pull request to wordpress-develop. Here are a few things to be aware of that may help you out!

No one monitors this repository for new pull requests. Pull requests must be attached to a Trac ticket to be considered for inclusion in WordPress Core. To attach a pull request to a Trac ticket, please include the ticket's full URL in your pull request description.

Pull requests are never merged on GitHub. The WordPress codebase continues to be managed through the SVN repository that this GitHub repository mirrors. Please feel free to open pull requests to work on any contribution you are making.

More information about how GitHub pull requests can be used to contribute to WordPress can be found in ​this blog post.

Please include automated tests. Including tests in your pull request is one way to help your patch be considered faster. To learn about WordPress' test suites, visit the ​Automated Testing page in the handbook.

If you have not had a chance, please review the ​Contribute with Code page in the ​WordPress Core Handbook.

The ​Developer Hub also documents the various ​coding standards that are followed:

• ​PHP Coding Standards
• ​CSS Coding Standards
• ​HTML Coding Standards
• ​JavaScript Coding Standards
• ​Accessibility Coding Standards
• ​Inline Documentation Standards

Thank you,
The WordPress Project

Fixes Ticket #51811

For searching, in addition to search, now just like in WP_Query class we can pass 's' as a parameter. This aims in keeping the code consistent.

@westonruter I am not sure why the unit tests are failing, also there is no re-running jobs option. Can you guide me on how should I proceed further.

Hey @mukeshpanchal27 , I have made the suggested changes. Can you review them.

[motylanogha]

Refreshed patch for current trunk. Adds 's' as alias for 'search' in WP_Term_Query for consistency with WP_Query. 'search' takes precedence when both are provided. 3 unit tests, all 45 term query tests pass.

WP_Query, WP_User_Query, and WP_Comment_Query all accept s as a shorthand alias for search. WP_Term_Query did not, so authors switching between query classes were silently dropping their search criterion.

This PR registers s as a recognized argument and copies it onto search when search is not explicitly set, preserving precedence for the long form.

Tests cover:

• s returns the same matches as search
• search takes precedence when both are provided
• s returns empty for no-match input

Complements GH-780 and GH-6746.

[motylanogha]

PR #11696 still applies cleanly to current trunk (7.1-alpha), CI green, with unit tests. This is a small parity fix — adding 's' as an alias of 'search' in WP_Term_Query, matching WP_Query/WP_User_Query/WP_Comment_Query. Requesting a review for 7.1 consideration.

[logicrays]

Reproduction Report

Environment

• WordPress: 7.1-alpha-62606
• Subdirectory: No
• PHP: 8.2.27
• Server: nginx/1.26.1
• Database: mysqli (Server: 8.0.35 / Client: mysqlnd 8.2.27)
• Browser: Chrome 149.0.0.0
• OS: Linux
• Theme: Twenty Twenty-Four 1.5
• MU Plugins:
  • trac-51811-term-query-s-test.php
• Plugins:
  • Test Reports 1.3.0
  • WordPress Beta Tester 4.0.0

Steps taken

1. Created temporary category "Trac51811Findable"
2. Ran get_terms() with search = Trac51811Findable -> returned Trac51811Findable (count=1)
3. Ran get_terms() with s=Trac51811Findable -> returned ["Trac51811Findable","Uncategorized"] (count=2)
4. Compared 's' results with unfiltered get_terms() -> both matched (s ignored)
5. Confirmed 's' is missing from WP_Term_Query query_var_defaults
6. 🐞 Bug occurs

Expected behavior

• 's' should work as an alias for 'search' in WP_Term_Query (same as WP_Query)
• Both should return the same filtered set: Trac51811Findable
• When both are set, 'search' should take precedence

Additional Notes

• 'search' still works correctly on this install
• 's' is ignored and returns the full unfiltered term list
• Patch under review (not applied in this test): ​https://github.com/WordPress/wordpress-develop/pull/11696
• Tester used: Tools -> #51811 Term Query Test (local mu-plugin)

Screenshots/Screencast with results

• Attached: tester results table showing search PASS (count=1) and s FAIL (count=2 = all terms)

Support Content

• search results: Trac51811Findable
• s results: ["Trac51811Findable","Uncategorized"]
• all terms (no search): ["Trac51811Findable","Uncategorized"]

[logicrays]

tester results table showing search PASS (count=1) and s FAIL (count=2 = all terms)

[logicrays]

Hello Team, as per my knowledge, I have checked and mentioned it here.
Please review it.

Rebased onto current trunk in 15c0dac. The branch had gone CONFLICTING.

The conflict was purely additive and in the test file only: trunk gained test_id_and_parent_fields_should_return_parent_ids_keyed_by_term_id() for #65817 at the same end-of-file position as the three tests here. Both sets are kept, neither was modified.

Verified after the rebase, PHP 8.3, single site:

• tests/phpunit/tests/term/query.php: OK (46 tests, 112 assertions), which includes trunk's new id=>parent test alongside the three for this ticket.
• phpcs on src/wp-includes/class-wp-term-query.php and the test file: 0 errors, 0 warnings.

Full CI is green: 153 check runs, 0 failures.

Also worth recording here that @logicrays filed an independent reproduction on the ticket (comment:9) against 7.1-alpha-62606 on PHP 8.2: search returned 1 term, s returned all of them. That is the behaviour this PR fixes and it matches test_s_param_is_alias_for_search().