Thread

Hello All,

I’ve read the EE docs, searched the forums and tried numerous variations, but the only way I can get my conditional statements to work is with the code below. I expect that there is a cleaner, lighter way to do this, and wonder if anyone would be so kind to show me. 😊

<div id="printdet_table"> <!-- Print Details table div. Contents controlled via misc. content weblog. -->
    {if custom_field_two == "1" AND custom_field_three == "A"}
        {exp:weblog:entries weblog="misc_content" disable="categories|pagination|trackbacks|member_data" dynamic="off" url_title="tier_1_price_table_a"}
            {page_body}
        {/exp:weblog:entries}
    {if:elseif custom_field_two == "1" AND custom_field_three == "B"}
        {exp:weblog:entries weblog="misc_content" disable="categories|pagination|trackbacks|member_data" dynamic="off" url_title="tier_1_price_table_b"}
            {page_body}
        {/exp:weblog:entries}
    {if:elseif custom_field_two == "2" AND custom_field_three == "A"}
        {exp:weblog:entries weblog="misc_content" disable="categories|pagination|trackbacks|member_data" dynamic="off" url_title="tier_2_price_table_a"}
            {page_body}
        {/exp:weblog:entries}
    {if:elseif custom_field_two == "2" AND custom_field_three == "B"}
        {exp:weblog:entries weblog="misc_content" disable="categories|pagination|trackbacks|member_data" dynamic="off" url_title="tier_2_price_table_b"}
            {page_body}
        {/exp:weblog:entries}
    {if:else}
        Please enquire for size and price details regarding this image.
    {/if}
</div> <!-- closes Print Details table (printdet_table) div -->

In dBase III-type syntax and I suppose PHP, one would likely use “case” (with “switch” if php) for a list of conditionals that is more than three options or so long. What is best here? I can see this set growing by two more options, possibly more. I tried one option using “url_title=”{embed:tier_1_price_table_a}” which I found here in the forum, but I couldn’t get the syntax to fly. It seemed like it might be a little lighter.

(The current url_titles are long for my sanity while chipping at this.)

Thank you for any help.

That… is not a good idea for a number of reasons and I would bet is not working as you expect since the custom field conditionals are outside the weblog entries tag - they have to be inside to have context.

Perhaps, though, you could take a step back and tell us, in plain English, what you need to accomplish?

You would likely be better off using the search: parameter in combination with URL segments.

Hi Lisa,

Thanks for your reply. I’d be curious to learn why “that is not a good idea”.

If I understand correctly, URL segments will not work in this case (I have used them before with conditionals and they worked great), because there is no url change. This is a div on a page with an image which can be purchased. The images are in a gallery (photo gallery module). Each image is available in one of a couple of price tiers, and one of a couple size sets.

Custom_field_two determines the price tier, and custom_field_three determines the size set. Size set varies depending on aspect ratio of the images, so depending on which set the images falls within a price table is embedded into the div. When a visitor views an image, they are to see what sizes it’s available in and at what price for each size (a table).

So far, this is working as needed, at least on my Macs with five different browsers, but I’d like to learn to do it correctly. What do you suggest?

By the way, this KB post is what lead me to order my tags as above: http://expressionengine.com//knowledge_base/article/tags_within_advanced_conditionals/

Perhaps I misunderstood.

Ok, that article is showing you an example that will work.  However - custom field variable calls:

custom_field_two

Need to be within a weblog entries tag or other tag that gives them context. 

Put this on your page:

{custom_field_two}

outside a weblog entries tag and you’ll see information is being used inside of the conditional - you’re getting a false response from it that won’t hold up.

Have you considered using dynamic parameters instead?

Also, advanced conditionals are parsed after the weblog entries tag - this means that all of that code is always being executed, the results are simply hidden.  This can become very processor intensive, which is why it is not a good idea.

I would seriously recommend re-thinking how you are approaching this as what you are doing is likely not behaving really as you expect it, and is going to end up taking a bit of resources due to the parse order.

Okay, I’ll have to wrap my head around how dynamic parameters might work in this case. I’ve not used it for selects (don’t know how yet), but a “select” is what I was originally looking for, so maybe that’s the ticket.

1) If weblog entries tags wrap the custom field tags would that be safer until I get it sorted?

2) Also, are you suggesting against using advanced conditionals ever? Even with URL segments? I did know about the timing of the advanced conditionals, but wasn’t aware of increased processor load.

In this application, the div is hidden (display:none) on load so there’s no problem with load time. And this particular site is and always will be relatively low traffic, though I still want to learn the best-practice methods.

3) The closest input I could find within the forum (reading other peoples’ threads) was pointing to placing the conditional (or semi-dynamic) content (the price table) into separate weblog entries. Are you also suggesting against that approach?

Thank you again.

1.  Not if you’re nesting tags, no.  But otherwise yes - however, you may end up hiding results and getting inaccurate limits.

2.  Absolutely not, advanced conditionals are fantastic - but their parse order should be considered and you should watch the performance of your site as with any change you make.

CSS display:none does not ever stop the code from being executed - it simply hides it from the browser.  It’s still being parsed by ExpressionEngine.  It is also shown in the source when you “View Source’ in your browser.

