1. Thank you for all the good wishes. I'm headed in for surgery (lumbar fusion) tomorrow, Thursday July 31st, I'll be in hospital for three days, and out of action for a few days after that. See y'all in about a week! Hugh.

Fabrik Content Plugin v2.1 Problem with ClearFilters ResetFilters

Discussion in 'Plugins' started by sparkymarky, Dec 1, 2011.

  1. sparkymarky New Member

    Level: Community
    I've been debugging this for 3 days. I've tried using it as a menu component, but it would not clear, so resorted to content plugin ...:

    Firstly, I have used the same table on multiple pages (filtered).

    The main problem is that when I want to show the whole table, with filters, it seems to carry across the filter settings from the last page the person looked at.

    The way around this was to use clearfilters, as it is the only command that seems to stop the filters from other pages being reapplied when browsing tot the main full table.

    Here is the page it is not working on:

    http://yorknaturalhealth.co.uk/fees

    Here is the code I am using in joomla article:

    {fabrik view=table id=3 showfilters=1 clearfilters=1 resetfilters=1 layout=default_grouped show-title=0}

    Whenever I change the filter manually on that main page, the results shown are from the previous filter. It never resets properly.

    I noticed that the page is showing this URL which might be odd.

    http://yorknaturalhealth.co.uk/fees?resetfilters=0&clearordering=0&clearfilters=0

    I tried setting it to AJAX, and that just didn't work either.

    I have enabled debugging if you need it.

    My Set Up:
    Joomla 1.5.25
    Fabrik 2.1
    Fabrik Content Plugin v2.1

    Table settings that are relevant:
    onchange
  2. cheesegrits Support Gopher

    Level: Community
    Hmmmm.

    Putting 'clearfilters=1' in the plugin args will screw up filtering, as 'clearfilters' has the same meaning as hitting the "clear" button, and won't apply new filter selections. However, I'm puzzled as to why that isn't actually clearing the filters. With debug mode in Fabrik and FireBug, I can see we are submitting the filter change, but the postFilters debug output show us somehow picking up the previous filter selection. Which is very puzzling. And I don't seem to be able to replicate it on my test server.

    Can you catch me on Skype? I'd like to put some debug code on your site, to see what's going on.

    For the issue of coming from another page with the same table, and the filters being preserved ... I have some ideas on how we might fix that, I'm testing some new code on my site.

    -- hugh
  3. Jaanus Active Member

    Level: Community
    I had the same issue. Not 100% sure, but one possible solution when no better one is available could be that you make special copy of this table for displaying only with content plugin (never as full table).

    I display some tables using content plugin inside details views, the code is in display text element. One important experience - you have to set the group with this element visible only in details view, not in form (perhaps setting element access to nobody would help, too) - otherwise the tables data after returning to details view weren't displayed at all and needed clearing filters.
    J1.5.25, F 2.1.1

    P.S (edit) : your site seems to be working for me (I used Google Chrome)
  4. cheesegrits Support Gopher

    Level: Community
    Jaanus - I worked on his site yesterday.

    The main problem (changing the filters on page having no effect) turned out to be some kind of nasty interplay between J!'s component and page caching. Where 'component caching' is the main "Cache, yes/no" option under global settings, which controls whether individual components can cache their output, and the "System - cache" plugin which will cache entire pages.

    With them both enabled, the J! content page with the Fabrik table in it was being cached. So our filter code was never getting called. Turning off component caching, but leaving page caching enabled, "solved" the problem.

    I think this must be some kind of caching logic issue in J! between the two caching methods, as there is absolutely nothing we can do to fix it within Fabrik. If our code never gets called, then we can't invalidate the cache when we see a change in the filters.

    The other issue - where having filters in place on another instance of the table on another page getting carried over if you then go to another page with the same table on it - I'm still looking at. The problem there are the session filters. When you make a filter selection ona table, we store that filter information in the PHP session, and (if no 'celar / reset filters' is in effect for the page) get applied on the next page load. But of course, at the moment, they are applied ona per-tableid basis. So your suggestion of a copy of the table should work, as the tableid will be different.

    What I have in mind is a small modification to our filtering that takes the J! itemId in to account. The idea being to use the itemId as well as the tableid in the session data key. But as with anything to do with filters, it isn't quite as simple as that. But I'm working on it ...

    -- hugh

Share This Page