products_date_available no longer NULL

[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]

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

[DigiBooks]

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

So check admin/includes/modules/document_general files and admin/includes/modules/document_product files against a fresh donwload is where I think you're advising me to check?

I know we haven't changed anything in these sections but it's a starting point :)

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

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

More specifically, somewhat working from the right first, create a date formatted as desired, but make it show the year 2037. Then the left part of the statement, replace 2037 with the part in the middle (the actual year that is being "displayed".) It has to do with bits and bytes etc... There are only so large of a number available. The time that is measured is like in milli seconds from some fixed point in "time". Once the largest number is met, it flips back around to the "beginning". So a little trickier is used. Get the parts of the date except the year, but force the year to be what is desired to be displayed by controlling the "solution". :)