products_date_available no longer NULL

[DigiBooks]

Hi all

When I checked the Products Expected in Admin I found around 2,700 books being listed when in fact there are only 5.

I've made the changes in the FAQ to change the display of US date format to UK date format in both the catalog english.php and the admin english.php and I have reset the products_date_available column to NULL for all records:

I then trialled adding a new record with no date expected date. In the MySQl database the products_date_available displays as:

0000:00:00 00:00:00

which from what I have read means that whatever date is being handled does not conform to the correct date format for the database and therefore is not set to NULL. The new record shows as a product in the Products Expected list even though it's not.

After I enter a record with an expected date (using the calendar selection - eg. 23 Mar 2016) when I edit the record that date shows in the Admin edit field as 2016-23-03 - so still in US format,

I am struggling to find where the column is populated with the zeroes instead of a NULL value.

Can anyone point me to where I should be looking please?

From the count in the database the first 8,000-odd records had a NULL value (v1.5.0) with the remainder being zeros (from v1.5.3 onwards).


Thanks

[DigiBooks]

Ok scrap the bit about the date displaying wrong in Admin after entering an Expected date - that is now working.

What I have found though is that if after setting the whole column to NULL you then amend an existing record it saves the zeroes back to products_date_available instead of leaving it has NULL ... this therefore forces that book to be listed in the Admin Products Expected listing.

I'm guessing therefore that something has changed somewhere in the update_product.php on the later versions of Zen-Cart becuase under v1.5.0 it left it as NULL.

Just cannot figure out where that change is taking place though :/

[DigiBooks]

The edited Book now shows 0000-00-00 in the Exoected date field when editing the record and under the Products Expected Listing it shows a date of 30/11/2036

[mc12345678]

So the default install has that field marked as NULL, so it would seem that something about the other changes performed is causing your issue... As to the date way out in the future like that, that's what happens in PHP wth a date of 0000-00-00...

[DigiBooks]

So the default install has that field marked as NULL, so it would seem that something about the other changes performed is causing your issue... As to the date way out in the future like that, that's what happens in PHP wth a date of 0000-00-00...

From the time I started using v1.5.3 and then copied the database over and updated it to v1.5.4 I hadn't picked up that all new records were populating that field with all zeroes.. I have reset all the the records to NULL using an SQL query. So when I then edit any record and save it back to the database it changes NULL to the zeroes again.

I've looked through quite a few of what I think are the relevant PHP files in Admin but cannot see anywhere where it could be doing that...

[mc12345678]

From the time I started using v1.5.3 and then copied the database over and updated it to v1.5.4 I hadn't picked up that all new records were populating that field with all zeroes.. I have reset all the the records to NULL using an SQL query. So when I then edit any record and save it back to the database it changes NULL to the zeroes again.

I've looked through quite a few of what I think are the relevant PHP files in Admin but cannot see anywhere where it could be doing that...

Already mentioned update_info (for the product type of your merch, there's also collect_info which preps the data for display... How do all of these product type files differ from a vanilla install? What product type is in question? Have you tried this operation using a different product type to see how it behaves? (Sort of like using a different template when troubleshooting display issues...)

[DigiBooks]

I have come across this line in admin/includes/unctions/general.php:

return preg_replace('/2037$/', $year, date(DATE_FORMAT, mktime($hour, $minute, $second, $month, $day, 2037)));

which comes with the standard installation but I'm not sure why it's there or what it means!

[mc12345678]

I have come across this line in admin/includes/unctions/general.php:

return preg_replace('/2037$/', $year, date(DATE_FORMAT, mktime($hour, $minute, $second, $month, $day, 2037)));

which comes with the standard installation but I'm not sure why it's there or what it means!

Allows a date beyond the php cutoff... There were some in the last year that needed to be able to address dates greater than 21 years away. That will take the year 2037 out of the "string" and substitute the applicable date if you understand it correctly...

[DigiBooks]

Already mentioned update_info (for the product type of your merch, there's also collect_info which preps the data for display... How do all of these product type files differ from a vanilla install? What product type is in question? Have you tried this operation using a different product type to see how it behaves? (Sort of like using a different template when troubleshooting display issues...)

Ok Products General is the norm - that's putting the zeroes in - Documents General is putting NULL into the database

[mc12345678]

Ok Products General is the norm - that's putting the zeroes in - Documents General is putting NULL into the database

So, something is different about the files for the product than product_document... And more than likely that difference may be seen by comparing your files against a vanilla set... There's not many files to compare in that sub-folder...