Thread

On the first, I think you are kind of making my point from above.  I didn’t know about that ‘show_pages’ control for the normal weblog:entries tag—how would I?

Well, how would I? It’s mentioned in the docs.

also, to get any use of it I would have to change all the templates which ran with that weblog.

Yes? I mean, it’s not as if this were particularly tedious, is it?

Thanks for pointing out the feature, too - good to know.

My pleasure.

PS: Could you not quote the posting you are replying to in its entirety at the bottom? This might make perhaps (perhaps!) sense for email, but not for discussion forums such as this one. Thanks.

Lisa, one last, before I go on this.  Though always available on a PM or something.

Here is a short and somewhat clever review of a good book, or at least people who have something to say on the topics mentioned here - http://fno.org/may2000/review.html. 

I like among other things the picture and point on cathedral buttresses.  They never did get back to the gargoyles - could have been intriguing, maybe 😉.  But John Seely Brown and the sociologist he works with, Paul Duguid, are famous for what they’ve said here.

Hope it’s interesting, and best,
Clive

OK i think i’m missing something.

I’m going to use this for things like an about page, and other ‘items’. but one thing I’m not clear on

I went to the publish form, created a new post, added the URI in the pages tab, and published some text.

i used my index template but here’s the catch. I’ve split my whole site up into templates. My index page doesn’t house any actual code. It calls 4 embeded templates. header, body, sidebar and footer.

How would someone use this with pages? it ‘sort of’ works but it looks like I’d have to create special templates to use just for the pages module, which defeats the purpose and would make it extremely inefficient because I’d have to manually update it to stay current with the site.

any help?

Clive - I understand what you are saying, but there are so many ways to do one thing that a step by step, like that which you linked to, is unduly limiting and not always accurate.  The documentation is not really intended as a step by step “here’s how you do this one thing” - because we never know what the end-user is going to do.  We document simply what *is possible* and then are sometimes surprised by the ingenuity of the end-uses. =)

JT, I am a bit cautious about adding anything more on this thread, but you might want to look at this page, and find the new page_uri and page_url variables.

You could use either one of them, testing for empty or not as in the examples.

By doing this, you could change the behaviours of your body template, to account for what needs to be done for Pages pages or ordinary ones.  Then you have only one file to maintain.

If I haven’t lost my picture of ‘how things work’, you would need to pass the page_uri/l variable through your embed statement for the body template, on the index template.  That’s easy, and here, under Embed Variables.  You probably know this…

Regards,
Clive
 

OK i think i’m missing something.

I’m going to use this for things like an about page, and other ‘items’. but one thing I’m not clear on

I went to the publish form, created a new post, added the URI in the pages tab, and published some text.

i used my index template but here’s the catch. I’ve split my whole site up into templates. My index page doesn’t house any actual code. It calls 4 embeded templates. header, body, sidebar and footer.

How would someone use this with pages? it ‘sort of’ works but it looks like I’d have to create special templates to use just for the pages module, which defeats the purpose and would make it extremely inefficient because I’d have to manually update it to stay current with the site.

any help?

The page URI and variables aren’t the concern though. The concern is that since my site is using all embeds for each part of the page, I can’t simply use an existing template because it won’t pull anything up. It will only display elements from the same categories that the front page does, which means anything published to the pages would also be visible from the main page of the site.

How would someone use this with pages? it ‘sort of’ works but it looks like I’d have to create special templates to use just for the pages module, which defeats the purpose and would make it extremely inefficient because I’d have to manually update it to stay current with the site.

JT, I use a single entry template for the pages I want to use on a site. The stand alone page I create are usually all in the same weblog and embedded templates can certainly be embedded.

JT - this is way too confusing for me. Can you start a new thread with your concerns/problems, please? Happy to address it but this particular post I don’t think is the best place for it. =)

Sure

[Edit by narration:  But logic isn’t right, either.  See here. ]

JT, I agree they aren’t concerns - the point here and in the examples in the doc is to use the presence of one of them, as a flag.

In other words, you test if page_url is there - if it has any contents as a string. This is what they show in the page_url example.

If it does contain something, that will be the static URL string.  As you suspect, you ignore this for value, but by testing have noticed it’s there - that’s the ‘flag’.  Then you do the things that a ‘Pages page’ needs to display. 

If page_url is empty, you don’t have the Pages page flag, so you revert to your normal body processing.  Here’s an example, extending slightly from the one in the doc:

{if page_url != ''}
    {exp:weblog:entries  weblog="news"  orderby="date"  limit="15" show_pages="only"}
      (then anything you want to do only for Pages)
    {/exp:weblog:entries}
{if:else}
    {exp:weblog:entries  weblog="news"  orderby="date"  limit="15" show_pages="no"}
      (then normal entries processing you do on body, which should not be done for Pages)
    {/exp:weblog:entries}
{/if}

I guess most of the difference would be to remove extra features when it’s a Pages page - so this is simple.

One other point is that you want to set the new ‘show_pages’ variable properly for either case of Pages or Ordinary:  the doc for that is here, and it explains why.  Thanks to our friend Ingmar for pointing that out.

I used show_pages above in the example.

Does this look sensible to what you want?

Regards,
Clive

