Pagelist filtering (publish page) bug? (C5.6)

Permalink
Hello,

Concrete 5.6.3.3
Cache is not enabled

I have created a custom block. Where I make use of a pagelist and made it possible to apply some filteres. To explain the problem I will take one filter as an example. The expertise filter is added via the page attribute with the handle "expertise".

The values of this attribute are shown in the filter. Ad first the filtering works. But when you change the selected expertise attribute value to another value (developer too designer) via the page attribute. The filtering does not reflect these changes.

Cache is disabled and clearing it does not solve the problem. The strange thing is when I go to the page, edit the page and publish the changes. Than the filtering is working correctly again and the earlier changes to the page attribute are reflected.

How comes that changing the page attribute value only is visible after editing and publishing the page.

class VacatureListBlockController extends BlockController{
   protected $btTable = 'btBlogList';
   protected $btInterfaceWidth = "500";
   protected $btInterfaceHeight = "350";
   public function getPageList(){
      Loader::model('page_list');
      $bID = $this->bID;
      $pl = new pageList();
      $pl->setNameSpace('b' . $this->bID);
      $pl->filterByCollectionTypeHandle('blog_item');
      $pl->sortByPublicDateDescending();
      $pl->setItemsPerPage($this->num);
      /**
       * Filter by attribute
       * @orderBy get value via post or

 
jero replied on at Permalink Best Answer Reply
jero
When filtering by a page attribute the page list object uses the CollectionSearchIndexAttributes table. This table is not always updated immediately following an attribute change - it can happen some time afterwards, typically on the next page load when the dispatcher code is run. My guess would be that the value in the ak_your_attribute_handle column (where "your_attribute_handle" is the handle of your attribute) is not set when you're running your search. Try rebuilding the search index and see if that helps. Also, if you're using a select attribute, there are all sorts of issues with filtering by it, which is why there's a filterBySelectAttribute() method - although I've often found that even this doesn't work. Good luck.
rge replied on at Permalink Reply
Thanks for your response.

Rebuilding the search index via automated jobs indeed works. Do you know if there is a way to work around this? It seems odd to me that we would have to run the job every time we make a change to a page attribute.

Another strange thing to this is that while the filter does not reflect the changes printing the attribute value shows the correct value. I geus they are not using the search index for this part.
jero replied on at Permalink Reply
jero
You should find that after changing the attribute, that a subsequent view of the page causes the index to be updated - this happens in the dispatcher code at some point, if I remember correctly. If you're changing the attribute through any other means, you most likely need to call reindex() on the page object so that the CollectionSearchIndexAttributes table is updated. Note that CollectionSearchIndexAttributes contains *copies* of the information you would find in the attribute tables themselves - the two are not the same thing which is why you'll be able to print out the attribute value yet not be able to search on it.