Occasionally the tracking fields will disappear from order summary, disabling/re-enabling the module brings them back. I have tried setting the weight for the module up to 100 but no avail.

Package Tracking for Ubercart 6.x-1.x-dev (2009-Dec-13)
Drupal 6.14 Ubercart 6.x-2.2 Pixture Reloaded 6.x-3.2

CommentFileSizeAuthor
#5 Untitled1.jpg20.14 KBRainman
#5 Untitled2.jpg20.71 KBRainman
#2 Untitled.jpg23.22 KBRainman

Comments

tr’s picture

tr commented

What do you mean by "order summary" ? Please give an example URL.

What do you mean by "disappear" ? Are just the tracking numbers missing, or is the whole table column missing, or ... ? An image would really help.

Rainman’s picture

Rainman commented
StatusFileSize
new Untitled.jpg23.22 KB

Hi, I mean the tracking column fails to display in order history. In fact when this happens, manually putting in a tracking request such as "/user/1/orders/track/ups/1Z123458698745214" fails to return a page also. apparently the menu callback fails.

attached is a screen clip with it working, what happens is the part at the end "Tracking" and the tracking number/link below it do not show up.

I will attach a clip with it gone as soon as it happens again.

tr’s picture

tr commented

I've never had this happen to me, so I will need your help in debugging. Can you do this for me? Edit uc_tracking.module and change this line:

  $breadcrumb[] = l(t('My order history'), 'user/'. $user->uid .'/orders');

to look like this:

  $breadcrumb[] = l(t('My orders'), 'user/'. $user->uid .'/orders');

You don't have to use the exact phrase "My orders" - you can change it to whatever you want. But since your customers will see this I chose "My orders" as something that would still make sense but would be *different* than the default "My order history".

Here's my working theory. When the tracking number disappears, I think uc_tracking is not actually being run. By changing the phrase above, it will be obvious whether the uc_tracking version of the order history page is being shown or whether the default uc_order version of the page is being shown.

uc_tracking works by implementing hook_menu_alter() to replace the default order history page with a new version that displays tracking numbers. If the uc_tracking version isn't getting called, that means something went wrong with the Drupal menu router. Perhaps there's a module weight problem (you tried that... but it would be good to look in the system table to see what the weight of uc_order is as well), or perhaps there's an access permission problem. But try the above change first and depending on the results maybe we can narrow it down.

Rainman’s picture

Rainman commented

Thanks TR, will do. It hasn't failed again yet today. Actually I was surprised it didn't. seems to happen during processing of orders, packaging and shipping. did quite a bit of that today. I am trying to pay particular attention to when it does fail and if I did anything different beforehand. but so far it has just seemed quite random, not sure what causes it.

Rainman’s picture

Rainman commented
StatusFileSize
new Untitled2.jpg20.71 KB
new Untitled1.jpg20.14 KB

Hi TR, I believe your assumptions were correct as the page does change name (with changes in the module) when the issue happens.

I have found that clearing the cache brings the tracking fields (replacement tracking page) back, I had been disabling/re-enabling the module which I suspect essentially did the same thing.

I am going to do some more testing to see if I can reproduce the issue, I think it may occur when either deleting or canceling an existing order.

Add: I was unable to reproduce any specific action to cause the issue to appear. The things that I thought may have caused it were deleting, canceling order, or an order stuck in checkout. a quick test of those conditions did not reproduce.

The one thing discovered is that the issue appears to be related to caching of the page.

tr’s picture

tr commented

I think the problem may be in uc_tracking_menu_alter(). The function body is currently enclosed in

  if ($user->uid) {
    // Body of function
  }

which appears to be a legacy of the Drupal 5 version of this module. If you remove that conditional, I think it might solve the problem. Can you give it a try and see if it works?

Rainman’s picture

Rainman commented

Hi TR Thanks. I see that condition in a few places in the module, I think this is the part you are talking about:

  // Modify user/#/orders menu to callback to uc_tracking_order_history()
  // instead of uc_order_history().  Allows us to modify core behavior
  // without hacking uc_order.module.
  if ($user->uid) {  // no order info page for anonymous users
    $items['user/%user/orders']['page callback'] = 'uc_tracking_order_history';
  }

change to:

  // Modify user/#/orders menu to callback to uc_tracking_order_history()
  // instead of uc_order_history().  Allows us to modify core behavior
  // without hacking uc_order.module.
  //if ($user->uid) {  // no order info page for anonymous users
    $items['user/%user/orders']['page callback'] = 'uc_tracking_order_history';
  //}

please let me know if that is correct

tr’s picture

tr commented

Correct.

Rainman’s picture

Rainman commented

Well it has happened again this morning. I made the changes after the issue appeared, but to no avail.

I thought well maybe if I clear the cache, but that has worked before for restoring the tracking without any changes to the module, so don't know if that really gets us anywhere?

Still trying to guess what is triggering the issue in the first place, I did have an abandoned cart left "In checkout" not too long before I noticed it and a completed (status "Pending") order after that.

Rainman’s picture

Rainman commented

I noticed a new Dev had been put up, assuming the uid changes were related to this issue.

New bug introduced: access denied for any access to order history (user or admin). i.e. access denied 12/21/2009 - 11:04 user/254/orders

tr’s picture

tr commented

The check on if ($user->uid) {} was removed because it was just wrong in Drupal 6 version (although it was needed in the Drupal 5 version). Drupal made a lot of changes in menus between the two versions.

I can't reproduce your error, but I just made a small change which might help, so try today's dev version and see if it works for you. I'm using exactly the same access check as in the uc_order module, so be sure you have the "view all orders" and the "view own orders" permissions set correctly for your users.

Rainman’s picture

Rainman commented

Thanks TR. I went back to the previous dev because nobody could access orders at all with the last one. Good point about the "view orders" permissions, although it was set correctly. I'll give this latest version a shot.

Rainman’s picture

Rainman commented

A follow up. I installed the 2009-Dec-26 dev a few days after it was released and so far everything is solid.

Thanks for your work on this TR!

tr’s picture

tr commented
Status: Active » Fixed

Cool. I'll consider it fixed then. Feel free to reopen the issue if it becomes a problem again.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.