3.  I’m not sure what this approach would look like in your situation so I am making no recommendations about it. =)

Okay, thank you for the information thus far. Excellent help, as always, Lisa.

2.  Absolutely not, advanced conditionals are fantastic - but their parse order should be considered and you should watch the performance of your site as with any change you make.

CSS display:none does not ever stop the code from being executed - it simply hides it from the browser.  It’s still being parsed by ExpressionEngine.  It is also shown in the source when you “View Source’ in your browser.

Yes, I’m aware of the status with CSS display:none. I was just mentioning it because for this little bit of content the div has little (or no) influence on the user experience. I’ve purposefully observed with and without the feature. But thanks for making sure I was aware. 😊 I tend to pound a site a little after every material change.

3.  I’m not sure what this approach would look like in your situation so I am making no recommendations about it. =)

Makes sense. Thanks anyway. For now, I’m using a “miscellaneous content” weblog to hold items that I need to place into various spots of the site. The four small price/size tables are four different entries within that weblog. This whole EE structure/process is still a bit new to me, and I’ll humbly accept suggestions for best-practice methods. For now I need to study dynamic parameters to see if that will do what I need.

Thanks again.

Dale -

to summarize what you need in English: you have images for purchase, stored as entries in the Photo Gallery module, and you need to give the user the ability to filter by both price and size?

Is that the general idea?

Lisa,

No, that’s much more involved than I’m doing. I’m giving no filtering controls in that sense.

I’m trying to arrange it so that I can edit a small price table in one location and it will update all images that fit that price/size description. Currently there are four possibilities which are set at upload: Tier 1 or Tier 2 pricing; and 16x24” or 16x22” size (actually there are smaller versions included in each table as well). So this whole exercise is just so that I can update the price and or size offerings for a given “class”.

Is that more clear? I can offer a link to an example if it would help.

That is more clear, I guess then that I’m not clear why you can’t pass that information in URL segments and use the search: parameter? It’s the cleanest, most direct route to do this.  Two search parameters is an AND so you immediately have the functionality you want and you can do it all in one template.

I guess I’m being dense (and new to EE). I’ve used URL segments as you have described in a “practice” site and it worked great, as well as another simpler live site. The content was different, more categories, e-commerce, etc. But I guess I’m missing something in this case.

The price tier and size options are completely arbitrary and/or subjective. Categories are set by topic of image collection or “portfolio”, so are not conveniently available to use for a price or size structure. Perhaps this illustrates a flaw in my structure, but categories were apparently ideal for separating portfolios IMO.

I’m sure I’m missing something(s), and it’s likely right in plain site.

Currently, when a photo is uploaded to the Photo Gallery, a category is chosen to determine the “portfolio” to which it belongs, but this category only shows when viewing the category in “table view”. This price list that I’m adding is only present on the “image_full” page, so the URL simply shows “.../index.php/gallery/image_full/20/”. This is why I’m struggling with the URL segment suggestion. 😊

Edit to add: the price and size table is only specific to an individual image in a “portfolio” (aka category). All images in a portfolio may be the same, or they may differ. Again, it depends on aspect ratio, sales history, edition status…

Ugh, right, these are on the photo gallery module.  What I was thinking will, unfortunately, not work.

Are you married to using the Photo Gallery module at this point?  I ask because if you’re not, you could use URL Segments with the search:// parameter, but only if you use the Weblog module to store your images.

Of course then you could use the simple commerce module to sell them as well.

With that said, if you are married to the idea of using the photo gallery module, how about using the Tag Module from Solspace.com?  You could then use inclusive tags to do your restrictions in a dynamic way.  I haven’t honestly thought through that option entirely but I believe you could make it work.

Lisa,

Thank you for patience and willingness to “play along” here.

I’m not married to anything, especially if it doesn’t work. This site doesn’t need extreme scalability, but batch uploading is a significant advantage. With the apparent plans to remove the photo gallery approach from EE 2.0 I have been thinking about how “married” to the gallery I really am. Honestly, for pro photography sites there will need to be some solution for batch entries to make it a practical option.

For this project, the main section is rather low-volume in terms of content uploads. However, client work, i.e. portrait sessions, commercial product work, etc. require the batch approach. This can obviously be handled with external solutions, integrated with the EE content, but that’s not really ideal either.

A friend who is a web programmer asked me why I don’t just remove the code that I posted at top here and replace it with PHP. Or I could use embeds dynamically populated by PHP. But I have no idea how EE templates handle PHP tossed in this way. I’m really trying to learn “the EE way” so that I better understand what I’m doing should I choose to deviate.

Hi, Dale,

Batch processing is a valid reason to choose the gallery over the weblog, absolutely.  For that you do give up some flexibility that the weblog entries have, such as the search parameter.

Have you looked at the Tag module?  That may be a clean way to do it.  The other option would be to custom develop a plugin that allows this kind of restriction - that’s a better option than all of the information in the template, especially if you’re going to use it in many places.

You could nest a weblog entries tag inside the gallery entries tag, and pass your variables via embed.  That is an option but it will lead to using many conditionals that need to be updated in the template if you expand.  That’s why I’m trying to help you find a more dynamic and scalable solution here.