OLD Super Orders 2.0 (See v3.0 thread instead)

[DivaVocals]

Okay.. So I just re-tested.. At first it didn't work.. Initially I had the exact same issue. (only opposite) When the the customer was not notified, the legend seemed to indicate that they had been..

I knew that the FEC add-on had code in it's super_orders.php file to correct the notification issue as well. So I was installing FEC anyway so I used Winmerge to merge the FEC code into the super_orders.php file. I grabbed the notification code from the FEC version of the super_orders.php file and replaced the rev 47 notify code, and it now works with the correct legend flags..

Not gonna do it now, but I'll have to go back and do a vanilla install of Zen and Super Orders to see what I did to break the Rev 47 super_orders.php file.

[DivaVocals]

So just wanted to follow-up with my testing of these changes..

I applied these changes to not only the super_batch_status.php file, but the super_batch_forms.php as well.. It appears that this has fixed the SQL errors as well as the errors that would ocurr if you clicked the "Search" button on either the batch print or batch updates pages, when no order search criteria is entered.

I've been pounding away at it, and it works.. No more errors..

There is one small thing: Using the Order Totals "=(equals to)" option does not bring back any results no matter WHAT you type into the field.

Any thoughts?? Obviously, truly this is minor in the scheme of things..

Anyway, just wanted to say thanks.. This worked perfectly!

Now I am going to figure out once and for all why some of the Super Order form fields (particularly "textarea") act strange in IE.. another long standing pet peeve.. Experimenting with this as we speak..

Should be long standing indeed, as the = in the array is set as == which would never work in that statement.

The <= is probably not working, either because of browser issue or some cleaner stripping html tags.

To make it work you could do this, first rewrite the array in <admin folder>/super_batch_status.php:

$ot_sign = array();
  $ot_sign[] = array('id' => '1',
                     'text' => ' > ' . DROPDOWN_GREATER_THAN);
  $ot_sign[] = array('id' => '2',
                     'text' => ' < ' . DROPDOWN_LESS_THAN);
  $ot_sign[] = array('id' => '3',
                     'text' => ' = ' . DROPDOWN_EQUAL_TO);

now adjust the SQL query build to match the id's:

if (isset($_GET['order_total']) && zen_not_null($_GET['order_total'])) {
    if ($_GET['ot_sign'] == 3) { $sign_operator = '='; }
    elseif ($_GET['ot_sign'] == 2) { $sign_operator = '<='; }
      else { $sign_operator = '>='; }
      $orders_query_raw .= " AND o.order_total " . $sign_operator . " '" . (int)$_GET['order_total'] . "'";
    //$orders_query_raw .= " AND o.order_total " . $_GET['ot_sign'] . " '" . (int)$_GET['order_total'] . "'";
  }

finally, have a last look at these fields, as you will probably never use em while they're error free

Jeroen

[DivaVocals]

Now I am going to figure out once and for all why some of the Super Order form fields (particularly "textarea") act strange in IE.. another long standing pet peeve.. Experimenting with this as we speak..

So apparently this has been a long standing issue going back as far as November 2006 from what I can see.. I can't simply tell my clients to "use Firefox" as a solution.. Most won't, and I knew there had to be a REAL solution.. Searching through this support thread I got a hint of what the root cause of the issue might be. (http://www.zen-cart.com/forum/showpo...&postcount=289)

Turns out that it's related to an IE bug and how it interprets the display width for textarea elements. Apparently this bug affects IE 6 & &, but I can report that IE 8 is also affected by this bug. (whether you view the page in IE 8's very lame compatibility view or not)

I have a down and dirty fix for this which I will share the specifics on with the community when I get home and make the changes..

To summarize: The down and dirty the fix requires that both the super_batch_status.php file need to be modified so that the notification checkboxes appear below and not to the right of the comments field. My research indicates that if you wanted to retain the current layout for the notification checkboxes, then you would need to use containers with a width set to 100%. A quick look at the super_batch_status.php file tells me that this would probably require a re-write to this page to format things correctly (ie: going tableless). I'm gonna pass on this and go for the quick and dirty fix since it effectively resolves the immediate issue. Wanted to share my find with the forum.

Given the age of this issue.. I figured I wasn't the only one looking for the answer..

