[Skip to main content](#vessel-content)

#  Profile for Reincidente

##

[![Reincidente's Avatar](https://www.hikashop.com/media/kunena/core/svg/person.svg)](/forum/user/12307-reincidente "View Reincidente's Profile")

**[ Offline](/forum/user/12307-reincidente)**

- **User Type:** User

- **Register Date:** 12 Dec 2012
- **Last login:** 3 days 44 minutes ago
- **Time Zone:**  UTC +1:00
- **Local Time:** 08:04

- **Posts:** 465
- **Profile views:** 296
- **Thank you received:** 19

- **Gender:** Unknown
- **Medals:**  Hikashop Business

- Posts

#  Reincidente's recent posts  (466 messages )

All Since last visit 4 Hours 8 Hours 12 Hours 24 Hours 48 Hours Week Month Year     All Since last visit 4 Hours 8 Hours 12 Hours 24 Hours 48 Hours Week Month Year

| <a id="forumtop"> </a> [  ](#forumbottom) | Subject | Replies / Views | Last Post | <a id="forumbottom"> </a> [   ](#forumtop) |
|---|---|---|---|---|
| [](/forum/25-install-update/100000027-hikashop-generating-duplicate-product-urls-with-product-id#100000149) | [HikaShop generating duplicate product URLs with product ID](/forum/25-install-update/100000027-hikashop-generating-duplicate-product-urls-with-product-id#100000149 "-- Browser(s) name and version -- : Chrome 154.0  Hi Nicolas, We have noticed a new issue in Google Search Console after the recent changes related to HikaShop breadcrumbs. Google has suddenly started discovering hundreds of alternative product URLs containing the HikaShop product ID, for example: Correct URL:  Alternative URL discovered by Google:  Another example: Correct:  Alternative:  The alternative URLs return HTTP 200 and HikaShop correctly outputs a canonical pointing to the clean URL, so Google currently reports them as “Alternate page with proper canonical tag”. However, Google Search Console shows a large and recent increase in these URLs, and URL Inspection reports the clean product URL itself as a referring URL for the alternative URL. This seems to indicate that somewhere on the product page HikaShop is now generating/discovering links using the format:  instead of:  This appears to coincide with the recent breadcrumb changes. Could this be caused by the new HikaShop breadcrumb/router behaviour? Ideally, we would like HikaShop to generate only the clean product URLs internally, without the product ID, while keeping our existing URLs unchanged. Could you please check this before we modify anything on our side? Thanks, José Ángel")         Category: [Install &amp; Update](/forum/25-install-update "Having an installation or update issue? You will probably find some help here.")     Topic started 4 weeks 23 hours ago, by [Reincidente](/forum/user/12307-reincidente "View Reincidente's Profile")       [Last Post](/forum/25-install-update/100000027-hikashop-generating-duplicate-product-urls-with-product-id#100000151 "Hi Nicolas,  We ran the test with Error Reporting set to Maximum and found the cause of the HTTP 500.  The fatal error is: Call to a member function get() on null  File: /plugins/system/hikashop&#95;ga4/hikashop&#95;ga4.php Line: 594  Before the fatal error, Joomla also reports: Warning: Undefined variable $categoryClass in the same file and line.  The failing line is: $cat = $categoryClass-&gt;get($categoryId);  The stack trace shows the error originates in plgSystemHikashop&#95;ga4-&gt;getCategoryInfo(), called from getCategoryJS() and then onBeforeCompileHead().  So it appears that the hikashop&#95;ga4 system plugin is not initializing $categoryClass in this particular product listing context.  We have now restored Joomla Error Reporting to its previous setting.  Does this plugin belong to HikaShop, or should we contact its developer to have this case fixed?  Thanks, José Ángel") 4 weeks 11 hours ago     by [Reincidente](/forum/user/12307-reincidente "View Reincidente's Profile") | Replies:2  Views:120 | [Last Post](/forum/25-install-update/100000027-hikashop-generating-duplicate-product-urls-with-product-id#100000151 "Hi Nicolas,  We ran the test with Error Reporting set to Maximum and found the cause of the HTTP 500.  The fatal error is: Call to a member function get() on null  File: /plugins/system/hikashop&#95;ga4/hikashop&#95;ga4.php Line: 594  Before the fatal error, Joomla also reports: Warning: Undefined variable $categoryClass in the same file and line.  The failing line is: $cat = $categoryClass-&gt;get($categoryId);  The stack trace shows the error originates in plgSystemHikashop&#95;ga4-&gt;getCategoryInfo(), called from getCategoryJS() and then onBeforeCompileHead().  So it appears that the hikashop&#95;ga4 system plugin is not initializing $categoryClass in this particular product listing context.  We have now restored Joomla Error Reporting to its previous setting.  Does this plugin belong to HikaShop, or should we contact its developer to have this case fixed?  Thanks, José Ángel") by [Reincidente](/forum/user/12307-reincidente "View Reincidente's Profile")      4 weeks 11 hours ago |
| [](/forum/25-install-update/100000027-hikashop-generating-duplicate-product-urls-with-product-id#100000137) | [HikaShop generating duplicate product URLs with product ID](/forum/25-install-update/100000027-hikashop-generating-duplicate-product-urls-with-product-id#100000137 "-- Browser(s) name and version -- : Chrome 154.0  Hi Nicolas, We have noticed a new issue in Google Search Console after the recent changes related to HikaShop breadcrumbs. Google has suddenly started discovering hundreds of alternative product URLs containing the HikaShop product ID, for example: Correct URL:  Alternative URL discovered by Google:  Another example: Correct:  Alternative:  The alternative URLs return HTTP 200 and HikaShop correctly outputs a canonical pointing to the clean URL, so Google currently reports them as “Alternate page with proper canonical tag”. However, Google Search Console shows a large and recent increase in these URLs, and URL Inspection reports the clean product URL itself as a referring URL for the alternative URL. This seems to indicate that somewhere on the product page HikaShop is now generating/discovering links using the format:  instead of:  This appears to coincide with the recent breadcrumb changes. Could this be caused by the new HikaShop breadcrumb/router behaviour? Ideally, we would like HikaShop to generate only the clean product URLs internally, without the product ID, while keeping our existing URLs unchanged. Could you please check this before we modify anything on our side? Thanks, José Ángel")         Category: [Install &amp; Update](/forum/25-install-update "Having an installation or update issue? You will probably find some help here.")     Topic started 4 weeks 23 hours ago, by [Reincidente](/forum/user/12307-reincidente "View Reincidente's Profile")       [Last Post](/forum/25-install-update/100000027-hikashop-generating-duplicate-product-urls-with-product-id#100000151 "Hi Nicolas,  We ran the test with Error Reporting set to Maximum and found the cause of the HTTP 500.  The fatal error is: Call to a member function get() on null  File: /plugins/system/hikashop&#95;ga4/hikashop&#95;ga4.php Line: 594  Before the fatal error, Joomla also reports: Warning: Undefined variable $categoryClass in the same file and line.  The failing line is: $cat = $categoryClass-&gt;get($categoryId);  The stack trace shows the error originates in plgSystemHikashop&#95;ga4-&gt;getCategoryInfo(), called from getCategoryJS() and then onBeforeCompileHead().  So it appears that the hikashop&#95;ga4 system plugin is not initializing $categoryClass in this particular product listing context.  We have now restored Joomla Error Reporting to its previous setting.  Does this plugin belong to HikaShop, or should we contact its developer to have this case fixed?  Thanks, José Ángel") 4 weeks 11 hours ago     by [Reincidente](/forum/user/12307-reincidente "View Reincidente's Profile") | Replies:2  Views:120 | [Last Post](/forum/25-install-update/100000027-hikashop-generating-duplicate-product-urls-with-product-id#100000151 "Hi Nicolas,  We ran the test with Error Reporting set to Maximum and found the cause of the HTTP 500.  The fatal error is: Call to a member function get() on null  File: /plugins/system/hikashop&#95;ga4/hikashop&#95;ga4.php Line: 594  Before the fatal error, Joomla also reports: Warning: Undefined variable $categoryClass in the same file and line.  The failing line is: $cat = $categoryClass-&gt;get($categoryId);  The stack trace shows the error originates in plgSystemHikashop&#95;ga4-&gt;getCategoryInfo(), called from getCategoryJS() and then onBeforeCompileHead().  So it appears that the hikashop&#95;ga4 system plugin is not initializing $categoryClass in this particular product listing context.  We have now restored Joomla Error Reporting to its previous setting.  Does this plugin belong to HikaShop, or should we contact its developer to have this case fixed?  Thanks, José Ángel") by [Reincidente](/forum/user/12307-reincidente "View Reincidente's Profile")      4 weeks 11 hours ago |
| [](/forum/25-install-update/100000027-hikashop-generating-duplicate-product-urls-with-product-id#100000131) | [HikaShop generating duplicate product URLs with product ID](/forum/25-install-update/100000027-hikashop-generating-duplicate-product-urls-with-product-id#100000131 "-- Browser(s) name and version -- : Chrome 154.0  Hi Nicolas, We have noticed a new issue in Google Search Console after the recent changes related to HikaShop breadcrumbs. Google has suddenly started discovering hundreds of alternative product URLs containing the HikaShop product ID, for example: Correct URL:  Alternative URL discovered by Google:  Another example: Correct:  Alternative:  The alternative URLs return HTTP 200 and HikaShop correctly outputs a canonical pointing to the clean URL, so Google currently reports them as “Alternate page with proper canonical tag”. However, Google Search Console shows a large and recent increase in these URLs, and URL Inspection reports the clean product URL itself as a referring URL for the alternative URL. This seems to indicate that somewhere on the product page HikaShop is now generating/discovering links using the format:  instead of:  This appears to coincide with the recent breadcrumb changes. Could this be caused by the new HikaShop breadcrumb/router behaviour? Ideally, we would like HikaShop to generate only the clean product URLs internally, without the product ID, while keeping our existing URLs unchanged. Could you please check this before we modify anything on our side? Thanks, José Ángel")         Category: [Install &amp; Update](/forum/25-install-update "Having an installation or update issue? You will probably find some help here.")     Topic started 4 weeks 23 hours ago, by [Reincidente](/forum/user/12307-reincidente "View Reincidente's Profile")       [Last Post](/forum/25-install-update/100000027-hikashop-generating-duplicate-product-urls-with-product-id#100000151 "Hi Nicolas,  We ran the test with Error Reporting set to Maximum and found the cause of the HTTP 500.  The fatal error is: Call to a member function get() on null  File: /plugins/system/hikashop&#95;ga4/hikashop&#95;ga4.php Line: 594  Before the fatal error, Joomla also reports: Warning: Undefined variable $categoryClass in the same file and line.  The failing line is: $cat = $categoryClass-&gt;get($categoryId);  The stack trace shows the error originates in plgSystemHikashop&#95;ga4-&gt;getCategoryInfo(), called from getCategoryJS() and then onBeforeCompileHead().  So it appears that the hikashop&#95;ga4 system plugin is not initializing $categoryClass in this particular product listing context.  We have now restored Joomla Error Reporting to its previous setting.  Does this plugin belong to HikaShop, or should we contact its developer to have this case fixed?  Thanks, José Ángel") 4 weeks 11 hours ago     by [Reincidente](/forum/user/12307-reincidente "View Reincidente's Profile") | Replies:2  Views:120 | [Last Post](/forum/25-install-update/100000027-hikashop-generating-duplicate-product-urls-with-product-id#100000151 "Hi Nicolas,  We ran the test with Error Reporting set to Maximum and found the cause of the HTTP 500.  The fatal error is: Call to a member function get() on null  File: /plugins/system/hikashop&#95;ga4/hikashop&#95;ga4.php Line: 594  Before the fatal error, Joomla also reports: Warning: Undefined variable $categoryClass in the same file and line.  The failing line is: $cat = $categoryClass-&gt;get($categoryId);  The stack trace shows the error originates in plgSystemHikashop&#95;ga4-&gt;getCategoryInfo(), called from getCategoryJS() and then onBeforeCompileHead().  So it appears that the hikashop&#95;ga4 system plugin is not initializing $categoryClass in this particular product listing context.  We have now restored Joomla Error Reporting to its previous setting.  Does this plugin belong to HikaShop, or should we contact its developer to have this case fixed?  Thanks, José Ángel") by [Reincidente](/forum/user/12307-reincidente "View Reincidente's Profile")      4 weeks 11 hours ago |
| [](/forum/25-install-update/100000015-automatic-discounts-are-lost-when-completing-a-customers-cart-from-the-backend#100000066) | [Automatic discounts are lost when completing a customer's cart from the backend](/forum/25-install-update/100000015-automatic-discounts-are-lost-when-completing-a-customers-cart-from-the-backend#100000066 "-- Browser(s) name and version -- : Chrome 154.0  Hello Nicolas, We have detected an issue when we complete an order manually from the backend on behalf of a registered customer. The scenario is the following:  &#42; A registered customer already has products in their cart.  &#42; The cart qualifies for automatic discounts based on the order amount and/or product quantity.  &#42; These are always automatic discounts, not coupon codes entered manually by the customer.  &#42; The customer contacts us because they cannot complete the checkout themselves and asks us to finalize the order from the backend.  When we complete the order from the backend, the automatic discounts that were applicable to the customer's cart are not preserved/recalculated, so the order is created without those discounts. Is there any way to make HikaShop apply the same automatic discounts when we complete the order from the backend, so that the final order keeps exactly the discounts the customer would have received through the frontend checkout? If this is not currently possible by default, could you please let us know whether there is a setting, workaround, or small customization that could achieve this? Thank you. Best regards, José Ángel")        Category: [Install &amp; Update](/forum/25-install-update "Having an installation or update issue? You will probably find some help here.")     Topic started 1 month 3 days ago, by [Reincidente](/forum/user/12307-reincidente "View Reincidente's Profile")       [Last Post](/forum/25-install-update/100000015-automatic-discounts-are-lost-when-completing-a-customers-cart-from-the-backend#100000067 "Hi Nicolas, Thank you for your explanation. Unfortunately, it has not worked in our case. We followed the procedure you described: Customers &gt; Carts, opened the customer's existing cart and used the &quot;Create order&quot; button. However, the automatic discounts were still not carried over to the order. There is one important detail that may be relevant: we use AwoCoupon to manage our coupons and automatic discounts. Could you please confirm whether the fact that we are using AwoCoupon could be the reason why the automatic discounts are not preserved when HikaShop creates the order from the customer's cart? Thank you. Best regards, José Ángel") 1 month 2 days ago     by [Reincidente](/forum/user/12307-reincidente "View Reincidente's Profile") | Replies:2  Views:129 | [Last Post](/forum/25-install-update/100000015-automatic-discounts-are-lost-when-completing-a-customers-cart-from-the-backend#100000067 "Hi Nicolas, Thank you for your explanation. Unfortunately, it has not worked in our case. We followed the procedure you described: Customers &gt; Carts, opened the customer's existing cart and used the &quot;Create order&quot; button. However, the automatic discounts were still not carried over to the order. There is one important detail that may be relevant: we use AwoCoupon to manage our coupons and automatic discounts. Could you please confirm whether the fact that we are using AwoCoupon could be the reason why the automatic discounts are not preserved when HikaShop creates the order from the customer's cart? Thank you. Best regards, José Ángel") by [Reincidente](/forum/user/12307-reincidente "View Reincidente's Profile")      1 month 2 days ago |
| [](/forum/25-install-update/100000015-automatic-discounts-are-lost-when-completing-a-customers-cart-from-the-backend#100000060) | [Automatic discounts are lost when completing a customer's cart from the backend](/forum/25-install-update/100000015-automatic-discounts-are-lost-when-completing-a-customers-cart-from-the-backend#100000060 "-- Browser(s) name and version -- : Chrome 154.0  Hello Nicolas, We have detected an issue when we complete an order manually from the backend on behalf of a registered customer. The scenario is the following:  &#42; A registered customer already has products in their cart.  &#42; The cart qualifies for automatic discounts based on the order amount and/or product quantity.  &#42; These are always automatic discounts, not coupon codes entered manually by the customer.  &#42; The customer contacts us because they cannot complete the checkout themselves and asks us to finalize the order from the backend.  When we complete the order from the backend, the automatic discounts that were applicable to the customer's cart are not preserved/recalculated, so the order is created without those discounts. Is there any way to make HikaShop apply the same automatic discounts when we complete the order from the backend, so that the final order keeps exactly the discounts the customer would have received through the frontend checkout? If this is not currently possible by default, could you please let us know whether there is a setting, workaround, or small customization that could achieve this? Thank you. Best regards, José Ángel")        Category: [Install &amp; Update](/forum/25-install-update "Having an installation or update issue? You will probably find some help here.")     Topic started 1 month 3 days ago, by [Reincidente](/forum/user/12307-reincidente "View Reincidente's Profile")       [Last Post](/forum/25-install-update/100000015-automatic-discounts-are-lost-when-completing-a-customers-cart-from-the-backend#100000067 "Hi Nicolas, Thank you for your explanation. Unfortunately, it has not worked in our case. We followed the procedure you described: Customers &gt; Carts, opened the customer's existing cart and used the &quot;Create order&quot; button. However, the automatic discounts were still not carried over to the order. There is one important detail that may be relevant: we use AwoCoupon to manage our coupons and automatic discounts. Could you please confirm whether the fact that we are using AwoCoupon could be the reason why the automatic discounts are not preserved when HikaShop creates the order from the customer's cart? Thank you. Best regards, José Ángel") 1 month 2 days ago     by [Reincidente](/forum/user/12307-reincidente "View Reincidente's Profile") | Replies:2  Views:129 | [Last Post](/forum/25-install-update/100000015-automatic-discounts-are-lost-when-completing-a-customers-cart-from-the-backend#100000067 "Hi Nicolas, Thank you for your explanation. Unfortunately, it has not worked in our case. We followed the procedure you described: Customers &gt; Carts, opened the customer's existing cart and used the &quot;Create order&quot; button. However, the automatic discounts were still not carried over to the order. There is one important detail that may be relevant: we use AwoCoupon to manage our coupons and automatic discounts. Could you please confirm whether the fact that we are using AwoCoupon could be the reason why the automatic discounts are not preserved when HikaShop creates the order from the customer's cart? Thank you. Best regards, José Ángel") by [Reincidente](/forum/user/12307-reincidente "View Reincidente's Profile")      1 month 2 days ago |
| [](/forum/25-install-update/910798-visibility-of-published-default-icons-in-product-variants#373295) | [Visibility of “Published / Default” icons in product variants](/forum/25-install-update/910798-visibility-of-published-default-icons-in-product-variants#373295 "-- HikaShop version -- : 6.6.0  Hi Nicolas.  After updating HikaShop, we have noticed that in the product variants list, the icons indicating whether a variant is Published and/or set as Default are now barely visible.  I have attached a screenshot. As you can see, especially in the “Published” column, the white icons on the light grey background have very little contrast. Previously, these statuses were much easier to identify at a glance.  Are you aware of this change or of any styling issue related to the latest HikaShop versions?  If so, is a fix planned? In the meantime, is there any backend CSS we can safely modify to make these icons more visible without causing issues with future updates?  We are currently using HikaShop 6.6.0.  Thank you.  Best regards, José Ángel Hermanos Galiano")         Category: [Install &amp; Update](/forum/25-install-update "Having an installation or update issue? You will probably find some help here.")     Topic started 1 month 4 weeks ago, by [Reincidente](/forum/user/12307-reincidente "View Reincidente's Profile")       [Last Post](/forum/25-install-update/910798-visibility-of-published-default-icons-in-product-variants#373296 "Hello,  That build does contain the fix, but the fix is only in a CSS file, which is installed in the media folder of Joomla, separately from the rest of HikaShop. And the problem you reported came from a change in a PHP file, so seeing it appear after the update doesn't tell us that the CSS file was updated too. Two checks:  1. In the Configuration menu of HikaShop, Display tab, click on the pencil next to the &quot;Back-end CSS File&quot; setting. First, make sure it is set to &quot;default&quot;. Also, the edit button displays the file as it is on your server. Search for the text span.icon-publish in it. If it is not there, add these two rules at the end and save:  2. If the text is there, open   www.yourwebsite.com/media/com&#95;hikashop/css/backend&#95;default.css  in your browser, with your own domain, and search for it again. If you don't find it there, a cache in front of your website, a CDN like Cloudflare for example, is serving the old file, and emptying its cache will solve it.  If neither of the two explains it, we'll need a backend access to your website to look at it directly. You can send it to us with our contact form,   www.hikashop.com/support/contact-us.html , along with a link to this thread.") 1 month 4 weeks ago     by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:3  Views:238 | [Last Post](/forum/25-install-update/910798-visibility-of-published-default-icons-in-product-variants#373296 "Hello,  That build does contain the fix, but the fix is only in a CSS file, which is installed in the media folder of Joomla, separately from the rest of HikaShop. And the problem you reported came from a change in a PHP file, so seeing it appear after the update doesn't tell us that the CSS file was updated too. Two checks:  1. In the Configuration menu of HikaShop, Display tab, click on the pencil next to the &quot;Back-end CSS File&quot; setting. First, make sure it is set to &quot;default&quot;. Also, the edit button displays the file as it is on your server. Search for the text span.icon-publish in it. If it is not there, add these two rules at the end and save:  2. If the text is there, open   www.yourwebsite.com/media/com&#95;hikashop/css/backend&#95;default.css  in your browser, with your own domain, and search for it again. If you don't find it there, a cache in front of your website, a CDN like Cloudflare for example, is serving the old file, and emptying its cache will solve it.  If neither of the two explains it, we'll need a backend access to your website to look at it directly. You can send it to us with our contact form,   www.hikashop.com/support/contact-us.html , along with a link to this thread.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile")      1 month 4 weeks ago |
| [](/forum/25-install-update/910798-visibility-of-published-default-icons-in-product-variants#373292) | [Visibility of “Published / Default” icons in product variants](/forum/25-install-update/910798-visibility-of-published-default-icons-in-product-variants#373292 "-- HikaShop version -- : 6.6.0  Hi Nicolas.  After updating HikaShop, we have noticed that in the product variants list, the icons indicating whether a variant is Published and/or set as Default are now barely visible.  I have attached a screenshot. As you can see, especially in the “Published” column, the white icons on the light grey background have very little contrast. Previously, these statuses were much easier to identify at a glance.  Are you aware of this change or of any styling issue related to the latest HikaShop versions?  If so, is a fix planned? In the meantime, is there any backend CSS we can safely modify to make these icons more visible without causing issues with future updates?  We are currently using HikaShop 6.6.0.  Thank you.  Best regards, José Ángel Hermanos Galiano")         Category: [Install &amp; Update](/forum/25-install-update "Having an installation or update issue? You will probably find some help here.")     Topic started 1 month 4 weeks ago, by [Reincidente](/forum/user/12307-reincidente "View Reincidente's Profile")       [Last Post](/forum/25-install-update/910798-visibility-of-published-default-icons-in-product-variants#373296 "Hello,  That build does contain the fix, but the fix is only in a CSS file, which is installed in the media folder of Joomla, separately from the rest of HikaShop. And the problem you reported came from a change in a PHP file, so seeing it appear after the update doesn't tell us that the CSS file was updated too. Two checks:  1. In the Configuration menu of HikaShop, Display tab, click on the pencil next to the &quot;Back-end CSS File&quot; setting. First, make sure it is set to &quot;default&quot;. Also, the edit button displays the file as it is on your server. Search for the text span.icon-publish in it. If it is not there, add these two rules at the end and save:  2. If the text is there, open   www.yourwebsite.com/media/com&#95;hikashop/css/backend&#95;default.css  in your browser, with your own domain, and search for it again. If you don't find it there, a cache in front of your website, a CDN like Cloudflare for example, is serving the old file, and emptying its cache will solve it.  If neither of the two explains it, we'll need a backend access to your website to look at it directly. You can send it to us with our contact form,   www.hikashop.com/support/contact-us.html , along with a link to this thread.") 1 month 4 weeks ago     by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:3  Views:238 | [Last Post](/forum/25-install-update/910798-visibility-of-published-default-icons-in-product-variants#373296 "Hello,  That build does contain the fix, but the fix is only in a CSS file, which is installed in the media folder of Joomla, separately from the rest of HikaShop. And the problem you reported came from a change in a PHP file, so seeing it appear after the update doesn't tell us that the CSS file was updated too. Two checks:  1. In the Configuration menu of HikaShop, Display tab, click on the pencil next to the &quot;Back-end CSS File&quot; setting. First, make sure it is set to &quot;default&quot;. Also, the edit button displays the file as it is on your server. Search for the text span.icon-publish in it. If it is not there, add these two rules at the end and save:  2. If the text is there, open   www.yourwebsite.com/media/com&#95;hikashop/css/backend&#95;default.css  in your browser, with your own domain, and search for it again. If you don't find it there, a cache in front of your website, a CDN like Cloudflare for example, is serving the old file, and emptying its cache will solve it.  If neither of the two explains it, we'll need a backend access to your website to look at it directly. You can send it to us with our contact form,   www.hikashop.com/support/contact-us.html , along with a link to this thread.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile")      1 month 4 weeks ago |
| [](/forum/25-install-update/910784-product-import-unexpectedly-changes-tax-category#373192) | [Product import unexpectedly changes tax category](/forum/25-install-update/910784-product-import-unexpectedly-changes-tax-category#373192 "Hi,  I have noticed an issue when updating existing products through HikaShop import.  The import itself works correctly and updates the product information as expected. However, after importing, the product's Tax category is automatically changed.  Before the import, the product has:  Tax category: Impuestos España  After the import, it changes automatically to:  Tax category: Electronic goods &amp; services  I am not intentionally modifying the tax category during the import.  Could you please tell me:  What CSV field/column controls the product tax category during an import? If that column is not included in the CSV, should HikaShop preserve the existing tax category? Could HikaShop be assigning a default tax category during the import? Is there any configuration or import behaviour that could explain why Electronic goods &amp; services is being assigned automatically?  The product already exists in HikaShop; I am using the import mainly to update its content, not to create a new product.  I can provide the CSV headers and an example imported row if necessary.  I have attached screenshots showing the tax category before and after the import.  Thanks.")         Category: [Install &amp; Update](/forum/25-install-update "Having an installation or update issue? You will probably find some help here.")     Topic started 2 months 4 days ago, by [Reincidente](/forum/user/12307-reincidente "View Reincidente's Profile")       [Last Post](/forum/25-install-update/910784-product-import-unexpectedly-changes-tax-category#373197 "Hi,  Thank you for the clear report, you found a bug and I could reproduce it here.  To answer your questions in order:  - The column is product&#95;tax&#95;id, and it takes either the identifier of a tax category or its name. - Yes, when that column is not in your file, an update should leave the tax category of the product alone. - It does not, and that is the bug: the tax category HikaShop gives to a product being created was also applied to the products being updated. The one it picks is the last of your tax categories in the ordering of Configuration &gt; Taxes, which is why &quot;Electronic goods &amp; services&quot; is the one you see. - So there is no setting behind it, nothing on your side to correct.  It is fixed on our end and the fix has been added on our end. Download the install package of HikaShop on our website and install it on yours in order to get it.  Without the patch, adding a product&#95;tax&#95;id column to your file with the value you want, for example:  keeps each product on its own tax category through the import. If all the products of the file share the same one, that is a single value repeated on every row.") 2 months 4 days ago     by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:1  Views:216 | [Last Post](/forum/25-install-update/910784-product-import-unexpectedly-changes-tax-category#373197 "Hi,  Thank you for the clear report, you found a bug and I could reproduce it here.  To answer your questions in order:  - The column is product&#95;tax&#95;id, and it takes either the identifier of a tax category or its name. - Yes, when that column is not in your file, an update should leave the tax category of the product alone. - It does not, and that is the bug: the tax category HikaShop gives to a product being created was also applied to the products being updated. The one it picks is the last of your tax categories in the ordering of Configuration &gt; Taxes, which is why &quot;Electronic goods &amp; services&quot; is the one you see. - So there is no setting behind it, nothing on your side to correct.  It is fixed on our end and the fix has been added on our end. Download the install package of HikaShop on our website and install it on yours in order to get it.  Without the patch, adding a product&#95;tax&#95;id column to your file with the value you want, for example:  keeps each product on its own tax category through the import. If all the products of the file share the same one, that is a single value repeated on every row.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile")      2 months 4 days ago |
| [](/forum/26-product-category-display/910758-secondary-product-images-appear-distorted#373061) | [Secondary product images appear distorted](/forum/26-product-category-display/910758-secondary-product-images-appear-distorted#373061 "Hi Nicolas,  We have noticed an issue with the secondary images in the product page gallery.  The secondary images are displayed very tall and narrow, which distorts their proportions and makes them difficult to view properly.  The main product image is displayed correctly. The issue only affects the secondary images/thumbnails.  Do you know what could be causing this?")         Category: [Product &amp; Category Display](/forum/26-product-category-display "Questions about product and category display. You can't find how to make Hikashop looks incredible? The answer is here!")     Topic started 2 months 3 weeks ago, by [Reincidente](/forum/user/12307-reincidente "View Reincidente's Profile")       [Last Post](/forum/26-product-category-display/910758-secondary-product-images-appear-distorted#373067 "Hi,  That comes from the CSS of your template, not from the thumbnails themselves.  HikaShop generates the thumbnails at a fixed size and writes that size on the image tag, like this :  If the CSS of your template contains a rule which forces the width of the images, for example img { width: 100% }, without setting the height back to auto, the browser stretches the image to the whole width of the column while it keeps the height written on the tag. The result is exactly what your screenshot shows : thumbnails as wide as the block and completely flattened. The main image is not affected because it sits in a container of its own size.  Two ways to confirm it in one minute :  - open one of the thumbnails alone in a browser tab (right click on it, open the image in a new tab). If the file itself has the right proportions, then it is the CSS of the page. - right click on a thumbnail and choose Inspect : the rule which sets the width will be shown in the styles panel, with the name of the CSS file it comes from.  The fix is to add this in the custom CSS of your template :  Note that HikaShop never distorts an image : the two modes available in the configuration for the thumbnails are &quot;keep the ratio&quot; and &quot;crop&quot;, so a generated thumbnail always keeps its proportions.  If that does not solve it, give me the address of a product page of your website and I will look at it directly.") 2 months 3 weeks ago     by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:1  Views:255 | [Last Post](/forum/26-product-category-display/910758-secondary-product-images-appear-distorted#373067 "Hi,  That comes from the CSS of your template, not from the thumbnails themselves.  HikaShop generates the thumbnails at a fixed size and writes that size on the image tag, like this :  If the CSS of your template contains a rule which forces the width of the images, for example img { width: 100% }, without setting the height back to auto, the browser stretches the image to the whole width of the column while it keeps the height written on the tag. The result is exactly what your screenshot shows : thumbnails as wide as the block and completely flattened. The main image is not affected because it sits in a container of its own size.  Two ways to confirm it in one minute :  - open one of the thumbnails alone in a browser tab (right click on it, open the image in a new tab). If the file itself has the right proportions, then it is the CSS of the page. - right click on a thumbnail and choose Inspect : the rule which sets the width will be shown in the styles panel, with the name of the CSS file it comes from.  The fix is to add this in the custom CSS of your template :  Note that HikaShop never distorts an image : the two modes available in the configuration for the thumbnails are &quot;keep the ratio&quot; and &quot;crop&quot;, so a generated thumbnail always keeps its proportions.  If that does not solve it, give me the address of a product page of your website and I will look at it directly.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile")      2 months 3 weeks ago |
| [](/forum/25-install-update/910634-checkout-takes-several-seconds-after-clicking-finish-order#372470) | [Checkout takes several seconds after clicking “Finish order”](/forum/25-install-update/910634-checkout-takes-several-seconds-after-clicking-finish-order#372470 "Hi Nicolas,  I would like to ask you about something we are noticing during the checkout process.  When a customer clicks on the button to complete the order, the order processing takes a few seconds. During that time, a kind of loading/spinner icon appears, as if the system is “thinking”.  The problem is that several customers have told us that this step “takes too long”, and we are worried that some users may think the checkout is blocked or may even leave before the order is completed.  Is there any way to improve this delay, or at least to show a clearer message during that loading time, such as “Your order is being processed, please wait”?  Thank you. Best regards, José Ángel")        Category: [Install &amp; Update](/forum/25-install-update "Having an installation or update issue? You will probably find some help here.")     Topic started 4 months 6 days ago, by [Reincidente](/forum/user/12307-reincidente "View Reincidente's Profile")       [Last Post](/forum/25-install-update/910634-checkout-takes-several-seconds-after-clicking-finish-order#372471 "Hi,  I don't know all the features of AWOCoupon and I don't know exactly what you're using in AWOCoupon, so it would be foolish of me to guarantee you that you'll be able to do the same in HikaShop without relying on AWOCoupon. However, between all the features we've added in HikaShop in the past year, as well as the coupon conditions plugin we've added on our marketplace recently and the cart fee plugin, etc I think we should be able to cover anything.   www.hikashop.com/marketplace/product/292-coupon-conditions.html") 4 months 2 days ago     by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:9  Views:305 | [Last Post](/forum/25-install-update/910634-checkout-takes-several-seconds-after-clicking-finish-order#372471 "Hi,  I don't know all the features of AWOCoupon and I don't know exactly what you're using in AWOCoupon, so it would be foolish of me to guarantee you that you'll be able to do the same in HikaShop without relying on AWOCoupon. However, between all the features we've added in HikaShop in the past year, as well as the coupon conditions plugin we've added on our marketplace recently and the cart fee plugin, etc I think we should be able to cover anything.   www.hikashop.com/marketplace/product/292-coupon-conditions.html") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile")      4 months 2 days ago |

[](/forum/topics/feed/mode-topics?format=feed&type=rss)

Time to create page: 0.127 seconds

[Powered by](/forum/credits) [Kunena Forum](https://www.kunena.org)
