products_date_available no longer NULL

DigiBooks:

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

Yeah, it seemed like the layout of product listing was about what I was thinking. The added "feature" would offer a middle ground so that if the product were available to you (but not to others/public) then the default ZC code could take over...

As to the "reverse" logic, the $upcoming_date_check variable is not shown above as what it equals... That should be something either just above that series of checks or in the applicable pages directory... Old friend of developers toolkit ought to show where it is assigned it's value... An important thing to notice which it seems that you have applied is that in the assignment part (when true) the $upcoming_date_check variable is not used which leads me to think/believe that it is not solely the value of the future date and therefore is a bit of a source to your consternation...

Once you come to realize how similar php is to all the other languages you referenced, while some of the "mystery" will go away, it should be significantly easier for you to operate... I mean yeah it's uniquely designed for what it is used for, but pick up a php book and you'll see the same old schtick... hello world, for loops, while loops, if structure, etc... The rest is just different ways of having "containers", there's a lot more use of classes than perhaps some of the "older" code, but really... Not too much to handle if you can do the others. :)

As always I appreciate all your help. I did load a fresh install that I will leave to play around with and see if I can recode the Expected Products section correctly as I learn more.

I think the problem is that whist we are a little different to other "shops" I still don't believe that any system should have an automatic right to clear expected dates.

For instance, say, a clothes shop might say something will be in stock on a particlar date and once past reverts to saying that it is in stock - but the stock may have been delayed and not arrived and therefore cannot be supplied.

I think these decisions should be under the store owner's control. Maybe that is something that can be looked at in future releases :)

DigiBooks:

As always I appreciate all your help. I did load a fresh install that I will leave to play around with and see if I can recode the Expected Products section correctly as I learn more.

I think the problem is that whist we are a little different to other "shops" I still don't believe that any system should have an automatic right to clear expected dates.

For instance, say, a clothes shop might say something will be in stock on a particlar date and once past reverts to saying that it is in stock - but the stock may have been delayed and not arrived and therefore cannot be supplied.

I think these decisions should be under the store owner's control. Maybe that is something that can be looked at in future releases :)

First of all want to say I agree that there should be a way to prevent the auto-trigger of active status in absence of some outside trigger (in the case described above, receipt of material) and it has been requested in one way or another over time... There has also been discussion of turning off a product by date... Not everyone uses both or either, but that's also what plugins are about.

As to the thought of a product's availability versus it being "active" on the site, there's also the concept of pre-orders and well, the need (or lack of) controlling the ability to purchase upon it being in one's hands... Might be worth looking through the numbers to see 1) what is the history of never receiving a product, 2) what is the history of timeliness of delivery by an organization, etc.., 3) what is your product view history like and that over time? There may be ways that the store can increase income, by taking advantage of some of those facts from a business perspective.

The big thing though is that hardly can a product be put together that completely covers every aspect, every site owner straight out of the box, but having enough flexibility to shape it to the individual needs... Priceless..

Hi Guys, excuse me for butting in here, but in case you aren't aware mysql v5.6 introduced some changes to the way date fields and nulls are handled. Whether this is currently relevant to what is being discussed I don't know, but since there is mention of dates and nulls I feel its something to be aware of if an older version is currently being used (an update may break all that you are trying to achieve)

As for how the date fields are stored in the database, this is "fixed" . In other words, regardless of the date format used in the store (UK or US) this data needs to be converted to suit the mysql requirements (probably obvious to many, but easy to overlook)

I believe that internally mysql still saves the date/time as the number of seconds elapsed since 1970 (a bit of semi useless trivia). The reason being is that storing it this way makes it trivial to perform date related calculations (something not easily possible if they were stored as the strings (yyyy-mm-dd) that they are displayed as.

As I say, all quite probably irrelevant to the discussion at hand but the mysql compatibility/upgrade could be important for the future. The rest is just trivia to demonstrate how clever I am.<JOKE>

Cheers
RodG

mc12345678:

First of all want to say I agree that there should be a way to prevent the auto-trigger of active status in absence of some outside trigger (in the case described above, receipt of material) and it has been requested in one way or another over time... There has also been discussion of turning off a product by date... Not everyone uses both or either, but that's also what plugins are about.

As to the thought of a product's availability versus it being "active" on the site, there's also the concept of pre-orders and well, the need (or lack of) controlling the ability to purchase upon it being in one's hands... Might be worth looking through the numbers to see 1) what is the history of never receiving a product, 2) what is the history of timeliness of delivery by an organization, etc.., 3) what is your product view history like and that over time? There may be ways that the store can increase income, by taking advantage of some of those facts from a business perspective.

The big thing though is that hardly can a product be put together that completely covers every aspect, every site owner straight out of the box, but having enough flexibility to shape it to the individual needs... Priceless..

I totally agree with everything you're saying .. I guess we're just trying to do something that could be considered outside of the box .. we'll find a wayto get around the problem and in the meantime we will use the vanilla install to see if we can identify where our testing of dates really should sit :)

Just another thing I find really odd .... even when the product is due to be in stock in the future on the product listing page it still gives the end user the option to write a review .. which I would have thought was not actually possible!!!

The whole concept of expected products is good .. the execution of these in the current versions of Zen-Cart is flawed which, I understand, as a not very-proficient PHP prgrammer I don't have the answers to but as a store-owner I am simply applying basic logic.

I don't know how many zen-cart users actually use the expected products but it is very useful and just needs some tweaking. We all know that there are many of you out there who put so many hours into developing an out of the box product for which I am sure we are all very grateful so please don't think I'm criticising .. I'm just making some observations :)

Two ways to look at it, fully agree and offer that I'm sure in certain cases the review could still be about a product that exists in "space" but not at this store.... Again something applicable to a store.

That said, seems like you have the logic available to apply to that area, the difference being doesn't matter if upcoming or delayed, it's not available for purchase if there is a date in the expected field for this store... Skip the ability to provide a review for that product. :)

Fyi, may want to dig a little more than just the initial display of the "button" on the product page like the actual page(s) associated once that button is selected. (For those "power users" that might navigate to that area and try to review that product.)

mc12345678:

Two ways to look at it, fully agree and offer that I'm sure in certain cases the review could still be about a product that exists in "space" but not at this store.... Again something applicable to a store.

That said, seems like you have the logic available to apply to that area, the difference being doesn't matter if upcoming or delayed, it's not available for purchase if there is a date in the expected field for this store... Skip the ability to provide a review for that product. :)

Fyi, may want to dig a little more than just the initial display of the "button" on the product page like the actual page(s) associated once that button is selected. (For those "power users" that might navigate to that area and try to review that product.)

I'm building a patch for our site to remove the Write review and the bit that says that the product was added to the catalog on the date we added the expected book as these are irrelevant at this stage .. later I will attempt to change the added to catalog date to the same date that we physically remove the expected date and the book goes live.

Again I know these patches are not ideal which is why I will use the vanilla install to see if I can improve my PHP knowledge and place the coding correctly in the right module.

For our site logic has to be the key element ... if a book has not actually been published then there shouldn't be any "power users" who have read it because it doesn't physically exist in any shape or form and therefore cannot be reviewed.