products_date_available no longer NULL

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

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 :/

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

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

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

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

DigiBooks:

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

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!

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!

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:

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

DigiBooks:

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:

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:

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

mc12345678:

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:

So check admin/includes/modules/document_general files and admin/includes/modules/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 :)

Sorry I think these are the two folders you meant?

DigiBooks:

Sorry I think these are the two folders you meant?

Those last two would be my suggestion though I would start with product, because document_general is working as expected... The other thing, do you have any plugins installed that possibly modify the number of fields in the products table or display "extra" fields on the data input screen?

mc12345678:

Those last two would be my suggestion though I would start with product, because document_general is working as expected... The other thing, do you have any plugins installed that possibly modify the number of fields in the products table or display "extra" fields on the data input screen?

Thank you for pointing me in the right direction ... with your advice and trusty old Winmerge I found one difference in admin/includes/modules/preview_info.php

Instead of:

  if ($pInfo->products_date_available > date('Y-m-d')) {

it read:

  if (true || $pInfo->products_date_available > date('Y-m-d')) {

Now I remember changing this because we didn't want our site to say books will be available on a specific date but we use it as an EXPECTED date (they don't necessarily publish on time).

So I reset it to the vanilla setting and all seemed to work. The other thing we don't want is when a book goes past it's due date that it automatically gets set to available (products_date_available set to NULL). So I changed it back and all seemed OK - no zeroes in the field but the past due date was reset to null.

My conclusion is that I didn't make that (true || ... statement correct in the first instance.

So digging further I find that the field is reset in admin/includes/modules/update_product.php where it states:

$products_date_available = (date('Y-m-d') < $products_date_available) ? $products_date_available : 'null';

so I have replaced this with:

// Stop removing past due by dates
// $products_date_available = (date('Y-m-d') < $products_date_available) ? $products_date_available : 'null';
if ($products_date_available == '') { $products_date_available = 'null'; }
//

That works a treat - no more zeroes in the database and past due dates are retained until we manually remove them!

All I have to do now is find the product info page and stop any past due book from allowing Add To Cart,

Thank you for your patience and assistance to someone to whom certain PHP statements are actually NOT logical!!!!

Quite welcome. Whatcha mean though about having to find the product info page? The "start" of it is the header in includes/modules/pages/product_info then the chase starts with the applicable tpl file. :)

Don't forget tools such as the developer's toolkt, the resulting web page source, etc... :)

mc12345678:

Quite welcome. Whatcha mean though about having to find the product info page? The "start" of it is the header in includes/modules/pages/product_info then the chase starts with the applicable tpl file. :)

Don't forget tools such as the developer's toolkt, the resulting web page source, etc... :)

Found the page I need .. just need to work out where to switch off Add To Cart for past Due Date books.

Now forgive me if this seems wrong but from what I can gather certain PHP statments are totally REVERSE LOGIC!!!

OK I was brought up on BASIC, FORTRAN, PERL etc...... so when I see a statement that says:

case ($zc_current_date > 0 && $zc_current_date >= $upcoming_date_check):
$return_button = 'AVAILABLE: ' . zen_date_short($button_check->fields['products_date_available']);
break;

I interpret that as: Today is not zero and Today is greater than or equal to the Expected date therefore it means that the Expected date has past and should not be showing the product as Available on a particular date.

then I add the statement:

case ($zc_current_date > 0 && $zc_current_date <= $upcoming_date_check):
$return_button = 'OVERDUE: ' . zen_date_short($button_check->fields['products_date_available']);
break;

which to me means: Today is not zero but is less than or equal to the Expected date and should not, therefore, show the product as Overdue.

What am I missing, please?

To me this is totally (at a logical level) in reverse because it actually works .. but in reverse.

I'm guessing there is something in PHP that I have yet to grasp?????

So it's not php, but the programmer that put that series of statements together... That code isn't part of the base install as I couldn't find it... The important part in that section is understanding what the value of $upcoming_date_check is based on... The series of case statements will be evaluated from top to bottom, typically whichever is true first is executed...

The only thing I see about the added code is that basically both are true if they are equal, which means that whichever is first would be the one to "win"...

You know, since this has all started, I've been trying to think of a way to make some of this easier for you. Right now you're process is, apply an expected due date, leave the date alone until the product arrives at which point you have to manually go and clear that date... This is a smidge of an override of the way ZC works as a default... The problem with this override is what if you have say an event or something that you "refuse" to allow being sold until a certain date (publisher prevents release until for example).... Now though you are chomping at the bit and have to manually login at "midnight" to do that mod...

If though you had an addtional piece of data, say an on/off switch that when off, then all this additional logic applied, but when on (default for example) then the date auto-cleared and the product was "magically" available, it seems like it would make the best of both worlds...

Part of the reason I suggest this also, is because it could be relatively easy to "add" to the cart. Check this thread out: https://www.zen-cart.com/showthread.php?217954-Flag-discontinued-products

The code provided there (though on a todo list for me to take a little further) would offer a "button" that could be clicked from the admin products listing, the effect of being a controller for using the modified code in one state and the default code in the other... Anyways, the todo part is to incorporate it into the product_info sections as well... Rather than just on the products listing page.

mc12345678:

You know, since this has all started, I've been trying to think of a way to make some of this easier for you. Right now you're process is, apply an expected due date, leave the date alone until the product arrives at which point you have to manually go and clear that date... This is a smidge of an override of the way ZC works as a default... The problem with this override is what if you have say an event or something that you "refuse" to allow being sold until a certain date (publisher prevents release until for example).... Now though you are chomping at the bit and have to manually login at "midnight" to do that mod...

If though you had an addtional piece of data, say an on/off switch that when off, then all this additional logic applied, but when on (default for example) then the date auto-cleared and the product was "magically" available, it seems like it would make the best of both worlds...

Part of the reason I suggest this also, is because it could be relatively easy to "add" to the cart. Check this thread out: https://www.zen-cart.com/showthread.php?217954-Flag-discontinued-products

The code provided there (though on a todo list for me to take a little further) would offer a "button" that could be clicked from the admin products listing, the effect of being a controller for using the modified code in one state and the default code in the other... Anyways, the todo part is to incorporate it into the product_info sections as well... Rather than just on the products listing page.

Thanks on both points .. firstly a former programmer seems to have added this reverse logic (which works) and I'm still trying to get my head around !!!!!

On your second point a switch would be the answer (I will check out the link you sent shortly).

I guess we are operating slightly differently to the norm so just to clarify:

Book 1 and Book 2 in THE TRILOGY are available, loaded on site and downloadable by subscribed members.

Book 3 is still being written and will be published in 9 months time .. but we have a description and often a book cover that we can load as 'teaser' with an Expected publication date of, say 1st September 2016. Book fails to publish by that date so under normal Zen-Cart rules it disappears from Expected Books because the date is set back to Null. As users we suddenly lose the teaser .. as Admins we no longer get reminded to seek Book 3 out - hence the reason we need to see it as Overdue.

When Book 3 is eventually published us Admins can load it for the members and remove the Expected Date and it all goes live.

Nothing can magically appear as it has to be manually made live in the catalog as a downloadable file.

Hopefully our simplistic method helps with what we're trying to achieve.

And thanks again :)