Subcategory archive does work with any name as parent category in URL

[ocean90]

Parent category is parentcategory and his sub category is subcategory.

The URL will be domain.com/category/parentcategory/subcategory.

The problem is, that you will get the same page if you use any words as parentcategory.

Examples:

• domain.com/category/xxx/subcategory
• domain.com/category/subcategory
• domain.com/category/foo/bar/subcategory

IMO redirect_canonical should do his work here (and sometimes it does).

In 3.1 it does redirect.
In 3.1.4 it doesn't redirect; after r17549.
In 3.2.1 it doesn't redirect.
Duck_ found that it does redirect before r18079.
In current trunk it doesn't redirect.

[duck_]

We need tests for all the bugs the have been fixed and unfixed over time.

Related: #17174, #16627, #12659

[duck_]

Some more canonical tests: ​[UT444]

History in trunk

[13091] for original /category/child/ to /category/parent/child/ redirection.

Broken by [15462] as "The easiest one is to assume that if we had come to the right category page without any get variables, we don't need the logic for redirecting to the canonical category page. This is valid statement, because that logic relies only on removing get arguments." (#14201) is incorrect. parse_url($tax_url) ... $redirect['path'] = $tax_url['path']; is redirecting to the correct term link.

Fixed again in [15705], but re-introducing #14201. The scope of the !empty($redirect['query'] conditional was changed.

Re-broken by [18079] which moved stuff back inside !empty($redirect['query'] (also fixing #14201 again).

tl;dr: canonical isn't kicking in unless the URL has a query. This was done as a stop-gap fix for #14201.

[ocean90]

Duck_, any idea what we can do here?

[juliobox]

Waiting for a fix, i created this hack:

add_action( 'wp', 'baw_non_duplicate_content' );
function baw_non_duplicate_content()
{
	global $wp_query;
	if( isset( $wp_query->query_vars['category_name'], $wp_query->query['category_name'] )
		&& $wp_query->query_vars['category_name'] != $wp_query->query['category_name'] ):

		$correct_url = str_replace( $wp_query->query['category_name'], $wp_query->query_vars['category_name'], $wp->request );
		wp_redirect( home_url( $correct_url ), 301 );
		die();
	endif;
}

[SergeyBiryukov]

#25737 was marked as a duplicate.

[wonderboymusic]

This hasn't received any action in a while ... should these redirects be occurring? are we intentionally not touching this?

[SergeyBiryukov]

Replying to wonderboymusic:

should these redirects be occurring?

This crops up on support forums once in a while, so I would say yes, as long as it doesn't introduce any regressions. Looks like this should be handled together with #14201.

[boonebgorges]

Removing from trunk as per #30284

[ocean90]

#31022 was marked as a duplicate.

[dd32]

#31022 was marked as a duplicate.

[kasparsd]

Compare the full category paths

[kasparsd]

Attached is a patch that will

• ensure that the current category has a parent category,
• ensure that the category permastructure actually contains the category slug %category%

Only then it will

• generate a list of all parent categories,
• check if the category path matches the $wp->query_vars['category_name']
• replace the incorrect category path $wp->query_vars['category_name'] with the correct one

Notice that this approach will respect any pagination, feeds and custom endpoints that might be present in the URL.

[kasparsd]

Include the category permastructure in the replacement strings.

[kasparsd]

And here are the tests.

[SergeyBiryukov]

#41211 was marked as a duplicate.

[SergeyBiryukov]

#55273 was marked as a duplicate.

[dd32]

#55735 was marked as a duplicate.

[huzaifaalmesbah]

Tested both attached patches against current trunk:

• 18734-tests.diff – rejects in PHPUnit test files
• 18734-proper-replace.diff – rejects in wp-includes/canonical.php

Both patches fail to apply cleanly, so the changes cannot be tested at this time. The patches appear to be outdated (10+ years old) and need rebasing for current trunk.

Removing needs-testing and i see already have needs-refresh.

as a refreshed patch and core review will be needed before further testing.

Trac ticket: https://core.trac.wordpress.org/ticket/18734

[kasparsd]

Thanks for testing @huzaifaalmesbah!

I've refreshed the patch ​as a pull request and tested it locally. Everything appears to be working correctly -- here is a test setup with subject as category permalink prefix and top → top-child as hierarchical terms:

curl -v http://localhost:8889/subject/INVALID/top-child/
* Host localhost:8889 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:8889...
* Established connection to localhost (::1 port 8889) from ::1 port 65036 
* using HTTP/1.x
> GET /subject/INVALID/top-child/ HTTP/1.1
> Host: localhost:8889
> User-Agent: curl/8.17.0
> Accept: */*
> 
* Request completely sent off
< HTTP/1.1 301 Moved Permanently
< Server: nginx/1.29.4
< Date: Tue, 03 Feb 2026 11:28:57 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< X-Powered-By: PHP/8.2.29
< X-Redirect-By: WordPress
< Location: http://localhost:8889/subject/top/top-child/

I also confirmed that post permalinks with %category% fragments still redirect as expected.