This page was created by MDAWaffe, and moved in. The title "Pages" was chosen since it talks about all aspects of creating and using pages. The content can be split into multiple files as and when this gets too long.

Carthik 16:36, 7 Feb 2005 (GMT)

Agreed, it will probably have to be split up at some point. The whole nomenclature bit may be unecessary as time goes by, as well. Also, the "Codex should do this/Codex should do that" was not meant to be definative, but rather... riot inducing? I'm hoping people will stick their head in and say "that's awful and foolish" until some sort of consensus is reached.

I'd particularly like other people's thoughts on the static v. dynamic issus. I more or less made it up on the spot, though I agree with myself :) My way of looking at it says that all Pages are dynamic since all of them are pulled from the database when necessary. The only way to make a 100% truly static content page through the WordPress interface without a special plugin is by making a flat file through the file editor.

The issue is that if people start calling anything but flat HTML "static" then, in addition to incorrectly using the term (in my opinion), they lose the ability to easily understand what real static pages are and what plugins which make them actually do: So this "Ultra Staticizer 20X6" makes pages static? So it turns Posts into Pages? That's nice - can it also be used it to make stickies? (or some other flawed logical chain). How is someone thinking this going to survive a slashdotting? (Though, most of the people in danger of being slashdotted probably already understand the difference and would just use wget instead). --MDAWaffe 19:45, 7 Feb 2005 (GMT)

I reworked the stat v dyn bit a bit. It previously said Pages have static content, in that the content of a particular Page does not change. True, but so do Posts; the content of a paticular Post does not change. The real "static nature" of a Page comes from the fact that it's content is timeless. Posts apply to a specific moment in time (breakfast was good this morning), the information described in Pages is applicable for a long interval of time (my name is Zarqon). --MDAWaffe 20:30, 7 Feb 2005 (GMT)

---

On another, perhaps less productive note, I really hate the name of this feature. I'm not blaming anyone, it's just an awful name from a user perspective. Is it worth talking to the devs about doing a 180, pissing off hundreds of people who are already using it, hopefully even changing the name of wp_list_pages, and in general creating a HUGE short-term mess in order to change the name of "Pages" to "...Anything Else".

I know, I don't have any good ideas, so the point may be moot. I kind of like "Folio" though.

• Pane
• Shell
• Sheet
• Partition
• Facade
• Folio
• Spread
• Leaf
• Panel
• Record

?? --MDAWaffe 19:45, 7 Feb 2005 (GMT)

---

1) The name of the feature was not chosen after deliberation, it just happened to take on some common-sensical name. I am particularly averse to different web-based cmses and software defining and using their "own" terms for features, which would serve to confuse the reader. I beleive "pages" is simple, straightforward and conveys the meaning. After all, this feature was born in response to "how do I use WP to create and manage pages on the server, besides the blog?", so I'd lean towards not renaming the feature - this is only my personal opinion, of course.

2) The reason I rewrote most of the stuff I did in this article is because the Codex aims at being functional, task-oriented documentation. A lay user should not have to be involved in discussions regarding the "semantics" or the "reasons" behind any feature, unless it furthers their ability to use the provided features. What does the user gain by reading up on what "static" pages are and what "dynamic" pages are? After all, the user wants to create and manage pages using WordPress, and I guess we should deal with that first. Long, descriptive prose would not be what they would be looking for - which is my underlying assumption when creating articles. so say it short and sweet, and provide steps for users to follow, since they are often impatient and just want to "get on with the job", so to speak.

3) It would be good to limit discussion of a "meta" nature (like how Codex should work in general etc) to Talk pages, and keep articles to the point and relevant.

4) Post don't really "come and go" - a post, as well as a page, will stay as long as the user want either to :) So maybe we could change that a little.

Do you really think we need to be verbose about what static pages are, what dynamic pages are etc? Can we not define what "pages" are in WordPress' terms and be done with describing how to create and manage them?

Carthik 21:09, 7 Feb 2005 (GMT)

1) Coming up with new words for things that already have good words associated with them is annoying, but here I don't think there is a good word for this feature. The problem is exactly "pages besides the blog". Literally everything you see at a WordPress site (be it the site itself or the admin section) can be described as a "page". And rightfully so. They are all webpages. I am certainly not trying to take that terminology away. But calling a very specific feature by a name which is otherwise used to lable a very generic thing is confusing. Also, since Pages are such a core feature of 1.5, they will soon be considered part of the blog.

