Super Orders v4.0 Support Thread for ZC v1.5.x

gwynwyffar:

While I was hoping for a finished version
Yep.. meeee too! and when I have some free time in the next week or so, then I will finish this and submit it..

gwynwyffar:

the Github link helps, thank you!You're welcome.. If you find anything significant to report, please feel free to let me know..

I've installed and tested the latest Github version of Super Orders on my local zencart v1.5.4 installation and all appears to work correctly. The only very minor issue I found was the layout of the search boxes on the top of the Orders page. (See screenshot below)
[Attachment no longer available]

I did get a DEBUG log file created when I used the Batch Print function, but the error was my own fault in a way. I chose Batch Print Orders > chose status Processing>hit Print Orders button (without checking the box next to any of the orders)> was taken to a page with Error message - no orders selected. This generated DEBUG log file with the following information:

[09-Jan-2015 19:53:00 UTC] PHP Warning:  Invalid argument supplied for  foreach() in C:\wamp\www\newzencart153\control\super_batch_pages.php on  line 37

[09-Jan-2015 19:53:00 UTC] PHP Stack trace:

[09-Jan-2015 19:53:00 UTC] PHP   1. {main}() C:\wamp\www\newzencart153\control\super_batch_pages.php:0

As I said, it was my user error in failing to check anything, but I was not sure if the DEBUG file information would be useful for you so posting it here.

gwynwyffar:

I've installed and tested the latest Github version of Super Orders on my local zencart v1.5.4 installation and all appears to work correctly. The only very minor issue I found was the layout of the search boxes on the top of the Orders page. (See screenshot below)
[Attachment no longer available]I wouldn't call this an "issue" because the search works.. It's just located in a different place (left side vs right side).. I intentionally removed the tables that surrounded the search form, and this moved the form to the left..

The Zen Cart admin is one place where Zen Cart very much still reflects it's osCommerce roots..:smile: (for the record, the admins are aware and re-writing the admin is high up on the "to-do" list and some of this is reflected in the upcoming v1.6.0 codebase) ALL of the admin pages unfortunately include old outdated and (by current standards) invalid HTML. I'm experimenting with and toying with the idea of making the entire orders.php page tableless, but it is a BIG undertaking.. So I started with the orders search form on the orders.php page.. Besides removing the tables that surrounded the search form, I added in additional reset functionality to places where it didn't exist before.. The search form will display a reset button after initiating a search but ONLY for certain search options.. I modified things so that it worked for all the search options except 1 (I'm at work.. and don't have my notes.. so which ONE as of this writing escapes me :smile:)

That said if you REALLY just want the search back on the right side again and you are comfortable editing the file, it would be simply a matter of adding some classes and IDs and a little CSS to line things back up.. If this code is part of the final submitted package, I will do this, but if you want it NOW, you'd have to take a crack at it yourself..

gwynwyffar:

I did get a DEBUG log file created when I used the Batch Print function, but the error was my own fault in a way. I chose Batch Print Orders > chose status Processing>hit Print Orders button (without checking the box next to any of the orders)> was taken to a page with Error message - no orders selected. This generated DEBUG log file with the following information:

[09-Jan-2015 19:53:00 UTC] PHP Warning: Invalid argument supplied for foreach() in C:\wamp\www\newzencart153\control\super_batch_pages.php on line 37

[09-Jan-2015 19:53:00 UTC] PHP Stack trace:

[09-Jan-2015 19:53:00 UTC] PHP 1. {main}() C:\wamp\www\newzencart153\control\super_batch_pages.php:0

> As I said, it was my user error in failing to check anything, but I was not sure if the DEBUG file information would be useful for you so posting it here.Thanks for this.. will take a look and see if this can be addressed..

I have installed Super Orders and everything seems to be working fine, however, the message "Super Orders v4.0 install completed!" wont go away from the top of the screen. How can I remove this message?

Thank you!

Louis:

After applying the changes for 1.5.3 I am getting the following error when capturing payments.

The payment is still stored but the status is not updated. The following screen is also blank and not the usual "click to close and return" screen.

Any idea what I am doing wrong?

After some digging and debugging I found the problem. If you are also experiencing the same issue you need to make the following changes to your /XXadmin/includes/classes/super_order.php file:

