All Low add-ons are now owned by EEHarbor. Read the blog post.

Support archive

Low Reorder Fallback ordering

Tidy 8 May 2017 15:08 question, complete

I'd like to use Low Reorder for custom ordering a few categories, and then just have a default ordering (based on status and entry date) otherwise. Is this possible?

My sets are of the type 'show entries per single category'.
I'm using fallback="yes" in the low_reorder:entries tag but if I specify orderby and sort parameters in the tag (to use only in the fallback scenario) they override the low reorder set ordering even when I add force_set_params="yes". Also sticky entries no longer seem to be listed first in the fallback channel entries list.

Here's my tag for reference:
{exp:low_reorder:entries set="{if segment_2 != 'category'}shops{if:else}filters{/if}" category="{segment_3_category_id}" force_set_params="yes" fallback="yes" channel="shops" limit="15" orderby="status|entry_date" sort="asc|asc" status="Featured|open" disable="member_data|category_fields"}

So is there a way to achieve the following:
1) if there is a low reorder set, order by that
2) if no reorder set use channel entries fallback with sticky entries first and certain ordering parameters?

Thanks,
Janine.

Replies

  1. Low 8 May 2017 15:16

    I think that should work, yeah. Are you getting unexpected results?

  2. Tidy 8 May 2017 15:22

    Thanks for the quick reply. It works fine for categories where a low reorder set exists, but otherwise I just seem to get entries in reverse date order i.e. the default EE ordering and sticky entries are no longer first either.

  3. Low 8 May 2017 15:25

    Can you turn on template debugging and share all the lines that mention Low Reorder here?

  4. Low 8 May 2017 15:51

    For what it's worth, Low Reorder will create a record in the DB of a (sub)set when you save an entry, regardless of whether you've manually reordered entries in the CP via the Low Reorder module.

    This is especially true for the 'show entries per single category' setting. If you create a new category, no entries will exist in that category, and therefore no custom orders exist.

    As soon as you assign an entry to that new category, LR will create a record in the exp_low_reorder_orders table (creating a subset for that set/category combo) and the entry will be saved there. This will also happen for any other entries that will have that new category assigned to it. In that sense, no 'custom' order exists, but the default will exist, with each entry appended/prepended to the list as per the set's settings.

  5. Tidy 8 May 2017 21:42

    I've done more tests this evening & here's the behaviour I'm seeing.

    I have one set that is just for all entries in a channel (not per category).
    Even though this set exists, once I add sorting parameters to the low_reorder:entries tag, these override the set order & sticky entries also go at the top. This happens regardless of whether force_set_params is set to yes or no.

    Template debugging output for full channel set type:
    ----------------------------------------------------------------------
    Calling Tag: {exp:low_reorder:entries set="shops" category="" force_set_params="yes" fallback="yes" channel="shops" orderby="status|entry_date" sort="asc|asc" status="Featured|open" limit="15" disable="member_data|category_fields"}
    0.097861 / 6.96MB Low Reorder: Retrieving set from database
    0.098255 / 6.97MB Low Reorder: Getting ordered entry_ids from database
    0.101772 / 7.10MB Low Reorder: Setting parameters show_expired="n" show_future_entries="n" sticky="n" channel="shops" status="open|Featured" channel_id="7" entry_id="136|56|57|689|86|166|89|243|121|62|27|241|229|81|80|625|627|714|629|703|41|232|202|170|626|167|609|593|531|530|664|529|321|221|215|212|181|207|192|184|93|91|87|85|82|208|225|79|77|76|75|74|73|72|71|69|60|58|55|54|53|52|48|47|45|40|39|36|33|32|624|467|63|64|209"
    0.101784 / 7.10MB Low Reorder: Calling the channel module
    0.119225 / 8.47MB Calling Extension Class/Method: Low_reorder_ext/channel_entries_query_result
    0.166352 / 9.96MB -> Data Returned
    -----------------------------------------------------------------------------

    The other set is the 'show entries per single category' type referred to in posts above.

    Originally, when I hadn't set an order for a category, the fallback seemed to order newest entries first without stickies at the top. When I tried adding sorting parameters and force_set_params=yes to fix this, that messed up the order for categories where I had set an order in low reorder.

    However, when I tested the 'show entries per single category' type later on, things got stranger. Categories without low reorder set just returned a max of 2 entries, even though a standard channel entries loop for the same category (and the low reorder screen for that category) would list many more.

    After reading your reply about saving entries, it hit me that the only entries listed out for categories I have not set a low reorder order for are entries which I have updated since installing it. This has me confused because I thought that the low_reorder:entries tag should always return the same number of entries as a standard entries tag?

    Template debugging output for 'entries per single category type' for category without order set (channel entries would return 80 results here, not 2):
    ------------------------------------------------------------------------
    Calling Tag: {exp:low_reorder:entries set="filters" category="49" fallback="yes" channel="shops" status="Featured|open" limit="15" disable="member_data|category_fields"}
    0.117257 / 7.39MB Low Reorder: Retrieving set from database
    0.117827 / 7.46MB Low Reorder: Retrieving cat_id from parameter
    0.117845 / 7.46MB Low Reorder: Getting ordered entry_ids from database
    0.119233 / 7.47MB Low Reorder: Setting parameters show_expired="n" show_future_entries="n" sticky="n" channel="shops" status="open|Featured" channel_id="7" fixed_order="27|229"
    0.119247 / 7.47MB Low Reorder: Calling the channel module
    0.135031 / 8.48MB Calling Extension Class/Method: Low_reorder_ext/channel_entries_query_result
    0.158597 / 9.67MB -> Data Returned
    -----------------------------------------------------------------------------

    For the moment I'm working around all this oddness by using a hard coded conditional to only use the low_reorder:entries tag for categories I know I have set an order for, and using a standard channel entries tag otherwise. However it would be nicer if I could just order certain categories as needed & then automatically fall back to a full category listing with a certain default ordering for less important category views. Is that possible or beyond the scope of low reorder?

    By the way, the site is running EE 3.3.3 so if that could be a factor here let me know & I'll prioritise upgrading.

  6. Low 9 May 2017 12:56

    So, here's the thing.

    When a set is found and entries are in it, LR will call the channel:entries tag with either the entry_id or fixed_order parameter populated with those IDs, depending on whether the orderby parameter is set. This is regardless of the force_set_params parameter.

    This will also limit the entries returned to the entry IDs that were given (present in the orders table). In the situation that I explained before, this could be that not all entries are there; you'd need to save the set/category combination at least once. Automatically processing all the entries in a set proved to be very inefficient indeed, performance wise.

    So I'd advice to make sure each set (and category sub set) is saved at least once via the CP, after which they will be updated automatically. When creating a new category, make sure that set/category combo is saved once, too.

    You could make the conditional a bit more elegant by setting a preload_replace var with the module name, eg.

    {if a == b} 
    {preload_replace:mod="low_reorder"}
    {preload_replace:order=""}
    {/if}
    {preload_replace:mod="channel"}
    {preload_replace:order="status|entry_date"}
    ---
    {exp:{mod}:entries set="filters" orderby="{order}" ... }
    ...
    {/exp:{mod}:entries}


    Thus using just one block of code to generate the list of entries.

  7. Tidy 9 May 2017 13:14

    Many thanks for explaining things Low & also for the preload replace code. While I've often made use of your handy preload replace conditional approach, I never realised that you preload replace was parsed within a tag name itself - you learn something new every day! :) Thanks again

  8. Misha Avrekh 23 May 2017 19:21

    Hi!

    I am experiencing an identical issue and the approach above looks like what I need to use here.

    Is there a way to check if a set exists before setting the preload_replace vars?

    Basically, I have several sets that are named based on a URL parameter, and the page is supposed to default to the standard (pre-set) channel entries list if the set for that URL hasn't been set up. So what I would need is where you have
    {if a == b}
    ...
    to say something like
    {if 'my_set_{segment_3}' != ''} (or ifExists('my_set_{segment_3}'))
    ...

    Is this possible?

    Sorry if I am overlooking this here or in the docs.

    Low 23 May 2017 20:09

    Right now there isn't a built-in way to check if a given set name exists or not. You'd have to create a custom query (or plugin) for that.

    Misha Avrekh 26 May 2017 15:08

    OK, thank you! I'll try implementing a plugin.

    Just to make sure that I fully understand the issue: I have the following tags in my template --

    {exp:low_reorder:entries
    set="my_set_{segment_3}"
    disable="member_data|category_fields"
    fallback="yes"
    force_set_params="yes"
    dynamic="no"
    paginate="hidden"
    channel="my-channel"
    search:keyword='my-keyword'
    orderby="status|date"
    sort="asc|desc"
    status="Featured|Open"
    }

    ....
    {/exp:low_reorder:entries}

    The behavior I'm hoping to achieve is:
    * If my_set_whatever exists, show the entries in the order determined by the set.
    * If the set does not exist, default to the channel entries sort, featured entries first, otherwise by date.

    What I'm seeing is that the fallback option works correctly, but the sets (when they exist) appear to be sorted by status, not in the order of the low reorder set.

    Here is the debugging output:

    Calling Tag: {exp:low_reorder:entries set="my_set_blah" disable="member_data|category_fields" fallback="yes" force_set_params="yes" dynamic="no" paginate="hidden" channel="my-channel" search:typical_bloom_months='May' search:keyword='my-keyword' orderby="status|date" sort="asc|desc" status="Featured|Open" }
    0.265509 / 12.3MB Low Reorder: Retrieving set from database
    0.266472 / 12.3MB Low Reorder: Getting ordered entry_ids from database
    0.269421 / 12.3MB Low Reorder: Setting parameters show_expired="n" show_future_entries="n" sticky="n" channel="my-channel" status="open|Featured" channel_id="46" search:keyword="my-keyword" entry_id="3379|3367|3305|3346|3378|3322|3227|3363|3230|3231|3321|3351|3347|3297"
    0.269441 / 12.3MB Low Reorder: Calling the channel module
    0.279121 / 12.7MB Calling Extension Class/Method: Low_reorder_ext/channel_entries_query_result
    0.279669 / 13.0MB Calling Extension Class/Method: Low_search_ext/channel_entries_query_result
    1.340077 / 13.5MB -> Data Returned
    1.340197 / 13.4MB - End Tag Processing -
    ...etc....

    Low 27 May 2017 06:58

    Explicitly setting the orderby parameter on the low_reorder:entries will override the custom order and show the entries in the order defined in the orderby param.

    Misha Avrekh 30 May 2017 16:15

    OK, thank you for clarifying. I'll work around this.

    May I suggest just throwing away the orderby parameter, even if one is defined, if you find a valid ordering set? It seems to me that with the addon in place, content managers would rightly expect their sets to override whatever order the coders have set in the tags.

    Low 30 May 2017 19:41

    You'd be surprised to see what people actually expect.