Pages are not hard to use once you understand them, but I think the terminology creates an activation barrier to that understanding. Perhaps, though, the real problem is that it makes Pages difficult to talk about (meta, as you say). But that means that support will be difficult and frustrating as well. And this documentation should attempt to minimize the amount of support (as in forums) needed.

2) I see your point. Perhaps only a brief notational note should be made at the top, and the rest should be moved to the end of the page (or to a different page). Users gain nothing in terms of being able to use a feature by knowing meta-information about the feature. But again, this brings up the issue of support. Someone necessarily needs to know about the meta-information in order to talk about it and ask clear questions (or respond clearly to questions). Flat HTML vs. Pages might be confusing to some people. It'd be nice if it were described somewhere. Again, a small note and a link to a different document might be appropriate.

3) Meta: again - support and clarity. Again - a different page.

4) You see how hard it is to talk about these things? ;) And I thought I was being so clear. I meant Posts come and go in the sense that they come and go off the main page. But you're absolutely right - it's the exact same issue I had with "Page content is static (implying Post content is not)".

Really this is all just an issue of how to talk about the feature, not use it. In that sense, I agree with you; it may not be appropriate for this document. It needs to be somewhere, though. Blogs don't sit out on an island, people talk about them (conversationally, in support forums, etc.) and need to be able to communicate effectively. Using a "wrong" word to describe something makes that somethign difficult to understand, and it makes that something difficult to talk about (making it hard to make someone understand - you see the recursion).

Or maybe I'm jsut being anal :) --MDAWaffe 21:54, 7 Feb 2005 (GMT)

The document, as is, is good enough. It can be improved by addressing issues like what do I use this for? and how do I create a bunch of sensible pages? more effectively. I guess this document already does that, so no sweat. Users can always ask questions, and this page can be refined further, so no big deal :) Let the static and dynamic dialogue remain - it might be useful to the end-user to get acquainted with these things, and lower some gaps between users and support vols. It can be trimmed later, as and when it's required.

Carthik 22:26, 7 Feb 2005 (GMT)

Maybe, in the end, it'll be best to talk about "static Pages" and "truly-static pages" (the latter implying flat HTML). It seems, at any rate, that's how things are pointing. I don't like it in that I don't think "it's right", but I love it that I think people would be comfortable with the terms and, hopefully, understand them. It certainly helps to differentiate Pages from generic pages. Of course if someone learns these terms from WordPress and then ventures out into the world at large on his/her own, he/she might get confused all over again :)

Anyway. So you don't think moving the nomenclature to the bottom (but leaving the notation) at the top is necessary? The idea is growing on me, as it allows the page to get to the point faster, as you point out. Though I suppose it's more pedagogical to leave it at the top. I leave it up to you or someone else. Do as you will with it. --MDAWaffe 23:22, 7 Feb 2005 (GMT)

Well, let it be the way it is, makes for interesting reading :)

Carthik 08:11, 8 Feb 2005 (GMT)

Excuse me for jumping in, but this has been one of the biggest problems I've had getting my head around 1.5 and how it works. On the forums, I'm not alone in the confusion of trying to understand and explain the different between a page and a Page. Helping out by editing the codex, I'm always challenged with which page is being discussed. Before 1.5 is totally released to the public, the issue over page vs Page has to be dealt with and a decision must be reached. Calling it a "pane" or "shell" or "pane page" or "shell page" or whatever, it needs to have an identifying feature to separate it from post pages.

These things grow of their own accord, I know, but we have to think further into the future rather than frustrating people with a new name for a feature common to other software programs. What do others call the Page? Or is WordPress the first with it? Is it called Page? If not, and no one has it, then we need to set the standard for what this is to be called. Make it simple, make it identifiable, and make it memorable.

Lorelle 01:17, 11 Feb 2005 (GMT)

Document types

Pages are not Posts. They do not cycle through your blog's main page, nor can they be associated with Categories.

Hi,

I'm quite new to WP. I was just wondering is there any plans for a "document type" functionality like in Daisy and Drupal? The idea is, that all content would be stored, retrieved and handled the same way. And that you could define your own document types.

I would try the forums --MDAWaffe 09:41, 12 Feb 2005 (GMT)

Edits as of 2/17/05

This is really an amazingly wonderful work, MDA. And of course, I have a few nags and questions.

At least on this page, since the Pages and pages are discussed a lot, we at least identify them by calling them Individual Pages or individual Pages. They are individuals, at the least. Until a decision is made. No need to use it for every reference but the ones where it gets confusing might help.

