Make WordPress Core

Opened 2 years ago

Last modified 12 months ago

#57622 new enhancement

Add filter to get_page_by_path

Reported by: uzumymw's profile uzumymw Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords: has-patch
Focuses: Cc:

Description

Everything looks like that use WP_Query in get_page_by_path will be reverted 56689.

Therefore, I have an idea to add a filter that allows ability to control results.

Example:
apply_filters('get_page_by_path', $found_page, $page_path, $output_type, $post_type)

Attachments (2)

57622.2.diff (1.5 KB) - added by xipasduarte 12 months ago.
57622.3.diff (1.5 KB) - added by xipasduarte 12 months ago.

Download all attachments as: .zip

Change History (5)

This ticket was mentioned in PR #3983 on WordPress/wordpress-develop by @uzumymw.


2 years ago
#1

  • Keywords has-patch added

This ticket was mentioned in PR #7060 on WordPress/wordpress-develop by xipasduarte.


12 months ago
#2

Adds a couple of hooks to filter values inside the function get_page_by_path.

  • page_by_path_cache_key filters the value for the cache key.
  • page_by_path_id filters the found ID.

Trac ticket: core.trac.wordpress.org/ticket/57622

#3 @xipasduarte
12 months ago

Hello @uzumymw. I've taken a stab at this and provided a different version with a couple of hooks. I found your ticket based on a need I encountered where I wanted to keep the same post_name for two posts, but differentiate then by another property (language, for example). Due to the usage of this function we were not able to make it work without a bunch of hooks and corrections to the returning ID.

The hooks that I propose are:

  • page_by_path_id filters the found ID to something that the user believes is the desired result.
  • page_by_path_cache_key adds the ability to control the cache key, which allows for scenarios where the same perceived path is actually a reference for two, or more, posts, based on something else.

I didn't add the $last_changed value, because its current effect will bust all caches when the 'posts' cache group is updated. I feel we might want to keep this in the resulting value, even after filtering, so as to prevent caching issues, but I'd differ to others better equipped to answer this.

Note: See TracTickets for help on using tickets.