WordPress.org

Make WordPress Core

Opened 4 months ago

Last modified 3 months ago

#52889 new enhancement

Add filter to disable forced plain permalinks

Reported by: cneumann Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.7
Component: Permalinks Keywords:
Focuses: Cc:

Description

There should be an option to disable forced plain permalinks introduced with #5272. In my use case, showing the permalinks is totally fine and a requirement, even for private posts. Even worse, wp_force_plain_post_permalink results in additional capatibility checks which are expensive in my use case, especially for pages with lots of permalinks (e.g. menus). Setting the posts or the post statuses to public is not possible, as this results in other unwanted side effects. With wp_force_plain_post_permalink, there is currently no way to have the old behaviour.

As a proposal, I added a patch that introduces a filter for wp_force_plain_post_permalink to completely disable the check.

Attachments (1)

link-template.diff (812 bytes) - added by cneumann 4 months ago.
Proposal to add filter to wp_force_plain_post_permalink

Download all attachments as: .zip

Change History (4)

@cneumann
4 months ago

Proposal to add filter to wp_force_plain_post_permalink

#1 @peterwilsoncc
4 months ago

@cneumann Just a quick note to acknowledge this, I'm currently focused on the 5.7.1 release so will get back to you once that is out.

#2 @peterwilsoncc
3 months ago

  • Component changed from Security to Permalinks

A part of the reason for introducing the function was that get_permalink() could return URLs for valid, public posts that would throw a file not found error. This was a particular problem for attachments, please see #52373 as the commit for #5272 was only a partial fix.

The main reason was to prevent data exposure of private post urls to unauthorised users. The permission check only runs for private post statuses.

Are you able to explain a little more about your use case, particularly where the expense is coming from for testing the user capabilities? current_user_can() uses a cached user object so the extra function calls shouldn't be too expensive.

Finally, if this enhancement is added I'd suggest a preflight/short-circuit filter rather than a disabling filter. This is similar to how such filters work in other functions (see the pre_wp_mail filter for an example) but provides a little more flexibility to developers like yourself :)

<?php
function wp_force_plain_post_permalink( $post = null, $sample = null ) {
        // ... 

        /**
         * Preflight forcing of plain permalinks.
         *
         * Allow plugins to override how the use of plain permalinks are determined.
         */
        $preflight = apply_filters( 'pre_wp_force_plain_post_permalink', null, $post, $sample );
        if ( null !== $preflight ) {
                return $preflight;
        }

        // ... 
}

#3 @cneumann
3 months ago

@peterwilsoncc I have custom checks as a map_meta_cap filter for the read_post capability that are expensive. I could cache them for permalinks, but I don't now who called the check and I must not cache the check for all calls (e.g. when a page is actually visited and I have to decide if the user is permitted to do so).

Yes, the preflight filter looks even nicer. Would be a good solution to have something like this.

Note: See TracTickets for help on using tickets.