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

@wickedclown
Okay, so here's the situation as I see it...

1. The order status does update from the order details page
2. The order status also updates from the batch page
3. You can successfully e-mail your customer on a status update from the order details page
4. You CANNOT send the same e-mail from the batch page

Super Orders uses a single function -- email_latest_status() -- to e-mail order status updates regardless of where they originate. That fact, combined with the list above, means that the problem resides with the batch file's call to this function.

I should have asked earlier, but what version of PHP are you using? I'm wondering if the syntax that calls this function is not the problem. Open admin/super_batch_status.php, and go all the way to the bottom, find this line...

Code:

---

    if ($notify == 1) email_latest_status($oID);

---

Note the lack of curly braces { }. I want you to add those braces so it looks like the following...

Code:

---

    if ($notify == 1) {
      email_latest_status($oID);
    }

---

Then, as a precautionary measure, lets make sure that $notify is actually being set properly. Go back to the top of the page, and find this line...

Code:

---

$notify = $_POST['notify'];

---

Let's define this so that it's set as a variable type int, like this...

Code:

---

$notify = (int)$_POST['notify'];

---

Based on all the information you've provided, that's about the only possible cause; it must be somewhere in the code that actually calls the email_latest_status() function within super_batch_status.php.

If you still have the issue after these steps, trying echo'ing out the $notify variable both outside and inside the batch_status() function. It would look something like this...

Code:

---

  // DEBUG
  echo '<br />' . $notify . '<br />';

---

That may tell you more about what is being (or not being) passed. If that doesn't make sense, or the thought terrifies you, just report back what happened with the code changes.

Quote:

---

Originally Posted by BlindSide

@wickedclown
Okay, so here's the situation as I see it...

1. The order status does update from the order details page
2. The order status also updates from the batch page
3. You can successfully e-mail your customer on a status update from the order details page
4. You CANNOT send the same e-mail from the batch page

Super Orders uses a single function -- email_latest_status() -- to e-mail order status updates regardless of where they originate. That fact, combined with the list above, means that the problem resides with the batch file's call to this function.

I should have asked earlier, but what version of PHP are you using? I'm wondering if the syntax that calls this function is not the problem. Open admin/super_batch_status.php, and go all the way to the bottom, find this line...

Code:

---

    if ($notify == 1) email_latest_status($oID);

---

Note the lack of curly braces { }. I want you to add those braces so it looks like the following...

Code:

---

    if ($notify == 1) {
      email_latest_status($oID);
    }

---

Then, as a precautionary measure, lets make sure that $notify is actually being set properly. Go back to the top of the page, and find this line...

Code:

---

$notify = $_POST['notify'];

---

Let's define this so that it's set as a variable type int, like this...

Code:

---

$notify = (int)$_POST['notify'];

---

Based on all the information you've provided, that's about the only possible cause; it must be somewhere in the code that actually calls the email_latest_status() function within super_batch_status.php.

If you still have the issue after these steps, trying echo'ing out the $notify variable both outside and inside the batch_status() function. It would look something like this...

Code:

---

  // DEBUG
  echo '<br />' . $notify . '<br />';

---

That may tell you more about what is being (or not being) passed. If that doesn't make sense, or the thought terrifies you, just report back what happened with the code changes.

---

blindside, you think that its the code for emailing that is the problem? it seems that the emails are fine- iv not had an issue with them, its the order status comments in the catalog side, and the admin side.
Do you still believe that i should do this edit? it looks to me like its to fix the batch email..... i dont really use the batch system that offten unless to print. which has seemed to work just fine.

please advise... thanks

Dear Blindeside,

This might be the longest post on this thread. Please bear with me, for I really want this Super Order mod to work in my cart.

I did everything like you suggested, here is the details on my actions and problems that followed:

1. Tried to restore my DB backup both by using DB-Backup MySQL (by DrBite) from Admin and PhPmyAdmin on my server. Both methods seemed working fine. But, I noticed that there are four fields "zen_so_payment_types", "zen_so_payments", "zen_so_purchase_orders","zen_so_refunds" which seemed did not get erased during DB restore. So, I dropped them by using PhPMyAdmin. Now, I am ready to re-run super_orders_sql.sql

2. Tried using PhPMyAdmin upload super_orders_sql.sql and got the following:

Error SQL query:
-- EDIT EXISTING TABLES
ALTER TABLE orders ADD date_completed datetime default NULL
MySQL said:
#1146 - Table 'wwwlin5_zc1.orders' doesn't exist

