Page 1 of 3

Issue with new orders

Posted: Thu Sep 07, 2023 7:14 pm
by Phil
Hello, am running phoenixcart 1.0.8.20, PHP 7.4, upgraded from an older phoenixcart version installed about a year ago.
I migrated an old oscommerce 2.3.4 store, by importing separate tables from the old database of products/customers/orders/addresses, etc.

Everything seemed to work fine, all old orders and customers show up in the admin panel, products, categories all look great.

The issue I am having is with some new orders.. Some orders appear in the admin panel with an empty customer name (but invoice/packing slip has the Shipping/Billing address populated). Seems that the software somehow allows checkout, but it has trouble associating the order with a customer's default name/address? Maybe newly created customers?

Seems the "orders" table does not populate some of the columns: customers_name, customers_street_address, customers_city, customers_postcode, customers_state, customers_country, phone, email, customers_address_format_id...
Still, other columns like the "delivery_name"... and "billing_name"... get populated ok. The "customers_id" column is correct as well.

If I try to register a new customer and order all seems well, my customer name shows in the "Customer" column in the admin panel just fine, so I can't reproduce the issue on my end. Still, there are multiple orders from different customers with the same blank customer column issue.

Here are the php warnings that I get around the time of those orders with an empty customer column in the admin panel:

Code: Select all

[07-Sep-2023 08:06:53 America/New_York] PHP Warning:  array_filter() expects parameter 1 to be array, null given in /store/includes/system/versioned/1.0.5.1/customer.php on line 52
[07-Sep-2023 08:07:01 America/New_York] PHP Warning:  array_filter() expects parameter 1 to be array, null given in /store/includes/system/versioned/1.0.5.1/customer.php on line 52
[07-Sep-2023 08:07:02 America/New_York] PHP Warning:  array_filter() expects parameter 1 to be array, null given in /store/includes/system/versioned/1.0.5.1/customer.php on line 52
[07-Sep-2023 08:08:06 America/New_York] PHP Warning:  array_filter() expects parameter 1 to be array, null given in /store/includes/system/versioned/1.0.5.1/customer.php on line 52
[07-Sep-2023 08:08:07 America/New_York] PHP Notice:  Undefined index: street_address in /store/includes/modules/customer_data/cd_traditional_address.php on line 94
[07-Sep-2023 08:08:07 America/New_York] PHP Notice:  Undefined index: city in /store/includes/modules/customer_data/cd_traditional_address.php on line 96
[07-Sep-2023 08:08:07 America/New_York] PHP Notice:  Undefined index: postcode in /store/includes/modules/customer_data/cd_traditional_address.php on line 109
[07-Sep-2023 08:08:07 America/New_York] PHP Warning:  array_filter() expects parameter 1 to be array, null given in /store/includes/system/versioned/1.0.5.1/customer.php on line 52
[07-Sep-2023 08:08:21 America/New_York] PHP Warning:  array_filter() expects parameter 1 to be array, null given in /store/includes/system/versioned/1.0.5.1/customer.php on line 52
The most common/obvious being warning about an empty array passed to array_filter() in customer.php on line 52.

Can someone point me in the right direction how to troubleshoot this issue? Any other info I can provide?

Thanks in advance.

Re: Issue with new orders

Posted: Fri Sep 08, 2023 12:14 pm
by burt
The error seems to do with Customers Address Book.
Did you bring the 2.3.4 address_book table into the 1.0.8.20 ? Is it blank?
Do customer ID's in this table match up with the correct customers?

Re: Issue with new orders

Posted: Fri Sep 08, 2023 1:33 pm
by Phil
Hello Burt, thanks for trying to help.

I did bring in the adress_book table. IDs in the address_book match between the two databases, so do customers. New addresses are being created without a problem it seems. Customer IDs seem to match from the adress_book to the customers table as well.

The strange thing is the issue is intermittent (does not happen to all orders), and it probably happens during creating an order. The only empty fields are in the orders table, from "customers_name" to "customers_address_format" columns (including all columns in between), yet their billing/shipping addresses, their customers_id and everything else is populated.

Re: Issue with new orders

Posted: Fri Sep 08, 2023 2:02 pm
by Kofod95
Are they using the same payment method (if you use multiple) when it fails?
Which add-ons have you added?
If you run a test using the same country, state, address, shipping-method, payment-method and other selections (ot_modules, same type of products, shop as guest/create customer etc), can you get the error on yourself? You might not have to proceed to payment to find out, depending on what you use there.

//Daniel

//Daniel

Re: Issue with new orders

Posted: Fri Sep 08, 2023 2:15 pm
by burt
Please make a DUMP of your orders table and paste it here. Structure only NOT the data.

Re: Issue with new orders

Posted: Fri Sep 08, 2023 2:36 pm
by Phil
burt wrote: Fri Sep 08, 2023 2:15 pm Please make a DUMP of your orders table and paste it here. Structure only NOT the data.
Here it is:

Code: Select all

-- Host: localhost
-- Generation Time: Sep 08, 2023 at 10:32 AM
-- Server version: 10.4.20-MariaDB-log
-- PHP Version: 7.4.26

SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
START TRANSACTION;
SET time_zone = "+00:00";

--
-- Database: `p_____store`
--

-- --------------------------------------------------------

--
-- Table structure for table `orders`
--