[nagelkruid]

I applied these changes to not only the super_batch_status.php file, but the super_batch_forms.php as well.. It appears that this has fixed the SQL errors as well as the errors that would ocurr if you clicked the "Search" button on either the batch print or batch updates pages, when no order search criteria is entered.

I've been pounding away at it, and it works.. No more errors..

Cool, i couldn't test with this as i have made a small amendment that will start both forms with the first option as the default (order taken) as those are the orders you will want to either print or do the update on and it saves an extra click.

However, when i click on print with no orders selected i will still get that error in the output screen. Should be easy to prevent with a little javascript when i get to it.

There is one small thing: Using the Order Totals "=(equals to)" option does not bring back any results no matter WHAT you type into the field.

Any thoughts?? Obviously, truly this is minor in the scheme of things..

That is because the form is transferring any number you put in there to an int, which basicly renders this useless.
If you have or make an order that is exacly 1, or 2 or 5 dollars, then if you search for that order it will pop-up.

I was looking to do something like, if you put 10.15 in there, i will take the int +1 -1 and do a search for anything between 9 & 11, which could be more useful. and probably more what people expect when they but an amount in there.
Coding that up takes a bit more time.

Anyway, just wanted to say thanks.. This worked perfectly!

You're welcome

Now I am going to figure out once and for all why some of the Super Order form fields (particularly "textarea") act strange in IE.. another long standing pet peeve.. Experimenting with this as we speak..

Noticed that too, i bet you, it can be fixed somewhere in the css

cheers,
Jeroen

[DivaVocals]

However, when i click on print with no orders selected i will still get that error in the output screen. Should be easy to prevent with a little javascript when i get to it.

Yep.. Just saw that this morning on the super_batch_forms.php page:

Warning: Invalid argument supplied for foreach() in /home/content/o/v/e/overthehill/html/zen138.overthehillweb.com/admin/super_batch_forms.php on line 349
Error: No orders selected!

Interesting because when you click "Update on the super_batch_status.php page with no orders selected, you at least get a message of

Error: No orders selected!

IMO the two pages should have consistent behavior when no orders are selected. Gonna take a look and see if I can figure this out.. Would you be so geneous as to share your javascript solution?? Sounds better than what I have planned.. (Yep.. still not afraid to ASK!!)

That is because the form is transferring any number you put in there to an int, which basicly renders this useless.
If you have or make an order that is exacly 1, or 2 or 5 dollars, then if you search for that order it will pop-up.

I was looking to do something like, if you put 10.15 in there, i will take the int +1 -1 and do a search for anything between 9 & 11, which could be more useful. and probably more what people expect when they but an amount in there.
Coding that up takes a bit more time.

Yeah I figured as much.. I think I'm gonna comment the option out for now.. I don't think it would be missed..

Noticed that too, i bet you, it can be fixed somewhere in the css

A bit more than CSS.. See my post right above.. This is yet another of those lovely (stupid) IE bugs which affects IE versions 6, 7 & 8. Gotta down and dirty fix, but the real answer is that the super_batch_status.php & super_batch_forms.php should be re-done so that they are tableless. Gonna use my down and dirty method for now.. I may roll up my sleeves and have a real go at converting them to tableless pages this weekend..

[DivaVocals]

Fixing textarea so it displays correctly in Internet Explorer (confirmed display bug in versions 6, 7, & 8 of IE)

So I took a look this morning.. Tackling making this page tableless is a quite a bit of work. (More than I want to do right now..) So here's the down and dirty solution (this solution works in my testing.. your mileage may vary..):

