Hikashop Google Products Plugin Missing Variants?

  • Posts: 250
  • Thank you received: 7
4 years 4 months ago #219623

Hi Nicolas,

I've only paraphrased what you have said previously and which you repeat here. You have argued that there isn't the demand for handling variants with Google products (unnecessary) and that it is very complex (can't be done), but let's not argue about that. It's not my intention to cause offence as I have every respect for what you have achieved with Hikashop,

I am by no means a programmer but have managed to make a version of the plugin that works with variants, it took me time but it wasn't technically that hard (thanks in part to your responses to my questions) but there are performance issues. It works with my site that has only 600 variants but Hal has tried it and gets time outs with 3000 variants. I suspect that this is largely due to the way the plugin is written, by loading all the product data into an array and using nested polling loops to process it which seems to me to be a very resource intensive way of doing it. In my post above I have offered to share what I have done with you if you can look at the parts that use these arrays and have them rewritten to be more efficient, maybe by using smarter SQL queries.

I'm not in a position to give you millions of euros, if I were I wouldn't still be working at this time of night, but I have given you several hundred for a product which has a very extensive feature list already, but frustratingly some features that don't work as well or as fully as might be expected. This has cost me a lot, hence my frustration.

If you can't help with this then I'll carry on but it will take a lot longer, and when I have it ready you can pay me some of those euros :)

Ian

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

  • Posts: 68452
  • Thank you received: 10202
  • MODERATOR
4 years 4 months ago #219643

Hi,

It's actually not a matter of using smarter SQL queries. or pulling the data differently. The queries are already quite optimized like that you if you want to increase the performances, you sure can, but then you can't take into account all the cases and you'll miss data for users with different kind of products configured. That's why we also can't use the code you have. It works for you, but it's not something we can add by default in the plugin or it would break for most people, and thus there is no point to have these modifications by default in it.
The problem with variants is that you just can't load them all in one php process when you have lots of them, regardless of how you optimize the queries and don't handle some edge cases.
Even with products it becomes a problem when you have too much of them.
To have a solution that works in all the cases, it would require to have some kind of cron system triggering the plugin which would generate the XML bits by bits by loading only a handful of products/variants at a time.
It's a complete different paradigm to what is written in the code and thus the whole plugin code needs to be completely rewritten.
There is no easy solution unfortunately and that's why we didn't undertook that work yet.

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

  • Posts: 265
  • Thank you received: 1
4 years 4 months ago #220233

I don't really understand this, forgive my simplicity.

Could you please confirm the following?

1) If I had a setup which had 2000 products, but no variants, I wouldn't have a problem using the current google shopping plugging. However, If I have 500 products with 4 variants (2000), then it's too resource intensive using the current plugin set up? (If it was designed to include variants, that is!)

2) Why can't each variant be treated as a product? If a required cell of information is empty then this can be sourced from the main product listing. Alternatively, on creating a variant of a main product, the information cells could be automatically populated with the information of the main product (This could be a yes/no checkbox within the main settings).

As always, thank you for your time.

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

  • Posts: 68452
  • Thank you received: 10202
  • MODERATOR
4 years 4 months ago #220250

Hi,

1. The resources usage would be the roughly the same. In the second case, you would actually load 2500 entries and have twice the number of SQL queries. So if would be 20% slower compared to the first case.

2. Google Products has a specific system for the support of variants.
I invite you to read this page:
support.google.com/merchants/answer/188494?hl=en
There is an item grouping system, that has to be used in some cases.
So it's not only a matter of considering a variant as a product.

Believe us, we did research that possibility and if it was just a few lines of code to add, it would already be there.

Last edit: 4 years 4 months ago by nicolas.

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

  • Posts: 265
  • Thank you received: 1
4 years 4 months ago #220352

This is directly from the page that you linked to regarding item grouping:

"All items that are variants of the same product must have the same item group id. If you have a “Parent SKU” that is shared by all variants of a product, you can provide that as the value for 'item group id'."

It would be logical to use the 'Product code' as the item group identifier. This can already be assigned within the main product.

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

  • Posts: 250
  • Thank you received: 7
4 years 3 months ago #224427

There is an issue using this plugin with a large number of products where it can timeout usually generating a 500 server error. In the server log you'll see something like ...

[Wed Dec 02 13:37:46 2015] [warn] [client xx.xxx.xxx.xxx] mod_fcgid: read data timeout in 45 seconds, referer:
then the URL of the script


This is because the plugin performance configuration is setting the php "max_execution_timeout" parameter but in a fast cgi environment you also need to set the 'FcgidIOTimeout".

If you are having this problem look up how to set 'FcgidIOTimeout" for your hosting. In my case I set this to 240 (seconds) and it works fine.

Ian

The following user(s) said Thank You: nicolas

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

  • Posts: 250
  • Thank you received: 7
3 years 11 months ago #234725

I hope Nicolas doesn't mind me posting this here but for anybody else wanting to use variants with Google Products I'm now offering a plugin customisation service.

With the help of Holmes-Pierce I have rewritten the plugin to work with variants and to overcome the performance limitations of the original. Holmes-Pierce has it working on his site, elevateyoursole , with 1600 variants. I have it working on my site Artist Papers with 600 variants.

As Nicolas says it's difficult to make a plugin that will accommodate everyone's requirements as there are many ways of using variants, so customisation seems to be the way to go to develop this further.

A bit more background on my blog here or contact me with what you are needing to do.

Ian

The following user(s) said Thank You: nicolas

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

  • Posts: 846
  • Thank you received: 92
3 years 8 months ago #244780

i reverse the way variant logic is implemented using SQL proxy to follow how variant are create .
Does this method can resolve the issue only for export not use by hihashop in joomla :
1- create " structure " for each characteristic a specific field in product table
2- create/insert "data" in this table relative to number of variant use in hikashop

here a captrue screen of mysql table / GUI BE where column value contain both value and label field name !!!
jos_hikashop_product.product_code = jos_hikashop_product.product_code value + _number ( _1 _ 2 _ 3)
number = hikashop_characteristic.characteristic_id




regard's

Attachments:
Last edit: 3 years 8 months ago by lionel75.

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

Time to create page: 0.111 seconds
Powered by Kunena Forum