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

wickedklown:

in the admin console, under LOCALIZATION, youll find PAYMENT TYPES

you can add/delete payment types and refund types from there.

ok great thanks for your help

BlindSide:

No idea off hand as to what might cause it, but the nature of them leads me to believe it's in your mods and any customizations you've done. Here's a couple things to check...1. >

2. Did you perform a full installation, particularly the required edits to the order classes in the admin and catalog sides?

3. Do you have any customizations to the account page in the catalog. It would be includes/modules/pages/account/header_php.php and/or includes/templates/[your_template]/templates/tpl_account_default.php

4. What version of Zen Cart are you running? This module shouldn't be used under v1.2.5.

5. I'm not totally familiar with all your mods, do any of them affect orders, order statuses, or the associated tables? If so, you may want to remove or disable them and see if the behavior continues.

well iv looked at all these files, and checked it all,

everything seems ok. Both the files you reqested i look at are identical to those that come with the zc install fileset. so they are unchanged.

is there anything else i can try?

its a drag having to del a comment and re-do it, just to make an edit..

thanks again. if you can think of anything, please let me know.

it works fine, as long as i dont try and edit it. thats when it gets all messed up.

Extra NOTE:
I have a customized super_orders page now. It has the Info at a Glance contrib on it, as well as the USPS AUTOFILL contrib.
Search through the USPS Autofill contrib support thread and he has it posted right there for you to see. i also posted it in the info at a glace thread.
Just so you guys can take advantage of it too.

wickedklown:

Extra NOTE:
...I have a customized super_orders page now. It has the Info at a Glance contrib on it...

hi,

can you share with us the customized super_orders page?! :yes:

I am willing to let absolute look at my admin side , if its going to be any use for you , to help fix the batch e-mail thing. my cliemt really needs this to work , as he has 40+ orders a day . if it needs some money thrown at it let me know.

here is a link to the authors post.
http://www.zen-cart.com/forum/showpost.php?p=274758&postcount=15

basicly, there are two files in there. both have the USPS click-n-ship autofill contrib, and the other overlib has the info at a glance.

NOTE: you must already have both these mods installed in order for this to work. all we are doing is adding them to super orders. for more info, contact the author

crazycucumber:

My settings are set to sendmail , I will try and get SMTP set up and working and test it that way.

Don't think it is spam , as the red cross is appearing in the update customer box etc . as if it never sent. Could it be a permissions thing ? I installed the easy Admin tool thing ( before super orders ) to create new users under admin , I have set myself and other user full perms to the super orders mod, but still no joy ! .
Bolded part has me curious. Are you using one of the admin levels modifications, which allow/deny access to various admin pages? That could very well be the issue. You need access to several files in order for the e-mail to go through. Here's a list...

• admin/includes/languages/english/super_orders.php
• admin/includes/functions/extra_functions/super_orders_functions.php
• admin/super_batch_status.php
  I don't use any of those admin level mods, so I have no diea how SO will behave with them. Any way to disable it and then try again?

wickedklown:

by offending dates - you mean find an order that has 2 payments, one with correct data and one with $0.00. and the dates should NOT match?

This is my most current order. This is the second payment created (YES in green payments bar) it now shows all 0's
$0.00 0000-00-00 00:00:00 0000-00-00 00:00:00

Unfortunitly, the manager told them to remove the other payment data that was not valid- so that is now the only one that i have showing 2 payments.

i told them to leave them be for now, becuase i need to look at them. so when the next order comes in, ill post what it says.
if this is a coding problem within my site, how will i track it down, and is there someone here that i can hire to fix it?
thanks again for your time BS- im sorry to be a pain..
It's creating the record, but not storing the proper values (the table defaults to all 0's when no value is added). Did you place the code from README step Edit the order.php class (catalog side) after the indicated line? it must go after

$insert_id = $db->Insert_ID();

The result you're seeing is possible otherwise.

modchipfitters.co.uk:

btw 1 other thing how can i add paypal to the drop down box when im applying a payment cause at the mo there cash cheque and various credit card types but no paypal
Admin > Localization > Payment Types