First we have to move the checkboxes to their own row. Apparently IE renders textarea elements incorrectly if there are elements to the right of the textarea element (in this case it's the checkboxes). In admin/super_batch_status.php find this:

              <tr>
                <td class="smallText" valign="top"><?php echo HEADING_ADD_COMMENTS; ?></td>
                <td class="smallText"><?php echo zen_draw_textarea_field('comments', 'soft', '50', '4'); ?></td>
                <td class="smallText" valign="center"><?php
                  echo zen_draw_checkbox_field('notify', 'on', false); echo '&nbsp;' . ENTRY_NOTIFY_CUSTOMER . '<br>';
                  echo zen_draw_checkbox_field('notify_comments', 'on', true); echo '&nbsp;' . ENTRY_NOTIFY_COMMENTS; ?><br /><br />
                  &nbsp;<input type="submit" value="<?php echo BUTTON_UPDATE_STATUS; ?>">
                </td>
              </tr>

Replace with this:

              <tr>
                <td class="smallText" valign="top"><?php echo HEADING_ADD_COMMENTS; ?></td>
                <td class="smallText" colspan="2"><?php echo zen_draw_textarea_field('comments', 'soft', '50', '4'); ?></td>
              </tr>
              <tr>
                <td class="smallText" valign="top"><?php echo HEADING_NOTIFICATION; ?></td>
                <td class="smallText" colspan="2"><?php
                  echo zen_draw_checkbox_field('notify', 'on', false); echo '&nbsp;' . ENTRY_NOTIFY_CUSTOMER . '<br>';
                  echo zen_draw_checkbox_field('notify_comments', 'on', true); echo '&nbsp;' . ENTRY_NOTIFY_COMMENTS; ?><br /><br />
                  &nbsp;<input type="submit" value="<?php echo BUTTON_UPDATE_STATUS; ?>">
                </td>
              </tr>

Now we need add a new label for the checkboxes. Go to admin/includes/languages/english/super_batch_status.php under line 40 add this:

define('HEADING_NOTIFICATION', 'Notification:');

Optionally you could make one small adjustment in your admin stylesheet (admin/includes/stylesheet.css) as follows:
Change this

textarea {
width: 80%;
}

To this:

textarea {
width: 95%;
}

So apparently this has been a long standing issue going back as far as November 2006 from what I can see.. I can't simply tell my clients to "use Firefox" as a solution.. Most won't, and I knew there had to be a REAL solution.. Searching through this support thread I got a hint of what the root cause of the issue might be. (http://www.zen-cart.com/forum/showpo...&postcount=289)

Turns out that it's related to an IE bug and how it interprets the display width for textarea elements. Apparently this bug affects IE 6 & 7, but I can report that IE 8 is also affected by this bug. (whether you view the page in IE 8's very lame compatibility view or not)

I have a down and dirty fix for this which I will share the specifics on with the community when I get home and make the changes..

To summarize: The down and dirty the fix requires that both the super_batch_status.php file need to be modified so that the notification checkboxes appear below and not to the right of the comments field. My research indicates that if you wanted to retain the current layout for the notification checkboxes, then you would need to use containers with a width set to 100%. A quick look at the super_batch_status.php file tells me that this would probably require a re-write to this page to format things correctly (ie: going tableless). I'm gonna pass on this and go for the quick and dirty fix since it effectively resolves the immediate issue. Wanted to share my find with the forum.

Given the age of this issue.. I figured I wasn't the only one looking for the answer..

[mooomers]

I did that with the code in http://www.zen-cart.com/forum/showpo...postcount=1466

set the id in the first query to the status id that your orders get when they arrive in the shop.

Jeroen

i'm not sure i did it right, but it doesn't seem to work for me when doing this inside admin.

[nagelkruid]

i'm not sure i did it right, but it doesn't seem to work for me when doing this inside admin.

did you get an error ?
if so, what was the error message.

If you didn't get an error but it didn't work, you should check your order status number to be correct.

[mooomers]

did you get an error ?
if so, what was the error message.

If you didn't get an error but it didn't work, you should check your order status number to be correct.

yep! this is the error i got after executing it:

1146 Table 'yabycosm_zc1.orders_status_history' doesn't exist
in:
[UPDATE zen_so_payments sp, orders_status_history osh set sp.date_posted = osh.date_added where sp.orders_id = osh.orders_id AND osh.orders_status_id = 1;]
If you were entering information, press the BACK button in your browser and re-check the information you had entered to be sure you left no blank fields.

[nagelkruid]

yep! this is the error i got after executing it:

Ah got it, you aren't allowed to do this via the SQL tool that is build into the admin, or at least that functionality is not build into it.
From the help file: UPDATE (just a single table)

So if you want these queries to run succesful, you will need to execute them directly via dbadmin if you have access to it.
Remember to add your table pre-fix to the 2 tablenames if you run it from there.

Cheers,
Jeroen