I agree with the others that the Notations and Nomenclature should be appreviated and the comment that pages are not posts... is very condensed but very helpful. I can slash and burn, but I thought I'd give you first option.

In the section "What Template is used to Display a Particular Page?", I did a minor clarification edit but this isn't clear if it is referring to a Page or a page.

In the section on "Using Pages" here is my rewrite with a few spelling fixes. Use it if you would like. Basically, it just offers a better intro for each section and organizes them in a way that seems to work better for the new user discovering this process for the first time. Note: As a general rule, when using two ll words like traveling and labeling, there is only one l, unless you come from a country that doubles their Ls.

I hope this helps and doesn't hurt. If you want me to put these changes in, I will. The core is intact, just a little housekeeping.

Lorelle 17:55, 17 Feb 2005 (GMT)

Good work.

1. If you think the occassional "Individual Page" is clearer, go ahead.
2. I would like to see a brief notation blurb at the top and the rest of the nomenclaturre moved to end of this article. I can do that after all the other edits you mention are settled (then you can go in and fix it :)) Thoughts?
3. I like my version of the "What Template is used to Display a Particular Page?" better for the following reasons. First, the Template is not a "Template Page"; it's a Template. It's just a file with those special five lines at the top. Second, You version makes it sound like WordPress goes through everything on the list and somehow applies the formatting found in each of those places to the Page. This is not true; WordPress uses only the first item it finds from that list. That needs to be clear.
4. Your rewrite of Using Pages is fine except for two things (In my opinion).
   • "Pages Can Have Specific Uses Such as for Forms". This should not be its own section. It should be an example in the "Pages Can Use Different Templates" section, since that's exactly what you're doing: making a new Template that offers forms for use with a particular Page. At some point, we'll run into a problem: too many good examples in the artcle. At that point I suggest making a subarticle: Pages/Examples. Put a few choice, basic, simple examples in the article and move the more complicated ones to that subarticle (of course, including a bright and obvious link).
   • "Pages Can Be Used Instead of Category Pages". This idea can be much better handled with Category Templates as opposed to Page Templates. I still plan on putting that forum discussion of ours into Codex, but it is not a Page issue. It is a Template issue and a Category issue. Recall, "Template" is a very generic word. index.php, for example, is a Template but has nothing to do with Pages (necessarily).

I agree with it all. Have your way with it as you feel. The only reason I pulled out the specific "Pages Can Have..." because it explains the specific uses of the Pages as functions. This isn't a difficult concept, but people are having some trouble with it, so outlining the specific uses as to why these are treated a bit differently will help.

I agree there should be a page with specific examples for the different uses.

What kind of a "brief notation blurb" are you thinking about? And YEAH the explanation should be moved to the bottom.

Now, it's a you or me thing. Do your worst, since this is your baby, and then I'll come in with another axe ;-).

Lorelle 21:06, 17 Feb 2005 (GMT)

All good suggestions. I don't have time to work in it now (and I don't think of it as "my baby" :)) so go ahead and change what you think is approriate. I'll do now what I meant about notation/nomenclature. I'll try to keep up with the changes people make, though. --MDAWaffe 01:46, 20 Feb 2005 (GMT)

OK - did what I can do now. If you've got the time to put in those corrections from above, please do so (pretty please?). Also, I've a preliminary doc on Category Templates here: Category_Templates. My you're doing awesome work --MDAWaffe 02:38, 20 Feb 2005 (GMT)

Okay, I've poked and shoved at this a little more and added a bit that lists specific examples of uses of Pages to help people get their heads around the concept of out of the time loop Pages. And of course, I live to make your life complicated, so I had some, shall we call them thoughts.

Since Pages are out of the Category loop, how do you list specific pages from within your index.php loop that will list the pages that might need to be within a category. Ah, complications. Here is an example. Say I have several series of "articles" that require specific stylesheets (call them Templates if you want), and I think using the Pages feature will allow me to specify those stylesheets outside of the enforced single stylesheet Posts permits. The problem comes when I want only those Pages listed in the Category or SubCategory that includes that series. Now what?

I just know we're going to get this question in the forums, so this somehow needs to be addressed. Not right now, but soon. Is there a better way of doing this or is Pages the answer?

Great work on all of this. This is a real challenge to explain when the nomenclature is so....messy. You really did a good job in distinguishing Pages from pages and posts. Lorelle 16:14, 20 Feb 2005 (GMT)