3. Restored my DB and tried to upload super_orders_sql.sql by using Install Sql Patch from Admin, then got the following:

1064 You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near 'True', 'False'), ')' at line 1 in:
[INSERT INTO zen_configuration VALUES (NULL, 'Enable Purchase Order Module', 'MODULE_PAYMENT_PURCHASE_ORDER_STATUS', 'True', 'Do you want to accept Purchase Order payments?', 6, 1, now(), now(), NULL, 'zen_cfg_select_option(array('True', 'False'), ');]
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.

4. Did not restore DB, and try upload super_orders_sql.sql again by using Install Sql Patch, then got the following:

1062 Duplicate entry 'CA' for key 2 in:
[INSERT INTO zen_so_payment_types VALUES (NULL, 1, 'CA', 'Cash');]
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.

5. Tried to run Fresh_install.sql in Ty_Package_Tracker contrib using PhPMyAdmin twice and got the following:

Error SQL query:

SELECT (@tyid := configuration_group_id) AS tyid
FROM configuration_group
WHERE configuration_group_title = 'Ty Package Tracker'
MySQL said:
#1146 - Table 'wwwlin5_zc1.configuration_group' doesn't exist

6. Tried upload Fresh_install.sql in Ty_Package_Tracker contrib using Install Sql Patch from Admin. Guess what, it worked!!! And I noticed that the four fields I dropped before were back, which are "zen_so_payment_types", "zen_so_payments", "zen_so_purchase_orders","zen_so_refunds".

My concerns now are:

Are there any relations between Super Order mod and Ty_Package_Tracker mod? It seemed that Ty_Package_Tracker added "zen_so_x_x" fields.

Are there any thing wrong with PhPMyAdmin settings on my server side? Nonetheless, it seemed that PhPMyAdmin can run my DB backup sql file ok.

Here are some of my server info:

MySQL 4.0.27-standard
Server OS: Linux 2.6.9999-MIDPHAZED-410a66d10418e44a615e653ff4a8476e
HTTP Server: Apache/1.3.34 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.3.10 FrontPage/5.0.2.2635 mod_ssl/2.8.25 OpenSSL/0.9.7a
PHP Version: 4.3.10 (Zend: 1.3.0)
Database Host: localhost

If you need more of my server info such as PHP settings, I can always run techsupp.php in zc_install folder and post those settings here.

Thank you for all your help in advance!

Sincerely,

Frank

Hello!

The more i check out this contribution, the better i realise it is! Great work :cool: !!

I am having a problem with the display of the payment date and time for Paypal payments, however, and am hoping someone can help me. Nothing to do with a probem with the code, just a setting that is wrong for my set up...

Basically i have a UK PayPal account but on the Super Orders page it shows the Paypal payment date in US format and the time in presumably a US time zone. Is there anyway to change this to show UK date and time of payment???

Thanks in advance :D .

Quote:

---

Originally Posted by frank_lyy

Dear Blindeside,

This might be the longest post on this thread. Please bear with me, for I really want this Super Order mod to work in my cart.

I did everything like you suggested, here is the details on my actions and problems that followed:

1. Tried to restore my DB backup both by using DB-Backup MySQL (by DrBite) from Admin and PhPmyAdmin on my server. Both methods seemed working fine. But, I noticed that there are four fields "zen_so_payment_types", "zen_so_payments", "zen_so_purchase_orders","zen_so_refunds" which seemed did not get erased during DB restore. So, I dropped them by using PhPMyAdmin. Now, I am ready to re-run super_orders_sql.sql

2. Tried using PhPMyAdmin upload super_orders_sql.sql and got the following:

Error SQL query:
-- EDIT EXISTING TABLES
ALTER TABLE orders ADD date_completed datetime default NULL
MySQL said:
#1146 - Table 'wwwlin5_zc1.orders' doesn't exist

3. Restored my DB and tried to upload super_orders_sql.sql by using Install Sql Patch from Admin, then got the following:

1064 You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near 'True', 'False'), ')' at line 1 in:
[INSERT INTO zen_configuration VALUES (NULL, 'Enable Purchase Order Module', 'MODULE_PAYMENT_PURCHASE_ORDER_STATUS', 'True', 'Do you want to accept Purchase Order payments?', 6, 1, now(), now(), NULL, 'zen_cfg_select_option(array('True', 'False'), ');]
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.

4. Did not restore DB, and try upload super_orders_sql.sql again by using Install Sql Patch, then got the following:

1062 Duplicate entry 'CA' for key 2 in:
[INSERT INTO zen_so_payment_types VALUES (NULL, 1, 'CA', 'Cash');]
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.

