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

VERSION 210 php 8.3 getting this error when deleting a payment

[17-Apr-2025 22:53:32 UTC] Request URI: /admin/index.php?cmd=super_payments&oID=11504&payment_mode=payment&index=175&action=delete, IP address: 35.139.226.29
--> PHP Fatal error: Uncaught TypeError: sizeof(): Argument #1 ($value) must be of type Countable|array, false given in /admin/super_payments.php:456
Stack trace:
#0 /admin/index.php(16): require()
#1 {main}
thrown in /admin/super_payments.php on line 456.

[17-Apr-2025 22:53:32 UTC] Request URI: /admin/index.php?cmd=super_payments&oID=11504&payment_mode=payment&index=175&action=delete, IP address: 35.139.226.29
--> PHP Fatal error: Uncaught TypeError: sizeof(): Argument #1 ($value) must be of type Countable|array, false given in /admin/super_payments.php:456
Stack trace:
#0 /admin/index.php(16): require()
#1 {main}
thrown in /admin/super_payments.php on line 456.

how would i fix this

VERSION 210 php 8.3 getting this error when deleting a payment

[17-Apr-2025 22:53:32 UTC] Request URI: /admin/index.php?cmd=super_payments&oID=11504&payment_mode=payment&index=175&action=delete, IP address: 35.139.226.29
--> PHP Fatal error: Uncaught TypeError: sizeof(): Argument #1 ($value) must be of type Countable|array, false given in /admin/super_payments.php:456
Stack trace:
#0 /admin/index.php(16): require()
#1 {main}
thrown in /admin/super_payments.php on line 456.

[17-Apr-2025 22:53:32 UTC] Request URI: /admin/index.php?cmd=super_payments&oID=11504&payment_mode=payment&index=175&action=delete, IP address: 35.139.226.29
--> PHP Fatal error: Uncaught TypeError: sizeof(): Argument #1 ($value) must be of type Countable|array, false given in /admin/super_payments.php:456
Stack trace:
#0 /admin/index.php(16): require()
#1 {main}
thrown in /admin/super_payments.php on line 456.

Anyone know whats going on here

jimmie:

VERSION 210 php 8.3 getting this error when deleting a payment

[17-Apr-2025 22:53:32 UTC] Request URI: /admin/index.php?cmd=super_payments&oID=11504&payment_mode=payment&index=175&action=delete, IP address: 35.139.226.29
--> PHP Fatal error: Uncaught TypeError: sizeof(): Argument #1 ($value) must be of type Countable|array, false given in /admin/super_payments.php:456
Stack trace:
#0 /admin/index.php(16): require()
#1 {main}
thrown in /admin/super_payments.php on line 456.

[17-Apr-2025 22:53:32 UTC] Request URI: /admin/index.php?cmd=super_payments&oID=11504&payment_mode=payment&index=175&action=delete, IP address: 35.139.226.29
--> PHP Fatal error: Uncaught TypeError: sizeof(): Argument #1 ($value) must be of type Countable|array, false given in /admin/super_payments.php:456
Stack trace:
#0 /admin/index.php(16): require()
#1 {main}
thrown in /admin/super_payments.php on line 456.

> Anyone know whats going on here

fixed
changed line to 
for ($a = 0; $a < sizeof((array)$so->refund); $a++) {

jimmie:

fixed
changed line to
for ($a = 0; $a < sizeof((array)$so->refund); $a++) {

there's a lot that needs to get changed with that, including the extra functions. At some point, I'll try to submit an update to the module for 8.4 but I'm trying to get as much of it to be observers than anything.

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.

strelitzia:

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.

Oh thank lord, I was in the middle of trying to modernize it with 2.1.0. Can't wait to see what you have!

strelitzia:

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!

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

lat9:

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

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.

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.

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();

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.

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();

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

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

Any updates on this plugin?

Hi,

Sorry for the delay in replying. Things have been somewhat hectic.

The plugin was almost ready, but I ran into a couple of issues that were blockers for it being encapsulated. I intend to pick this up again within the next few days to try and get it over the line. I'll be sure to let you know as soon as I have a beta version ready for testing.