Problem with taxes (Canada)

  • Posts: 72
  • Thank you received: 5
3 years 4 months ago #334487

I just send you the FTP info.

If you need anything else, please let me know.

Cheers, Maurice

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

  • Posts: 82863
  • Thank you received: 13372
  • MODERATOR
3 years 4 months ago #334492

Hi,

I got the FTP access and started working on it. However, I hit a road block.
You have opcache activated on your website.
Because of that, when I modify the PHP files, I sometimes don't get the change to apply before a long time.
For example, it's been 20 minutes I've added this code to the address.php file:

//RHD



$query = 'UPDATE '.hikashop_table('address').' SET address_state = \'\' WHERE address_id = '.(int)$addressData->address_id;

$this->database->setQuery($query);

hikashop_writeToLog($query);

$this->database->execute();

$query = 'SELECT * FROM '.hikashop_table('address').' WHERE address_id = '.(int)$addressData->address_id;

$this->database->setQuery($query);

hikashop_writeToLog($query);

$ret = $this->database->loadObject();

hikashop_writeToLog($ret, 'nicolas_test');
I'm trying to reset the address_state value in the database before running the save of the new data to make sure that the address_state is empty in the database, before starting the test and the log.
However, I'm yet to see the "nicolas_test" text in the log.
So could you first check with your hosting how you can disable temporarily opcache on your website so that the modifications of the PHP files are directly taken into account ?
Otherwise, it's almost impossible to move forward with the debug.

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

  • Posts: 72
  • Thank you received: 5
3 years 4 months ago #334493

I disabled Sitegrounds cache tool: NGINX DIRECT DELIVERY. Does that work for you now?

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

  • Posts: 82863
  • Thank you received: 13372
  • MODERATOR
3 years 4 months ago #334495

Hi,

Yes. I was able to do the necessary debugging.

Here is the report:
In the file administrator/components/com_hikashop/classes/address.php I've left the code:

$query = 'UPDATE '.hikashop_table('address').' SET address_state = \'\' WHERE address_id = '.(int)$addressData->address_id;

$this->database->setQuery($query);

$this->database->execute();

$query = 'SELECT * FROM '.hikashop_table('address').' WHERE address_id = '.(int)$addressData->address_id;

$this->database->setQuery($query);

$ret = $this->database->loadObject();
This code clears the address_state in the database from the address being updated before the saving of the address.
That way, we're sure that the state we see in the log doesn't come from the address data already in the database.

I've also left the code:
hikashop_writeToLog($addressData, 'before onAfterAddressUpdate');

$query = 'SELECT * FROM '.hikashop_table('address').' WHERE address_id = '.(int)$addressData->address_id;

$this->database->setQuery($query);

$ret = $this->database->loadObject();

hikashop_writeToLog($ret, 'Address Table');
and:
hikashop_writeToLog($addressData, 'after onAfterAddressUpdate');

$query = 'SELECT * FROM '.hikashop_table('address').' WHERE address_id = '.(int)$addressData->address_id;

$this->database->setQuery($query);

$ret = $this->database->loadObject();

hikashop_writeToLog($ret, 'Address Table');
which checks the address state in the database before and after the 'onAfterAddressUpdate' event.
I had to modify the code a bit as your code was basing itself on the address_user_id instead of the address_id and thus it was not always logging the correct address and thus provided false results in some of my tests.

Finally, I've left the code:
if($event== 'onafteraddressupdate'){ 
$db = JFactory::getDBO();
$db->setQuery('SELECT * FROM #__hikashop_address WHERE address_id = '.$args[0]->address_id);
$address = $db->loadObject();
hikashop_writeToLog($address, 'xxx');
hikashop_writeToLog(get_class($this->_observers[$key]), 'xxx');
$db->setQuery('SELECT * FROM #__hikashop_address WHERE address_id = '.$args[0]->address_id);
$address = $db->loadObject();
hikashop_writeToLog($address, 'xxx');
}
in the file libraries/joomla/event/dispatcher;php
That code will log the address data from the database before and after each plugin has been called as well as the plugin class.

All these pieces of code can now be removed (you can keep the first one in case you still have addresses with the wrong address_state already in the database).

If you check the folder media/com_hikashop/upload/safe/logs you will see many log files. I've basically incremented the number of the report by 1 for each test I've made. These log files can also be deleted after you review them.

The interesting ones are report_483062856.log and report_483062858.log
If you check report_483062856.log, you'll see that :
- the address_state is empty before the call to triggerEvent
- the address_state is empty before the trigger of the address mass action plugin (with the log line plgHikashopMassaction_address)
- the address_state is empty after the trigger of the address mass action plugin
- the address_state is set to state_malta_2408 after the call to triggerEvent

So first, thanks to that debug you can see that there is only one plugin being called by the triggerEvent call and it's the address mass action plugin.
And the strange thing here is that the address_state is not changed by the mass action plugin but still, after the triggerEvent call, the address_state happens to be state_malta_2408 for some reason.
So I'm tempted to say that the issue might come from a Stored Procedure in your MySQL which would be triggered automatically by the saving of the address with the address mass action, but not having direct access to the database, I can't say for sure.
But since it seems to be linked to the mass action "Staat veldje" saving the address, I decided to disable that mass action in your backend to see if it would prevent that from happening. And the result is what you can see in the report_483062858.log file.
In it, the mass action plugin is still called but the address_state stays empty from start to finish.

