Problème affichage lors de mise à jour produits sur panier

  • Posts: 361
  • Thank you received: 28
  • Hikashop Multisite
1 year 2 months ago #354884

-- HikaShop version -- : 4.7.5
-- Joomla version -- : 4.3.4
-- PHP version -- : 8.1

Bonjour,
Je rencontre un souci d'affichage lorsque je met à jour le nombre de produit en étant sur le panier.
Testé avec Cassiopeia également.

En fait, il recharge la page puis ajoute le template par ligne... Voir screenshot, avec Cassiopeia et mon template.
Si je recharge la page manuellement une seconde fois, tout rentre dans l'ordre.


“Si tu ne travaille pas pour tes rêves, quelqu'un t'embauchera pour travailler pour les siens" - Steeve Jobs
"La sagesse, c’est d’avoir des rêves suffisamment grands pour ne pas les perdre de vue quand on les poursuit." - Oscar Wilde
Attachments:

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

  • Posts: 4747
  • Thank you received: 644
  • MODERATOR
1 year 2 months ago #354889

Bonjour,

Pour en savoir plus nous allons avoir besoin de voir le problème par nous même, donc pouvez vous nous fournir un lien Url (où nous pouvons observer le problème).

Une autre chose qui peut expliquer ce comportement hiératique, des plugin qui interviennent sur l'HTML de la page (pour le modifier où ajouter des éléments "à la volée").
Du coup, une façon rapide de vérifier cela est de dépublier les plugins potentiellement responsable un par un, ET de refaire le test (à chaque plugin éteins) pour voir si cela change quelque chose.

En attente de vos retours
Cordialement

Last edit: 1 year 2 months ago by Philip.

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

  • Posts: 361
  • Thank you received: 28
  • Hikashop Multisite
1 year 2 months ago #354907

En désactivant le plugin 4SEF le problème n'apparait plus.

Du coup, comment on fait pour le résoudre ? Je dois voir avec Yannick Gaultier de Weeblr ou avec vous ou les deux ?


“Si tu ne travaille pas pour tes rêves, quelqu'un t'embauchera pour travailler pour les siens" - Steeve Jobs
"La sagesse, c’est d’avoir des rêves suffisamment grands pour ne pas les perdre de vue quand on les poursuit." - Oscar Wilde

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

  • Posts: 4747
  • Thank you received: 644
  • MODERATOR
1 year 2 months ago #354909

Bonjour,

Il y a de bonne chance (au moins pour le début) que vous deviez commencer par voir le dev support 4SEF.
En espérant que vous aller trouver votre solution, et d'ailleurs si vous pouviez nous faire un retour ici sur la solution qui vous sera apporter.

Cordialement

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

  • Posts: 361
  • Thank you received: 28
  • Hikashop Multisite
1 year 2 months ago #354915

OK ça marche. Bon leur support est en vacances jusqu'au 18.09... Pas de bol.
Je vous tiendrais au courant.


“Si tu ne travaille pas pour tes rêves, quelqu'un t'embauchera pour travailler pour les siens" - Steeve Jobs
"La sagesse, c’est d’avoir des rêves suffisamment grands pour ne pas les perdre de vue quand on les poursuit." - Oscar Wilde
The following user(s) said Thank You: nicolas

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

  • Posts: 361
  • Thank you received: 28
  • Hikashop Multisite
1 year 2 months ago #355201

Bonjour,
J'ai des nouvelles de Weeblr (Yannick Gaultier), voici ces remarques :

**********************************
The reason this is happening is because Hikashop is doing 3 requests to update the display, one per line in the cart:



I don't know why it does, but it does.

The other problem, which may be the root cause, is that to edit the quantity, they use such URL:

meylanmateriaux.ch/panier/checkout/submitblock/tmpl-raw
meylanmateriaux.ch/panier/product/cart/m...-cart/tmpl-component
These are wrong and I don't know why they use that instead of a non-sef URL.

I also noticed the following: when I run a 4SEO analysis on the site, I see new URLs being created in 4SEF similar to:

