[wp-trac] [WordPress Trac] #65412: Namespace collision in WP 7.0 Font Library query var overrides custom router page_slug

[WordPress Trac]

#65412: Namespace collision in WP 7.0 Font Library query var overrides custom
router page_slug
--------------------------+------------------------------
 Reporter:  sgovaerts     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Query         |     Version:  7.0
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Description changed by wildworks:

Old description:

> ### Description
> After upgrading to WordPress 7.0, websites utilizing a custom routing
> system or custom rewrite rules that register and use the query variable
> `page_slug` experience breaking behavior.
>
> With the introduction of the new Font Library feature in WP 7.0, the core
> now internally claims and heavily uses the `page_slug` query/global
> variable. If a custom route is accessed where our custom `page_slug` is
> intended to be empty or null (e.g., viewing a main archive/overview
> page), WordPress 7.0 forcefully overwrites this empty variable with the
> string `'font-library'`.
>
> ### Steps to Reproduce
> 1. Register a custom route via a routing system or standard
> `add_rewrite_rule()` that captures a variable named `page_slug`.
> 2. Navigate to a URL corresponding to the route where the `page_slug`
> parameter should remain empty/unset (e.g.,
> `mysite.com/department/service/docs`).
> 3. Dump the variable inside the loaded template file using
> `get_query_var('page_slug')` or inspection of global arguments.
>
> ### Expected Behavior
> `get_query_var('page_slug')` should return `null`, `false`, or an empty
> string, allowing the template logic to process the page as a root/archive
> page.
>
> ### Actual Behavior
> The variable is hijacked by the WP 7.0 core. `get_query_var('page_slug')`
> unexpectedly returns the string `'font-library'`.
>
> This causes severe backward compatibility issues. Template logic checking
> `if ( !empty($page_slug) )` gets triggered falsely. Functions like
> `get_page_by_path('font-library')` are subsequently executed, returning 0
> results and leading to blank pages (broken template loops) for existing
> custom implementations.
>
> ### Suggested Fix
> The Font Library core feature should use a more strictly namespaced query
> variable (e.g., `wp_font_page_slug` or `wp_font_library_slug`) instead of
> the generic `page_slug` to maintain backward compatibility with existing
> custom themes, routers, and plugins that have been using this common
> variable name for years.

New description:

 After upgrading to WordPress 7.0, websites utilizing a custom routing
 system or custom rewrite rules that register and use the query variable
 `page_slug` experience breaking behavior.

 With the introduction of the new Font Library feature in WP 7.0, the core
 now internally claims and heavily uses the `page_slug` query/global
 variable. If a custom route is accessed where our custom `page_slug` is
 intended to be empty or null (e.g., viewing a main archive/overview page),
 WordPress 7.0 forcefully overwrites this empty variable with the string
 `'font-library'`.

 === Steps to Reproduce
 1. Register a custom route via a routing system or standard
 `add_rewrite_rule()` that captures a variable named `page_slug`.
 2. Navigate to a URL corresponding to the route where the `page_slug`
 parameter should remain empty/unset (e.g.,
 `mysite.com/department/service/docs`).
 3. Dump the variable inside the loaded template file using
 `get_query_var('page_slug')` or inspection of global arguments.

 === Expected Behavior
 `get_query_var('page_slug')` should return `null`, `false`, or an empty
 string, allowing the template logic to process the page as a root/archive
 page.

 === Actual Behavior
 The variable is hijacked by the WP 7.0 core. `get_query_var('page_slug')`
 unexpectedly returns the string `'font-library'`.

 This causes severe backward compatibility issues. Template logic checking
 `if ( !empty($page_slug) )` gets triggered falsely. Functions like
 `get_page_by_path('font-library')` are subsequently executed, returning 0
 results and leading to blank pages (broken template loops) for existing
 custom implementations.

 === Suggested Fix
 The Font Library core feature should use a more strictly namespaced query
 variable (e.g., `wp_font_page_slug` or `wp_font_library_slug`) instead of
 the generic `page_slug` to maintain backward compatibility with existing
 custom themes, routers, and plugins that have been using this common
 variable name for years.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65412#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform