Disappearing Master Category ID, product name & product description

[kcb410]

Hello Everyone,

We're in the process of creating a few new products using the native copy or new product functions in Zen admin. When we use the new product function, the new product initially has a Product Master Category ID, we give it a name and type a product description and insert it. When you reopen the product the Product Master Category ID, product name and description are blank. When we use the copy function the same thing occurs.

The log file is generating the following error:

[13-Jun-2017 08:51:25 America/New_York] PHP Warning: reset() expects parameter 1 to be array, null given in XXXXX/includes/classes/object_info.php on line 29
[13-Jun-2017 08:51:25 America/New_York] PHP Warning: Variable passed to each() is not an array or object in XXXXX/includes/classes/object_info.php on line 30

We use the following addons:
Zen Lightbox, CSS/JSS Loader, Sitemap XML, COWOA, Google Mapinator, TPP, Google Analytics, Short Product Descriptions, Apsona, Snapshot and Maibeez

Can anyone point me in the right direction to correct this?

Any help is appreciated. Thanks.

[mc12345678]

Some helpful additional questions to be answered: When did this last work? What changed between then and now? Is this a new upgrade or an existing store? From what version was it last upgraded?

Can you identify while stepping through the transaction of at which point the error is generated? Ie. first display the "blank" page to enter new data. Check/refresh logs. Then, enter information, and move to the review step, check/refresh logs. Then insert the product, check/refresh logs.

Are you also able/willing to check/test an update of a product to see if it ends up suffering the same consequence? (Mind you, you would want to try this on a backup of the site and/or make a backup before doing so.)

Also, PHP version?

[kcb410]

Hello mc12345678,

Thank you for the reply. I've tried to answer your questions below.

Some helpful additional questions to be answered: When did this last work? What changed between then and now? Is this a new upgrade or an existing store? From what version was it last upgraded?

It's been quite some time since I copied or created a new product so I'm unsure when this last worked. There's been no changes since the last update other than Zens occasional patches. The store was started 2008 , here's the upgrade path:

v1.5.4 [2015-01-28 12:57:58] (Version Update 1.5.3->1.5.4)
v1.5.3 [2015-01-28 12:57:58] (Version Update 1.5.2->1.5.3)
v1.5.2 [2015-01-28 12:57:58] (Version Update 1.5.1->1.5.2)
v1.5.1 [2015-01-28 12:57:56] (Version Update 1.5.0->1.5.1)
v1.5.0 [2012-12-03 16:52:07] (Version Update 1.3.9->1.5.0)
v1.3.9d [2010-06-28 00:54:17] (Version Update 1.3.8->1.3.9d)
v1.3.8 [2008-12-05 15:49:32] (Version Update 1.3.7->1.3.8)
v1.3.7 [2008-12-05 15:49:10] (Version Update 1.3.6->1.3.7)
v1.3.6 [2008-12-05 15:48:16] (Version Update 1.3.5->1.3.6)
v1.3.5 [2008-12-05 15:47:17] (Version Update 1.3.0.2->1.3.5)
v1.3.0.2 [2008-11-07 22:35:35] (Fresh Installation)

We have 155e running on a dev and it doesn't happen on that version.

Can you identify while stepping through the transaction of at which point the error is generated? Ie. first display the "blank" page to enter new data. Check/refresh logs. Then, enter information, and move to the review step, check/refresh logs. Then insert the product, check/refresh logs.

When we use the new product function, the new product initially has a Product Master Category ID, we give it a name and type a product description as shown below.



Click Preview and the info is there.



Click Insert and it saves the new product.



Click the product we just created and it's gone.

Are you also able/willing to check/test an update of a product to see if it ends up suffering the same consequence? (Mind you, you would want to try this on a backup of the site and/or make a backup before doing so.)
Also, PHP version?

This problem doesn't occur when editing an existing product, we can open a product change text, save it and everything remains.

The PHP Version is: 5.6.30

[mc12345678]

Copying of what product was attempted?
Was it a newly created product or was it one that had already existed?

[kcb410]

Copying of what product was attempted?
Was it a newly created product or was it one that had already existed?

It happens if you copy a live, existing product and if you create a new one.

[mc12345678]

Here's my thoughts on this and a little additional "testing" to confirm "operation".

Attempt to generate a new product. Step to the review screen.
From there select the back button in the window (not the browser) and verify that the information that had been entered remains.

If so, my thought is that there is an issue with admin/includes/modules/update_product.php within one or both of the sections that include 'insert_product' as an action comparison (or data as related before that which would be processed within that band of code). Meaning, that somehow in this process, data to be entered into the database becomes/became misaligned. Would suggest comparing the contents of that file with a copy from a clean install.

And based on the recent notification of occurring with new or existing product, would suggest review of the file admin/includes/modules/copy_to_confirm.php.

Now, it was said above that with a ZC 1.5.5 install, this problem is not occurring; however, is that with a copy of the existing database or a new one?

It could also be an issue of "some sort" with the database, though I would first try to track down the differences in files, particularly in the admin/includes/modules folder as related to a clean install...

[kcb410]

Here's my thoughts on this and a little additional "testing" to confirm "operation".

Attempt to generate a new product. Step to the review screen.
From there select the back button in the window (not the browser) and verify that the information that had been entered remains.

If so, my thought is that there is an issue with admin/includes/modules/update_product.php within one or both of the sections that include 'insert_product' as an action comparison (or data as related before that which would be processed within that band of code). Meaning, that somehow in this process, data to be entered into the database becomes/became misaligned. Would suggest comparing the contents of that file with a copy from a clean install.

And based on the recent notification of occurring with new or existing product, would suggest review of the file admin/includes/modules/copy_to_confirm.php.

Now, it was said above that with a ZC 1.5.5 install, this problem is not occurring; however, is that with a copy of the existing database or a new one?

It could also be an issue of "some sort" with the database, though I would first try to track down the differences in files, particularly in the admin/includes/modules folder as related to a clean install...

I've created a new product and selected the back button and the info remains.

The Z155 install uses a copy of the existing database.

I'll do a comparison of my existing admin/includes/modules/update_product.php and admin/includes/modules/copy_to_confirm.php to a clean version of the 154 files.

Thank you for your help.

[mc12345678]

I've created a new product and selected the back button and the info remains.

The Z155 install uses a copy of the existing database.

I'll do a comparison of my existing admin/includes/modules/update_product.php and admin/includes/modules/copy_to_confirm.php to a clean version of the 154 files.

Thank you for your help.

Well, the use of the existing (copy of) database and it's successful operation definitely rules out the database as an issue, so it's something related to the files. Perhaps one of the "updates"? Though I can't think of anything that has been posted that would affect this area of the code.

The only other common file that seems to relate to these two issues is the admin/categories.php file.

That said, it still would be good to know during which step of the entire process generated the error log that you posted about earlier. I'm thinking that it is when attempting to access one of the "new" products as a result of the files not being able to successfully pull data from the database (because it didn't get stored "correctly".)

[kcb410]

Well, the use of the existing (copy of) database and it's successful operation definitely rules out the database as an issue, so it's something related to the files. Perhaps one of the "updates"? Though I can't think of anything that has been posted that would affect this area of the code.

The only other common file that seems to relate to these two issues is the admin/categories.php file.

That said, it still would be good to know during which step of the entire process generated the error log that you posted about earlier. I'm thinking that it is when attempting to access one of the "new" products as a result of the files not being able to successfully pull data from the database (because it didn't get stored "correctly".)

Thanks for the reply.

The existing admin/includes/modules/update_product.php and admin/includes/modules/copy_to_confirm.php are identical to a clean version of the 154 files.

The admin/categories.php has been altered by the Shorter Descriptions for Categories Plugin. I replaced the admin/categories.php with an original from 154 and it still generates the same error log referenced earlier.

[mc12345678]

Thanks for the reply.

The existing admin/includes/modules/update_product.php and admin/includes/modules/copy_to_confirm.php are identical to a clean version of the 154 files.

The admin/categories.php has been altered by the Shorter Descriptions for Categories Plugin. I replaced the admin/categories.php with an original from 154 and it still generates the same error log referenced earlier.

Which operation causes the generation of the error?