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

[lat9]

I don't know how many people still use Super Orders, but I'm in the testing phase with a much updated version that works on 2.1.0 and the upcoming 2.2.0 release.
It's tested up to PHP 8.4.15 and many core file edits have been removed. admin/orders.php now only requires a couple of new notifier hooks to be added. Once initial testing is complete I'll upload to github and also submit it here.

If you also PR those new notifier hooks to the Zen Cart base GitHub, those changes won't be needed for SO's use on zc220!

[strelitzia]

An update regarding the ongoing work to drag Super Orders into the modern age and allow compatibility with Zen Cart 2.2.0

One major step forward with the latest version is that it's now an encapsulated plugin.

Popup windows have been retired and it now uses modal popups.

Pages have been updated to use Zen Cart's modern Bootstrap styling.

Does anyone have any objections if I identify this update as version 6.0.0?
The version numbers in the files are all over the place. I think v5.0.0 is the highest I've seen listed in the files, but as this is such a major rewrite I'd prefer not to just make it 5.1.0

If you also PR those new notifier hooks to the Zen Cart base GitHub, those changes won't be needed for SO's use on zc220!

I'll do a PR once I've finished testing and I'm sure I don't need to add any more.
So far there are new notifiers in invoice.php, packingslip.php, and orders.php

[swguy]

> Does anyone have any objections if I identify this update as version 6.0.0?

Please do so. This is very much in line with the kind of Semantic versioning that we're trying to use in the product.

And thanks for your hard work on Super Orders.

[strelitzia]

Hi @lat9 and @swguy,

While testing recent Super Orders updates, I’ve encountered a fatal error during batch printing of invoices or packing slips and would appreciate some guidance.

Issue Summary

When batch-printing multiple invoices or packing slips, a fatal error occurs once the second order is processed:

PHP Fatal error: Cannot declare class currencies, because the name is already in use
in /includes/classes/currencies.php on line 18

Root Cause

Batch printing loops through multiple order IDs and repeatedly requires the same invoice/packing slip file:

foreach ($batch_order_numbers as $_order_number) {
  $_GET['oID'] = $_order_number;
  require $target_file;  // invoice.php or packingslip.php
}

Both invoice.php and packingslip.php contain:

require('includes/application_top.php');
...
$currencies = new currencies();

On the first iteration, application_top.php loads normally and includes the currencies class.
On subsequent iterations, require causes application_top.php to execute again, attempting to
re-declare the currencies class and resulting in the fatal error.

Proposed Solutions

Solution 1: Notifier-Based Approach (Observer Pattern)

In invoice.php and packingslip.php:

require('includes/application_top.php');

$currencies_already_initialized = false;
$zco_notifier->notify(
  'NOTIFY_ADMIN_INVOICE_CURRENCIES_INIT',
  $currencies_already_initialized
);

if (
  !$currencies_already_initialized &&
  (!isset($currencies) || !is_object($currencies))
) {
  $currencies = new currencies();
}

Observer example:

$zco_notifier->attach(
  $this,
  'NOTIFY_ADMIN_INVOICE_CURRENCIES_INIT',
  function (&$currencies_already_initialized) {
    global $currencies;
    if (isset($currencies) && is_object($currencies)) {
      $currencies_already_initialized = true;
    }
  }
);

Solution 2: Explicit require_once for currencies Class

require('includes/application_top.php');
require_once(DIR_WS_CLASSES . 'currencies.php');
$currencies = new currencies();

Question

From a core-development perspective, which approach would be preferred for addressing this
batch printing issue: a notifier-based solution aligned with Zen Cart’s observer pattern, or a
simpler require_once safeguard?

Thanks for your guidance.

[strelitzia]

There was an error in this section

require('includes/application_top.php');
require_once(DIR_WS_CLASSES . 'currencies.php');
$currencies = new currencies();

It would probably need to be more like

require('includes/application_top.php');
 
// Ensure currencies class is available (use require_once to prevent redeclaration)
require_once(DIR_WS_CLASSES . 'currencies.php');
// $currencies = new currencies();

[strelitzia]

Having reviewed this further, would it be workable to attach an observer to NOTIFIER_CURRENCIES_CONSTRUCT_END that treats the first currencies instance as canonical, and on subsequent instantiations copies state from the original instance so repeated new currencies() calls are effectively idempotent.

[retched]

There was an error in this section

require('includes/application_top.php');
require_once(DIR_WS_CLASSES . 'currencies.php');
$currencies = new currencies();

It would probably need to be more like

require('includes/application_top.php');
 
// Ensure currencies class is available (use require_once to prevent redeclaration)
require_once(DIR_WS_CLASSES . 'currencies.php');
// $currencies = new currencies();

You can leave the $currencies = new currencies line alone as all it does is just refresh it with the same data it already has. Messing around with the batch pages, I had the same bandaid fix as well. (Plus, a few more to get the page breaks to work too.)

[swguy]

Where does the update stand? I have customers who still use Super Batch Print. Thanks!

[swguy]

Any updates on this plugin?