Bug fix release. Shared slugs previously worked on custom post types but silently did nothing on the default post type.
The bug
PLL_Shared_Slugs::should_constrain_flat() read the queried post type as:
$pt = $qv["post_type"] ?? "post";WP_Query fills post_type with an empty string (not null) before posts_where fires, so ?? never fell back. The guard then tested pll_is_translated_post_type("") — false — and skipped the language constraint.
That affected exactly one post type: post, the only one whose rewrite rule omits post_type from the query. Custom post types carry an explicit post_type and were never affected.
Impact
With two translations sharing a post slug, both matched the by-name query, so:
- a single-post template looped over every translation, rendering each language copy one after another on the same page, and
- the default-language URL 301-redirected to whichever translation sorted first.
Fix
Fall back on emptiness rather than nullness. Arrays and "any" still bail out via the existing is_string / is_translated_type checks, so all conservative cases are unchanged.
No settings or data changes; update and the fix applies.