Like wickedclown said, I have code to automate PayPal payments made at checkout for the next version. If you're feeling adventurous, here's the code for the modified function. Just replace the entire function as it exists in [catalog]/includes/class/super_order.php...

  function cc_line_item() {
    global $db;

    // first we look for credit card payments
    $cc_data = $db->Execute("select cc_type, cc_owner, cc_number, cc_expires, cc_cvv, date_purchased, order_total
                             from " . TABLE_ORDERS . " where orders_id = '" . $this->oID . "' limit 1");
    if ($cc_data->RecordCount() ) {
      // collect payment types from the DB
      $payment_data = $db->Execute("select * from " . TABLE_SO_PAYMENT_TYPES . "
                                    where language_id = " . $_SESSION['languages_id']);
      $cc_type_key = array();
      while (!$payment_data->EOF) {
        $cc_type_key[$payment_data->fields['payment_type_full']] = $payment_data->fields['payment_type_code'];
        $payment_data->MoveNext();
      }

      // convert CC name to match shorthand type in SO payment system
      // the name used at checkout must match name entered into Admin > Localization > Payment Types!
      $payment_type = $cc_type_key[$cc_data->fields['cc_type']];
      $new_cc_payment = array('orders_id' => $this->oID,
                              'payment_number' => $cc_data->fields['cc_number'],
                              'payment_name' => $cc_data->fields['cc_owner'],
                              'payment_amount' => $cc_data->fields['order_total'],
                              'payment_type' => $payment_type,
                              'date_posted' => 'now()',
                              'last_modified' => 'now()');

      zen_db_perform(TABLE_SO_PAYMENTS, $new_cc_payment);
    }

    // now look for PayPal data
    $pp_data = $db->Execute("select * from " . TABLE_PAYPAL . " where zen_order_id = " . $this->oID);
    if ($pp_data->RecordCount() ) {
      $new_pp_payment = array();
      while (!$pp_data->EOF)  {
        $name = $pp_data->fields['first_name'] . ' ' . $pp_data->fields['last_name'];
        $new_pp_payment[] = array('orders_id' => $this->oID,
                                  'payment_number' => $pp_data->fields['txn_id'],
                                  'payment_name' => $name,
                                  'payment_amount' => $pp_data->fields['mc_gross'],
                                  'payment_type' => 'PP',
                                  'date_posted' => 'now()',
                                  'last_modified' => 'now()');

        $pp_data->MoveNext();
      }

      foreach ($new_pp_payment as $key => $payment) {
        zen_db_perform(TABLE_SO_PAYMENTS, $payment);
      }
    }
  }

I'd also like to hear from those of you who use PayPal extensively (I don't at all). What other stuff can I do here to make this more useful?

Blindside,

can you please help me to find out the problem with my order status comments box.

I really need to find a fix for it

I have posted in the general forum hoping that maybe someone would have an idea, or maybe went through the same problem, and found a fix.

any help would be great at this point.
thanks man

a man in desperate need of help :)
benjamin

Yes BS,

I checked to make sure i had that SO code below the indecated line, and i do. i fallowed and double checked the edits before i came asking about the problem..

thanks man

(The following is from a PM)

frank_lyy:

I was trying to install Super Order 2.0 rev45 on Zen Cart Version 1.3.5 (Clean Installation/Not upgrade). After uploading all Admin & Includes files, tried to upload super_orders_sql.sql and encountered the following error messages:

1. When using "Install SQL Patch" in Zen Admin:

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.

2. When using "PHPmyAdmin" from my web server:

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

As you can see, two different error messages when using two different methods to install the super_orders_sql patches.

In addittion, I cannot find Admin>Configuration>Super Orders field after installation.

Can you please help?
The first issue sounds like you have run and rerun the SQL file over your DB. The so_payment_types is a new table that SO installs, so it would only find it if you had already run the script. UNless you know what the initial error was, your best bet is to restore from your DB backup and try again. I recommend that you use phpMyAdmin instead of the Zen SQL installer.

The second may or may not be related. Look at the table name: wwwlin5_zc1.orders. In the first error, you have a table prefix (zen_), and here you have none. Restore from your backup, go through the entire file to add your DB prefix (if you do, in fact, have one), and run the file again.

@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...

    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...

    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...

$notify = $_POST['notify'];

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

$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...

  // 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:

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

2. The order status does update from the order details page

3. The order status also updates from the batch page

4. You can successfully e-mail your customer on a status update from the order details page

5. 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...

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...
> ```
    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...

$notify = $_POST['notify'];

> Let's define this so that it's set as a variable type **int**, like this...
> ```
$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...

// 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 .

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:

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:

<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...

$notify_comments = $_POST['notify_comments'];

Adjust the line to read as follows...

$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.

BlindSide:

@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...

$notify_comments = $_POST['notify_comments'];

> Adjust the line to read as follows...
> ```
$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.

This problem didnt have to do with batch status. it was just when doing order status via super orders. I rarly use batch status update, or any of those batch's.

should i still preform this fix, and will it fix my current problem?