categories/articles-speciaux/x-wblr-cw-cdn-bpass-id-f9173531-b3ea-4503-91dd-c2ee80fdb994
The x-wblr-.... part is coming from 4SEO (it's used to bypass cdn caching, such as cloudflare). It's normally removed and should never be used in URL but it looks like the Hikashop router is appending all these bits to the URL for some reason.

To be able to troubleshoot the URL creation part, and understand if the problem comes only from Hikashop, from 4SEF or both, I'll need to take a backup of your current site and install locally to trace how each URL is created. You have 3 akeeba backup profiles, which one should I use? (I don't need the images actually)
*********************************


Puis dans une seconde réponse :

***********************************
Hi

So at least I know why there are such weird URLs.

Hikashop just add anything in the non-SEF URLs to the SEF URL, if it does not know how to handle it. That's why the URLs below are created and stored by 4SEF:

/panier/checkout/submitblock/tmpl-raw
/panier/product/cart/module_id-122/module_type-cart/tmpl-component
categories/articles-speciaux/x-wblr-cw-cdn-bpass-id-f9173531-b3ea-4503-91dd-c2ee80fdb994
At the end of their router.php file, they have this code:

if(!empty($query)){
foreach($query as $name => $value){
if(!in_array($name,array('option','Itemid','start','format','limitstart','lang','cart_id'))){
if(is_array($value)) $value = implode('-',$value);
$segments[] = $name.$separator.$value;
unset($query[$name]);
}
}
}
which does add all non-used query variables to the SEF URL. Not much I can do about it.

I think this is the source of the problem, and at this stage, I'd really need their feedback. This is pretty bad for any installation of Hikashop that works with 4SEF (and with sh404SEF in the past) and I never realized that.

Currently, the list of excluded query variables is:

'option','Itemid','start','format','limitstart','lang','cart_id'
At the very least, it should also include 'tmpl' and likely others (search term?). If they could also exclude any variable that starts with "x-wblr", that'd be great.

Can you pass this message to them in extenso and get their feedback?
****************************************

Je n'y comprend rien, donc je ne fait que transmettre :)


“Si tu ne travaille pas pour tes rêves, quelqu'un t'embauchera pour travailler pour les siens" - Steeve Jobs
"La sagesse, c’est d’avoir des rêves suffisamment grands pour ne pas les perdre de vue quand on les poursuit." - Oscar Wilde
Attachments:

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

  • Posts: 82863
  • Thank you received: 13372
  • MODERATOR
1 year 2 months ago #355204

Bonjour;

Je vais répondre en Anglais du coup. Merci de transmettre dans l'autre sens :)
Sinon, vous pouvez fournir l'URL de ce sujet à Yannick pour qu'il réponde directement ici. Voir qu'il me contacte à mon adresse email perso, vu qu'il l'a déjà :)

Hikashop is doing 3 requests to update the display, one per line in the cart

That's not the case. It's sending the new data to the server via /panier/checkout/submitblock/tmpl-raw
Then, upon receiving the response from the server, it triggers javascript HikaShop events, and the different views of the checkout listen to these events to refresh themselves. So each view which needs to be refreshed will be refreshed. Normally, if you look at the POST of these "showblock" HTTP requests, the parameters will be slightly different.

These are wrong and I don't know why they use that instead of a non-sef URL.

How are they wrong ? The two URLs you provided with this message look fine to me. Why are they SEFed ? Because SEF is activated on the frontend of the website. So all the URLs are SEFed. Why would that be a problem ?

Hikashop just add anything in the non-SEF URLs to the SEF URL, if it does not know how to handle it. That's why the URLs below are created and stored by 4SEF

Indeed.

This is pretty bad for any installation of Hikashop that works with 4SEF (and with sh404SEF in the past) and I never realized that.

No one ever reported a problem with this with sh404SEF though ?

If they could also exclude any variable that starts with "x-wblr", that'd be great.