So to conclude, disabling the "Staat veldje" mass action you created fixes the problem, but I'm not sure why since it doesn't have that malta state filled in it and thus it might be linked to something on the database side triggered by that mass action.

I spent more or less one hour on the debugging and analysis. Here is the payment link for that time:
www.hikashop.com/component/hikashop/prod...d-4/quantity-16.html

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

  • Posts: 72
  • Thank you received: 5
3 years 4 months ago #334503

Thanks for testing and your explanation.

However, disabling the “staat veld” creates another problem wich we had before, see www.hikashop.com/forum/install-update/90...oblem-at-step-3.html
In order to solve that problem you advised us back then to create the mass action staat veldje. And indeed that works for the problems we had in step 3. Disabling this mass action brings back the old problem that (sometimes) it is impossible to go from step 3 to 4.

How do we solve that?

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

  • Posts: 82863
  • Thank you received: 13372
  • MODERATOR
3 years 4 months ago #334533

Hi,

I tried to look at the problem today but I was not able to reproduce the problem.
I've made several orders after disabling the address_state custom field and the massaction, but by the time I was at the end of the checkout, the mass action was enabled again.
So each time I was able to place an order with the address in Germany and the VAT number DE322326233 but I'm not sure if it's because someone reactivated the mass action in the mean time or not.

Please provide a precise set of instructions to reproduce the issue and I can look into it.

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

  • Posts: 72
  • Thank you received: 5
3 years 4 months ago #334540

I had enabled this field beause of the problems. I disabled it now again, so you can test it.

Here is an example of an adress that fails to pass to step 4:
SiteSuccess
Mr Maurice Lehr
Koperslagershoek 12
3981 SB Bunnikc
Germany
Telephone: 061111111
VAT number: DE322326233

Note: if I set the country to The Netherlands, it works fine.

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

  • Posts: 82863
  • Thank you received: 13372
  • MODERATOR
3 years 4 months ago #334561

Hi,

Thanks, I was able to reproduce the issue with that exact address and a guest checkout.
I did some debug on this today and I found that it is linked to country being somehow wrongly overridden by something when the address is updated on the cart which invalidate the progression to the next step.
So I'm not sure what is the source of the problem.
However, I've made a patch in HikaShop's code to only update the address in the cart if the address is not already the one in the cart. And since the address is already set in the cart when the address is saved, going to the next step doesn't need to update it if it's the same one. So doing it like that avoids the country being overridden and invalidating the progression, and thus, the checkout can go the next step properly. We'll add that modification on our end too.

I won't ask anything for the debug today. However, I'll still ask you for the payment of the debug I did last week.

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

  • Posts: 72
  • Thank you received: 5
3 years 4 months ago #334562

Thanx, looks like the problem is solved :)

We paid today for the debug of last week.

Cheers, Maurice

The following user(s) said Thank You: nicolas, Philip

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

  • Posts: 72
  • Thank you received: 5
3 years 3 months ago #334637

Hi Nicolas,

After some extra testing we discovered that not everything is working as it should. This is what we found:

When you change the (billing) country after login (either by login button in the top bar of the main screen or login button during checkout), the checkout gets stuck in the shipping page, it does not go to the payment page.

Steps to recreate this:
• When logged out, put an article in the shopping basket
• Go to Checkout, click Next for Login page
• Press Login button, enter User ‘Canadian’ and PW ‘Canadian765’, press Next
• In the Address page, Edit the billing address, change the country from Canada to Netherlands, or vice versa.
• Press Next to go to Shipping. Sometimes need to press Next twice
• Accept the terms and conditions and press Next


>The page stays in the Shipping page.
• When the billing country is changed back to the initial country during login, the checkout process completes correctly

On several occasions during this process I get an ‘Invalid Token’ page. I need navigate back to the preceding page, press browser refresh and then I can continue what I was doing.

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

  • Posts: 4747
  • Thank you received: 644
  • MODERATOR
3 years 3 months ago #334642

Hello,

we process a lots of tests and here some idea and theories :
1. Your website behavior is really erratic, as an example, we were able to process complete checkout in guest mode but not in login mode.
2. In "login mode" we succeed to process a complete checkout as well with account your provide for access the backend but not with your "Canadian" account (and the Canada country).
3. When I process some tests with another navigator, I fill the cart with a product, the cart is automatically empties... That don't allow to process freely more tests...

Conclusion, a little as said as previous, all of this prevent us to process tests and make conclusion about what happen unfortunately...
Now the point is what ? A plugin ? A custom code in a override view (seems unlikely) or directly in HikaShop core file ?
Almost impossible to understand without any clue from yourself, does there are a plugin in order to automatically login your website that confuse the checkout process ? Or a custom directly in the core file ?

Actually we need some help and elements that can point us the root issue.
Regards

Last edit: 3 years 3 months ago by Philip.

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

  • Posts: 72
  • Thank you received: 5
3 years 3 months ago #334789

Thanx for your reply.

For now we have decided to let it rest and see how things develop.

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

Time to create page: 0.059 seconds
Powered by Kunena Forum