Just as a note, page_uri and page_url are variables within the weblog entries tag - so the conditionals would need to be inside the weblog entries tag, not outside as in your example.

Ok, you’re right here, Lisa, fair enough. 

I’m late coming back because broadband disappeared for the evening, but finally I want this off my plate, so hooked up the old phone line for modem.  Slow, but methodical.

The upshot of this scoping you mention means I believe that it’s not possible to solve this problem by conditionals on one page.  I tried setting a variable, using an early entries tagset just to find the page_uri value, but that doesn’t work by evaluation order.

So I think this has to be hard wired, beginning with Sue’s way to use a separate template.  We know the the basis of index and its embeds can be copied, with just a change to the body embed.  We know the original body embed needs a show_pages=“no”.  The static body doesn’t need to specify anything, as it will always be called with a static page, and the default is “any”.  No use of page_uri/l is needed anywhere, since the decision has been made, but could be used to allow duplicate code for convenience.  If that really is convenient.

I think that’s all I want to put in here, for one or more reasons.

You take care, Lisa,
Clive

Just as a note, page_uri and page_url are variables within the weblog entries tag - so the conditionals would need to be inside the weblog entries tag, not outside as in your example.

I honestly am not following why you think this has to be hard-coded.  That may be idea lin some situations, but any weblog entries tag can display the page information, if show_pages isn’t set to no.

The weblog entries tag is extremely powerful and flexible unless you restrict it from being so.

Hi Lisa,

What I am meaning here is that I don’t think it’s possible to have a single template decide itself to give fully proper activity for both Ordinary pages and Pages pages.

That was what I understood JT originally asked for, so I was trying to provide it—for his body template to work on both kinds of pages, and from the same weblog, so nothing would fundamentally change on his site.

The reason I think this is because page_uri/l aren’t available, as you found, outside the entries loop.

Thus, you have no information at the right point (at the time of calling entries) to set show_pages to the proper value.  It means you would have Pages static pages showing up in the main weblog view, if you used show_pages=“yes” or left it to default, for example.

By hard-coded, I mean then that you have to have a different body template for each case—Ordinary pages or Pages pages.  In JT’s structure, that also means you need to have a different main template that calls the embeds.

Both of these are very easy, and cut down on extra work.

- for the normal weblog use, you need the current structure as it is, but if you are putting static pages in the same weblog, you need to modify the current body template entries tag, just adding show_pages=“no”.  That prevents the new Pages static pages from being seen and interfering there.

- to show the new Pages static pages themselves, you need a new body, which means you need a differently named copy of the index page (I use the name ‘display’ for that page).  This is exactly a copy except for the name, and that it embeds a different body template - let’s call that display_body.  Thus it keeps all the work on the other embeds, and is unlikely to need maintenance itself in future.

It’s this ‘display’ template that you would set the in the Pages tab as the processing template for new static pages (in the Posting screen).

In display_body, you would first of all set show_pages=“only”, so you don’t get extras and interference from ordinary pages.  Probably limit=1 and the other things Lisa shows in her wolves example.  Then you would alter other things you need to so the static pages show as you want. 

I don’t know why at the moment JT’s present body template makes blanks for the static pages, so that’s the first thing to fix.  Once that’s ok, which is no doubt something simple, then you probably just cut out features (like pagination) from what the original body had, until you have what you want for the Pages pages.

So this new display_body will end up low maintenance as well, since it’s just a simplified version of the main body template.

Ok, hope that clarifies at least the way I’m viewing it here—and in many senses, how I’m going to arrange this on my own site.

Lisa, of course you are free to criticise 😉.

Best to both of you, and I will cross-post a link,
Clive

What I am meaning here is that I don’t think it’s possible to have a single template decide itself to give fully proper activity for both Ordinary pages and Pages pages.

It most certainly is possible.  In fact, my dem/info template is serving both purposes and has been since I got my hands on the Pages module.  As I mentioned in the other thread for JT - pages can show using any weblog entries that that does not specifically restrict pages from showing.

All of this happens based on the URL.

Thus, you have no information at the right point (at the time of calling entries) to set show_pages to the proper value.  It means you would have Pages static pages showing up in the main weblog view, if you used show_pages=“yes” or left it to default, for example.

There are ways around this, but you are right - they might come up in the archives.  That is fine for me - I siphon all of my pages into a separate weblogs with its own category structure - a system I’ve been using for 3 years now, and has done well for me.  But in some situations this won’t work nor be ideal and the immense flexibility of the system certainly allows other methods.

Personally, though, I’m *always* going to be a proponent of a separate template for “Pages”, why? Because my everyday articles are displayed with many differences from my static pages.  I don’t allow comments, I don’t need pagination, I usually (but not always) forget to categorize them, I don’t tag them, I want the display to be a fair bit different than articles because of all of this. 

But having more than one template is not the end of the world - a lot of people on these forums get the idea that having one template is the final light with ExpressionEngine - the highest attainable goal, and that’s a foolish view to take, and unreasonably limits folks as well as creating darned complicated templates that make me go cross-eyed. 

Anyhow - the short of it is that the Pages module utilizes the weblog entries tag for display - and so there is a ton of power and flexibility there, and I’m sure in the coming weeks we’ll see some ingenious uses of that ability. =)