Catalog Block not expanding for anonymous users

Well, the Catalog block isn't designed to work with block caching.

But that's actually a really easy fix. It's designed to look different on each page, so that's what the cache setting should be. Theoretically, it can also be different because of the user's role, but block caching is disabled in the presence of content access modules.

Bah. This patch.

@jasonbc: Yes, you need to reproduce the problem, apply the patch, confirm the patch solves the problem without causing any other problems, then post to describe what you've done and change the status to RBTC.

Committed. Thanks.

Wait, did you test it with block caching enabled? That's what this patch is supposed to fix.

Good morning,
I'd been puzzled by this behaviour too and tried the mentioned patch so I can confirm this:
With the patch (654648_catalog_cache.patch 393 bytes) applied to uc_catalog.module and Block Caching enabled, the Catalog block is always collapsed for anonymous users. Disable Block Caching and it expands/collapses correctly.

I'm leaving Block Caching disabled for now.

Thanks - Grant.

Try saving the block administration form again, or disabling and enabling the catalog block. All of the block info data is stored in the {blocks} table, so it might need to be refreshed from the code before the changes will take effect.

Definitely have to go to the admin/build/block form and save it in order for this new setting to take effect. I guess this update should be forced in uc_catalog_update_N()

Thank you Island Usurper, I have just tried your suggestion and included a blow by blow in case it helps.

Login as an admin.
Go to Administer | Site Building | Blocks
Click [Save Blocks] - (no changes made to the block layout at all)
Got "The block settings have been updated." Message.

Log out. (block cache still disabled)
Catalog expands and collapses.

Log in.
Go to Administer | Site configuration |Performance
and check Block cache: enabled and save.

Log out.
Catalog won't expand.

Login.
Go to Administer | Site Building | Blocks
Set Catalog region to <none> and save blocks.
Set Catalog region to [Right Sidebar Top] and save blocks. (my theme has Right Sidebar Top and Right Sidebar Bottom)

Logout.
Catalog won't expand.

Login.
Go to Administer | Site configuration | Performance
Hit Clear cached Data.

Logout.
Catalog Block won't expand.
Check and make sure uc_catalog.module is patched (copy and paste lines starting at 403):

   case 'list':
      $blocks[0]['info'] = variable_get('uc_catalog_name', t('Catalog'));
      $blocks[0]['cache'] = BLOCK_CACHE_PER_PAGE;
      return $blocks;

Login.
Change the title of the catalog block and save it.

Logout.
Catalog Block won't expand.

Login
Catalog expands and collapses.
Disable Block Caching

Logout.
Catalog expands and collapses.

I must be missing something.
Drupal ver 6.15
ubercart-6.x-2.2

Hi,

I see this patch is included in the 6.x-2.4 version, but the catalog menu block continues to not function properly with block caching enabled.

Does anyone have any helpful troubleshooting tips?

Thanks, jwant.

@jwant: Please describe *exactly* what you mean when you say it does "not function properly", and supply enough information for someone to reproduce your problem. Is this for anonymous users? Authenticated users? Both? What are your page caching settings? Etc.

I also have this problem. I had to disable all caching to get the cart block to expand for anonymous users.

Cannot reproduce this on latest 6.x. Catalog block functions correctly for anonymous users with all combinations of page and block caching.

@ntrepid8: you say "cart block", this issue is about the catalog block - please open a new issue if you have a different problem.

I have always had this behavior. I'm now at ubercart 2.11 and still can only get the cart to expand and show products if both page and block caching is off. When I enable caching the cart block will not expand.

I get the same issue when also using Ajax cart.

@xl_cheese: you say "cart block", this issue is about the catalog block, which is a separate issue that has long since been fixed - please open a new issue if you have a different problem.

Snap! I'm sorry.