I'm not sure the best way to do what you want regarding different templates/stylesheets for different posts. If you want them in categories, though, they have to be Posts; Pages simply cannot be in categories. So if you can't add the information using the ideas from Category Templates, you'll have to be sneakier. In fact, you'll have to do exactly what you don't like doing: split up one of your Templates (single.php) with a bunch of if statements. USER:MDAWaffe/Conditional Tags (Conditional Tags) is a preliminary article on various WordPress 1.5 functions that test for various conditions.

if ( is_single(5) || is_single(8) ) {
// Do some PHP/HTML
} else {
// Do some different PHP/HTML
}

Putting that in your single.php will tell WordPress to do something different for post ID# 5 and 8 versus all the other posts. This method doesn't use Pages, though (and I think implementing what you want should not), so this probably isn't the best place to talk about it. --MDAWaffe 23:36, 20 Feb 2005 (GMT)

I just try to think like the user, which I am, all the time to anticipate the most obvious of questions, and the fact that Pages can't be indexed in Categories is troublesome for me, so it will be asked by others.

The more I think about it, the more I realize that your above explanation about categories is part of what is missing in this article. There are a couple of fly-by mentions that posts can't be in Categories, but not an understanding of how to get around it or if people should get around it. I'm not talking about a complex treatis but we need to deal with the issue. My example is a little more complicated, but people will be thinking "Hey, it says to use my imagination!" I'd include some kind of condensed explanation like you've given me above, with the reference to Category Templates to help explain some of these issues.

I love the concept of the Category Templates! I'll run with that immediately!

Lorelle 03:04, 21 Feb 2005 (GMT)

You're right - it is a tricky issue. I'll think on it a bit and see if I can clairfy things. If you get to it first though, that's cool `:)` Part of the problem, though is that there's no good article to link to (Category Templates not being live yet - hopefully soon - Wiki Day if nothing else). --MDAWaffe 06:09, 21 Feb 2005 (GMT)

Added details on how to hide a page on the menu (6.1)

I had troubles finding anything for this and made a solution, thought it would help other users to add here. This is where I looked originally for it so here it is. -- Grand Edgemaster 19th Feb 05 23:52 GMT

Excellent example. I would prefer to see it on Template Tags/wp_list_pages, however, and have moved it there and provided a link to it. Thanks. --MDAWaffe 02:23, 20 Feb 2005 (GMT)

Markdown or Textile to edit pages

Can you make the pages format according to Markdown / Textile rules? Currently by default it looks like it doens't work. Also you should probably make some mention of this in the description of the feature, it was looking forward to editing static pages with Markdown --User RanH

Please ask questions like this in the forums. Codex is for documentation, not support. If you find an answer to your question, feel free to make any necessary changes to the article (though be sure and follow the Codex Guidelines). If you're not sure what the best way to include a certain piece of information on the Pages article, you can try posting a link to the relevant forum discussions here; I imagine someone will see it eventually and try to incorporate it.

Also, please sign any future posts to TALK/DISCUSSION pages such as this with four tildes:

~~~~

So that people can see who is posting and when you posted. --MDAWaffe 03:20, 6 Mar 2005 (UTC)

Page to Top plugin comment...

Hello,

This Page to Top plugin is the cat's pajamas for my using wordpress as a CMS.

Thing is, once I make a Page the top.. I don't see how to get back to the blog main page. What do I need to do to still have a blog main page, just not have it on top.

Thanks,

Larry

Please take your questions to the support forums. There are many more people over there with the knowledge you are looking for than there are here, and posting there will help everyone else looking to tha answer for any similar questions. Codex is for documentation only (though, certainly, several examples on Codex have come from the forums). When you find an answer, please feel free to add it to the article, or post it on this Talk page --MDAWaffe - Talk 22:58, 21 Mar 2005 (UTC)

Since I found the problem interesting, I edited the section a little to make it clearer, though I wonder if the suggested method would work, since regardless of whether the link is hardcoded in, or generated by wp_list_pages();, the visitor may get redirected to the new "front page" :Carthik ‹ ℂ › Talk 04:54, 22 Mar 2005 (UTC)

---

Thanks Carthik, your clarification changes to this page of the manual make this crystal clear. I'd read through the forums pretty thoroughly and didn't see anything that answered my specific question, so thanks for the extra detail! I'm not sure if it will work either, i'll try it out and let you know.

-Larry

---