That's definitely something we can do. I can change the line
if(!in_array($name,array('option','Itemid','start','format','limitstart','lang','cart_id'))){
to:
if(!in_array($name,array('option','Itemid','start','format','limitstart','lang','cart_id')) && substr($name,0,6) != 'x-wblr'){
so that it skips the 4SEF variables.
Can you confirm that it is ok with this modification ?

Regarding tmpl it is only used in popups and AJAX requests. There is no particular reason in having it in the SEFed URL or not on our end. It just ended up like this because it didn't matter so far. Why would it be a problem having it in the SEFed URL ?

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

  • Posts: 3
  • Thank you received: 1
1 year 2 months ago #355211

Bonjour Nicolas,

That's not the case. It's sending the new data to the server via /panier/checkout/submitblock/tmpl-raw

Pourtant c'est ce qu'il fait:

How are they wrong ? The two URLs you provided with this message look fine to me. Why are they SEFed ? Because SEF is activated on the frontend of the website. So all the URLs are SEFed. Why would that be a problem ?

Ce n'est pas un problème en théorie, je suppose, mais dans ce cas (et dans d'autres) cela pose 2 souçis:
- comme l'URL est SEF, la valeur tmpl=component ou tmpl=raw ne devient disponible qu'après le parsing de l'URL. Il y a donc un risque - si une extension fait appel à Factory::getDocument typiquement) que Joomla force le type de Document à HTML au lieu de raw.

- dans le cas particulier d'extension SEF, c'est terrible parce que chaque modification/suppression dans le panier (pareil pour la recherche par exemple) crée une nouvelle URL dans la base de donnée.

No one ever reported a problem with this with sh404SEF though ?

Des tas et des tas d'enregistrements dans la base de données, j'en ai vu, mais effectivement, cela ne pose pas de problème car tout "fonctionne".

Dans le cas de sh404SEF, cela n'avait pas plus d'effet que ça.
Dans le cas de 4SEF, justement pour éviter ce genre de souçi, je garde la variable "tmpl" non-sef systématiquement. Dans le cas, d'Hikashop, comme tu l'intègres dans l'URL SEF (ce que je n'ai jamais vu personnellement), cette variable a déjà disparue et 4SEF ne la voit pas, elle n'est donc pas stockée dans l'URL non-sef et 4SEF ne la génère pas quand il parse l'URL.

Le résultat est que la réponse à ta requête /panier/checkout/submitblock/tmpl-raw est le document complet HTML et non juste la réponse RAW que tu attends. Je suppose que c'est ce qui met le bazar ensuite dans l'affichage.

Regarding tmpl it is only used in popups and AJAX requests. There is no particular reason in having it in the SEFed URL or not on our end. It just ended up like this because it didn't matter so far. Why would it be a problem having it in the SEFed URL

Voir ci-dessus. Au pire, ça ne change rien, au mieux tu t'épargnes des risques avec certains sites. Si tmpl est une query var, elle est disponible tout de suite, au lieu d'avoir à attendre onAfterRoute.

so that it skips the 4SEF variables.
Can you confirm that it is ok with this modification ?

Je pense que oui, même s'il faut toujours tester bien sur (je vais le faire sur une copie du site)

Par ailleurs (c'est plus rapide à tester), je te confirme que l'ajout de 'tmpl dans la liste des exclusions résoud le problème rencontré par le client.

On s'en reparle demain.

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

  • Posts: 3
  • Thank you received: 1
1 year 2 months ago #355212

Je confirme aussi que le code pour supprimer x-wblr... fonctionne.

Est-ce que tu peux faire en sorte que cette liste soit extensible simplement? (un filtre à la WordPress par exemple?)

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

  • Posts: 82863
  • Thank you received: 13372
  • MODERATOR
1 year 2 months ago #355222

Bonjour,

Pourtant c'est ce qu'il fait

Non. Regarde ta capture d'écran. Il n'y a que la première requête HTTP qui est un "submitblock" (et qui donc envoi les données de la vue panier au serveur). Les autres requêtes HTTP ensuite sont pour rafraîchir les différentes vues suite à la mise à jour du panier.
Cela n'a rien à voir avec le nombre de produits dans le panier, mais avec le nombre de vues sur la même étape du passage en caisse qui a besoin d'être rafraîchie suite aux changements dans le panier.

Dans le cas de 4SEF, justement pour éviter ce genre de souçi, je garde la variable "tmpl" non-sef systématiquement. Dans le cas, d'Hikashop, comme tu l'intègres dans l'URL SEF (ce que je n'ai jamais vu personnellement), cette variable a déjà disparue et 4SEF ne la voit pas, elle n'est donc pas stockée dans l'URL non-sef et 4SEF ne la génère pas quand il parse l'URL.

