[wp-trac] [WordPress Trac] #42148: url_to_postid plain permalinks for CPTs

[WordPress Trac]

#42148: url_to_postid plain permalinks for CPTs
-------------------------+-----------------------------
 Reporter:  soulseekah   |      Owner:
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Permalinks   |    Version:  trunk
 Severity:  normal       |   Keywords:
  Focuses:               |
-------------------------+-----------------------------
 Would be nice to have {{{url_to_postid}}} working with plain permalinks
 for custom post types.

 There's are currently some issues in {{{url_to_postid}}} where the wrong
 ID is returned for custom post type plain permalinks (query-based).

 {{{
 <?php
 add_action( 'init', function() {
         /** Register a post type */
         register_post_type( 'findme', array(
                 'public' => true
         ) );

         /** Create a post */
         $post_id = wp_insert_post( array( 'post_type' => 'findme',
 'post_status' => 'publish' ) );
         $findme = get_permalink( $post_id );
         $found = url_to_postid( $findme );

         /** Guess it */
         printf( "%s (%s) == %s (%s)", $post_id, $findme, $found,
 get_permalink( $found ) );
         exit;
 } );
 }}}

 {{{30 (http://localhost:8080/?findme=30) == 0 ()}}} and {{{30
 (http://localhost:8080/?findme=30) == 2 (http://localhost:8080/)}}} if the
 frontpage is setup to point ot a post.

 Why is it not working? Why is the frontpage post being returned? Let's see
 how the {{url_to_postid}} function works:

 {{{
 // First, check to see if there is a 'p=N' or 'page_id=N' to match against
 if ( preg_match('#[?&](p|page_id|attachment_id)=(\d+)#', $url, $values) )
 {
   $id = absint($values[2]);
   if ( $id )
     return $id;
 }
 }}}

 Then?

 {{{
 if ( trim( $url, '/' ) === home_url() && 'page' == get_option(
 'show_on_front' ) ) {
   $page_on_front = get_option( 'page_on_front' );
   if ( $page_on_front && get_post( $page_on_front ) instanceof WP_Post ) {
     return (int) $page_on_front;
   }
 }
 }}}

 Uh, wait what... already? So a short-circuit without checking the custom
 post types. And that's understandable, since there is inherently no
 support for custom post type ID mappings as pointed out by:

 {{{
 // Check to see if we are using rewrite rules
 $rewrite = $wp_rewrite->wp_rewrite_rules();

 // Not using rewrite rules, and 'p=N' and 'page_id=N' methods failed, so
 we're out of options
 if ( empty($rewrite) )
   return 0;
 }}}

 What stands in our way to find the URL earlier?

 1. The query var is not one of p, page_id, attachment_id
 2. The query var value for CPTs is not necessarily, and most often not
 numeric (the post_title)

 A proposed solution would be to look at the query parameters much higher,
 maybe by injecting the custom ones, ones that support slugs as well, since
 WordPress sets the {{{page_title}}} for a CPT itself, so that {{{\d+}}}
 check would fail.

 Use case? Well, this was encountered when trying to paste plain oEmbed
 URLs for a custom post type
 (https://github.com/gravityview/GravityView/issues/927).

--
Ticket URL: <https://core.trac.wordpress.org/ticket/42148>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform