SOLVED - Content Plugin Ranged Filter

[nclaypool]

I have an article that uses the content plugin to display several filtered lists. They're using ranges to show only expiration dates of certifications within a certain timeframe. I'm having an problem with getting them to work.

This code:

{fabrik view=list id=36 show-title=0 showfilters=0 staff_certifications___cda[value][]=now staff_certifications___cda[value][]=%2B90+DAYS staff_certifications___cda[condition]=BETWEEN}

Produces results, but only with upcoming expirations, I can't figure out how to have it go back in time for already expired dates.

This code:

{fabrik view=list id=36 show-title=0 showfilters=0 staff_certifications___child_abuse_neglect[value][]=now staff_certifications___child_abuse_neglect[value][]=%2B30+DAYS staff_certifications___child_abuse_neglect[condition]=BETWEEN}

Produces no results, despite the list containing expirations that should fall within the range. Not sure what I'm missing that's breaking this. Only the the top one above works, the others show no results but are constructed in exactly the same way.

 

[cheesegrits]

To go back in time, use %2D.

You can also put fabridebug=1 in the plugin string, the look at the getData query in the debug output, to see what the WHERE clause being generated is ...

So for example, my test of ...

{fabrik view=list id=2 fabrikdebug=1 fab_main_test___date_time[value][]=%2D365+DAYS fab_main_test___date_time[value][]=%2B90+DAYS fab_main_test___date_time[condition]=BETWEEN}

... produces a WHERE clause of ...

WHERE ( `fab_main_test`.`date_time` BETWEEN '2015-07-15 05:00:00' AND '2016-10-13 04:59:59' )

So for your second one, try debugging the WHERE clause, see what's actually being generated.

-- hugh

 

[nclaypool]

Ahh, that made a difference, its now pulling past records.

Though I've discovered a bizarre problem. I selected "all" from the "Display #" menu and it refreshed to show nothing, even though it had been showing 10 records. I then selected 10 again and it still showed nothing. If I refresh the page the list shows the correct results for a split second then they disappear.

By adding "resetfilters=1" to the command it restores the results.

I'm also noticing if I add something like hide-add=1 to the top command, all subsequent commands honor that same code.

I'm wondering, is there any known issues with having multiple list commands within the same article.

 

[cheesegrits]

Hmmm.

Can you try taking one of those plugins out, see if the behavior changes.

-- hugh

 

[nclaypool]

Alright, I moved each plugin into its own article and linked to the category so the end result would be the same.
With all articles present and published each display shows no results, if I move the articles to an alternate folder so that only one article is displayed, it displays the proper results???

Can you think of some way I can accomplish this, each record has several different expiration dates and I'm trying to present a dashboard to my users that only displays the upcoming expiration dates for the corresponding item?

 

[cheesegrits]

No easy fix for doing it with the same copy of a list, as we use the list ID as the key for the "context". You'll also start running into issues with duplicate HTML ID's.

The only way to do it is to copy the list, and use a separate copy for each instance on the page. That way each instance has a different list ID. Then you can also do your filtering with pre-filters rather than query strings (which is what additional args in the plugin string get turned into), which tends to be more robust anyway.

-- hugh

 

[nclaypool]

I've never copied lists before, are there any precautions or special steps I need to take to ensure I don't break the original list or make sure it doesn't actually make a duplicate table in the database?

But what you're suggesting makes perfect sense, just want to make sure I don't screw something up.

 

[cheesegrits]

Just select the list and hit the Copy button. It'll ask if you want to re-name the list/form/group(s) on the copy, which I usually do, to avoid confusion. It's changing the backend names, not the visible front end labels. The new List will be using the same underlying table.

Elements in the copy will all initially be "linked" to the originals, meaning they inherit any changes you make to the originals. If you want to make a change to a linked element (but no the parent), Fabrik will let you "unlink" it, from which point onwards it will no longer inherit the parent's settings.

You can then independently configure anything on the copy's list / form / group(s) / elements, without affecting the original.

The only thing to watch for is if you ever delete the copy, when you empty the trash, do NOT drop the table.

If you want to remove elements from the copy, best way is just unpublish them, rather than deleting them. If you do delete them, do NOT drop the database field when you empty the trash.

As usual, if you are nervous, back your site up. Hell, even if you aren't nervous, back your site up.

-- hugh

 

[nclaypool]

Thank you, I appreciate the wealth of information, makes me feel more comfortable with the process.

I have backups going daily but always run a manual backup before I make big changes like this. Thanks again, I'll mark this as solved as it sounds like this is the best way to accomplish what I'm attempting.