Le résultat est que la réponse à ta requête /panier/checkout/submitblock/tmpl-raw est le document complet HTML et non juste la réponse RAW que tu attends. Je suppose que c'est ce qui met le bazar ensuite dans l'affichage.

Ok je vois. Je n'avais en effet pas penser qu'un plugin system dans un event avant le routage aurait besoin de tmpl. Et en effet, c'est surement cela qui met le bazar.

Par ailleurs (c'est plus rapide à tester), je te confirme que l'ajout de 'tmpl dans la liste des exclusions résoud le problème rencontré par le client.
Je confirme aussi que le code pour supprimer x-wblr... fonctionne.

Ok, merci du retour.

Est-ce que tu peux faire en sorte que cette liste soit extensible simplement? (un filtre à la WordPress par exemple?)

Je peux rajouter un event oui.
J'ai rajouté cela:
$params = array('option','Itemid','start','format','limitstart','lang','cart_id', 'tmpl');
JPluginHelper::importPlugin('hikashop');
$app = JFactory::getApplication();
$app->triggerEvent('onBeforeHikashopBuildRoute', array(&$query, $separator, &$params));
au début de _HikashopBuildRoute
Comme cela, $params sera utiliser dans
if(!in_array($name, $params) && substr($name,0,6) != 'x-wblr'){

J'ai testé tout cela, et cela fonctionne bien chez moi (sans 4SEF). J'ai fait un hot patch dans HikaShop vu qu'on vient tout juste de sortir HikaShop 5.0.0.

Last edit: 1 year 2 months ago by nicolas.

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

  • Posts: 3
  • Thank you received: 1
1 year 2 months ago #355225

Salut,

Les autres requêtes HTTP ensuite sont pour rafraîchir les différentes vues suite à la mise à jour du panier.

Pas de problème, je n'ai regardé que très rapidement ce que chaque methode JS faisait. Dans tous les cas, la réponse était une page HTML complète et non just du "raw".

qu'un plugin system dans un event avant le routage aurait besoin de tmpl. Et en effet, c'est surement cela qui met le bazar.

Par exemple certaines actions peuvent être désactivé si la page est du json ou raw. C'est rare. En pratique, le problème le plus courant est une erreur: le developpeur appelle la fonction getDocument() depuis un onAfterInitialise et cela suffit à forcer Joomla à mettre le type de document à HTML. Sauf si ?tmpl=raw est une variable query, dans ce cas, Joomla n'a pas besoin du parsing pour savoir que ce n'est pas du html.

Mais si tmpl=raw est SEF alors c'est seulement après onAfterRoute que Joomla sait que le document devrait être raw ou json et non HTML.
Et dans ce cas, il suffit du moindre appel à getDocument() avant onAfterRoute pour que la page soit full HTML.

J'ai testé tout cela, et cela fonctionne bien chez moi (sans 4SEF). J'ai fait un hot patch dans HikaShop vu qu'on vient tout juste de sortir HikaShop 5.0.0.

Si tmpl est dans la liste, j'ai testé manuellement chez moi et ça ira. C'est bien d'avoir une manière de modifier cette liste dynamiquement, car ce problème peut apparaître au cas par cas.

The following user(s) said Thank You: nicolas

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

  • Posts: 361
  • Thank you received: 28
  • Hikashop Multisite
1 year 2 months ago #355272

Bonjour,
J'ai installé la dernière version de Hikashop et le problème semble bien résolu.


“Si tu ne travaille pas pour tes rêves, quelqu'un t'embauchera pour travailler pour les siens" - Steeve Jobs
"La sagesse, c’est d’avoir des rêves suffisamment grands pour ne pas les perdre de vue quand on les poursuit." - Oscar Wilde

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

Time to create page: 0.105 seconds
Powered by Kunena Forum