Cache categories in native Joomla cache instead of session

  • Posts: 18
  • Thank you received: 0
1 day 7 hours ago #366963

-- HikaShop version -- : 5.1.5
-- Joomla version -- : 5.3.0
-- PHP version -- : 8.3

I was surprised when found that Hikashop caches all category data in session.

It's incorrect approach because the session data is retrieved and updated on each page load. If you have lots of categories, and especially with large HTML descriptions, the size of session data is too large and it affects page load time because the final session update sends kilobytes of data into database.

I.e. I have about 200 categories and the session data is stored as about 100kb! The session data update takes enormous 10ms!

The correct solution is to use native Joomla cache, i.e. "com_hikashop_categories" group and clean it on category create/update/change/delete. Additionally, this cache should not have useless information like descriptions.

I can help and provide the full code if required.

Please Log in or Create an account to join the conversation.

  • Posts: 83678
  • Thank you received: 13547
  • MODERATOR
14 hours 49 minutes ago #366964

Hi,

HikaShop does not usually store the categories data in the Joomla session.
However, I can think of an improvement I made 2 years ago to the filtering system which could result in some of the categories data being stored in the user session.
This is only needed when the "dynamic display" setting of filters is turned on. When this setting is turned on, only the value relevant to the current listing of products are displayed in a filter, instead of all of them.
The goal of the change we made is to store the available values for the filter in the session so that they can be used after a user has selected a value in the filter and the list of values available can't be loaded anymore as we don't know anymore which filters were selected and how they were selected.
So, in the vast majority of cases, HikaShop doesn't store these values in the session.
And these values are not just categories. It can be characteristic values, custom field values, etc. It depends on how the filters used are configured.
And, most importantly, the list of values is specific to the current user, and different users, with different user groups, or with a different filter selection will have a different list of available values to them.
The goal of storing the values in the database is not having a makeshift caching to avoid a MySQL query. It's to be able to know a filtered list of elements catered to the current user, for which we don't have anymore the necessary information to be able to retrieve it.
So I don't think that a caching system, which is common to all the users on the website (unless I'm wrong ?) is adapted.

Now, while doing this change, I didn't think that the size of the user session would be a problem, so I just stored everything loaded even if only the id and the name are actually used by the filter system. But indeed, the categories can potentially have a lot of data, with custom product fields, and the description, which the filter system actually doesn't need.
This is actually easily fixable. In fact, following your message, I've already included the changes on my end for the next version of HikaShop (the 5.1.7).
Also, if you don't need the list of categories in the filter to be dynamic, you might just want to turn off that "dynamic display" setting in your filter. That way, you won't have the problem anymore with the session data on your website, even without the changes I added for the next release of HikaShop.

Now, please note that I'm speculating here. Since you didn't provide precise information on what is in the session data, I can only suppose that we're talking about the filter system dynamic display mechanism (if my speculations are accurate, then the category data should be in an array with the key "hk_filter" in the user session). You might not be using a category filter with its "dynamic display" setting turned on. Also, I don't see any other thing in HikaShop which could do that, and we definitely don't do that for normal listings on the frontend so I'm not sure what else it could be. If it's not coming from the filters, then I would need a copy of a user session data to check what is going on. It could also well be a third party extension (like a categories module display them in a fancy way) loading the category data and storing it in the session for whatever reason.

Please Log in or Create an account to join the conversation.

  • Posts: 18
  • Thank you received: 0
9 hours 43 minutes ago #366968

Yes, sorry, you are right - it's filters data. I do have filtering module with categories and Dynamic Display enabled. Session has all categories and long SQL queries with lots of numbers (IDs) which also use lots of data.

Would be nice to get rid of these data from session in favor of cached data.

Or, even if category filter is loaded from DB, at least load the data only once time to not have duplicate queries when you have multiple category filters.

Thanks in advance!

Please Log in or Create an account to join the conversation.

Time to create page: 0.058 seconds
Powered by Kunena Forum