Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

I see people using this to pull in page content on their home pages, remove specific categories from archives etc.. e.g.

$post = get_post( 5 );

Someone suggested this was bad practice. Why is it bad and what should users do instead?

share|improve this question
    
Isn't the real issue here to hardcode things. Although @Rarst has a point regarding the use of IDs, the same problem applies if I want to change my page/post name/path from »about« to anything else, but get_page_by_*() has been hardcoded with »about«. So I think the only solution would be to make the content to be pulled selectable. Then of course it doesn't matter if ID/name/path is used. –  ialocin Aug 26 at 16:59
1  
@ialocin note that when you have option/interface to select then the exact same issue actually applies! People often use IDs in interface, which often makes even less sense than in code. –  Rarst Aug 26 at 17:06
    
@Rarst True, so very much true! I didn't intended to suggest to show the ID at the selection interface. I merely wanted to say if it is selectable, which it should be, then the step of selecting a name and then being able to use the ID has been - pretty much - done anyway. –  ialocin Aug 26 at 17:13

2 Answers 2

up vote 7 down vote accepted

For starters let's dive into what is 5 really. It is the post's ID. But what is ID in turn? It is value in the MySQL table row which identifies the specific post record.

Issues with using IDs

So first there are some conceptual problems with it. It's not content. It's not something user creates, manipulates, or (most of the time) aware of. WP is (by design) pretty sneaky about exposing IDs to the users and almost never does it, spawning quite a few plugins around just for that purpose.

As a product of it not being content (or value meaningful for human) it's not self–documenting. There is no way whatsoever to infer what post 5 might have been from your snippet.

And finally, while ID uniquely identifies post in specific database, it's much less certain to do so as soon as content starts moving around between databases and/or even different systems.

So what are better options?

I've observed two typical reasons to retrieve and make use of standalone post.

Working with specific content in site

The persistent content is typically pretty static and in most cases can be identified by title. For example in your snippet low ID as 5 often refers to something like "About" page.

For retrieval of such content get_page_by_title() is fitting. Despite name it accepts $post_type as third argument and would work for not just pages.

So using better identification (and producing self-documenting code while at it) your snippet turns into:

$about_page = get_page_by_title( 'About' );

Working with specific place in site

Another case is when the post is used as a place in site, rather than specific content. For example we would like to retrieve site's FAQ, but not sure (or care) what it's precisely named and other content details.

But if we know where is it in site's structure we can use get_page_by_path() function, very similar to the previous:

$faq_page = get_page_by_path( 'about/faq' );

Other cases

In more complicated cases there aren't always well–fitting functions. Sometimes it boils down to using get_posts() with its rich querying options, even if only for a single post.

share|improve this answer

This question is going to get some opinion based answers, but well, I'll give it a try.

There are a couple of reasons why someone might've told you that, it would be great to know the context also.

  1. Upto version 3.4 or 3.5, that function only worked when the parameter was a var, that might be one of the reasons why someone told you that.
  2. I, myself, don't consider that to be a bad practice, but I think it's better to avoid hardcoding IDs like that. I always try to use the Options API, as it's easier to modify a value like that. You can also use the Theme Customization API in some cases.
  3. Who is gonna manage the site? If you are going to be the one managing the site, it might not be a problem to change the value. But if you expect your client to be the one having to change the code, creating a proper "options panel" it might be better.

I built something similar to that a couple of weeks ago, I wrote a plugin for it. And in the theme I just called the plugin's function. The option to change the ID was in a metabox in each post, the user just had to check a checkbox in order to select the ID of the post he wanted to display in the main site.

As you can see, most of the reason are related with whom is going to have to change the value. And creating a proper "options panel" is also useful because you can set proper data validation, in case someone makes a mistake.

If you give me more context I might be able to expand my answer, I hope you find it useful.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.