Find ```
function add_payment($payment_number, $payment_name, $payment_amount, $payment_type, $purchase_order_id = false) {

and replace with ```
  function add_payment($payment_number, $payment_name, $payment_amount, $payment_type, $purchase_order_id = false) {
	global $db;

Find ```
function add_purchase_order($po_number) {

and replace with ```
  function add_purchase_order($po_number) {
	global $db;	

Find ```
function add_refund($payment_id, $refund_number, $refund_name, $refund_amount, $refund_type) {

and replace with ```
  function add_refund($payment_id, $refund_number, $refund_name, $refund_amount, $refund_type) {
	global $db;	

and voila, no more error log files!

Louis:

After some digging and debugging I found the problem. If you are also experiencing the same issue you need to make the following changes to your /XXadmin/includes/classes/super_order.php file:

Find ```
function add_payment($payment_number, $payment_name, $payment_amount, $payment_type, $purchase_order_id = false) {

> and replace with ```
  function add_payment($payment_number, $payment_name, $payment_amount, $payment_type, $purchase_order_id = false) {
    global $db;

Find ```
function add_purchase_order($po_number) {

> and replace with ```
  function add_purchase_order($po_number) {
    global $db;    

Find ```
function add_refund($payment_id, $refund_number, $refund_name, $refund_amount, $refund_type) {

> and replace with ```
  function add_refund($payment_id, $refund_number, $refund_name, $refund_amount, $refund_type) {
    global $db;    

and voila, no more error log files!

Thanks for the share.. Will check that if this isn't already in the GitHub repo, that it gets there..

The github version also resolves an issue in the Plugin page version's installer

[07-Feb-2015 14:52:21 America/New_York] PHP Warning: mysql_num_rows() expects parameter 1 to be resource, boolean given in /site/admin/includes/init_includes/init_so_config.php on line 13

As a sugggestion DivaVocals, it would be better not to do things like this:

   if(file_exists(DIR_FS_ADMIN . DIR_WS_INCLUDES . 'auto_loaders/config.so.php'))
    {
        if(!unlink(DIR_FS_ADMIN . DIR_WS_INCLUDES . 'auto_loaders/config.so.php'))
...

the problem it creates is that now if this set of files is transferred to another computer running against another database (as in, for example, an upgrade), the installer no longer works.

swguy:

The github version also resolves an issue in the Plugin page version's installer

[07-Feb-2015 14:52:21 America/New_York] PHP Warning: mysql_num_rows() expects parameter 1 to be resource, boolean given in /site/admin/includes/init_includes/init_so_config.php on line 13

As a sugggestion DivaVocals, it would be better not to do things like this:

if(file_exists(DIR_FS_ADMIN . DIR_WS_INCLUDES . 'auto_loaders/config.so.php'))
{
if(!unlink(DIR_FS_ADMIN . DIR_WS_INCLUDES . 'auto_loaders/config.so.php'))
...

> 
> the problem it creates is that now if this set of files is transferred to another computer running against another database (as in, for example, an upgrade), the installer no longer works.I've had a rough coupla last few days.. I'm tried and sleep deprived, and unfortunately still have work to do today..:laugh: 

So if I could ask you to do me a SOLID and help me understand that last part of your post.. I "borrowed" that code from another module's installer to begin with, and though I understand what it does, I'm not clear on the issue you say it will cause..

This is a pretty common workflow:

• Download a customer's cart files, which is at version X.
• Upgrade the cart to version Y locally
• Reinstall mods locally.
• Test locally
• Transfer cart files to their server for further testing (and later go-live).

In this case, auto_loaders/config.so.php will fail to be run, since it has been deleted (and not run on the non-local database).

swguy:

This is a pretty common workflow:

• Download a customer's cart files, which is at version X.
• Upgrade the cart to version Y locally
• Reinstall mods locally.
• Test locally
• Transfer cart files to their server for further testing (and later go-live).

In this case, auto_loaders/config.so.php will fail to be run, since it has been deleted (and not run on the non-local database).Got it.. Thanks.. Now I get it.. I guess because I always just simply re-copy up the auto installers in doing an upgrade, I never considered this an issue.. I also don't have a really good solution on how to resolve this either.. Will note it as an open enhancement in the Github repo for now..

DivaVocals:

Got it.. Thanks.. Now I get it.. I guess because I always just simply re-copy up the auto installers in doing an upgrade, I never considered this an issue.. I also don't have a really good solution on how to resolve this either.. Will note it as an open enhancement in the Github repo for now..

Just chipping in although nothing to do directly with me. But I suspect that indirectly I may have at least dome responsibility for the issue.

I am not sure what actions are actually taken in that config file ( or the associated init_include potentially ) . But whatever they are then the way round it is to write some code that checks if these actions have been carried out and then carry them out or not as appropriate, possibly with a user confirmation that that is what they want. Then you don't have to have the config file deleted.

Downsides are of course that code that is no longer used does remain on the server. And there will be a very slight loss in processing efficiency because the checking is going to run repeatedly unless you find a nice way to get around that. Conor did some stuff like this and it works, but gets complex in some situations.

Personally, as you know Diva, my focus is usually on individual, heavily modified carts. The code for them tends to be less generic that that which is needed in a publicly released module. But in this case Scott's point is very well made.

Just sent you a PR with the fix.

niccol:

Downsides are of course that code that is no longer used does remain on the server. And there will be a very slight loss in processing efficiency because the checking is going to run repeatedly unless you find a nice way to get around that. Conor did some stuff like this and it works, but gets complex in some situations.

This is the cost of not having external .sql files that need to be run by hand. But the loss is extremely small because you just check the value of a define'd variable from the configuration table. (See my PR.)

niccol:

Just chipping in although nothing to do directly with me. But I suspect that indirectly I may have at least dome responsibility for the issue.If you mean some responsibility in that I copied off of your homework to create the Super Orders installer, then yes you are guilty!!:laugh: Of course I had to add checks that aren't a part of IH4 (like not creating tables that already exist, and not adding columns that already exist in certain tables), but your IH4 example was a BIG help for me.. Dunno if I ever thanked you for that.. but if I didn't I'm saying thank you now.. You and many others here have been great teachers for me.. Speaking of which, I am gonna refine the installer to include something I picked up from copying off of lhungil's homework:laugh:..

niccol:

Personally, as you know Diva, my focus is usually on individual, heavily modified carts. The code for them tends to be less generic that that which is needed in a publicly released module. But in this case Scott's point is very well made. And I understand the concern.. Scott is one of the many folks here who's examples I have followed.. Trouble is at the risk of sounding silly here, I don't know how to make the change you guys are suggesting, but I DO understand the concern.. I am willing to learn though if I have an example to follow.. :smile:

swguy:

This is the cost of not having external .sql files that need to be run by hand. But the loss is extremely small because you just check the value of a define'd variable from the configuration table. (See my PR.)Thanks Scott. I just had a looksee at the PR.. Have some questions.. Will post those on Github.. Just want to make sure I fully understand EVERYTHING.. :smile:

I'm stumped. I cannot get the auto installer to run.

I'm using the Github version and upgrading from SO 4.0.2 Clicking in the admin does not start that installer and both ADMIN/auto_loaders/config.so.php and ADMIN/init_includes/init_so_config.php remain.

I read that some servers don't honor the autoload, so tested this same version of SO on a vanilla 1.5.4 cart. The installler ran.

One difference is this upgrade site is in a sub-domain but I don't see how that would matter.

What should I be looking for as the cause?

jeking:

I'm stumped. I cannot get the auto installer to run.

I'm using the Github version and upgrading from SO 4.0.2 Clicking in the admin does not start that installer and both ADMIN/auto_loaders/config.so.php and ADMIN/init_includes/init_so_config.php remain.

I read that some servers don't honor the autoload, so tested this same version of SO on a vanilla 1.5.4 cart. The installler ran.

One difference is this upgrade site is in a sub-domain but I don't see how that would matter.

What should I be looking for as the cause?Is this a NEW install or an upgrade??

DivaVocals:

Is this a NEW install or an upgrade??

Upgrade from Zen Cart 1.5.1 which is using SO 4.0.2

jeking:

Upgrade from Zen Cart 1.5.1 which is using SO 4.0.2

Is there some other way to trigger init_so_config.php? I really don't want to re-write it and run via phpMyAdmin

jeking:

Is there some other way to trigger init_so_config.php? I really don't want to re-write it and run via phpMyAdmin

But that's the thing.. an upgrade doesn't require a DB change.. the files change.. the only DB change is to update the version #.. Are you sure that didn't change?

DivaVocals:

But that's the thing.. an upgrade doesn't require a DB change.. the files change.. the only DB change is to update the version #.. Are you sure that didn't change?

That's actually what tipped me off. The version number did not change. And shouldn't config.so.php delete after it runs?

If the only difference between 4.0.2 and 4.0.10 are the files, then there may is no need to identify the cause. It's clearly an odd-ball something and while it would be nice to know, it's not affecting the functionality.