CREATE TABLE `orders` (
  `orders_id` int(11) NOT NULL,
  `customers_id` int(11) NOT NULL,
  `customers_name` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `customers_company` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `customers_street_address` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `customers_suburb` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `customers_city` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `customers_postcode` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `customers_state` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `customers_country` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `customers_country_id` int(11) NOT NULL,
  `customers_telephone` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `customers_email_address` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `customers_address_format_id` int(5) NOT NULL,
  `delivery_name` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `delivery_company` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `delivery_street_address` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `delivery_suburb` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `delivery_city` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `delivery_postcode` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `delivery_state` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `delivery_country` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `delivery_country_id` int(11) NOT NULL,
  `delivery_address_format_id` int(5) NOT NULL,
  `billing_name` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `billing_company` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `billing_street_address` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `billing_suburb` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `billing_city` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `billing_postcode` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `billing_state` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `billing_country` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `billing_country_id` int(11) NOT NULL,
  `billing_address_format_id` int(5) NOT NULL,
  `payment_method` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `cc_type` varchar(20) COLLATE utf8_unicode_ci DEFAULT NULL,
  `cc_owner` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `cc_number` varchar(32) COLLATE utf8_unicode_ci DEFAULT NULL,
  `cc_expires` varchar(4) COLLATE utf8_unicode_ci DEFAULT NULL,
  `last_modified` datetime DEFAULT NULL,
  `date_purchased` datetime DEFAULT NULL,
  `orders_status` int(5) NOT NULL,
  `orders_date_finished` datetime DEFAULT NULL,
  `currency` char(3) COLLATE utf8_unicode_ci DEFAULT NULL,
  `currency_value` decimal(14,6) DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

--
-- Indexes for table `orders`
--
ALTER TABLE `orders`
  ADD PRIMARY KEY (`orders_id`),
  ADD KEY `idx_orders_customers_id` (`customers_id`);

Re: Issue with new orders

Posted: Fri Sep 08, 2023 2:47 pm
by Phil
Kofod95 wrote: Fri Sep 08, 2023 2:02 pm Are they using the same payment method (if you use multiple) when it fails?
Which add-ons have you added?
If you run a test using the same country, state, address, shipping-method, payment-method and other selections (ot_modules, same type of products, shop as guest/create customer etc), can you get the error on yourself? You might not have to proceed to payment to find out, depending on what you use there.

//Daniel

//Daniel
Addons I've added... Admin Top - Left menu toggle... Featured Products home page... Holiday Message... Paypal Standard... and an old one "JcM More New Themes Header Tags-V1.2"... It only creates some hooks to allow different color schemes.

Excellent point about trying to recreate the issue on my end..:
I have 4-5 orders with missing customer data, and a couple with full customer data since the migration. The orders with missing data have different shipping methods (I have two shipping modules, both use table shipping). The orders with missing info also seem to be independent of the two different payment methods (Paypal Standard, and a Check/Money order). I doubt it has to do with the payment method, as one of them (Check/Money order) is simple text presented to the customer.

I couldn't recreate the missing info error for myself, registered two new users, proceeded to the shipping/payment and the whole thing, that's why I am stumped. At this point I am thinking it has to do something with the full customer information (class/array) not getting to the shipping/payment pages, but I don't know how to troubleshoot it, especially if I can't recreate it on my end.

I went through the mysql log file and saw no errors, web server log file showed one of the customers with missing data was using Chrome under Windows 10, same as me. I tried creating a user while checking out, creating a user and adding addresses before checking out, tried with two different addresses (one in the US where most orders are, one outside).. Still couldn't recreate the problem.

We asked one of the customers with empty data if they experienced any issues over the phone, they said they didn't see anything wrong. We asked them to place the order again, they tried a couple of times and I have like 3 separate orders with the exact same behavior from them, missing Customer column in the admin panel, but populated shipping/sold to addresses in the invoice/packing slip. There are no special characters in the customer name or the address. The customer seems to have only one address entry in the address_book table.

The empty columns (or zero for integers) in the "orders" table are:
`customers_name`,
`customers_company`,
`customers_street_address` ,
`customers_suburb`,
`customers_city`,
`customers_postcode`,
`customers_state`,
`customers_country`,
`customers_country_id`,
`customers_telephone`,
`customers_email_address` ,
`customers_address_format_id`

Re: Issue with new orders

Posted: Fri Sep 08, 2023 4:14 pm
by Kofod95
Hmm..

It sounds like this goes fine: https://github.com/CE-PhoenixCart/Phoen ... _order.php

Suggesting that it is the $order Global that lacks something. Maybe something goes wrong here: https://github.com/CE-PhoenixCart/Phoen ... er.php#L89

I have no good ideas for what to try, sorry. I'll try thinking some more

//Daniel

Re: Issue with new orders

Posted: Fri Sep 08, 2023 4:51 pm
by 14Steve14
burt wrote: Fri Sep 08, 2023 12:14 pm The error seems to do with Customers Address Book.
Did you bring the 2.3.4 address_book table into the 1.0.8.20 ? Is it blank?
Do customer ID's in this table match up with the correct customers?
To follow on from this with another question.

When bringing the data across from the old database, did all the columns match, and did you go through every version upgrade to the database as there were many if I remember correctly? Some may not affect the orders or customer table though.

Also is the problem with new customers, or those who have already created an account on the older store version?

Re: Issue with new orders

Posted: Fri Sep 08, 2023 5:30 pm
by Phil
The first time I imported data was about a year ago just to test out the store, fix layout, check payment/shipping modules, etc. before going live. Recently I upgraded to the latest phoenixcart, then re-imported all tables from the old working store and went live. I am sure this time I imported just the data, without modifying table structure. I am fairly certain I did the same last winter when I originally installed phoenixcart, importing just data.

The problems with customers... I checked, and they seem to be old customers that existed in the old database and were brought over. (I do have two other orders also from old customers that do show the customers data fine).