5. Tried to run Fresh_install.sql in Ty_Package_Tracker contrib using PhPMyAdmin twice and got the following:

Error SQL query:

SELECT (@tyid := configuration_group_id) AS tyid
FROM configuration_group
WHERE configuration_group_title = 'Ty Package Tracker'
MySQL said:
#1146 - Table 'wwwlin5_zc1.configuration_group' doesn't exist

6. Tried upload Fresh_install.sql in Ty_Package_Tracker contrib using Install Sql Patch from Admin. Guess what, it worked!!! And I noticed that the four fields I dropped before were back, which are "zen_so_payment_types", "zen_so_payments", "zen_so_purchase_orders","zen_so_refunds".

My concerns now are:

Are there any relations between Super Order mod and Ty_Package_Tracker mod? It seemed that Ty_Package_Tracker added "zen_so_x_x" fields.

Are there any thing wrong with PhPMyAdmin settings on my server side? Nonetheless, it seemed that PhPMyAdmin can run my DB backup sql file ok.

Here are some of my server info:

MySQL 4.0.27-standard
Server OS: Linux 2.6.9999-MIDPHAZED-410a66d10418e44a615e653ff4a8476e
HTTP Server: Apache/1.3.34 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.3.10 FrontPage/5.0.2.2635 mod_ssl/2.8.25 OpenSSL/0.9.7a
PHP Version: 4.3.10 (Zend: 1.3.0)
Database Host: localhost

If you need more of my server info such as PHP settings, I can always run techsupp.php in zc_install folder and post those settings here.

Thank you for all your help in advance!

Sincerely,

Frank

---

\

YES, TY does have releate back to super orders for editing, IF you instruct it to. for that reason, i would say that it prolly does have a field in the db to work with super orders.

bascily, you can set the tracking system to point you to super orders when needing to make a change to an order, rather than going to the standard order system.

Have to agree with wicked on this one, Frank. The Ty package piggybacks on SO. Do you have a backup of your DB without Ty installed? Install SO first, then Ty; and do so from phpMyAdmin.

hay Blindside, this is a feature request....

it would be nice if super orders could be able to search out model numbers with the search function.

so that you could pull up super orders, and do a search for "part28648" and it will pull up all the orders that have orderd that item.

does anyone know how i could add a .js call to the header of my super_orders.php file in the admin section?

i want to put in a call to a new .js file, similar to the one in the header of the stats_sales_report.php file. something like this:

<script language="javascript" src="includes/javascript/spiffyCal/spiffyCal_v2_1.js"></script>

i'm trying to install a date search tool that has javascript calendar function and it's not working b/c i think the .js path is missing in the header.

thanks everyone

k-

@wicked: Yeah we could see about that...

@krizzle: Umm, what about mimicking the line you copied? :happy:

Code:

---

<script language="javascript" src="includes/javascript/YOUR_JS_HERE.js"></script>

---

Just be sure to put it in the admin/includes/javascript/ folder.

@wickedklown et. al.
The problem you experienced with the tags being displayed improperly in status update comments is due to the comments not being properly scrubbed before inserting them into the DB. "Scrubbing" is the act of prepping the data for DB insert. The stock zen uses two functions -- zen_db_input() and zen_db_prepare_input() -- to complete this task. I combined the two and went a few steps further with the zen_db_scrub_in() function.

The important part for this problem is that we also do a conversion from <br> tags to newline returns (aka the br2nl() function). This process is then reversed when the status is outputted on the page (nl2br(), new lines become <br> tags again). Since the code isn't doing it on the way in, the output gets kinda screwy.

I know that it was there at some point, but it was probably edited/moved/removed and never re-added in the course of writing the file. My apologies. Here's how to fix it. Find this line near the top of super_batch_status.php...

Code:

---

$notify_comments = $_POST['notify_comments'];

---

Adjust the line to read as follows...

Code:

---

$notify_comments = zen_db_scrub_in($_POST['notify_comments'], true);

---

That will prevent the problem from occuring further. To correct already affected comments, go to the Orders Detail page for the affected order and click "edit status history" beneath the status history table. Edit the comments as necessary and click "Submit" (this file does perform the scrubbing correctly)

For those of you who do not use Admin > Customers > Batch Status Update, I still strongly recommend you perform the above fix, as not scrubbing the input leaves you vulnerable to SQL injections. Fortunately, since it's an admin file, the problem is only on the admin side, so access is extremely limited. Still, always better to be safe than sorry.