The Short:
When feeding the path into get_page_by_path() something like this:
$post_object = get_page_by_path( 'path_of_post', OBJECT, 'my_custom_post_type' )
… Assuming the custom post type is non-hierarchal, is there any scenario where the path entered into the function would not match a post object’s slug?
(What I mean by slug is $post_object->post_name)
=============================
The Long:
I’m using custom post types in the background for a couple of plugins I’m creating. The end-user has no access to the actual edit post screens for these custom post types. All of the admin pages the end-user actually sees are custom built.
For an example of two things I have going on: I have a plugin that creates slideshows, where each slideshow is a custom post type “slider”. I have a layout builder plugin where each custom layout is a custom post type “layout”. In this example, the two meet when within a layout, the user could assign a slideshow to the layout.
Currently I have this setup where in the post meta for a layout the user can save the post ID of a slider.
The problem with using post ID’s:
What I would like to do in the end is provide users sample XML files from WordPress’s Export tool. So, they could then just import these posts of different post types along with all post meta info, and everything will all running together without me having to build any kind of mod to WordPress’s Import/Export tool to accomodate this.
But since when you import posts from an Export file, WordPress’s built-in tool obviously has to assign new ID’s to all of the posts, so if (for example) a layout had a slider assigned to it by the post ID, when the two posts were imported, the ID of the slider would no longer match to what the layout has.
My new plan:
So, I’m trying to figure out a different way to assign everything to each other, so everything will be compatible with WordPress’s import/export and I can efficiently grab assigned posts.
The best idea I’ve had is to assign (for example) a slider to a layout by referencing the slider post’s slug $post_object->post_name. This way, on the front-end of the site, I can use WordPress get_page_by_path(); function to grab the post’s object.
So the reason for my question (see top) is just to make sure there isn’t something I’m overlooking with using this function and referencing all of these things by their slugs? Also, maybe there’s a better way to reference all of my custom post type posts other than this method I’ve come up with?
I’m not extremely familiar with the export module so what I’m suggesting may not be a fit for your needs but the answer to your stated question of “Will a post object’s
post_namealways be equal to the'path'on non-hierarchal custom post types? (usingget_page_by_path()function)” is “it depends.” 🙂More specifically, the path of a post type can be filtered using the
'post_type_link'hook, so it won’t always be equal topost_namebut interesting theget_page_by_path()function does not worry itself with that hook. So if a site uses a plugin that modifies the custom post type’s path using the'post_type_link'hook then there is a good chance they won’t sync up. Even so, sinceget_page_by_path()ignores the hook it would probably work for your needs.That said, I wouldn’t recommend using the
page_nameto link the two. I’ve tried similar in the past and down that path lies madness. It’s simply too easy for another plugin to change thepage_nameand break your associations. I’ve learned from many hard knocks that if you care about robustness then you should always store your associations (aka foreign keys) using IDs and (almost?) never human-readable strings.Better to use the
post_parentfield in your slider to store the layout’spost_id(but only if each slider is unique to a layout) or to store the layout’spost_idinwp_postmetafor a slider with ameta_keyof (something like)'_layout_id', ameta_valueof the layout’spost_id, andpost_idequal to the post ID of the slider.Would either of those two approaches work?