This line is confusing for me: "To create a new Template for a Page you must create a file. Let's call our first Template for our Page snarfer.php." It is unclear how this file for a Template is created. Can it be created with WordPress' Write screen, as a Page would be, or is it a file you must create with a text editor and upload to the correct folder? --User KathyP 21:38, 15 Apr 2005 (UTC)

---

This section on "a template to display a Page's actual Content" is also perplexing. Earlier in the article you state that Pages are not Posts, and yet here you are putting "The Loop" into a custom template for a Page. Does "The Loop" apply to content other than posts? If so, that needs to be made clear in the article on "The Loop." --User KathyP 21:52, 15 Apr 2005 (UTC)

---

Including a Page is also not clear. I would need to see examples to understand what including a Page would do for me. --User KathyP 21:52, 15 Apr 2005 (UTC)

Edit of 16 May 2005

I've recently revised a lot of the content on this page to improve readability. There was a lot of clutter, a lot of repeated information, and a lot of stuff that was irrelevant. I have also clarified the info about Page Templates.

Also, do we need to be so anal about bolding every occurance of Page or Pages? Wikipedia's policy on Bolding the term is to Bold it the first time it appears on the page. I'm not against the capitalization of the term, but maybe bolding every occurance is a bit much... Glutnix 03:47, 17 May 2005 (UTC)

The anal retentiveness applied to date to the word "Page" was a result of massive and honest confusion about the difference between a page and a Page (to use the article's notation). Capitalization was not enough (what if "page" came at the beginning of a sentence?). If that confusion has dissolved for old users and is not present in new users, I have no problem with a less eye grabbing notation.

A quick note about section titles, though: Changing them breaks #anchor type links within the article (which I assume you've checked) and from other articles (which you may not have checked). Change section titles with caution. Also, note that "Pages can be SubPages" allows people skimming the TOC to immediately understand that Pages have this feature, while "Organizing your Pages" does not. That's just something to think about (perhaps in concert perhaps in opposition to Codex's "Task Based" mantra).

Thanks for all the work! --MDAWaffe - Talk 04:07, 17 May 2005 (UTC)

No problem, MDAWaffe! Was worried I would be shot down... :)

I just went through the page, and the only real "page" (non-Page) mentions refer to 'home page' or 'front page'. If we clarify those two terms at the top, I think that would definitely improve clarifications. I also propose a guideline that you only need to Bold the word Page if it is ambiguous without it.

Actually, here's what I propose we put at the top of the page.:

Terms Used in this Article For the purpose of clarity, throughout this document: "page", with a lowercase "p", will describe any HTML document on the web. Use "page", in italics, when the use of the term is ambiguous. "Page", with a capital "P", will refer to a "WordPress Page", the feature of WordPress that this wiki page details. Use "Page", in bold, when the use of the term is ambiguous. For further Page related nomenclature issues, see A Note on Nomenclature.

MDAWaffe, if you agree, go ahead and make the change, red table and all. Cheers, Glutnix 05:45, 17 May 2005 (UTC)

I think the italics is unecessary; trying to emphasize something that's generic seems backward to me. I think the lowercase is enough. Thoughts? --MDAWaffe - Talk 07:41, 17 May 2005 (UTC)

Yeah, it might be a bit much... No worries then, implemented - Glutnix 23:16, 17 May 2005 (UTC)

Broken "Pages_can_be_SubPages" link fixed

I fixed the Pages_can_be_SubPages link by changing it to the Organizing_Your_Pages section. That seemed to be the most appropriate place here, and a search didn't turn up any pages that looked more appropriate. I can't be sure that was the actual intent, though.

Suggestion for the end of Organizing Your Pages section

While you can use permalinks when you want one Page to link to another, you can also use relative links. For example, on the Page "Cameroon", a link to "Togo" would be coded as

href="../togo/"

Always remember the trailing slash on the addresses you enter manually. If you don't, the referenced page will come up fine, but any of its relative links will be broken.

Optionally, more discussion on why the "../" is needed there could be included. --Converting2wp 00:45, 19 May 2007 (UTC)

Static page information obsolete?

All the info about customizing the home page with a static page should be obsolete information, right? --Tom 03:34, 26 April 2008 (UTC)

Tom - I would say that is a correct statement. --MichaelH (talk) 12:45, 26 April 2008 (UTC)

Article Updated

