product_status - can it be more flexible?

[Kofod95]

I'm wondering if it is possible (or even if it might become so in the future) to have more options for product status than '0' and '1'? Or rather, I'm wondering if it is possible to add to this code in admin/categories.php lines 942-946:

Code: Select all

                  <?=
                  ($p->get('status') == '1')
                  ? '<i class="fas fa-check-circle text-success"></i> <a href="' . tep_href_link('categories.php', 'action=setflag&flag=0&pID=' . $p->get('id') . '&cPath=' . $cPath) . '"><i class="fas fa-times-circle text-muted"></i></a>'
                  : '<a href="' . tep_href_link('categories.php', 'action=setflag&flag=1&pID=' . $p->get('id') . '&cPath=' . $cPath) . '"><i class="fas fa-check-circle text-muted"></i></a>  <i class="fas fa-times-circle text-danger"></i>'
                  ?>

without doing it in core?

The reason is, that a shop I help out represents stock that is in remote storage, and thus have a longer estimated shipping time. Sometimes stock in the actual store is sold out, while there is still stock at the remote warehouse, meaning the product could be turned from active ('1') to active in remote storage ('2') instead of inactive ('0') and impossible for the customers to buy.
Another reason is, that the same shop has a physical store, but no way of keeping track of the actual stock. Instead of going into the product-edit each time a product is sold, it would be nice to just click on of those small status-buttons, making it temporarily sold out ('3'), which on front end would be targeted to remove the buy-buttons, and add opacity to the image.

This is already done on the webshop, but by abusing the core-code of 1.0.4.0. Thus, I'm wondering if this is possible with hooks or other magic, and if there is any reason for only having two options for the product status?

//Daniel

[ecartz]

You're thinking of this incorrectly.

Instead of abusing status (show or don't show a product), add new columns for the new things you want to save. Then change the interface to change all the columns. So status still means show/not and a separate column means available/not when shown. If you want to integrate those in the interface, that's fine. But you shouldn't try to integrate those at the data level, because they're orthogonal questions.

If you change what product status means, you have to change it everywhere (because some places you want 2 to behave like 1 and in others 0). But if you add new columns, you only have to change where the new column has impact. For example, marking as temporarily out of stock might only affect the buttons and attempted purchases.

For now, you'd have to make a new page to edit this. It may be possible to hook it in the catalog page eventually, but I wouldn't expect that in the 1.0.8.* series (because I know the things that I have left to accomplish and that's not on the list). As of 1.0.8.5, the new page could use the same processing as the current page for the things that are not about setting the status flag.

[Kofod95]

Thank you for answering, suggesting and clarifying!

I will make it with a new column, one question though; I was once told that adding too much to one table would slow things down, and thus I thought (but I don't know much) that it would be better to use a column already there. Is that something that I shouldn't worry about?

Just for my couriosity; would expanding the use of the product_status in core be a lot of work or even impossible? I'm not expecting it to be done, but I think it would be useful in more scenarios than I described, so if it's rather easy to do, there is a suggestion for 1.0.9-series or further out

//Daniel

[ecartz]

It is in general considered a bad idea to try to put multiple pieces of data into one column. In this case, you are talking about three different questions:

1. Should the product be listed for potential customers?
2. Should the product be buyable?
3. Where is the product stored?

There are two basic problems with lots of data in one table. One, the data may be too big.

Two, the number of columns might be large, which can cause indexing problems. However, putting multiple pieces of data in the same column also causes indexing problems. The general suggestion when that happens is to split off the columns into their own table. Of course that can cause its own problems as joining multiple tables can be expensive.

In any case, when people start talking about limiting columns, they tend to give guidelines like "less than a hundred". The fourteen in the products table is well below that, much less the MySQL limit of 4096. And if you are concerned about it, you can always put the data in a separate table. That might be better for "Where is the product stored" regardless. Because while you are currently talking about two potential storage places, it's not hard to envision circumstances where that increases.

I think that a more complicated status column would be a bad design, so I am unlikely to look at it as something to put in core.

[Kofod95]

Thank you so much for taking the time to educate me on this!
I think I understand, and will look at a solution that will fit the needs I have, and hopefully find a way to make it flexible enough to support multiple storage spaces, so it potentially can be useful for other people as well.

Thank you also for satisfying my couriosity regarding core.

//Daniel