I updated this page in several ways. I added info about changing the page URL, since this is not intuitive in 2.5. Also, I removed the note about setting the front page as the home page in version 2.1. I only kept the info about setting the home page in the current version, as well as the alternate method for setting the home page. I moved the section on making your blog appear in a non-root folder to a new page at the bottom. It doesn't seem to fit on this page's topic. I clarified the title of the last section, renaming it "The Dynamic Nature of WordPress Pages." I consolidated the info to make it more concise. I added a link to Lorelle's advice on the importance of contact and about pages. And I removed the bit about Page versus page versus Page because it seemed unnecessary to me, and only made things less clear. The only possible place where it might be misconstrued is in the last section on the static versus dynamic nature of pages, so I clarified the difference there.

Here's the stuff I deleted from the page, so if you feel I trimmed in error, feel free to add it back.

{| cellspacing="3"
|- valign="top"
|class="MainPageKnowledgeBaseBox" style="border: 1px solid #ffc9c9; padding: .5em 1em 1em; color: #000000; background-color: #fff3f3"|
===Terms Used in this Article===
<span id="Notation_Used_in_this_Article"></span>
For clarity, throughout this document:
* "page", with a lowercase "p", will describe ''any'' [[Glossary#HTML|HTML]] document on the web.
* "Page", with a capital "P", will refer to a ''"WordPress Page"'', the feature of WordPress that this wiki page details. Use "'''Page'''", in '''bold''', when the use of the term is ambiguous.

For further '''Page''' related nomenclature issues, see [[#A Note on Nomenclature|A Note on Nomenclature]].
|}


'''Note:''' In 2.1, the conditional [http://codex.wordpress.org/Conditional_Tags#The_Main_Page is_home()] function no longer returns true for the Front Page set in Admin. In order to emulate the pre-2.1 function of returning true for the "front" home page, use the [http://www.bos89.nl/1197 is_frontpage plugin] or use [http://codex.wordpress.org/Conditional_Tags#A_PAGE_Page is_page(home)] where the slug of your desired front page is "home".

The following paragraphs explain how to duplicate this functionality for versions prior to v2.1.

The home.php file is not needed in versions 2.1+
. Use the setting in the control panel to set your static home page.

--Tom 17:47, 26 April 2008 (UTC)

I think the note about Pages versus pages versus Pages is unnecessary, and only adds to the bulk of this document. Would anyone mind if I take that little note out and remove the bold formatting from the word "Pages"? Also, we need to add instructions about changing the page slug in 2.5. --Tom 16:51, 26 April 2008 (UTC)

Link Broken

I have tried following the link to the "pages add new subpanel" but it keeps coming back to this page. Does the target page exist? Anyone know how to fix this?

I have discovered the obsolete page Write Page SubPanel. The new one is supposed to replace this. Lots of other pages link to the new one that isn't there.

DanDare 00:53, 24 June 2009 (UTC)

That's intentional until that article is actually written. --MichaelH (talk) 12:53, 24 June 2009 (UTC)

Obsolete plugins being referenced here?

Hello. There are a couple of plugins that are referenced in this page - one links to a page last updated in 2008, and the other to a domain that's no longer active. Should these links just be removed? I would go ahead and just do it, but I just registered today and don't want to mess anything up. Should I just fix the links? -- Ancawonka 00:12, 20 January 2010 (UTC)

Yes please just go ahead and delete any links from the pages that you notice are broken or spam.

mrmist 08:51, 20 January 2010 (UTC)

What for?

I think it would be appropriate to just remove the following heading and paragraph from this page.

http://codex.wordpress.org/Pages#WordPress_as_a_CMS

What does it actually mean/imply/aim-to-say. I think it could be trimmed simply because it serves little or no purpose to have it there.

http://codex.wordpress.org/Pages#A_Page_of_Posts

Why create a new WP_Query object for the page? There's one available, and if it's not being used or referenced (it's not in the example), then why use a seperate instance? Redeclare the main query if it's not being used (why create an extra query when it's not necessary)..

Suggestion: Use query_posts and drop the is_page() check, since you're not giving an example of using the existing query(ie. the page the page template is attached to).

T31os 19:44, 29 April 2010 (UTC)

New Page Templates Article

Upon recommendation of docs team we split Page_Templates pf of the Pages article. We took most of the information from this article, put it in the new one, updated it, then removed the now-redundant info in this article.

Hearvox 03:30, 3 May 2013 (UTC)

What Template to Display needs clarity.

http://codex.wordpress.org/Pages#What_Template_is_Used_to_Display_a_Particular_Page.3F

In the What Template is Used to Display a Particular Page? section, what directory is the template file supposed to be in? ex: page-131.php I have tried several locations and had no luck. Also is the commenting at the top of the file with the template name required for this to work?